Current Server Time: 02:43 (Central Europe)

#apertus IRC Channel Logs

2017/06/15

Timezone: UTC


01:09
antonio_
left the channel
01:26
BAndiT1983
changed nick to: BAndiT1983|away
03:17
RexOrCine
left the channel
04:12
aombk
left the channel
05:41
Rex0r
left the channel
05:42
Rex0r
joined the channel
05:49
champika_oO
joined the channel
06:48
champika_oO
left the channel
07:09
champika_oO
joined the channel
07:12
Bertl_zZ
changed nick to: Bertl
07:12
Bertl
morning folks!
07:13
champika_oO
Good Morning!
07:39
champika_oO
left the channel
08:12
pusle
joined the channel
08:48
pusle
left the channel
09:02
champika_oO
joined the channel
09:10
champika_oO
Bertl,
09:10
champika_oO
is it like this?
09:10
champika_oO
https://major.io/2010/12/14/mounting-a-raw-partition-file-made-with-dd-or-dd_rescue-in-linux/
09:11
champika_oO
I have tried with a lecture, but I couldn't still run the qemu
09:11
champika_oO
we tried to mount the .dd file, since it have 3 partitions, it can't be done
09:12
Bertl
mounting the .dd is trivial if you do what I suggested (i.e. load the loop module with max_part=8)
09:12
Bertl
but you can also use the loop offset, if you get it from the partition table
09:13
Bertl
(as shown in this article)
09:13
champika_oO
so directly I cant use this command? '$ qemu-system-arm beta_20170109.raw'
09:14
Bertl
you can, if qemu is able to boot from an SD card
09:14
Bertl
(which it should be)
09:16
champika_oO
ok, will keep trying :)
09:17
Bertl
I'll test it shortly and let you know ...
09:38
champika_oO
ok
09:49
champika_oO
So, what I tried was,
09:50
champika_oO
I first rename the beta_20170109.dd -> beta_20170109.raw
09:51
champika_oO
Then I enter `sudo rmmod loop0`
09:51
champika_oO
rmmod: ERROR: Module loop0 is not currently loaded
09:51
champika_oO
but when I enter 'modprobe loop max_part=8' it runs
09:54
BAndiT1983|away
changed nick to: BAndiT1983
09:56
Bertl
check that your kernel doesn't have loop compiled in
09:56
Bertl
(i.e. with modinfo loop)
09:56
champika_oO
modinfo: ERROR: Module loop not found.
09:56
BAndiT1983
champika_oO: have you looked at the script in the task ? -> https://lab.apertus.org/T737
09:58
BAndiT1983
my VM where i've tested QEMU is on another machine, so i can look it up later what my folder and latest script version look like
09:59
BAndiT1983
but if i remember correctly, some files have to be supplied externally, as QEMU has currently some trouble to get them from first partition
10:00
BAndiT1983
at least DTB and kernel have to be supplied, see the beginning of the QEMU start script
10:00
BAndiT1983
ah, and there is a note by me in the task -> "zImage (kernel) and .dtb (device tree) have to be supplied seprately, as boot bin has problems to start in QEMU, neds investigation"
10:16
BAndiT1983
__m___: are you there?
10:23
mithro
se6astian|away: ping?
10:30
champika_oO
left the channel
10:59
XDjackieXD
left the channel
11:01
XDjackieXD
joined the channel
11:42
RexOrCine
joined the channel
12:04
__m___
left the channel
12:05
__m__
joined the channel
12:22
Bertl
BAndiT1983: hey, I just gave the QEMU stuff a try and I think I found a way to get closer to the real hardware boot
12:22
Bertl
qemu-system-aarch64 -M arm-generic-fdt-7series -machine linux=on -m 1024 -serial /dev/null -serial mon:stdio -nographic -hw-dtb devicetree.dtb -kernel u-boot -drive if=sd,format=raw,index=0,file=beta_20170109.dd -boot mode=5
12:23
Bertl
where devicetree.dtb is a 'generic' device tree to describe the hardware for QEMU
12:23
Bertl
and u-boot is the u-boot elf without the FSBL
12:24
Bertl
(the one I used can be found here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/u-boot )
12:25
Bertl
this successfully imports the uEnv.txt and runs uenvboot from the sd image, it also gets the devicetree and kernel from the sd image
12:27
Bertl
I think I know why the boot.bin doesn't work here and I definitely know why QEMU is not loading the boot.bin in the first place
12:33
Bertl
off for now ... bbl
12:33
Bertl
changed nick to: Bertl_oO
12:37
BAndiT1983
good to know, maybe you can elaborate more on it later, as there are some tasks which were planned for gsoc, but were not selected at the end
12:51
BAndiT1983
changed nick to: BAndiT1983|away
13:08
pusle
joined the channel
13:40
se6astian|away
changed nick to: se6astian
14:00
BAndiT1983|away
changed nick to: BAndiT1983
14:05
jucar
joined the channel
14:47
jucar
left the channel
15:03
BAndiT1983
changed nick to: BAndiT1983|away
15:36
Bertl_oO
changed nick to: Bertl
15:37
Bertl
well, as usual, it is because of proprietary code ... the BOOT ROM of the Xilinx ZYNQ is top secret and said to be protected in such a way that it cannot be read from the device itself
15:38
Bertl
as this initializes the platform and does the actual SD/SPI boot, QEMU has to work around it
15:39
Bertl
starting the next best thing would be the FSBL, but I haven't figured out how to map that for QEMU yet
15:40
Bertl
the alternative (not sure it is worth the efford) would be to compile a minimalistic bootloader which replaces the boot rom and can read the FSBL from SD card
16:56
Champika|away
changed nick to: Champika
16:57
BAndiT1983|away
changed nick to: BAndiT1983
16:59
BAndiT1983
we can consider it, when someone has gained some experience with QEMU, currently it's rather early to think about it
16:59
BAndiT1983
as long as there are no or only few shortcomings, we can focus on the development tasks, afterwards we can adjust the infrastructure
17:00
slikdigit__
joined the channel
17:00
Bertl
agreed
17:00
slikdigit__
changed nick to: slikdigit
17:02
Champika
I have burn the disk image file to a USB
17:03
BAndiT1983
why?
17:03
Bertl
I guess for educational purposes :)
17:03
BAndiT1983
starting from local hdd was already slow enough in QEMU, as the image is rather big
17:03
Champika
because the image had 3 partitions with it
17:03
BAndiT1983
my concern is the performance
17:04
BAndiT1983
3 partitions, yes, but what purpose should it have on USB?
17:04
Bertl
ah, because his kernel does not support partitioned loop devices
17:04
Bertl
(at least not out of the box)
17:04
BAndiT1983
have i missed something important? there was no need for it on my machine
17:04
BAndiT1983
or are you trying different approach?
17:04
Bertl
the usb stick is actually a nice approach to get access to the partitions
17:05
Bertl
(without using loop offsets)
17:05
Champika
So, I thought I will be able to run qemu from USB
17:05
Bertl
wouldn't do that though
17:05
BAndiT1983
good luck, usb sticks are really slow when reading random data
17:06
Bertl
have you seen the qemu line I pasted to start it with the full image?
17:06
BAndiT1983
my thunderbird runs like a snail from usb stick, and the stick is a fast one with a a couple of 100mb/s
17:07
Champika
I'm using USB3.0
17:07
Champika
guess, it will be fine with speed
17:07
BAndiT1983
ehm, it has less to do with usb, but with the architecture of the things
17:07
BAndiT1983
read my sentence again: usb sticks are really slow when reading random data
17:07
BAndiT1983
you will experience rather long boot up in QEMU
17:08
BAndiT1983
sequential one would be better, but it'S not possible in that case
17:09
Champika
yes, I got the point
17:10
Bertl
qemu-system-aarch64 -M arm-generic-fdt-7series -machine linux=on -m 1024 -serial /dev/null -serial mon:stdio -nographic -hw-dtb devicetree.dtb
17:10
Bertl
-kernel u-boot -drive if=sd,format=raw,index=0,file=beta_20170109.dd -boot mode=5
17:11
Bertl
get the devicetree.dtb from the first partition of the image
17:11
Bertl
and the u-boot from here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/u-boot
17:12
Bertl
this should boot up to the beta login prompt
17:12
BAndiT1983
looks similar to my script, but i've compiled uboot and kernel myself a couple of months ago for the test
17:13
Bertl
for actual kernel driver testing I strongly suggest to reduce the userspace to a minimum, maybe just a /bin/bash or so on bootup
17:13
Bertl
(to reduce the overhead)
17:14
Bertl
you can also put all the userspace into an initramfs (via cpio) and use that together with the kernel you built (see T737 for details)
17:15
Bertl
it pays off to spend some time to get that process working efficiently first before you spend a lot of time on waiting for the emulation
17:15
Bertl
(https://lab.apertus.org/T737)
17:22
Champika
still trying...
17:23
Champika
qemu-system-aarch64: Unable to get size of device tree file 'devicetree.dtb'
17:23
Champika
qemu-system-aarch64: Error: Unable to load Device Tree devicetree.dtb
17:23
Bertl
check if you have your devicetree.dtb
17:24
Bertl
(this is usually the qemu message for 'file not found')
17:25
BAndiT1983
have you supplied the path to it?
17:25
BAndiT1983
like in the script -> -dtb $target_dir/$dtb
17:26
Champika
do I need to download devicetree.dtb?
17:26
BAndiT1983
you can get it from first partition
17:27
BAndiT1983
i've extracted all the files from there when i was testing it the first time
17:27
Bertl
http://vserver.13thfloor.at/Stuff/AXIOM/BETA/devicetree.dtb
17:27
BAndiT1983
or that way ;)
17:28
BAndiT1983
both of you should consider to adjust T737 when new knowledge is available
17:30
Bertl
what does the -machine linux=on actually do?
17:30
Champika
sec.
17:30
BAndiT1983
-machine
17:30
BAndiT1983
linux=on
17:30
BAndiT1983
Tells QEMU to boot Linux
17:30
BAndiT1983
argh, sorry, thought it would add it as one line
17:30
BAndiT1983
http://www.wiki.xilinx.com/QEMU
17:30
Bertl
well, sounds nice, but that's not the case here
17:31
Bertl
we are booting u-boot, and still it is required to work correctly
17:31
BAndiT1983
it maybe just a snippet which was left while testing dozens of options back then
17:31
Champika
it seems like, working now... something is loading
17:31
Bertl
so it seems to do something, maybe suspend the second CPU?
17:31
BAndiT1983
http://www.wiki.xilinx.com/QEMU+-+Zynq-7000#x--Running%20a%20Zynq%20Linux%20Kernel%20Image%20In%20QEMU
17:32
BAndiT1983
maybe i got it from such examples there
17:32
Bertl
have you found any idication how the 'emulated' hardware can be activated?
17:33
Bertl
for example, this page lists I2C and the AT24C08 eeprom
17:33
Bertl
but I have no idea how the I2C driver can be activated in QEMU
17:33
BAndiT1983
it should be supplied by devicetree i suppose
17:34
BAndiT1983
there should be the address at least or the path
17:34
Bertl
well, yes, the devicetree has the information, but QEMU seems not to care
17:34
Champika
it worked! :)
17:34
Champika
came to beta login
17:35
BAndiT1983
https://mike632t.wordpress.com/2014/01/28/enabling-i2c/
17:35
BAndiT1983
try the info from raspi, don't have the setup running at the moment, so cannot try anything actively
17:35
Bertl
https://pastebin.com/raw/wTp7wSn0
17:35
Bertl
this is the qtree shown from qemu ... not a lot of devices it seems
17:35
BAndiT1983
i2c should be standard in qemu -> https://github.com/hackndev/qemu/blob/master/hw/i2c.h
17:36
BAndiT1983
the driver is not active, i suppose
17:36
BAndiT1983
https://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg02440.html
17:36
Bertl
well, the guest certainly has everything enabled for I2C, as it works on the Beta)
17:37
Champika
what is the login name/passwd for the beta login?
17:37
Bertl
to find that on the wiki is your next assignment :)
17:37
BAndiT1983
then try the docs -> https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_4/ug1169-zynqmp-qemu.pdf
17:39
BAndiT1983
also here they mention peripherals like i2c supplied by DTB -> http://zedboard.org/content/qemu-deep-dive-0
17:39
Bertl
and the device driver, which would be cdns.i2c-r1p10 is compiled in (i.e. shows up in 'info qdm') but adding it as -device fails with "this is not a device you can create via -device"
17:40
Bertl
maybe the device tree is not interpreted correctly by QEMU
17:43
BAndiT1983
possibly, but i don't think that xilinx is that lazy
17:43
slikdigit
left the channel
17:45
BAndiT1983
wiki article about beta software should be reviewed a bit, credentials are shown 2 times at least not far from each other, also it should be done more prominently
17:56
slikdigit
joined the channel
18:03
Champika
changed nick to: Champika|away
18:08
arpu
left the channel
18:11
Bertl
yes, I can confirm that the QEMU dtb parser does not understand the linux kernel device tree :)
18:12
Bertl
creating a minimalistic devicetree for QEMU with the cadence i2c and an attached eeprom works just fine
18:18
BAndiT1983
hm, could it be sufficient for axiom dev tasks?
18:18
BAndiT1983
or do you need the full-blown solution?
18:19
Bertl
well, probably it will be fine to model a separate QEMU compatible devicetree, but it should be simpler to fix QEMU
18:19
Bertl
when I find some time, I'll take a look at the parser
18:19
Bertl
(and where it goes wrong)
18:22
Bertl
note that the default dts/dtb built from the kernel tree doesn't work either
18:23
BAndiT1983
you mean this things? -> https://github.com/Xilinx/qemu-devicetrees
18:23
Bertl
I mean the one you get when you do something like 'make zynq-zed.dtb' inside the kernel source
18:39
Bertl
arm_generic_fdt_7000_init() does something to the simple-bus (amba) node
18:39
Bertl
/* Mark the simple-bus as incompatible as it breaks the Zynq boot */
18:40
Bertl
this might be the reason that the devicetree is not working
18:42
Bertl
well, commenting this out certainly gives a full qtree
18:42
Bertl
but also keeps qemu from booting :)
18:55
BAndiT1983
changed nick to: BAndiT1983|away
19:01
slikdigit
left the channel
19:33
slikdigit
joined the channel
20:34
Bertl
off for now ... bbl
20:34
Bertl
changed nick to: Bertl_oO
21:08
BAndiT1983|away
changed nick to: BAndiT1983
21:54
BAndiT1983
changed nick to: BAndiT1983|away
22:23
Rex0r
Home computing - https://youtu.be/bwtjucKFjtg
22:28
intrac
left the channel
23:01
se6astian
changed nick to: se6astian|away
23:44
intrac
joined the channel
00:05
dimaursu16
left the channel
00:05
slikdigit
left the channel
00:09
dimaursu16
joined the channel
00:27
dimaursu16
left the channel