Hi, today I received my Pandaboard ES (Rev. B3) and I tried to use Fedora-Minimal-VFAT-armhfp-19-1-sda.raw.xz to boot it and I received on the serial console:
U-Boot SPL 2013.04 (Jun 17 2013 - 12:42:04) OMAP4460 ES1.1 SDRAM: identified size not same as expected size identified: 0 expected: 4000000
Is there already a solution for this problem?
Searching for the problem gave me some solutions/hints: https://groups.google.com/forum/#!topic/pandaboard/OWvyla72e00 http://www.eewiki.net/display/linuxonarm/PandaBoard#PandaBoard-FAQ https://groups.google.com/forum/#!topic/pandaboard/n5h8wKJ84Ok
Before trying myself I wonder if someone already has a ready-to-use solution for it? (Because it is my only ARM-system compiling might get complicated for me...)
Best regards, Franz
P.S.: Will this problem also happen in Fedora 20 or are the developers aware of this problem? (Or is Rev B3 a not-supported-out-of-the-box system?)
ugh.. CCing the list this time, sorry Franz for the repeat...
On Tue, Aug 27, 2013 at 2:40 PM, Franz Ilano franzila@lotkit.org wrote:
Hi, today I received my Pandaboard ES (Rev. B3) and I tried to use Fedora-Minimal-VFAT-armhfp-19-1-sda.raw.xz to boot it and I received on the serial console:
U-Boot SPL 2013.04 (Jun 17 2013 - 12:42:04) OMAP4460 ES1.1 SDRAM: identified size not same as expected size identified: 0 expected: 4000000
Is there already a solution for this problem?
Searching for the problem gave me some solutions/hints: https://groups.google.com/forum/#!topic/pandaboard/OWvyla72e00 http://www.eewiki.net/display/linuxonarm/PandaBoard#PandaBoard-FAQ https://groups.google.com/forum/#!topic/pandaboard/n5h8wKJ84Ok
Before trying myself I wonder if someone already has a ready-to-use solution for it? (Because it is my only ARM-system compiling might get complicated for me...)
Best regards, Franz
P.S.: Will this problem also happen in Fedora 20 or are the developers aware of this problem? (Or is Rev B3 a not-supported-out-of-the-box system?)
With Rev B3, the manufacture (Svtronics) used a newer version of Elpida memory, as the version used on the original ES went EOL..
However this new memory only has 1 CS line, (where as the old module had 2 lines)..
The u-boot fix for right now, is to disable: #define CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap4_common.h;hb=...
and the memory will be auto-detected. Memory patches where recently posted for another omap4470 board on the u-boot mailing list that also uses this same newer module, so at some point we should patch u-boot to detect this revision via the gpio's and use the newer memory settings.
Afterwhich u-boot will load the kernel just fine...
So, now for the really bad part... Some versions of the linux kernel also touch the CS lines.. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/ar...
It's really great timing, as there really isn't any paid TI omap4/panda developers left...
Regards,
On Tue, Aug 27, 2013 at 5:14 PM, Robert Nelson robertcnelson@gmail.com wrote:
It's really great timing, as there really isn't any paid TI omap4/panda developers left...
And how do they expect the Pandaboard to be of any use if nobody is working on the kernel? Sheesh..
FC
On Tue, Aug 27, 2013 at 3:40 PM, Fernando Cassia fcassia@gmail.com wrote:
On Tue, Aug 27, 2013 at 5:14 PM, Robert Nelson robertcnelson@gmail.com wrote:
It's really great timing, as there really isn't any paid TI omap4/panda developers left...
And how do they expect the Pandaboard to be of any use if nobody is working on the kernel? Sheesh..
I agree... You should read the pandaboard thread, their response is pretty hilarious when i asked them about getting the memory datasheet (which i still haven't got..)
Luckily there are still a lot of pre-B3's with the good old memory available: http://www.digikey.com/product-detail/en/UEVM4460G-02-01-00/1055-1000-ND/277...
Regards,
On 08/27/2013 10:43 PM, Robert Nelson wrote:
[...] Luckily there are still a lot of pre-B3's with the good old memory available: http://www.digikey.com/product-detail/en/UEVM4460G-02-01-00/1055-1000-ND/277... [...]
Hi, I ordered it. It is a Pandaboard ES (Rev. B2)! U-Boot works indeed, but Fedora crashes all the time. So is FC19 regarded stable on Pandaboard ES (Rev. B2)?
I see this (full listing at http://pastebin.com/VpWEteFg): U-Boot SPL 2013.04 (Jun 17 2013 - 12:42:04) OMAP4460 ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img
U-Boot 2013.04 (Jun 17 2013 - 12:42:04)
CPU : OMAP4460 ES1.1 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 reading boot.scr ** Unable to read file boot.scr ** reading uEnv.txt 186 bytes read in 4 ms (44.9 KiB/s) Importing environment from mmc0 ... Running uenvcmd ... 17848 bytes read in 46 ms (378.9 KiB/s) Running boot.scr script from mmc ... ## Executing script at 82000000 Welcome to a-b-c 0.56.
Using findfdt to set u_dtb Using defaults for omap4-panda-es.dtb, but will not load dtb during startup. Will scan for kernels on mmc usb, using ext4 ext2 fat filesystems with bootz
Starting menu init....
Using kernel k1 (3.9.5-301.fc19.armv7hl). Auto-booting 3.9.5-301.fc19.armv7hl in 3 seconds. Type ^C to abort then run menu for help. 3 2 1... 4299496 bytes read in 233 ms (17.6 MiB/s) 15102401 bytes read in 727 ms (19.8 MiB/s) bootargs are ro rootwait rhgb quiet root=UUID=ec232929-5693-4a59-8a16-67e70d2fae0f console=ttyO2,115200n8 ## Loading init Ramdisk from Legacy Image at 81600000 ... Image Name: initramfs Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 15102337 Bytes = 14.4 MiB Load Address: 00000000 Entry Point: 00000000
Starting kernel ...
[ 0.299224] omap_mux_get_by_name: Could not find signal sys_nirq [ 0.300292] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [ 0.316894] omap_init_sham: platform not supported [ 0.316894] omap_init_aes: platform not supported [ 2.018585] voltdm_scale: No voltage scale API registered for vdd_mpu [ 2.201934] Power Management for TI OMAP4. [ 2.209411] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ OK ] Started dracut initqueue hook. Starting dracut pre-mount hook... [ OK ] Started dracut pre-mount hook. Mounting /sysroot... [ OK ] Mounted /sysroot. [ OK ] Reached target Initrd Root File System. Starting Reload Configuration from the Real Root... [ OK ] Started Reload Configuration from the Real Root. [ OK ] Reached target Initrd File Systems. [ OK ] Started Show Plymouth Boot Screen. [ OK ] Reached target Paths. [ OK ] Reached target Basic System. [ OK ] Reached target Initrd Default Target. [ 38.405273] Unable to handle kernel NULL pointer dereference at virtual address 0000000e [ 38.413757] pgd = c0004000 [ 38.416595] [0000000e] *pgd=00000000 [ 38.420349] Internal error: Oops: 5 [#1] SMP ARM [ 38.425170] Modules linked in: panel_tfp410 omapdss mmc_block [ 38.431213] CPU: 1 Tainted: G W (3.9.5-301.fc19.armv7hl #1) [ 38.438323] PC is at 0xc11219a8
A second try gives this (full listing at http://pastebin.com/3HbigJV2): [...] Starting kernel ...
[ 0.299163] omap_mux_get_by_name: Could not find signal sys_nirq [ 0.300231] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [ 0.316833] omap_init_sham: platform not supported [ 0.316864] omap_init_aes: platform not supported [ 2.018585] voltdm_scale: No voltage scale API registered for vdd_mpu [ 2.201904] Power Management for TI OMAP4. [ 2.209442] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 3.755828] Unable to handle kernel paging request at virtual address f09287e4 [ 3.763397] pgd = eef60000 [ 3.766235] [f09287e4] *pgd=00000000 [ 3.769989] Internal error: Oops: 80000005 [#1] SMP ARM [ 3.775451] Modules linked in: omapdss(+)[ 3.778717] Unable to handle kernel paging request at virtual address be986dbc [ 3.778717] pgd = eeeb0000 [ 3.778717] [be986dbc] *pgd=bd1c8831
[ 3.793609] mmc_block [ 3.796264] CPU: 0 Not tainted (3.9.5-301.fc19.armv7hl #1) [...]
It seems to me that the kernel isn't stable on this platform. I wonder why it does not crash all the time at the same place....
Any ideas what's goiing on?
Have fun! Franz
P.S.: I will try to compile a different kernel by myself.
-
Fernando Cassia -
Franz Ilano -
Robert Nelson