Mity CPU Platforms » MitySOM-335x (ARM Cortex-A8 Based Products)

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

Yes, MLO & u-Boot were rebuilt for DDR3 and ran fine on the 3354 w/ DDR3 booting from SD card.

-Kim

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

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)

• 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

Thanks.

What are your boot jumper settings?

-Mike

001001110100 (bit 0 on the left)
JJOJJOOOJOJJ (J = jumper, O = open)

-Kim

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

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

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.

I will be looking in to this very soon and will report back.
cheers
/Tim

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

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

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

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

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

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

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

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

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?

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

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

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.

formation to u-boot supports. I mean "format that u-boot supports". Sorry, spell check....

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?

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