Le 07/11/2013 14:04, Alexander Graf a écrit :
> On 07.11.2013, at 14:00, Guillaume Gardet <[email protected]> wrote:
>
>> Le 07/11/2013 13:34, Alexander Graf a écrit :
>>> On 07.11.2013, at 13:19, Guillaume Gardet <[email protected]> wrote:
>>>
>>>> Le 07/11/2013 11:17, Alexander Graf a écrit :
>>>>> On 07.11.2013, at 11:14, Guillaume Gardet <[email protected]>
>>>>> 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. :(
>
>>>> 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.
>
>>>> '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?
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?
>
>>
>>>> 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
Guillaume
>
>
> Alex
>
>
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
