On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gar...@free.fr> wrote:
> > Le 07/11/2013 14:04, Alexander Graf a écrit : >> On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gar...@free.fr> wrote: >> >>> 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? >> 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. > > >> >>>>> 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. > >> >>>>> '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. > 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. > >> >>> >>>>> 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... Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
