Le 07/11/2013 13:34, Alexander Graf a écrit : > On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gar...@free.fr> wrote: > >> Le 07/11/2013 11:17, Alexander Graf a écrit : >>> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gar...@free.fr> wrote: >>> >>>> Hi, >>>> >>>> here are some tests results of 13.1 images. Results are pretty bad ATM. :( >>>> >>>> >>>> * Beagleboard xM rev B : >>>> - Image fails to boot with the following error message: >>>> ******************************************************************************** >>>> [ 8.109588] Freeing unused kernel memory: 532K (c07e5000 - c086a000) >>>> setterm: cannot (un)set powersave mode: Inappropriate ioctl for device >>>> /usr/sbin/klogconsole >>>> Thu Nov 7 00:00:00 UTC 2013 >>>> [ 13.670684] ehci-omap ehci-omap.0: Can't get PHY device for port 1: -6 >>>> [ 15.271728] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is >>>> bad? >>>> [437097081.923981] Including oem partition info file >>>> [437097082.043030] Searching for boot device... >>>> [ 16.471771] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is >>>> bad? >>>> [ 17.671752] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is >>>> bad? >>>> [ 18.925598] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is >>>> bad? >>>> [ 18.933227] hub 1-0:1.0: unable to enumerate USB device on port 1 >>>> [437097110.607544] Failed to find boot device ! >>>> [437097110.639527] rebootException: reboot in 120 sec... >>>> ******************************************************************************** >>>> >>>> The USB problem seems to be known: >>>> http://www.spinics.net/lists/linux-omap/msg90670.html >>>> Is boot problem related? I do not know. >>>> >>>> D6 and D7 lights (related to MMC) are turned OFF when kernel start whereas >>>> it was ON with u-boot. >>>> So, MMC seems to be not working at all. It seems that kernel modules (at >>>> least omap mmc modules) from initrd are not loaded. Very strange. >>> If you boot with kiwidebug=1 you should be able to get a shell and check >>> whether the modules are loaded or not. >> Indeed, mmc modules are not loaded. But loading them manually does not help >> to get mmc device to appear. I think we are missing other drivers (maybe >> GPIO). > Could you quickly compare the defconfig for omap4 and the one we have to see > what we're missing?
I think it is missing from initrd only, not rootfs, since initrd has only some of kernel modules. I will try to add some kernel modules to our initrd and see if it helps. > >>>> * Pandaboard rev A3 : >>>> - Image hangs early with the following message: (Tested with 2 SD cards). >>>> ******************************************************************************** >>>> U-Boot SPL 2013.04 (Oct 21 2013 - 22:37:21) >>>> OMAP4430 ES2.2 >>>> OMAP SD/MMC: 0 >>>> ******************************************************************************** >>>> >>>> >>>> Is there anyone who could test those images on their baords, especially >>>> pandaboard? >>> Andrew reported the same issue. Could you please try with 12.3's SPL (MLO) >>> and/or u-boot.bin to boil down which component is at fault here? >> I managed to get u-boot working using old MLO (and copying u-boot.bin from >> boot/ folder to the root of the boot partition). > Does only replacing one of the two help already? Yes, replacing MLO only does help. I think our ext2 patch for MLO may be broken for 13.1 u-boot. Maybe we could bump u-boot version at the same time we check MLO patch? > >> But now, I get the following error in u-boot: >> ******************************************************************************** >> U-Boot SPL 2013.04-rc2 (Apr 17 2013 - 07:35:53) >> OMAP4430 ES2.2 >> OMAP SD/MMC: 0 >> >> >> U-Boot 2013.04 (Oct 21 2013 - 22:37:21) >> >> CPU : OMAP4430 ES2.2 >> Board: OMAP4 Panda >> I2C: ready >> DRAM: 1 GiB >> MMC: OMAP SD/MMC: 0 >> Using default environment >> >> In: serial >> Out: serial >> Err: serial >> Net: No ethernet found. >> Hit any key to stop autoboot: 0 >> mmc0 is current device >> SD/MMC found on device 0 >> 1562 bytes read in 12 ms (127 KiB/s) >> Running bootscript from mmc0 ... >> ## Executing script at 82000000 >> kerneladdr=0x80000000 >> ramdiskaddr=0x82000000 >> itest - return true/false on integer compare >> >> Usage: >> itest [.b, .w, .l, .s] [*]value1 <op> [*]value2 >> mmc0 is current device >> ** File not found boot/linux.vmx ** >> 4417952 bytes read in 241 ms (17.5 MiB/s) >> ** File not found /boot/omap4-panda-es.dtb ** >> Booting from mmc0 ... >> ERROR: Did not find a cmdline Flattened Device Tree >> Could not find a valid device tree >> ******************************************************************************** >> the problem is that bootpart has a bad value. >> 'echo $bootpart' returns '0:2' instead of 0. >> This is the default value in u-boot for panda but should be overwritten by >> our script. Why not? I found the problem. We must reset $bootpart otherwise value is not updated. >> >> 'itest' error can easily be fixed by setting usefdt and loadfdt to 0 by >> default. (I could submit a patch for this one later). > i thought we do an itest 0$var = 0 or so exactly to not run into this? Yes. But it seems there is still a problem with one of the itest. Defaulting to 0 is not a big deal. > >> Once all those little problems fixed manually, u-boot loads kernel and >> initrd, but I get: >> ******************************************************************************** >> Starting kernel ... >> >> undefined instruction >> pc : [<8000012c>] lr : [<00000090>] > Which instruction is that? Just run objdump -d on the vmlinux file and check > for the instruction at 0x12c Maybe the one before. objdump -d linux.vmx objdump: linux.vmx: File format not recognized Guillaume > > > Alex > >> sp : 804379b8 ip : 00436998 fp : 00436974 >> r10: 00000000 r9 : 00903ae0 r8 : 80000100 >> r7 : 00000ae7 r6 : 804369a0 r5 : 80000000 r4 : 80008001 >> r3 : 004369b8 r2 : 004369a0 r1 : 0000029c r0 : 80000000 >> Flags: Nzcv IRQs off FIQs off Mode SVC_32 >> Resetting CPU ... >> >> resetting ... >> ******************************************************************************** >> Which is very bad. :( >> >> >> Guillaume >> >> >> >>> >>> Alex >>> >> -- >> To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org >> To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org >> -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
