#apertus IRC Channel Logs

Good Morning!

is it like this?

I have tried with a lecture, but I couldn't still run the qemu

mounting the .dd is trivial if you do what I suggested (i.e. load the loop module with max_part=8)

(as shown in this article)

you can, if qemu is able to boot from an SD card

ok, will keep trying :)

ok

I first rename the beta_20170109.dd -> beta_20170109.raw

rmmod: ERROR: Module loop0 is not currently loaded

(i.e. with modinfo loop)

champika_oO: have you looked at the script in the task ? -> https://lab.apertus.org/T737

but if i remember correctly, some files have to be supplied externally, as QEMU has currently some trouble to get them from first partition

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"

se6astian|away: ping?

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

and u-boot is the u-boot elf without the FSBL

this successfully imports the uEnv.txt and runs uenvboot from the sd image, it also gets the devicetree and kernel from the sd image

off for now ... bbl

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

as this initializes the platform and does the actual SD/SPI boot, QEMU has to work around it

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

as long as there are no or only few shortcomings, we can focus on the development tasks, afterwards we can adjust the infrastructure

agreed

I have burn the disk image file to a USB

I guess for educational purposes :)

because the image had 3 partitions with it

3 partitions, yes, but what purpose should it have on USB?

(at least not out of the box)

or are you trying different approach?

(without using loop offsets)

wouldn't do that though

have you seen the qemu line I pasted to start it with the full image?

I'm using USB3.0

ehm, it has less to do with usb, but with the architecture of the things

you will experience rather long boot up in QEMU

yes, I got the point

-kernel u-boot -drive if=sd,format=raw,index=0,file=beta_20170109.dd -boot mode=5

and the u-boot from here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/u-boot

looks similar to my script, but i've compiled uboot and kernel myself a couple of months ago for the test

(to reduce the overhead)

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

still trying...

qemu-system-aarch64: Error: Unable to load Device Tree devicetree.dtb

(this is usually the qemu message for 'file not found')

like in the script -> -dtb $target_dir/$dtb

you can get it from first partition

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/devicetree.dtb

both of you should consider to adjust T737 when new knowledge is available

sec.

linux=on

argh, sorry, thought it would add it as one line

well, sounds nice, but that's not the case here

it maybe just a snippet which was left while testing dozens of options back then

so it seems to do something, maybe suspend the second CPU?

maybe i got it from such examples there

for example, this page lists I2C and the AT24C08 eeprom

it should be supplied by devicetree i suppose

well, yes, the devicetree has the information, but QEMU seems not to care

came to beta login

try the info from raspi, don't have the setup running at the moment, so cannot try anything actively

this is the qtree shown from qemu ... not a lot of devices it seems

the driver is not active, i suppose

well, the guest certainly has everything enabled for I2C, as it works on the Beta)

to find that on the wiki is your next assignment :)

also here they mention peripherals like i2c supplied by DTB -> http://zedboard.org/content/qemu-deep-dive-0

maybe the device tree is not interpreted correctly by QEMU

creating a minimalistic devicetree for QEMU with the cadence i2c and an attached eeprom works just fine

or do you need the full-blown solution?

when I find some time, I'll take a look at the parser

note that the default dts/dtb built from the kernel tree doesn't work either

I mean the one you get when you do something like 'make zynq-zed.dtb' inside the kernel source

/* Mark the simple-bus as incompatible as it breaks the Zynq boot */

well, commenting this out certainly gives a full qtree