Referring to VYBRIDRM Rev 7, 06/2014:
Page 860: NAND Boot eFuse config appears to allow only 2 or 3 address cycles. Larger NAND devices require 4 or 5 cycles - does this mean I can't boot from them ?
I think the issue is solved, but the original poster (Alan) doesn't know who solved it (and neither do I). Also, it seems that the Freescale Vybrid document dropped an XLS spreadsheet and Page 860: NAND Boot eFuse should probably be more specific about 'address cycle'. Memory people often think of devices as an array with Columns and rows, but most of the rest of us think of it as a linear device. So if you want to follow up, a ticket/SR to the documentation people is probably better.
Page 860: NAND Boot eFuse - 2 ROW address cycles (four address cycles total)
- 3 ROW address cycles (five address cycles total)
I would also appreciate a 'ping' in this thread,
I still don't think we have an answer?
Thank Bill for your update on this case. Based to the other case you mentioned, can you create a new case with this link as a reference and add the current status please?
Did you have a data sheet on the 4/5 cycle chips? Is it possible that they support a 3 cycle that only reads the first ~16MB. You need to use a 3 cycle read command (also read command fues) and the boot code must be in the first ~16MB. After you boot, you could try to access > 16MB with a 4/5 cycle command. At least that is just some guessing and not an official answer, but seems to make some technical sense.
Datasheet (these are Spansion parts as it happens) says :
The Address Input bus operation allows the insertion of the memory address. For the S34ML02G1 and
S34ML04G1 devices, five write cycles are needed to input the addresses. For the S34ML01G1, four write
cycles are needed to input the addresses
Fair enough, the last one or two cycles are for high order row address, but there's nothing that states you can do a short load and the upper bits will then default to zero.
I note the Vybrid Tower uses a NAND chip (Micron) that implies the same thing , and I *assume* that must work...
Sorry I did not reflect on your question enough, I am not certain what the Page 860: NAND Boot eFuse refers to. I think that the NFC controller always runs a five address cycle for normal reads. See for instance, pg 1297 and NFC_CMD2:CODE. Nand Flash boot on the Vybrid tower does work without changing any fuses. I am pretty sure that the JEDEC NAND standard will specify a read like this (5 cycles). The low level details are completely controlled by the NFC and there is no documented programmer control of this besides the 'NFC_CMD2:CODE'. Ie, most of the raw cycles are outside the ARM/software control. Other Nand controller issue each cycle individually. All of the different Linux/U-boot/MQX 'NFC' drivers use the same 'NFC_CMD2:CODE' value (so five cycle read).
The question would be what does 'cycle' refer to in the Boot/eFuse document.
In RM rev. 5, there was a document attached with the name "Fuse-RCON Mapping.xlsx". In this document, you find the following descrption regarding this fuse (BOOT_CFG1[1:0]):
00 - 3
01 - 2
10 - Reserved
11 - Reserved
I think this is not the cycle count of reads... Bill, you probably have a better understanding what this exactly means...
Yes, I am not really sure Fuse-RCON Mapping.xlsx is much more helpful; the info is a lot the same as Page 860: NAND Boot eFuse. There are these threads,
Arrgh. I guess the 'Fuse-RCON' may have the secret sauce if you read really carefully,
0x00 col1 col2 row1 row2 row3 0x30 -> Five cycle (or 3 ROWS)
0x00 col1 col2 row1 row2 0x30 -> Four cycle (or 2 ROWS)
So I think that the Spansion 1G is 2 cycle, but the others are three. That is just a guess. Fuse defaults are zero and the Micron chip on the tower board with NAND boot with things setup as "3 Row cycles". Pg860 should definitely mention ROWS.
I am not a SW person but the first question coming to my mind is "How does Freescale's code operate in this case"? If help needed with that, I hope timesyssupport (i.e. the code author) will be able to help you with that.
Sincerely, Naoum Gitnik.