[opensuse-arm] openSUSE 13.1 beagle and panda images status
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. * 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? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
* 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? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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).
* 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). 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? 'itest' error can easily be fixed by setting usefdt and loadfdt to 0 by default. (I could submit a patch for this one later). Once all those little problems fixed manually, u-boot loads kernel and initrd, but I get: ******************************************************************************** Starting kernel ... undefined instruction pc : [<8000012c>] lr : [<00000090>] 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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?
* 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?
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?
'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?
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. 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
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? ;)
'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 :)
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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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. :(
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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit : > On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
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
On 07.11.2013, at 14:37, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
> Le 07/11/2013 11:17, Alexander Graf a écrit : >> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
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.
Ok, forget what I said. So you're saying that the for loop does not update $bootpart when it already contains a value? That sounds pretty broken. Yes, just reset it before the for loop then.
> '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?
Let's make it obvious: should_load_fdt should_use_fdt
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?
I'd say it's a bug. But I know very little about the way Allwinner SoCs work.
> 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.
Hrm. Maybe the kernel gets relocated down? I have no idea. Either way, __turn_mmu_on_loc only contains addresses to functions it wants to call. We should never reach that as instructions that get executed. I'm also slightly confused why this happens. This is the same kernel as the beagle one, right? So there really should be no major difference between the two kernel execution paths. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 15:12, Alexander Graf a écrit :
On 07.11.2013, at 14:37, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit : > On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote: > >> Le 07/11/2013 11:17, Alexander Graf a écrit : >>> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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. 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. Ok, forget what I said.
So you're saying that the for loop does not update $bootpart when it already contains a value? That sounds pretty broken. Yes, just reset it before the for loop then.
Yes, this is what I said. (Tested on pandaboard). Maybe it is not broken but a feature? ;)
>> '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? Let's make it obvious:
should_load_fdt should_use_fdt
Ok. One more thing. Upstream uses $fdtfile and we are using $fdt. Should we update to $fdtfile? I think so, since beagle and panda have a special function (findfdt) which set $fdtfile to the right file for a given board version/revision.
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? I'd say it's a bug. But I know very little about the way Allwinner SoCs work.
Well, it seems it is not very a DT but they call this a sys_config file. So let's it like this.
Hrm. Maybe the kernel gets relocated down? I have no idea. functions it wants to call. We should never reach that as instructions that get executed.
I'm also slightly confused why this happens. This is the same kernel as the beagle one, right? So there really should be no major difference between the two kernel execution paths.
Yes, this is very strange. Maybe a bad loading addr? Or an overlap with initrd? I do not know. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.11.2013, at 15:45, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 15:12, Alexander Graf a écrit :
On 07.11.2013, at 14:37, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
> Le 07/11/2013 13:34, Alexander Graf a écrit : >> On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote: >> >>> Le 07/11/2013 11:17, Alexander Graf a écrit : >>>> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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. 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. Ok, forget what I said.
So you're saying that the for loop does not update $bootpart when it already contains a value? That sounds pretty broken. Yes, just reset it before the for loop then.
Yes, this is what I said. (Tested on pandaboard). Maybe it is not broken but a feature? ;)
>>> '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? Let's make it obvious:
should_load_fdt should_use_fdt
Ok.
One more thing. Upstream uses $fdtfile and we are using $fdt. Should we update to $fdtfile? I think so, since beagle and panda have a special function (findfdt) which set $fdtfile to the right file for a given board version/revision.
Works for me, if this is truly universal in upstream u-boot and not just an OMAP specific thing. Alex
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? I'd say it's a bug. But I know very little about the way Allwinner SoCs work.
Well, it seems it is not very a DT but they call this a sys_config file. So let's it like this.
Hrm. Maybe the kernel gets relocated down? I have no idea. functions it wants to call. We should never reach that as instructions that get executed.
I'm also slightly confused why this happens. This is the same kernel as the beagle one, right? So there really should be no major difference between the two kernel execution paths.
Yes, this is very strange. Maybe a bad loading addr? Or an overlap with initrd? I do not know.
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 15:46, Alexander Graf a écrit :
On 07.11.2013, at 15:45, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 15:12, Alexander Graf a écrit :
On 07.11.2013, at 14:37, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit : > On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote: > >> Le 07/11/2013 13:34, Alexander Graf a écrit : >>> On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote: >>> >>>> Le 07/11/2013 11:17, Alexander Graf a écrit : >>>>> On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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. 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. Ok, forget what I said.
So you're saying that the for loop does not update $bootpart when it already contains a value? That sounds pretty broken. Yes, just reset it before the for loop then. Yes, this is what I said. (Tested on pandaboard). Maybe it is not broken but a feature? ;)
>>>> '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? Let's make it obvious:
should_load_fdt should_use_fdt Ok.
One more thing. Upstream uses $fdtfile and we are using $fdt. Should we update to $fdtfile? I think so, since beagle and panda have a special function (findfdt) which set $fdtfile to the right file for a given board version/revision. Works for me, if this is truly universal in upstream u-boot and not just an OMAP specific thing.
In upstream u-boot, you have findfdt function for omap3, 4, 5 and am335x. But $fdtfile is used for all boards using DT. Please accept SR #206130. Guillaume
Alex
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? I'd say it's a bug. But I know very little about the way Allwinner SoCs work. Well, it seems it is not very a DT but they call this a sys_config file. So let's it like this.
Hrm. Maybe the kernel gets relocated down? I have no idea. functions it wants to call. We should never reach that as instructions that get executed.
I'm also slightly confused why this happens. This is the same kernel as the beagle one, right? So there really should be no major difference between the two kernel execution paths. Yes, this is very strange. Maybe a bad loading addr? Or an overlap with initrd? I do not know.
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Le 07/11/2013 14:19, Alexander Graf a écrit :
On 07.11.2013, at 14:15, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 14:04, Alexander Graf a écrit :
On 07.11.2013, at 14:00, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit : > On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
Any update on u-boot? Another good point to bump u-boot version is new versions have full support for Device Tree. And (after workarounded MLO problem,) Pandaboard kernel start to boot boot when using a DTB (and then fails to find MMC for similar reasons as beagle xM failed, apparently) whereas without DTB I get the "undefined instruction" error. Guillaume (...) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 07/11/2013 14:00, Guillaume Gardet a écrit :
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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.
I added '<file name="drivers/gpio/*"/>' to driver list in kiwi since MMC0 uses TWL4030 GPIOs and now MMC is tried to be detected but fails: ******************************************************************************** [ 8.125213] 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.410552] twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules [ 13.683227] ehci-omap ehci-omap.0: Can't get PHY device for port 1: -6 [ 14.136383] omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ [ 14.142791] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 [437097413.135681] Starting boot shell on /dev/tty2 [ 15.306274] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [437097414.536286] Including oem partition info file [437097414.647187] Searching for boot device... [ 16.506408] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 17.706542] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.906585] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.914001] hub 1-0:1.0: unable to enumerate USB device on port 1 [437097442.617462] Failed to find boot device ! ******************************************************************************** The main problem seems to be: "twl4030_gpio: can't dispatch IRQs from modules" and as said here: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/085111.h... "twl4030_gpio: can't dispatch IRQs from modules ... apparently because there is no way to unregister a irq once the module is unloaded. That makes sdmmc pretty much unusable if twl gpio is built as a module." I will try to add more kernel drivers but I think we should have TWL4030 GPIO built-in and not as a module. Guillaume
* 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 07/11/2013 18:56, Guillaume Gardet a écrit :
Le 07/11/2013 14:00, Guillaume Gardet a écrit :
Le 07/11/2013 13:34, Alexander Graf a écrit :
On 07.11.2013, at 13:19, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 07/11/2013 11:17, Alexander Graf a écrit :
On 07.11.2013, at 11:14, Guillaume Gardet <guillaume.gardet@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. I added '<file name="drivers/gpio/*"/>' to driver list in kiwi since MMC0 uses TWL4030 GPIOs and now MMC is tried to be detected but fails:
[ 8.125213] 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.410552] twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules [ 13.683227] ehci-omap ehci-omap.0: Can't get PHY device for port 1: -6 [ 14.136383] omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ [ 14.142791] omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 [437097413.135681] Starting boot shell on /dev/tty2 [ 15.306274] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [437097414.536286] Including oem partition info file [437097414.647187] Searching for boot device... [ 16.506408] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 17.706542] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.906585] hub 1-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? [ 18.914001] hub 1-0:1.0: unable to enumerate USB device on port 1 [437097442.617462] Failed to find boot device ! ********************************************************************************
The main problem seems to be: "twl4030_gpio: can't dispatch IRQs from modules"
and as said here: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/085111.h... "twl4030_gpio: can't dispatch IRQs from modules ... apparently because there is no way to unregister a irq once the module is unloaded.
That makes sdmmc pretty much unusable if twl gpio is built as a module."
I will try to add more kernel drivers but I think we should have TWL4030 GPIO built-in and not as a module.
Adding TWL4030 gpio as built-in instead of module does help to boot on MMC. What would be the best way to add this patch? I would say: * Adding kernel-default (and kernel-source?) to 13.1:Ports to fix current version * Adding it to 13.1/master GIT repo for futur versions Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Guillaume Gardet