Current Server Time: 07:54 (Central Europe)

#apertus IRC Channel Logs

2017/06/15

Timezone: UTC


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