This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5728 NOR Boot

Other Parts Discussed in Thread: AM5728

Hi,

I have one question regarding NOR boot of AM5728.

Did anyone use AM5728 with NOR boot? My customer is trying to use NOR boot now. But they don't succeed it.

So I would like to know AM5728 NOR boot can really use without any issue.

I appreciate your quick reply.

Best regards,

Michi

  • Hi Michi,

    Which u-boot are they using? Mainline or the u-boot from SDK2.0?
    The device itself should be able to boot from NOR, see Section 33.3.7.3 XIP Memory in device TRM. However, I don't think the SDK2.0 u-boot support nor boot, I cannot find any configs for nor boot in beagle_x15.h.
    If your customer is using SDK2.0, can you suggest them to try the mainline u-boot?

    Best Regards,
    Yordan
  • Dear Yordan-san,

    Thank you for your quick reply.

    My customer does not use linux with AM5728. But if mainline u-boot is helpful,
    I would like to get it. How do I get mainline u-boot?

    I appreciate your quick reply.

    Best regards,
    Michi
  • Dear Yordan-san,

    Thank you for your quick reply.

    My customer does not use Linux with AM5728. But, if mainline u-boot is helpful, I would like to get it.
    How do I get the mainline u-boot? Please let me know how to do it.

    I appreciate your quick reply.

    Best regards,
    Michi
  • Hi,

    Michi Yama said:
    My customer does not use Linux with AM5728

    Then u-boot sources won't help much.  What OS are they trying to boot? 

    Can you provide a more detailed explanation of our problem? As I said AM5728 device should support NOR boot, have a look at Initialization chapter in AM572x TRM. 

    Best Regards, 
    Yordan

  • Dear Yordan-san,

    Thank you for your quick reply.

    My customer uses Windows Embedded OS.

    When customer access to CS0(0x8000 0000), CS0 signal does not occur. Read data are all "0".

    The AM5728 status after reset :

    TRM table 15-535, GPMC_CONFIG7_i :
    The address setting of CS0 space : 0x0000 0F40 (Chip-select size of 16MiB, CS enabled, Base address(A29-A24) = 0x0

    Please advise me .

    Best regards,
    Michi
  • Michi Yama said:
    When customer access to CS0(0x8000 0000), CS0 signal does not occur. Read data are all "0".

    0x8000 0000 is start address of DDR1 EMIF. GPMC start address is 0x0000 0000.

  • Biser-san,

    Thank you for your reply.

    > 0x8000 0000 is start address of DDR1 EMIF. GPMC start address is 0x0000 0000.

    Sorry I missed. Address is 0x0800 0000, not 0x8000 0000.

    Also according to TRM 33.3.7.3 XIP Memory,

    The device is connected to CS0 mapped to address 0x0800 0000.

    So I think 0x0800 0000 is start address when NOR booting.

    Best regards,
    Michi
  • Then base address(A29-A24) = 0x0 is not correct. It should be 001000b.
  • Biser-san,

    Thank you for your quick reply.

    > Then base address(A29-A24) = 0x0 is not correct. It should be 001000b.

    Yes. You are right. But the reset value of [5:0] BASEADDRESS bit of GPMC_CONFIG7_i register is 0x00. It shows A29-A24 =0x00.

    If ROM code detects XIP boot by sysboot pin, ROM code try to access to CS0 (0x0800 0000) without any configuration for GPMC?

    I appreciate your quick reply.

    Best regards,
    Michi
  • Yes, GPMC should be configured by ROM code without user intervention.
  • Biser-san,

    Thank you for your reply.


    According to my customer's information, the boot mode setting is the below.

    sysboot[5:4] =0b11
    sysboot[3:0] = 0b0101
    This setting is for XIP as first device

    And, according to customer's confirmation of CTRL_CORE_BOOTSTAP register, the register value is the below.

    CTRL_MODULE_CORE_CTRL_CORE_BOOTSTRAP(0x4A0026C4)
    0x0000A5F5

    BOOTWAITEN bit is set as WAIT pin is monitored.

    But , according to customer' s observation, it seems to be no wait action. I would like to know " Low - Level internal initializations " in TRM 7248 page. In this initialization, does ROM code change the systboot WAIT setting?

    Also customer will try to change from "XIP" boot to "Fast XIP" boot. Please see the Figure 33-7 in TRM. Customer will do "Step2".
    Is this try effective this issue?

    Please advise me.

    Best regards,
    Michi
  • Please provide all 16 SYSBOOT pin settings.
  • Dear Biser-san,

    Thank you for your reply.

    I had additional information from my customer.

    The below is GPMC register's contents when NOR booting.

    〇GPMC register value

    SYSTEM RESET FASTXIP XIP
    GPMC_GPMC_CONFIG1_i_0 00401000 00001000 00001010
    GPMC_GPMC_CONFIG2_i_0 00101001 00101001 001E1E01
    GPMC_GPMC_CONFIG3_i_0 22060514 22060514 00090907
    GPMC_GPMC_CONFIG4_i_0 10057016 10057016 0F071D0B
    GPMC_GPMC_CONFIG5_i_0 010F1111 010F1111 001C1F1F
    GPMC_GPMC_CONFIG6_i_0 8F070000 8F070000 8F070080
    GPMC_GPMC_CONFIG7_i_0 00000F40 00000F48 00000F48

    As you know, Bit22 of GPMC_CONFIG1_i_0 register is WAITREADMONITORING bit.

    As you see from the above result, the value of bit22 is 0x1 when system reset .
    But the value of bit 22 is changed from 0x1 to 0x0 after ROM code executed (Both FAST XIP and XIP).
    This shows ROM code rewrite GPMC_CONFIG1_i_0 register.

    My customer's hardware needs to have wait to access to NOR Flash. Why does ROM code change
    the register?

    Also I shows the log of FAST XIP execution. Please see the below.

    00038000: EA00026E b #0x389c0

    000389c0: E1A02000 mov r2, r0
    000389c4: E323F0D3 msr cpsr_xc, #0xd3
    000389c8: EE100FB0 mrc p15, #0, r0, c0, c0, #5
    000389cc: E2100003 ands r0, r0, #3
    000389d0: 1A000023 bne #0x38a64
    000389d4: E59F40F8 ldr r4, [pc, #0xf8]
    000389d8: E584200C str r2, [r4, #0xc]
    000389dc: E5841010 str r1, [r4, #0x10]
    000389e0: E59F00F0 ldr r0, [pc, #0xf0] r0 = 0x4A002134
    000389e4: E5900000 ldr r0, [r0] r0 = 0xFA
    000389e8: E2000D07 and r0, r0, #0x1c0
    000389ec: E1A00320 lsr r0, r0, #6
    000389f0: E3500003 cmp r0, #3 Read 0x3 = General Purpose (GP)
    000389f4: 1A000005 bne #0x38a10
    000389f8: E59F00DC ldr r0, [pc, #0xdc] r0 = 0x4A0026C4
    000389fc: E5900000 ldr r0, [r0] r0 = 0xA5FA
    00038a00: E1A06000 mov r6, r0
    00038a04: E200003F and r0, r0, #0x3f
    00038a08: E350003A cmp r0, #0x3a FAST XIP
    00038a0c: 0B0000BB bleq #0x38d00

    00038d00: E1A0700E mov r7, lr
    00038d04: EBFFFEB9 bl #0x387f0

    000387f0: E59F00AC ldr r0, [pc, #0xac]
    000387f4: E5901000 ldr r1, [r0]
    000387f8: E3C11007 bic r1, r1, #7
    000387fc: E3811005 orr r1, r1, #5
    00038800: E5801000 str r1, [r0]
    00038804: E3A00205 mov r0, #0x50000000
    00038808: E5901060 ldr r1, [r0, #0x60]
    0003880c: E59F2094 ldr r2, [pc, #0x94] r2 = 0x00403300 22:WAITREADMONITORING <------------- ①
    00038810: E1C11002 bic r1, r1, r2 0x0: Wait pin is not monitored for read accesses.
    00038814: E3A02C12 mov r2, #0x1200 0x1: Wait pin is monitored for read accesses.
    00038818: E1811002 orr r1, r1, r2
    0003881c: E5801060 str r1, [r0, #0x60]
    00038820: E3001F48 movw r1, #0xf48
    00038824: E5801078 str r1, [r0, #0x78]
    00038828: E12FFF1E bx lr

    00038d08: E1A00006 mov r0, r6
    00038d0c: E2000B06 and r0, r0, #0x1800 0x0800: Addr-Data Mux device attached
    00038d10: E3500000 cmp r0, #0
    00038d14: 0BFFFEC4 bleq #0x3882c

    0003882c: E3A00205 mov r0, #0x50000000
    00038830: E5901060 ldr r1, [r0, #0x60]
    00038834: E3A02C03 mov r2, #0x300
    00038838: E1C11002 bic r1, r1, r2 r2 = 0x00000300 Non-muxed device <------------- ②
    0003883c: E3A02000 mov r2, #0
    00038840: E1811002 orr r1, r1, r2
    00038844: E5801060 str r1, [r0, #0x60]
    00038848: E12FFF1E bx lr

    00038d18: E1A00006 mov r0, r6
    00038d1c: E2000A02 and r0, r0, #0x2000 0x2000: 16-bit BOOTDEVICESIZE
    00038d20: E3500000 cmp r0, #0
    00038d24: 0BFFFEC8 bleq #0x3884c
    00038d28: EB00000A bl #0x38d58

    00038d58: E1A00006 mov r0, r6
    00038d5c: E2000B06 and r0, r0, #0x1800 0x0000: Non-muxed device attached
    00038d60: E3500000 cmp r0, #0
    00038d64: 0A000022 beq #0x38df4

    As you see from the ① , ROM code clears WAITREADMONITORING bit without regard to BOOTWAITEN bit setting of CTRL_CORE_BOOTSTRAP register. Is this errata? or is this spec?

    Please advise me.

    I appreciate your quick reply.

    Best regards,
    Michi
  • I have asked the factory team to check this. Their response will be posted directly here.
  • Biser Gatchev-XID said:
    Please provide all 16 SYSBOOT pin settings.

    Please provide the answer to this question.

  • Dear Biser-san,

    Thank you for your cooperation.

    > Please provide all 16 SYSBOOT pin settings.

    you can see sysboot pin settings in CTRL_CORE_BOOTSTRAP register.

    CTRL_CORE_BOOTSTRAP(0x4A0026C4) = 0x0000A5F5 (at XIP)

    SYSBOOT[15] : vdd

    SYSBOOT[14] : vss

    SYSBOOT[13:10] : 0x1

    SYSBOOT[12:11] : 0x0

    SYSBOOT[10] : 0x1

    SYSBOOT[9:8] : 0x1

    SYSBOOT[7-6] : This is for QSPI

    SYSBOOT[5:4] : 0x3

    SYSBOOT[3:0] : 0x5( XIP boot), 0xA(Fast XIP)

    Customer confirmed their sysboot pin setting is reflected in CTRL_CORE_BOOTSTRAP register.

    Best regards,

    Michi

     

  • Biser-san,

    Thank you for your support.

    I confirmed the status of SYSBOOT[7:6] pin to my customer.

    SYSBOOT[7:0] : 0x3(0b11)

    Is this setting no problem? If XIP(or Fast XIP) is set, this bits are ignored? What is correct setting for XIP boot?

    Which register do these SYSBOOT pins reflect?

    I appreciate your quick reply.

    Best regards,
    Michi
  • From what I see here your setting for SYSBOOT[13:10] are 0x1. From TRM section 33.2.4.1 this corresponds to 8-bit non-muxed device with wait. In TRM section 33.3.6.1 the requirements for fast XIP mode are 16-bit A/D-muxed device.

    Please post what is the NOR device being used.
  • Biser-san,

    Thank you for your quick reply.

    Sorry, it is my mistaken. The correct is the below.

    SYSBOOT[13] : 0x1 --- 16bit device setting

    > From TRM section 33.2.4.1 this corresponds to 8-bit non-muxed device with wait. In TRM section 33.3.6.1 the requirements for fast XIP mode are 16-bit A/D-muxed device.

    You are right. However, frrom the log of fast xip boot that I posted here yesterday, ROM code changes the MUXCS0DEVICE based on SYSBOOT pin. This means that A/D-muxed device is not needed for fast XIP because sysboot pin setting is used instead of TRM requirement.

    Best regards,
    Michi
  • I have asked the factory team to look at this. Their comments will be posted directly here when available.