qemu palmetto-bmc

[Andrew Jeffery]

Hi Cédric,

On Thu, 2016-05-12 at 21:32 +0200, Cédric Le Goater wrote:
> Hello,
> 
> On 05/12/2016 02:30 AM, Andrew Jeffery wrote:
> > 
> > Hi Cédric!
> > 
> > On Wed, 2016-05-11 at 22:45 +0200, Cédric Le Goater wrote:
> > > 
> > > 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).
> > 
> > 
> > 
> > > 
> > > 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:
> > 
> >     $ 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 :
> 
> 	./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.

> 
> 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.

> 
> > 
> > > 
> > > 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.
> > 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!

> 
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160513/f61b67f7/attachment.sig>