[opensuse-arm] openSUSE JeOS Factory Build 207 not booting on Raspberry Pi
Greetings, I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot. U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip. Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** U-Boot> ----- There is a linux.vmx at the top level of the boot partition - so maybe a script path problem? -A -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 **
These should be 0:2, so maybe a variable mixup in the script? Regards, Andreas
U-Boot> -----
There is a linux.vmx at the top level of the boot partition - so maybe a script path problem?
-A
-- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Andreas Färber wrote:
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** These should be 0:2, so maybe a variable mixup in the script?
Regards, Andreas
I haven't yet found what's causing this, but I'm a bit confused by something else too. I think that the boot script is looking to boot 'boot/linux.vmx' with initrd 'boot/initrd.uboot' on the Second Partition (if I'm reading it right). But when I look at the directory structure I see this: <First Partition> BOOT/boot/ - linux.vmx - initrd.uboot <Second Partition> /boot/ - zImage -> zImage-3.11.4-3-raspberrypi - vmlinux-3.11.4-3-raspberrypi - initrd -> [broken link] What am I missing? -A -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Alex Armstrong wrote:
Andreas Färber wrote:
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** These should be 0:2, so maybe a variable mixup in the script?
Regards, Andreas
I haven't yet found what's causing this, but I'm a bit confused by something else too.
I think that the boot script is looking to boot 'boot/linux.vmx' with initrd 'boot/initrd.uboot' on the Second Partition (if I'm reading it right). But when I look at the directory structure I see this:
<First Partition> BOOT/boot/ - linux.vmx - initrd.uboot
<Second Partition> /boot/ - zImage -> zImage-3.11.4-3-raspberrypi - vmlinux-3.11.4-3-raspberrypi - initrd -> [broken link]
What am I missing?
-A Once at the u-boot prompt it's possible to load a kernel and initrd by hand with these commands:
<To load the kernel in the BOOT partition>
load mmc 0:1 ${kerneladdr} ${kernel}
HI! Any news on that? Tried today with openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build211.14.raw.xz but still no luck. Any further information needed I could provide? Ciao, Michael. BTW: It seems I did not receive all follow-ups cited in Alex' e-mail. Alex Armstrong wrote:
Alex Armstrong wrote:
Andreas Färber wrote:
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** These should be 0:2, so maybe a variable mixup in the script?
Regards, Andreas
I haven't yet found what's causing this, but I'm a bit confused by something else too.
I think that the boot script is looking to boot 'boot/linux.vmx' with initrd 'boot/initrd.uboot' on the Second Partition (if I'm reading it right). But when I look at the directory structure I see this:
<First Partition> BOOT/boot/ - linux.vmx - initrd.uboot
<Second Partition> /boot/ - zImage -> zImage-3.11.4-3-raspberrypi - vmlinux-3.11.4-3-raspberrypi - initrd -> [broken link]
What am I missing?
-A Once at the u-boot prompt it's possible to load a kernel and initrd by hand with these commands:
<To load the kernel in the BOOT partition> load mmc 0:1 ${kerneladdr} ${kernel}
load mmc 0:2 ${kerneladdr} boot/zImage <To load inird in BOOT partition> load mmc 0:1 ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}:${filesize}
Then can boot with:
bootz ${kerneladdr} ${ramdiskaddr}:${rd_filesize}
This starts the kernel booting - it uncompresses, verifies the checksum and boots Linux - but at about 4 seconds in it hangs while trying to register the ethernet device: ------ usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 usb 1-1.1: New USB device string: Mfr=0, Product=0, SerialNumber=0 smsc95xx v1.0.4 smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, 7a:60:5a:4c:e1:ea ------
-A
Beste Grüße, Michael Ströder -- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: michael@stroeder.com http://www.stroeder.com
Le 19/09/2014 14:28, Michael Ströder a écrit :
HI!
Any news on that?
Tried today with openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build211.14.raw.xz but still no luck.
Any further information needed I could provide?
I got the same problem as Alex (once loaded manually). No idea why the kernel stop like this... And I have no serial port on the RPi to check if there is something on serial. Guillaume
Ciao, Michael.
BTW: It seems I did not receive all follow-ups cited in Alex' e-mail.
Alex Armstrong wrote:
Alex Armstrong wrote:
Andreas Färber wrote:
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** These should be 0:2, so maybe a variable mixup in the script?
Regards, Andreas
I haven't yet found what's causing this, but I'm a bit confused by something else too.
I think that the boot script is looking to boot 'boot/linux.vmx' with initrd 'boot/initrd.uboot' on the Second Partition (if I'm reading it right). But when I look at the directory structure I see this:
<First Partition> BOOT/boot/ - linux.vmx - initrd.uboot
<Second Partition> /boot/ - zImage -> zImage-3.11.4-3-raspberrypi - vmlinux-3.11.4-3-raspberrypi - initrd -> [broken link]
What am I missing?
-A Once at the u-boot prompt it's possible to load a kernel and initrd by hand with these commands:
<To load the kernel in the BOOT partition> load mmc 0:1 ${kerneladdr} ${kernel}
load mmc 0:2 ${kerneladdr} boot/zImage <To load inird in BOOT partition> load mmc 0:1 ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}:${filesize}
Then can boot with:
bootz ${kerneladdr} ${ramdiskaddr}:${rd_filesize}
This starts the kernel booting - it uncompresses, verifies the checksum and boots Linux - but at about 4 seconds in it hangs while trying to register the ethernet device: ------ usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 usb 1-1.1: New USB device string: Mfr=0, Product=0, SerialNumber=0 smsc95xx v1.0.4 smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, 7a:60:5a:4c:e1:ea ------
-A
Beste Grüße,
Michael Ströder
-- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: michael@stroeder.com http://www.stroeder.com
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 19/09/2014 14:37, Guillaume Gardet a écrit :
Le 19/09/2014 14:28, Michael Ströder a écrit :
HI!
Any news on that?
Tried today with openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build211.14.raw.xz but still no luck.
Any further information needed I could provide?
I got the same problem as Alex (once loaded manually).
No idea why the kernel stop like this... And I have no serial port on the RPi to check if there is something on serial.
I just sent SR #250237 to fix the load but the kernel problem is still there. Guillaume
Guillaume
Ciao, Michael.
BTW: It seems I did not receive all follow-ups cited in Alex' e-mail.
Alex Armstrong wrote:
Alex Armstrong wrote:
Andreas Färber wrote:
Am 14.09.2014 um 02:27 schrieb Alex Armstrong:
Greetings,
I had a chance to test JeOS Factory Build 207.2 (13-Sep-14) on the Pi this weekend and found it didn't boot.
U-boot loads. It looks for /uEnv.txt, fails to find it. U-boot next looks for, and finds /boot.scr. It reads and executes the scrip.
Then this happens: ----- switch to partitions #0, OK mmc is current device ** File not found boot/linux.vmx ** SCRIPT FAILED: continuing... ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** ** Bad Partition specification mmc 0:0:2 ** These should be 0:2, so maybe a variable mixup in the script?
Regards, Andreas
I haven't yet found what's causing this, but I'm a bit confused by something else too.
I think that the boot script is looking to boot 'boot/linux.vmx' with initrd 'boot/initrd.uboot' on the Second Partition (if I'm reading it right). But when I look at the directory structure I see this:
<First Partition> BOOT/boot/ - linux.vmx - initrd.uboot
<Second Partition> /boot/ - zImage -> zImage-3.11.4-3-raspberrypi - vmlinux-3.11.4-3-raspberrypi - initrd -> [broken link]
What am I missing?
-A Once at the u-boot prompt it's possible to load a kernel and initrd by hand with these commands:
<To load the kernel in the BOOT partition> load mmc 0:1 ${kerneladdr} ${kernel}
load mmc 0:2 ${kerneladdr} boot/zImage <To load inird in BOOT partition> load mmc 0:1 ${ramdiskaddr} ${initrd}; setenv rd_filesize ${sizeprefix}:${filesize}
Then can boot with:
bootz ${kerneladdr} ${ramdiskaddr}:${rd_filesize}
This starts the kernel booting - it uncompresses, verifies the checksum and boots Linux - but at about 4 seconds in it hangs while trying to register the ethernet device: ------ usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 usb 1-1.1: New USB device string: Mfr=0, Product=0, SerialNumber=0 smsc95xx v1.0.4 smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, 7a:60:5a:4c:e1:ea ------
-A
Beste Grüße,
Michael Ströder
-- Michael Ströder Klauprechtstr. 11 Dipl.-Inform. D-76137 Karlsruhe, Germany Tel.: +49 721 8304316 Mobil: +49 170 2391920 E-Mail: michael@stroeder.com http://www.stroeder.com
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Guillaume Gardet wrote:
Le 19/09/2014 14:37, Guillaume Gardet a écrit :
Le 19/09/2014 14:28, Michael Ströder a écrit :
HI!
Any news on that?
Tried today with openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build211.14.raw.xz but still no luck.
Any further information needed I could provide?
I got the same problem as Alex (once loaded manually).
No idea why the kernel stop like this... And I have no serial port on the RPi to check if there is something on serial.
I just sent SR #250237 to fix the load but the kernel problem is still there.
Guillaume
Thanks for patching that. I'm out of town this weekend, but I do have a serial cable that should connect to the RPi. Is there anything in particular I should be looking for, or any special kernel boot options I should pass when I start looking at this? -Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 20/09/2014 06:58, Alex Armstrong a écrit :
Guillaume Gardet wrote:
Le 19/09/2014 14:28, Michael Ströder a écrit :
HI!
Any news on that?
Tried today with openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build211.14.raw.xz but still no luck.
Any further information needed I could provide? I got the same problem as Alex (once loaded manually).
No idea why the kernel stop like this... And I have no serial port on the RPi to check if there is something on serial. I just sent SR #250237 to fix the load but the kernel problem is still
Le 19/09/2014 14:37, Guillaume Gardet a écrit : there.
Guillaume
Thanks for patching that. I'm out of town this weekend, but I do have a serial cable that should connect to the RPi. Is there anything in particular I should be looking for, or any special kernel boot options I should pass when I start looking at this?
Boot and then have a look on the serial port to see if there is anything interesting on the serial port. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Guillaume Gardet wrote:
Boot and then have a look on the serial port to see if there is anything interesting on the serial port.
Guillaume
So here's what I find on the serial port - this first listing is what happens when I simply power on. It runs through some messages and then hangs at the last line: ########## U-Boot 2014.10-rc2 (Sep 15 2014 - 22:39:11) DRAM: 384 MiB WARNING: Caches not enabled MMC: bcm2835_sdhci: 0 Using default environment In: serial Out: lcd Err: lcd reading /uEnv.txt ** Unable to read file /uEnv.txt ** Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0... Found U-Boot script /boot.scr reading /boot.scr 2274 bytes read in 12 ms (184.6 KiB/s) ## Executing script at 00000000 setenv - set environment variables Usage: setenv [-f] name value ... - [forcibly] set environment variable 'name' to 'value ...' setenv [-f] name - [forcibly] delete environment variable 'name' switch to partitions #0, OK mmc0 is current device reading boot/linux.vmx 2604976 bytes read in 336 ms (7.4 MiB/s) reading boot/initrd.uboot 57941599 bytes read in 7085 ms (7.8 MiB/s) reading dtb/bcm2835-rpi-b.dtb 8003 bytes read in 22 ms (354.5 KiB/s) Kernel image @ 0x1000000 [ 0x000000 - 0x27bfb0 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 57941535 Bytes = 55.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02000000 Booting using the fdt blob at 0x2000000 Using Device Tree in place at 02000000, end 02004f42 Starting kernel ... Uncompressing Linux... done, booting the kernel. ########## I get this same behavior if I try executing the boot scrip commands by hand: ########## U-Boot> load mmc 0:1 ${kernel_addr_r} boot/linux.vmx reading boot/linux.vmx 2604976 bytes read in 434 ms (5.7 MiB/s) U-Boot> load mmc 0:1 ${ramdisk_addr_r} boot/initrd.uboot; setenv rd_filesize ${sizeprefix}${filesize} reading boot/initrd.uboot 57941599 bytes read in 9255 ms (6 MiB/s) U-Boot> load mmc 0:1 ${fdt_addr_r} dtb/bcm2835-rpi-b.dtb reading dtb/bcm2835-rpi-b.dtb 8003 bytes read in 22 ms (354.5 KiB/s) U-Boot> bootz ${kernel_addr_r} ${ramdisk_addr_r}:${rd_filesize} ${fdt_addr_r} Kernel image @ 0x1000000 [ 0x000000 - 0x27bfb0 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 57941535 Bytes = 55.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02000000 Booting using the fdt blob at 0x2000000 Loading Ramdisk to 14444000, end 17b85e1f ... OK Loading Device Tree to 1443f000, end 14443f42 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. ########## 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: ########## U-Boot> load mmc 0:1 ${kernel_addr_r} boot/linux.vmx reading boot/linux.vmx 2604976 bytes read in 434 ms (5.7 MiB/s) U-Boot> load mmc 0:1 ${ramdisk_addr_r} boot/initrd.uboot; setenv rd_filesize ${sizeprefix}${filesize} reading boot/initrd.uboot 57941599 bytes read in 9255 ms (6 MiB/s) U-Boot> bootz ${kernel_addr_r} ${ramdisk_addr_r}:${rd_filesize} Kernel image @ 0x1000000 [ 0x000000 - 0x27bfb0 ] ## Loading init Ramdisk from Legacy Image at 02100000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 57941535 Bytes = 55.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.11.4-3-raspberrypi (geeko@buildhost) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 PREEMPT Fri Oct 11 00:02:13 UTC 2013 (f1558bf) [ 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: BCM2708 [ 0.000000] cma: CMA: reserved 16 MiB at 17000000 [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 97536 [ 0.000000] Kernel command line: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 365664K/393216K available (4999K kernel code, 226K rwdata, 1508K rodata, 139K init, 696K bss, 27552K reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xd8800000 - 0xff000000 ( 616 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd8000000 ( 384 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc0662f74 (6508 kB) [ 0.000000] .init : 0xc0663000 - 0xc0685d68 ( 140 kB) [ 0.000000] .data : 0xc0686000 - 0xc06be8e0 ( 227 kB) [ 0.000000] .bss : 0xc06be8e0 - 0xc076cc08 ( 697 kB) [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] NR_IRQS:330 [ 0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms [ 0.000000] Switching to timer-based delay loop [ 0.000000] Console: colour dummy device 80x30 [ 0.000482] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000) [ 0.000505] pid_max: default: 32768 minimum: 301 [ 0.000846] Mount-cache hash table entries: 512 [ 0.001629] Initializing cgroup subsys devices [ 0.001658] Initializing cgroup subsys freezer [ 0.001671] Initializing cgroup subsys blkio [ 0.001748] CPU: Testing write buffer coherency: ok [ 0.002199] Setting up static identity map for 0xc04c27b8 - 0xc04c2814 [ 0.004203] devtmpfs: initialized [ 0.015786] xor: measuring software checksum speed [ 0.110268] arm4regs : 974.000 MB/sec [ 0.210303] 8regs : 470.800 MB/sec [ 0.310384] 32regs : 470.800 MB/sec [ 0.310400] xor: using function: arm4regs (974.000 MB/sec) [ 0.312561] NET: Registered protocol family 16 [ 0.318558] DMA: preallocated 4096 KiB pool for atomic coherent allocations [ 0.319463] bcm2708.uart_clock = 0 [ 0.321026] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers. [ 0.321044] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.321059] mailbox: Broadcom VideoCore Mailbox driver [ 0.321136] bcm2708_vcio: mailbox at f200b880 [ 0.321216] bcm_power: Broadcom power driver [ 0.321234] bcm_power_open() -> 0 [ 0.321245] bcm_power_request(0, 8) [ 0.821536] bcm_mailbox_read -> 00000080, 0 [ 0.821553] bcm_power_request -> 0 [ 0.821564] Serial: AMBA PL011 UART driver [ 0.821696] dev:f1: ttyAMA0 at MMIO 0x20201000 (irq = 83) is a PL011 rev3 [ 1.149136] console [ttyAMA0] enabled [ 1.173724] bio: create slab <bio-0> at 0 [ 1.340315] raid6: int32x1 44 MB/s [ 1.510008] raid6: int32x2 67 MB/s [ 1.680477] raid6: int32x4 86 MB/s [ 1.850983] raid6: int32x8 95 MB/s [ 1.854729] raid6: using algorithm int32x8 (95 MB/s) [ 1.859682] raid6: using intx1 recovery algorithm [ 1.865042] SCSI subsystem initialized [ 1.869110] usbcore: registered new interface driver usbfs [ 1.874729] usbcore: registered new interface driver hub [ 1.880311] usbcore: registered new device driver usb [ 1.886728] Switched to clocksource stc [ 1.890891] FS-Cache: Loaded [ 1.894020] CacheFiles: Loaded [ 1.910053] NET: Registered protocol family 2 [ 1.915383] TCP established hash table entries: 4096 (order: 3, 32768 bytes) [ 1.922638] TCP bind hash table entries: 4096 (order: 2, 16384 bytes) [ 1.929194] TCP: Hash tables configured (established 4096 bind 4096) [ 1.935617] TCP: reno registered [ 1.938897] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 1.944743] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 1.951346] NET: Registered protocol family 1 [ 1.956271] RPC: Registered named UNIX socket transport module. [ 1.962296] RPC: Registered udp transport module. [ 1.967030] RPC: Registered tcp transport module. [ 1.971728] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.978694] bcm2708_dma: DMA manager at f2007000 [ 1.983391] bcm2708_gpio: bcm2708_gpio_probe c0693d30 [ 1.988910] vc-mem: phys_addr:0x00000000 mem_base=0x00000000 mem_size:0x00000000(0 MiB) [ 1.998139] audit: initializing netlink socket (disabled) [ 2.003603] type=2000 audit(1.860:1): initialized [ 2.172466] VFS: Disk quotas dquot_6.5.2 [ 2.176464] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.183567] FS-Cache: Netfs 'nfs' registered for caching [ 2.189355] NFS: Registering the id_resolver key type [ 2.194493] Key type id_resolver registered [ 2.198784] Key type id_legacy registered [ 2.203505] bio: create slab <bio-1> at 1 [ 2.208165] Btrfs loaded [ 2.210827] msgmni has been set to 746 [ 2.217655] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 2.225355] io scheduler noop registered [ 2.229424] io scheduler deadline registered [ 2.233720] io scheduler cfq registered (default) [ 2.239954] BCM2708FB: allocated DMA memory 57400000 [ 2.244926] BCM2708FB: allocated DMA channel 4 @ f2007400 [ 2.266620] Console: switching to colour frame buffer device 100x30 [ 2.276346] kgdb: Registered I/O driver kgdboc. [ 2.281596] vc-cma: Videocore CMA driver [ 2.285518] vc-cma: vc_cma_base = 0x00000000 [ 2.290279] vc-cma: vc_cma_size = 0x00000000 (0 MiB) [ 2.295669] vc-cma: vc_cma_initial = 0x00000000 (0 MiB) [ 2.310362] brd: module loaded [ 2.318607] loop: module loaded [ 2.321999] vchiq: vchiq_init_state: slot_zero = 0xd7000000, is_master = 0 [ 2.329964] Loading iSCSI transport class v2.0-870. [ 2.335810] usbcore: registered new interface driver ax88179_178a [ 2.342291] usbcore: registered new interface driver smsc95xx [ 2.348147] dwc_otg: version 3.00a 10-AUG-2012 (platform bus) [ 2.554045] Core Release: 2.80a [ 2.557279] Setting default values for core params [ 2.562096] Finished setting default values for core params [ 2.767778] Using Buffer DMA mode [ 2.771098] Periodic Transfer Interrupt Enhancement - disabled [ 2.776946] Multiprocessor Interrupt Enhancement - disabled [ 2.782511] OTG VER PARAM: 0, OTG VER FLAG: 0 [ 2.786889] Dedicated Tx FIFOs mode [ 2.791086] dwc_otg bcm2708_usb: DWC OTG Controller [ 2.796001] dwc_otg bcm2708_usb: new USB bus registered, assigned bus number 1 [ 2.803321] dwc_otg bcm2708_usb: irq 32, io mem 0x00000000 [ 2.808859] Init: Port Power? op_state=1 [ 2.812775] Init: Power Port (0) [ 2.816095] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 2.822920] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 2.830164] usb usb1: Product: DWC OTG Controller [ 2.834865] usb usb1: Manufacturer: Linux 3.11.4-3-raspberrypi dwc_otg_hcd [ 2.841758] usb usb1: SerialNumber: bcm2708_usb [ 2.847239] hub 1-0:1.0: USB hub found [ 2.851014] hub 1-0:1.0: 1 port detected [ 2.855742] usbcore: registered new interface driver usb-storage [ 2.862216] mousedev: PS/2 mouse device common for all mice [ 2.868529] bcm2835-cpufreq: min=700000 max=840000 cur=700000 [ 2.874368] bcm2835-cpufreq: switching to governor performance [ 2.880296] bcm2835-cpufreq: switching to governor performance [ 2.887763] cpuidle: using governor ladder [ 2.891858] cpuidle: using governor menu [ 2.895827] sdhci: Secure Digital Host Controller Interface driver [ 2.902035] sdhci: Copyright(c) Pierre Ossman [ 2.906456] sdhci: Enable low-latency mode [ 2.910808] bcm2708_sdhci bcm2708_sdhci.0: couldn't allocate a DMA channel [ 2.917744] bcm2708_sdhci bcm2708_sdhci.0: probe failed, err -12 [ 2.923773] bcm2708_sdhci: probe of bcm2708_sdhci.0 failed with error -12 [ 2.930631] sdhci-pltfm: SDHCI platform and OF driver helper [ 2.936294] ledtrig-cpu: registered to indicate activity on CPUs [ 2.942488] hidraw: raw HID events driver (C) Jiri Kosina [ 2.948196] usbcore: registered new interface driver usbhid [ 2.953760] usbhid: USB HID core driver [ 2.958026] TCP: cubic registered [ 2.961339] Initializing XFRM netlink socket [ 2.965616] NET: Registered protocol family 17 [ 2.970239] Key type dns_resolver registered [ 2.974708] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 [ 2.983019] registered taskstats version 1 [ 2.988011] Waiting for root device /dev/mmcblk0p2... [ 3.046876] Indeed it is in host mode hprt0 = 00021501 [ 3.226790] usb 1-1: new high-speed USB device number 2 using dwc_otg [ 3.233361] Indeed it is in host mode hprt0 = 00001101 [ 3.437209] usb 1-1: New USB device found, idVendor=0424, idProduct=9514 [ 3.443923] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.451911] hub 1-1:1.0: USB hub found [ 3.455837] hub 1-1:1.0: 5 ports detected [ 3.736980] usb 1-1.1: new high-speed USB device number 3 using dwc_otg [ 3.857145] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00 [ 3.864019] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 3.874214] smsc95xx v1.0.4 [ 3.941321] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-bcm2708_usb-1.1, smsc95xx USB 2.0 Ethernet, 02:9f:30:8e:ff:72 ########## If there's any other info I can provide let me know. -Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 [ 7.243054] Freeing initrd memory: 58956K (c2101000 - c5a94000) ... [ 8.301281] AppArmor: AppArmor sha1 policy hashing enabled [ 8.307272] ../drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 8.316152] Freeing unused kernel memory: 420K (c0759000 - c07c2000) /bin/bash: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory [ 8.349982] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 8.349982] [ 8.359121] CPU: 0 PID: 1 Comm: init Not tainted 3.17.0-rc6-1-default #1 [ 8.365854] [] (unwind_backtrace) from [ ] (show_stack+0x18/0x1c) [ 8.373607] [ ] (show_stack) from [ ] (panic+0x84/0x1f8) [ 8.380496] [ ] (panic) from [ ] (do_exit+0x8a8/0x8e0) [ 8.387199] [ ] (do_exit) from [ ] (do_group_exit+0x48/0xa4) [ 8.394422] [ ] (do_group_exit) from [ ] (__wake_up_parent+0x0/0x20) [ 8.402332] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 [ 8.402332] [ 82.639768] random: nonblocking pool is initialized ########## (If anyone wants to see all 170 lines let me know.) This seems like progress or a sort. I also noticed that this boots the recent kernel 3.17 rc, but the first image I was using (when I could get it to boot at all) only booted to 3.11.4. But my primary question is, am I even testing the correct images or should I be looking at something else? -A -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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:/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. 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
Alexander Graf wrote:
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
Thanks for taking a look at this. I've tested image: openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build235.5.raw.xz from: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp... on 8 Oct. 14 and it boots to a functioning system, but has two failures. Here is the breakdown: U-Boot loads and runs /boot.scr. Kernel loads and starts. All subsystems and modules load without failures. GPT starts , reads the SD card, checks the file system and resizes the root partition automatically. Systemd starts and begins loading units. -- Here there is one failure -- [ 470.707495] systemd[1]: Found device /dev/disk/by-uuid/8b8c21e8-7bbe-41dd-a2a0-233eea2c7a2b. [ 470.728403] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 470.760556] systemd[1]: Starting Remote File Systems (Pre). -- Then I get to a login prompt on the serial terminal. I can login as root and execute normal system commands. -- However, on the graphical display I have a second failure -- YaST starts in ncurses mode, but gives this error: "Calling the YaST module 'firstboot_setup_dhcp' has failed." *Note that I didn't have network (or even a keyboard) hooked up on this run. Connecting a keyboard at this point works fine. 'Retrying' from the YaST error dialog fails again, and using the 'Back' button drops you to a working login prompt. The error says to check /var/log/YaST2/y2log. Here is y2log: linux:/var/log/YaST2 # less y2log 2014-10-08 02:08:08 <1> linux(6185) [liby2] genericfrontend.cc(main):575 Launched YaST2 component 'y2base' 'firstboot' '("firstboot")' 'ncurses' 2014-10-08 02:08:08 <1> linux(6185) [ui-component] YUIComponentCreator.cc(createInternal):124 Creating UI component for "" 2014-10-08 02:08:08 <1> linux(6185) [liby2] genericfrontend.cc(main):764 YAST_IS_RUNNING is yes 2014-10-08 02:08:09 <1> linux(6185) [Ruby] yast/wfm.rb:181 Call client /usr/share/YaST2/clients/firstboot.rb 2014-10-08 02:08:10 <1> linux(6185) [Pkg] PkgModule.cc(instance):68 Redirecting ZYPP log to y2log 2014-10-08 02:08:13 <1> linux(6185) [Ruby] modules/ProductControl.rb:1226 Candidates: ["/y2update/control.xml", "/control.xml", "/etc/YaST2/control.xml"] 2014-10-08 02:08:13 <1> linux(6185) [Ruby] modules/ProductControl.rb:1234 Reading control file: /etc/YaST2/control.xml 2014-10-08 02:08:13 <1> linux(6185) [Ruby] modules/XML.rb:141 Reading /etc/YaST2/control.xml 2014-10-08 02:08:13 <1> linux(6185) [agent-xml] XmlAgent.cc(Read):750 Setting XML generic error handler 2014-10-08 02:08:13 <1> linux(6185) [agent-xml] XmlAgent.cc(Read):785 Freeing generic XML error handler 2014-10-08 02:08:19 <1> linux(6185) [Ruby] modules/PackageCallbacks.rb:3704 PackageCallbacks constructor -AA -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 09.10.14 05:31, Alex Armstrong wrote:
Alexander Graf wrote:
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
Thanks for taking a look at this. I've tested image: openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build235.5.raw.xz
from: http://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Rasp...
on 8 Oct. 14 and it boots to a functioning system, but has two failures.
Here is the breakdown: U-Boot loads and runs /boot.scr. Kernel loads and starts. All subsystems and modules load without failures. GPT starts , reads the SD card, checks the file system and resizes the root partition automatically. Systemd starts and begins loading units.
-- Here there is one failure -- [ 470.707495] systemd[1]: Found device /dev/disk/by-uuid/8b8c21e8-7bbe-41dd-a2a0-233eea2c7a2b. [ 470.728403] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 470.760556] systemd[1]: Starting Remote File Systems (Pre).
Ah, I guess systemd wants to boot up to the graphical multiuser target which demands a display manager. But JeOS doesn't include any. I'm not sure whether it's a good idea to change the default target on JeOS. Maybe we're better off ignoring the error report above.
--
Then I get to a login prompt on the serial terminal. I can login as root and execute normal system commands.
-- However, on the graphical display I have a second failure -- YaST starts in ncurses mode, but gives this error:
"Calling the YaST module 'firstboot_setup_dhcp' has failed."
*Note that I didn't have network (or even a keyboard) hooked up on this run.
Connecting a keyboard at this point works fine. 'Retrying' from the YaST error dialog fails again, and using the 'Back' button drops you to a working login prompt. The error says to check /var/log/YaST2/y2log.
I guess that's because of the missing network link :(. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Alexander Graf wrote:
On 09.10.14 05:31, Alex Armstrong wrote:
-- Here there is one failure -- [ 470.707495] systemd[1]: Found device /dev/disk/by-uuid/8b8c21e8-7bbe-41dd-a2a0-233eea2c7a2b. [ 470.728403] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 470.760556] systemd[1]: Starting Remote File Systems (Pre). Ah, I guess systemd wants to boot up to the graphical multiuser target which demands a display manager. But JeOS doesn't include any.
I'm not sure whether it's a good idea to change the default target on JeOS. Maybe we're better off ignoring the error report above.
I haven't noticed this error on subsequent boots. And it's easy enough to set multi-user.target as the default after first login - I agree we can ignore this for now.
--
Then I get to a login prompt on the serial terminal. I can login as root and execute normal system commands.
-- However, on the graphical display I have a second failure -- YaST starts in ncurses mode, but gives this error:
"Calling the YaST module 'firstboot_setup_dhcp' has failed."
*Note that I didn't have network (or even a keyboard) hooked up on this run.
Connecting a keyboard at this point works fine. 'Retrying' from the YaST error dialog fails again, and using the 'Back' button drops you to a working login prompt. The error says to check /var/log/YaST2/y2log. I guess that's because of the missing network link :(.
Alex
I tried again with build: openSUSE-Factory-ARM-JeOS-raspberrypi.armv6l-1.12.1-Build235.11.raw on 17 Oct. 14 This time I started it up with keyboard, monitor, net plugged in. I had the same network error and an additional error ('firstboot_language_keyboard cannot import namespace GfxMenu'). But using the 'Next' button allowed me to set the time zone and root password as well as the authentication method. After which I got to a working login prompt. At this point it seems to work fine, network ssh login, local login and serial login are all good. So, it seems to be working alright, just a few rough edges on first boot. I'm afraid I don't have time to chase the YaST bugs right now. I think the underlying problem has been fixed, and we can mark this thread as solved. -ARA -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 13.10.2014 um 17:16 schrieb Alexander Graf:
On 09.10.14 05:31, Alex Armstrong wrote:
-- However, on the graphical display I have a second failure -- YaST starts in ncurses mode, but gives this error:
"Calling the YaST module 'firstboot_setup_dhcp' has failed."
*Note that I didn't have network (or even a keyboard) hooked up on this run.
Connecting a keyboard at this point works fine. 'Retrying' from the YaST error dialog fails again, and using the 'Back' button drops you to a working login prompt. The error says to check /var/log/YaST2/y2log.
I guess that's because of the missing network link :(.
I've seen that on multiple occasions with boards connected to networks, so I considered it a Factory regression of YaST. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Alex Armstrong -
Alexander Graf -
Andreas Färber -
Dirk Müller -
Guillaume Gardet -
Michael Ströder