Hi,
I have one question reagrding XIP Boot Options.
As you know, silicon revision 2.1 of AM3874 has one errata (Advisory 2.1.33).
At first, our customer thought to use MUX0 at XIP boot. But they found that some pins shared for other device(Ethernet). So they gave up to use MUX0, and they decided to use MUX1 instead of MUX0.
But AM3874 revision2.1 device has an errata "Advisory 2.1.33". So AM3874 does not multiplex the high-order address lines GPMC_A[27:13] during the XIP boot process. However customer would like to decode address "0800 0000h" for external memory. So they need to set A[27:13] = "1000 0000 0000 000b". it need to set A[27:20] = "1000 0000" ,at least. So they decided to use "M0" for A[27:20]. Because the PULL STATE of "M0" for A[26:20] is IPD and A[27] is IPU when OPTION B(BTMODE).
Also as I said the above first, they use "M1" for A[19-1]. This means they use both M0 and M1. Is this situation no problem? Please let me know.
Best regards,
Michi
Hi Michi,
Is customer want to use the A[19:1] after the XIP boot finish or during XIP boot? From the DS, only A[12:1] are using during XIP boot. All others are at default pull state (IPD/IPU).
BR,
Viet
Dear Viet-san,
Thank you for your reply.
Our customer would like to use Mux1(A[19:1]) as multiplexa mode. after XIP boot finish. But also customer would like to use Mux0(A[27:20) during XIP boot. Because customer needs to decode the address 800 0000 000h for their external device(ASIC) during XIP boot. So they would like to make [A27:13] ="1000 0000 0000 000b".
As you see from Table 4-2, the Pull state of A[20-26] is IPD with OPTION B during XIP BOOT. And the Pull state of A[27] is IPU during XIP BOOT. This combination makes the address(800 0000 000h) customer wanted. So our customer would like to use the combination M1 and M0 during XIP boot.
Is the above using any problem? Please let me know.
I appreciate your quick reply.
Hello Michi,
This is the comments from our XIP expert:
This is more a system issue than a boot ROM issue. The base address and range of each chipselect is not goverened by the the address lines, rather it is governed by the GPMC registers.
The proposed method will not work – the address 0x80000000 is governed by GPMC configuration – what it means is that any access at this address will simply assert CS0.
The best way is to use CS to enable the ASIC – connect the ASIC to CS1 and NOR to CS0 for boot.
Thank you for your cooperation.
Sorry, some my explanation was wrong. I attached a file. Please see it. 6170.AM3874 Connection.pdf
According to the connection diagram, NOR flash for boot is connected to CS0 via ASIC. ASIC is connected to CS1.
Customer's system has two Boot modes. One is from the internal RAM of ASIC. Other is from the NOR flash. When booting from NOR flash, ASIC takes in "CS0" signal from AM3874 once, and ASIC output CS0 to NOR flash. Then ASIC decodes 0800 0000h address to NOR flash.
When this timing, it is needed that A[27:13]="1000 0000 0000 000b" So customer would like to use M0 for A[27:20] pin.
Is the above using some problem? Please let me know.
Dear Michi-san,
I am afraid my previous explanation to Viet-san was not clear. The address that the NOR flash is visible from the A8 is configurable in the GPMC registers. For eg, the ROM configures NOR flash to be visible at 0x08000000 to the A8. When the A8 cores tries to access this address, the GPMC module detects this address as lying in the CS0 address range and the GPMC module drives CS0 low and A0-A27 to 0
What this means is that A8 address of 0x08000000 gets mapped to CS0 low + [A0:A27] -> 0x00000000 externally. [A0:a27] ->0x08000000 only if you are accessing offset 0x08000000 from GPMC CS0 base address (which is programmable in GPMC registers).
To enable the use case that you are describing above, CS0 must be connected to both ASIC and NOR flash chip selects using a mux. The mux selection must be externally configurable using a dip switch. When the mux sel = 0, the CS) form GPMC can be connected to the ASIC, and when mux sel = 1, the CS0 from GPMC can be connected to the NOR flash.
Another way of doing this would be to switch the memory map - let the NOR be on the lower addresses and the ASIC be on the upper addresses. Let us say for eg, that the NOR flash is 1MByte. So address 0x0 - 0x100000 will access the NOR and 0x100000 - 0xxxxx can be decoded by the ASIC as its addresses.
Regards,
Madan
Dear Madan-san,
I think I understand your explanation for XIP boot. As you say, external device must be connected to CS0 of AM3874 when booting.
And customer ASIC also is connected to CS0. Please see the AM3874 connection.pdf that I had attached in this folum. When customer's system boots up from external NOR flash, customer's ASIC pass the CS0 to NOR flash. And, when system boots up from the internal memory of ASIC, ASIC uses the CS0 for itself.
As I wrote in before, customer will use "M1". But when booting, they will use the condition of PULL STATE in Table4-2 "A[20]=IPD, A[21]=IPD, A[22]=IPD, A[23]=IPD, A[24]=IPD,A[25]=IPD, A[26]=IPD, A[27]=IPU". These coditions of PULL STATE are for "M0". This means customer uses both M1 and M0 when booting up. It is mixed. Customer would like to know whehter this using is problem, or not.
Please advise me.
Please reply me. The situation is urgent. Customer's development is pending for this matter.
Thank you for your support.
I think my question is complicated. So I change my question.
Customer uses Mux1 mode. And BTMODED[10] is option B. GPMC_A[20]-A[23] are not cared by customer.
According to Table 4-2, PULL STATE of GPMC_A[20]-A[26] are IPD with option B. And PULL STATE of GPMC_A[27] is IPU with optionB.
Can customer expect the above PULL STATE conditions for A[20]-A[27] when booting?
Please let me know.
Michi-san,
First of all, I must apologize for my delay in replying. I am on travel and do not have good access to the internet. The Boot ROM code does not touch the pin mux or the pulls of the pins it does not use, it leave it at power on default values.
Having said that, I have not specifically cross verified the value of GPMC A[20:27] while booting from NOR flash, as the ROM expects the board designer to externally pull them all down. You will have to ask someone from the design validation team to crosscheck what the values of the GPMC A[20:27] are on the actual silicon.
Again, I apologize for my delay in response.
I understood The Boot ROM code does not touch the pin mux or the pulls of the pins from your advice.
But you said me that I must ask this to design validation team for crosscheck. I don't know the person who design validation team.
Could you ask this to someone instead of me?
I would like to do crosscheck it that the Boot ROM code does not touch the pulls of the pins and it leave it at power on default values.
Whom should I ask this for crosschek. Please let me know.
ROM code does not touch the pulls of the pins a[20:27]
I believe you confirmed the fact to the design validation team that the values of the GPMC A[20:27] are on the actual silicon.
I will talk this to our customerI
I appreciate your support.
Viet is checking with the design validation teams - but we have not yet heard back from them.
Thank you for your information.
I will wait to get additional information from you. After that, I will talk it to our customer.