Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet
wrote: Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet
wrote: Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet
wrote: Le 07/11/2013 11:17, Alexander Graf a écrit : > On 07.11.2013, at 11:14, Guillaume Gardet
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? Hrm. We're at rc2 here. Maybe it is a good idea to bump the version after all. Sigh. Could you do it, please? I will not have time for that ATM. :( I can try, but if I don't get around until Saturday it won't happen for at least another week.
Ok. Thanks.
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. Or use a different variable name? ;) bootpart is the right name I think, we just need to update it after loading our script.
IIRC I set everything up in a way that you can always override any variable from nvram, if you have persistent nvram.
At u-boot load, u-boot try to get a working environment from flash, if it fails it redefines all vars. Moreover, in our script, we do not call saveenv to save datas. So, it should be fine to reset bootpart before updating it. No? Maybe I miss something, since I am not familiar with nvram.
'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. ok :)
I found the problem. U-boot already defines loadfdt: echo $loadfdt load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
Do we want to change our var name our do we overwrite loadfdt? We want to change the var name.
Ok. load_fdt or something else?
I think overwriting a u-boot var is not a good idea. Moreover, why do we have 2 vars: usefdt and loadfdt? if we want to use DT, we must load it. And we do not need to load it if we do not use it. Isn't it? I would like to remove loadfdt and only use usefdt. Are you ok? Not at all.
On highbank and midway we already get a working device tree preloaded by firmware. There we do not have to load an fdt, but only use it.
Good to know. Thanks for info. In melea1000/cubieboard, we load DT but we do not use it (in bootz cmdline). Does the kernel read a specific addr for DT or is it a bug?
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 You need to run objdump on the vmlinux file. linux.vmx is a uImage. I have: c000812c <__turn_mmu_on_loc>: c000812c: c000812c .word 0xc000812c c0008130: c05558f8 .word 0xc05558f8 c0008134: c0555918 .word 0xc0555918 Hrm. That is 0x812c. There is nothing earlier? In fact, looking at the lr address, we might be in self-extract code here...
I uploaded my objdump here: http://guillaume.gardet.free.fr/openSUSE/objdump.txt Please download it, so that you can have a look at it. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org