On 26.09.14 07:37, Alex Armstrong wrote: > Alex Armstrong wrote: >> Guillaume Gardet wrote: >>> Le 23/09/2014 09:54, Dirk Müller a écrit : >>>> Hi Alex, >>>> >>>>> But if I don't load the fdt file (bcm2835-rpi-b.dtb - what is that >>>>> anyway?), I get all the way to the network: >>>> the fdt file is the device tree, its a binary blob that should exactly >>>> describe the hardware. This is used to avoid the kernel having to >>>> guess about the hardware (as sometimes probing is not possible on ARM >>>> hardware due to lack of standardization). The obvious question for me >>>> is whether you actually use a Raspberry Pi - Type B board. It looks >>>> like the device tree is not actually matching your hardware. >>>> >>>> if it boots without it - we might consider building an image without >>>> the device tree, since I find it actually surprising that it works >>>> without device tree. >>> I think you can use 2 kernel images for RPi: >>> * upstream kernel which need a device tree >>> * downstream kernel which still uses a *.c source file to describe the >>> board and not a device tree. >>> >>> I thought I fixed that in my last JeOS commit (with the partition >>> problem fix). >>> >>> >>> Guillaume >>> >> Thanks for filling me in on the fdt files. I do have a RPi Model B >> revision 2 board (not the B+). This board works with the 13.1 JeOS >> images (build 38.14). I didn't see a fdt file there, which lead me to >> the experiment earlier. But then it hangs when loading the network >> module, so it doesn't quite work with auto detection. I'm not sure what >> the problem is, but I'm happy to keep testing. >> >> -Alex >> > So, I tried using some different images and had different results. > > I'm a bit confused actually, I had originally been using this image: > openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build215.1.raw.xz > > from here: > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi/images/ > > Which give the output I reported earlier - claims to boot the kernel, > but just hangs. > > Poking around the build website a bit, I found this image: > openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build219.1.raw.xz > > from here: > http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/RaspberryPi:/upstream/images/ > > And using this image, the kernel starts booting but stops with a panic - > here are the interesting bits: > ########## > Starting kernel ... > > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Initializing cgroup subsys cpuacct > [ 0.000000] Linux version 3.17.0-rc6-1-default (geeko@buildhost) (gcc > version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) > #1 Mon Sep 22 14:43:00 UTC 2014 (811b3a2) > [ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 > (ARMv7), cr=00c5387d > [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing > instruction cache > [ 0.000000] Machine model: Raspberry Pi Model B > ... > [ 0.664553] Unpacking initramfs... > [ 7.048904] Initramfs unpacking failed: write error
This hints to an OOM error while unpacking the initrd. You can work around this by passing "rootfstype=ramfs" on the kernel commandline. Furthermore something in u-boot isn't working. For some reason the kernel does not get the u-boot provided command line, but instead only sees the one that's already provided in the device tree. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
