Forums » Software Development »
Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND
Added by Omar Rahim over 11 years ago
Customer states that they are having difficulty flashing MLO and U-Boot into the 3354-GX-X38 module. No issues encountered when flashing MLO and U-Boot in the 3359-GX-226 module.
Replies (46)
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
Errr.... any more details than that???
The MLO and u-Boot images must be updated for the 3354 DDR3 configuration. Are they using the correct version of the MLO and u-Boot?
What is the FLASH procedure [edit] being used?
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Kim Weller over 11 years ago
Yes, MLO & u-Boot were rebuilt for DDR3 and ran fine on the 3354 w/ DDR3 booting from SD card.
-Kim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
Could you provide any details on what your FLASH procedure is and what you are seeing when you try to boot?
What bootmode are you configuring for FLASH boot?
This will allow us to reproduce the problem here.
Thanks.
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Kim Weller over 11 years ago
Here's my programming steps with NAND OOB info.:
U-Boot# nand bad
Device 0 bad blocks:
00780000
U-Boot# mmc rescan
U-Boot# mw.b 0x82000000 0xFF 0x20000
U-Boot# fatload mmc 0 0x82000000 MLO
reading MLO
39123 bytes read
U-Boot# nandecc hw 2
HW ECC BCH8 Selected
U-Boot# nand erase 0x0 0x20000
NAND erase: device 0 offset 0x0, size 0x20000
Erasing at 0x0 -- 100% complete.
OK
U-Boot# nand write.i 0x82000000 0x0 0x20000
NAND write: device 0 offset 0x0, size 0x20000
131072 bytes written: OK
U-Boot# nand bad
Device 0 bad blocks:
00780000
U-Boot# nand dump.oob 0
Page 00000000 dump:
OOB:
00 ff c8 b0 e8 12 b2 4a
63 70 83 0f c6 76 57 00
e9 0a 91 3b a9 5d 4f 2e
f7 b5 43 f1 5e 00 c8 da
5f fe c0 b5 08 42 92 68
2e 79 5e 00 b6 0d 50 88
f5 13 a9 a3 62 20 8b 28
84 00 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
U-Boot#
removed sd-card, power-on reset <<<
U-Boot# CCCCCCCCCCCCC
inserted sd-card, power-on reset <<<
U-Boot SPL 2011.09-00000-gab29171 (Feb 22 2013 - 13:25:56)
Texas Instruments Revision detection unimplemented
MityARM335x profile 1 - Model No: 3354-GX-X38-RC Serial No: 124511
configuring for 512 MB DDR3
Critical Link AM335X Dev Kit
PLL configuration complete
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2011.09-00000-gab29171-dirty (Apr 09 2013 - 15:05:34)
I2C: readyWARNING: Caches not enabled
NAND: HW ECC Hamming Code selected
512 MiB
MMC: OMAP SD/MMC: 0
- Warning - bad CRC, using default environment
Net: cpsw
Hit any key to stop autoboot: 0
U-Boot#
U-Boot#
U-Boot# nand bad
Device 0 bad blocks:
00000000
00780000
U-Boot# nand dump.oob 0
Page 00000000 dump:
OOB:
00 ff c8 b0 e8 12 b2 4a
63 70 83 0f c6 76 57 00
e9 0a 91 3b a9 5d 4f 2e
f7 b5 43 f1 5e 00 c8 da
5f fe c0 b5 08 42 92 68
2e 79 5e 00 b6 0d 50 88
f5 13 a9 a3 62 20 8b 28
84 00 ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
U-Boot# nandecc hw 2
HW ECC BCH8 Selected
U-Boot# nand bad
Device 0 bad blocks:
00000000
00780000
U-Boot# md.l 0x44e10040 1
44e10040: 004203e4 ..B.
U-Boot#
control_status register: 004203e4 <<<
-Kim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
Thanks.
What are your boot jumper settings?
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Kim Weller over 11 years ago
001001110100 (bit 0 on the left) JJOJJOOOJOJJ (J = jumper, O = open)
-Kim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
Hi,
Other than the fact that the selected boot mode will try to use the UART first over the NAND (and you aren't programming u-boot, only the MLO -- you'll need to program both into NAND), it's not obvious to me why this is not working. Just to be sure, you are waiting long enough for the UART loader to timeout and try the NAND before quitting, right?
We will need to reproduce your boot configuration and try it here with the updated u-Boot code supporting the DDR3 (AM3354) configuration. As soon as we have more information I will re-post. Sorry for the delay. Do you have a need-by date for this capability? I am fairly certain this is a software issue (MLO) or configuration issue.
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Kim Weller over 11 years ago
I have programmed both MLO and u-boot with the same results. It appears MLO is not loading & running. Why are the NAND blocks marked bad after flashing MLO and u-boot?
We're mainly have DDR3 (AM3354) CPU modules and ran out of the few DDR2 (AM3359) CPU modules for our new development boards. We need this problem resolved soon and appreciate any help you can give us.
Thanks,
-Kim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
I think I am having the same problem as Kim.
I use similar scripts:
mmc rescan; mw.b 0x82000000 0xFF 0x80000; fatload mmc 0 0x82000000 MLO; nandecc hw 2; nand erase 0x0 0x80000; nand write.i 0x82000000 0x0 $filesize
mmc rescan; mw.b 0x82000000 0xFF 0x1E0000; fatload mmc 0 0x82000000 u-boot.img; nandecc hw 2; nand erase 0x80000 0x1E0000; nand write.i 0x82000000 0x80000 $filesize
These scripts have no problem programming u-boot onto the AM3359/DDR2/256MB board's NAND, but do not appear to work with the AM3354/DDR3/512MB board.
I'm using the Critical Link Dev Kit as the carrier, with the same jumper settings for both the AM3359/DDR2/256MB and AM3354/DDR3/512MB boards - from 11 downto 0: JJUUUUUJJUJJ. I understand this jumper config sets to first boot UART, then XIP, then MMC, then NAND. With the MMC card in, the console will print 'C's (presumably UART boot) and I can boot fine with the space bar kicking it out of UART boot and into MMC boot. This works on both boards. When I remove the MMC card, the AM3359/DDR2/256MB board boots fine from NAND, but the AM3354/DDR3/512MB board never makes it to the SPL. And just to eliminate a variable, I tried with JJUUUUUUJUJJ, which boots from NAND first. I didn't get the 'C' on the console, but the results were otherwise the same; the AM3359 booted from NAND, while the AM3354 didn't appear to make it to the SPL.
I verified this using same (latest from git) builds of of u-boot/MLO on both systems.
Like Kim, I need a solution as I am low on AM3359/DDR2/256MB mityarms.
One other thing - and I'm not sure this is helpful but I'll note it anyway: On the AM3354/DDR3/512MB boards I received, I first used the MLO.readeeprom SPL linked on this page: http://support.criticallink.com/redmine/projects/armc8-platforms/wiki/Das_U-Boot_Port . This MLO indicated that the factory EEPROM on these boards was not programmed. I did not get this warning using the latest u-boot pulled from git on the AM335XPSP_04.06.00.08 branch when booting from MMC. Is it possible that there is a problem with the EEPROM that isn't being caught by this version of u-boot? Could such a problem impact the NAND?
Any help here would be appreciated.
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
I will be looking in to this very soon and will report back.
cheers
/Tim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
A quick update...
I have not had a chance to verify this suspicion, but the current u-boot is configured to use a 2K page size... the 4gb NAND uses a 4K page size...
I am going to try modifying u-boot (its in the config, so you can try it if you don't want to wait for me).
cheers
/Tim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
Tim,
Thanks for the tip.
I'm a bit uneasy hacking the bootloader for hardware that I didn't design and don't have a lot of details on (like schematic, BOM, etc.). Actually, a strong selling point for the mityarm is that I wouldn't have to worry about the lowlevel details of the hardware and bootloader.
I'll be happy to try this if you can give me more details on what I should modify - i.e. exactly which file and which line I need to modify.
Also, I have to ask: If block size is indeed the problem, how did Critical Link validate the 512MB flash hardware in the new boards? Is it possible that you have a branch of the bootloader code that is configured for the 512MB device?
Finally, if this block size fix does the trick, what would Crtitical Link's plan be moving forward regarding source control? Would you fork the bootloader for the 512MB NAND, branch it, put it upon us customers to make a guided hack, or something altogether different?
Thanks,
Mike Karasoff
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
Hi Mike,
We are still chasing this here. The 2K vs. 4K page size issue may not be correct for the 512 MB (it came up in conversation for supporting a 1 GB configuration and I wasn't sure if the 512MB part is 4K or 2K, we are tracking it down).
When we tested the DDR3 AM3354 module originally, we booted the unit to linux via MMC/SD and tested accessing the NAND flash using the linux MTD FLASH utilites, which are a bit more robust than u-Boot (e.g., they read the PAGE size, etc. from the NAND instead of being hard-coded). We did not observe any issues with this test. This is how part of our factory test works. We will boot a unit from SD, run some low level memory tests, then loads up linux to run some higher level interface testing (including mtd FLASH utilities, GPIO, RMII, etc.) that we can log.
We had not tested booting from NAND when we sent out the first run modules.
We intend to determine why booting from NAND is problematic with these modules and will provide a bootloader solution, but it may take a bit of time to get to the bottom of it. When we selected the NAND we confirmed that TI's ROM bootloader was supposed to support it in our current configuration, and we can access it when booted to linux, so we are fairly certain it's either a procedural issue with programming the NAND or bug in the MLO stage. Ideally, if it's a u-Boot or MLO fix, we will update the current u-Boot branch supporting the DDR3 modules.
I am sorry for the delay, we are working the issue. We are still producing the DDR2 modules if you are in a pinch, but we're hoping we can resolve this fairly soon.
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
Mike,
Thanks for the quick reply.
For our application, the 256MB flash is not a problem, but our current design relies on the 512DDR3 and the ability to boot from NAND. From what I can tell, 512MB Ram/256MB NAND is not an option that is immediately available from Critical Link.
As an immediate solution, we can boot from MMC for the next week or two. Long term, we will need to either:
1. Boot from 512MB NAND.
2. Order parts with 256MB NAND and 512MB DDR3 - assuming that the NAND part is the issue and that the AM3354 part supports such a configuration.
3. Revisit our software arcitecture.
If we have to go with options 2 or 3 then I'd prefer to know sooner. Otherwise, we'll end up have to deal with lead times - and/or - software changes too far down the line. Please let me know if Critical Link reaches a dead end here.
Thanks
Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
Mike
While I chase down the block size issue, other Mike pointed out that you have bit 9 of the SYSBOOT pins as a 1. This tells the boot ROM that the NAND device is doing
error correction. 99.9% sure you don't want this as the NAND device does not do ECC (as far as I know).
Also, the boot mode you have selected [ 00100 ] makes the NAND the last device to try and puts XIP w/Wait before it.
You might try setting bits 4-0 to 10011, which is NAND/NAND/MMC0/UART0.
cheers
/Tim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
The good news is I think we have found the cause of the issue.
When the 335x boot ROM sees the 4K page size in the NAND, it switches to a 16 bit ECC scheme, hence the data written with an 8 bit scheme
is invalid.
The less good news is that the 16 bit ECC code is not in u-boot. I am in the processes of patching u-boot to work with 16 bit ECC and will
get a version out as soon as possible, but it won't be today.
We have to look at the kernel as well to see how it deals with the device.
/Tim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
Tim,
Thanks. We bit 9 set to zero, we no longer get curious boottime ECC error messages we were getting on the DDR2 board.
Still I cannot boot from NAND on the DDR3 board, even with both 9 set to zero and bits 4-0 to 10011.
Also, regarding the XIP w/wait, with 4-0 set to 00100 - I'm not sure what exactly XIP is waiting on. The DDR2 board seems to boot just fine from NAND with this setting, and seems to ignore XIP all together. Does the module even have capability for XIP? I thought MMC required a directly addressable memory device, like a parallel NOR or EEPROM.
For what its worth, the reason we boot with the 00100 configuration in development is that it is a tad easier to develop when trying to boot from MMC first. This configuration prioritizes MMC over NAND in the boot sequence. This way, we can select between MMC and NAND by removing the SD card, without mucking with the jumpers. Do you have any alternative suggestions for prioritizing MMC over NAND? Is having XIP in the boot sequence a bad thing?
Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
Mike,
booting from MMC first sounds like a good plan to me :)
as for the XIP/wait... if the bootrom is not stalling waiting for the device, then you are all set!
There are no XIP bootable devices on the AM335X module or devkit board, and you are correct... XIP requires a directly addressable device.
The bit 9 issue will not fix the 512MB flash boot issue... You'll have to wait for the BSH16 patches to u-boot... almost there (I hope!)
cheers
/Tim
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
We have to look at the kernel as well to see how it deals with the device.
Does this mean there may be an issue with the kernel as well?
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Williamson over 11 years ago
It depends on whether you want to be able to (re)flash a bootable MLO from linux. If the linux kernel does not support BCH16 in the same format (it may be using BCH8, which is OK with this particular part) as the TI ROM bootloader requires we'll need to patch it to support that format.
-Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
Mike,
OK, this makes sense. Sorry for being a bit slow on the uptake. The issue isn't the flash per-se, its matching the SPL to the TI ROM scheme. Am I getting this right?
I can't speak for other customers, but for us flashing the MLO from Linux is not nearly at the priority that booting from NAND is. In fact, I'd almost prefer not to be in a position where I would need to flash the MLO from Linux.
Just a couple more questions (sorry to pester):
1. Will the modified MLO you are building support a BCH8 u-image.bin?
2. Will I still be able to flash the u-image.bin from Linux in whatever form (BCH8 or BCH16) Linux supports?
Thanks again for all your help here.
Mike
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
And also, I'm assuming that the bootloader environment section falls into the same category as u-boot.img. That is, the MLO doesn't rely on this section, and that it just needs to be in a formation to u-boot supports.
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
formation to u-boot supports. I mean "format that u-boot supports". Sorry, spell check....
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Michael Karasoff over 11 years ago
Out of idle curiosity, I ran mtdinfo on both boards:
For the 256MB:
mtd1
Name: SPL
Type: nand
Eraseblock size: 131072 bytes, 128.0 KiB
Amount of eraseblocks: 1 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: true
For the 512MB:
mtd1
Name: SPL
Type: nand
Eraseblock size: 262144 bytes, 256.0 KiB
Amount of eraseblocks: 0 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 4096 bytes
Sub-page size: 1024 bytes
OOB size: 224 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: false
Could there be a write protection issue, or is this normal?
RE: Difficulty in flashing MLO and U-Boot to the AM3354 with 512MB NAND - Added by Tim Iskander over 11 years ago
Mike
I discovered this same issue yesterday. The mtdparts in the kernel where set up for the 256MB part and not updated for the 512MB part. With the larger block size of the 512MB part, many of the partitions no longer fall on erase block boundaries and linux thus makes them read-only (you can see the error messages in the boot msgs). As luck would have it, the partition our factory test uses to check the NAND was one that aligned with the erase blocks on both parts, so the test passes (the factory test is really just checking that the NAND part is properly installed on the board).
I have fixed the mtdparts in my development branch of the kernel, so it should get up into our git repository soon.
root@mityarm-335x:~# cat /proc/mtd dev: size erasesize name mtd0: 00800000 00010000 "NOR User Defined" mtd1: 00040000 00040000 "SPL" mtd2: 00040000 00040000 "SPL.backup1" mtd3: 00040000 00040000 "SPL.backup2" mtd4: 00040000 00040000 "SPL.backup3" mtd5: 003c0000 00040000 "U-Boot" mtd6: 00040000 00040000 "U-Boot Env" mtd7: 00a00000 00040000 "Kernel" mtd8: 1f100000 00040000 "File System" root@mityarm-335x:~# mtdinfo /dev/mtd1 mtd1 Name: SPL Type: nand Eraseblock size: 262144 bytes, 256.0 KiB Amount of eraseblocks: 1 (262144 bytes, 256.0 KiB) Minimum input/output unit size: 4096 bytes Sub-page size: 1024 bytes OOB size: 224 bytes Character device major/minor: 90:2 Bad blocks are allowed: true Device is writable: true