On 07.10.14 01:30, Alexander Graf wrote:
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:/Rasp...
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:/Rasp...
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.
Ok, I think I've squashed all issues with the upstream image. Things are still building, but once they settled down, please give it another try. While fiddling with the image there's a good chance I fixed or broke the downstream image along the way. I'm not overly interested in downstream code, so whoever maintains that one, please stand up and check that things still work :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org