qemu palmetto-bmc

DISCUSSION Andrew Jeffery 1 participant 1 message May 13, 2016 3 messages not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andrew Jeffery

author

2016-05-13 05:18 UTC #3 lore raw

Hi Cédric,

Quoted 57 lines · Cédric Le Goater

Hello,
Quoted 39 lines · Andrew Jeffery
Hi Cédric!
Quoted 7 lines · Cédric Le Goater
Hello Andrew,
I spent some time today trying to find the good recipe between the kernel and qemu. I used all the latest with a custom dtb and failed to boot completely a guest :/
Hrm, that's no good. Admittedly I'm a little behind with the kernel, I've mostly been testing with some patches on top of obmc/dev-4.3. I had tried briefly with obmc/dev-4.4. It didn't work initially but that was a configuration problem on my part (I have it working now).
Quoted 4 lines
Could you educate me a bit and tell me which branches I should be using ? and which command line eventually. I rather stay out yocto for the moment.
Yep. Current goodness is:
qemu built from the aspeed-integration branch:
https://github.com/amboar/qemu/commits/aspeed-integration
kernel built from the openbmc repo, configured with make aspeed_defconfig:
https://github.com/openbmc/linux/commits/dev-4.4
CONFIG_RD_LZMA isn't set by aspeed_defconfig, which was tripping me up initially. I tweaked that manually.
qemu can be invoked with something like:
Quoted 11 lines
    $ qemu-system-arm \
    -M palmetto-bmc \
    -m 256 \
    -append "earlyprintk debug console=ttyS4" \
    -serial pty \
    -nographic \
    -s \
    -S \
    -kernel .../arch/arm/boot/zImage 
    -dtb .../arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dtb \
    -initrd ...
Using the qemu aspeed-integration branch (minus the RAM zero patch), the latest kernels boots with rootfs :

Quoted 7 lines

	./obmc-phosphor-image-palmetto-20160512040959.rootfs.cpio.gz
I had to deconfigure a couple of i2c devices which the kernel probes, and we don't have an aspeed i2c controller in qemu yet anyway. But the probe also hangs the guest which I suppose is a due to a timeout (clock) issue. Maybe because we don't have the support for non-zero match values. To be investigated.

Agh, yeah, forgot to mention that I'd disabled i2c in the devicetree in my original reply. So the 4.3 kernel doesn't need it disabled, as the i2c bus probes eventually time out. We boot to a getty on 4.3. On a 4.4-based kernel however, a number of things appear to not be timing out as you noted (i2c driver probe, the MACB NIC driver probe, something during init (if we get that far) that prevents a getty being spawned).

Trying to track down the 4.3 vs 4.4 issues now.

Quoted 4 lines

The boot reaches the end of systemd startup but without a getty on ttyS4. This is for tomorrow. I have a working environment I can play with now.

Sounds like some progress. For the record, if you're running with the "Remap RAM to 0" commit from the aspeed-integration branch you have to run with _at most_ 256M of RAM, otherwise the aliased region will overlap the MMIO address space.

With a few hacks to the runqemu script from the pull-req against the openbmc repo, qemu boots the system to a getty on ttyS4 (but it's with a obmc/dev-4.3-based kernel). Not that it affects you as you're avoiding the yocto stuff, but I'll update the pull-req against openbmc to limit the amount of RAM to a maximum of 256M.

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
I also spend some time with uboot on qemu but I fail to get a console with the latest 'aspeed-integration' branch ... Might be the DRAM work around patch. uboot does jump out the lowlevel_init routine but then it then fails when running the init functions. It looks like a relocation issue. Investigation in progress.

Quoted 6 lines

Quoted 2 lines
Yeah, I wasn't getting a console either due to that strange branch target value. I'll try to keep you across any progress I make.
As for u-boot, it boots with the same qemu if you link it where qemu maps the kernel, 0x40010000. I had to run the link command manually bc the u-boot Makefiles seem to be broken. I will send you a short patch when I am sure of the diagnostic on the Makefile.

Okay, sounds good!

Quoted 5 lines

uboot expects to start at 0x0 when it is pulled from the flash module, it then relocates itself but under qemu things are a little different as the platform implementation is not complete. We miss a flash controller.

Yep, modelling either the flash controller or the NIC is certainly up there on the list of things to do for qemu.

Andrew

Quoted 1 line