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.

am335x: XIP/NAND boot issue

I have a custom board, that has both MMC0 and NAND as boot devices. SYSBOOT[0:4] has following configuration: 00100, i.e. UART0->XIP->MMC0->NAND and non-multiplexed access.

NAND has 8-bit, but according to TRM ROM boot uses 16-bit address access. GPMC_AD0-AD7 go to NAND chip, but AD8-15 are connected to other components. Some of these components are inputs for am335x. So in this case I have a signal conflict: output vs output for a short period of time, till I can change the pinmux from U-Boot/Kernel.

Another signal conflict occurs on A0-A11 pins, as they are connected to a network PHY via RGMII2 interface. In this case two outputs work against each other during XIP detection phase.

Can it possibly damage the am335x?

Regards,

Yegor

  • Hi Yegor,

    I've asked the factory team to look into your issue.

    Best regards,
    Miroslav

  • Merging this with the old thread. Please post similar questions to one thread.

    Best regards,
    Miroslav

  • How this boot combination UART0->XIP->MMC0->NAND is supposed to work? I have system with an 8-bit NAND flash connected to GPMC_AD0..GPMC_AD7. As long as you don't write anything to the flash, it is possible to make a soft-reboot, i.e. via reset button or via invoking reboot command. But as soon as I burn u-boot, kernel and rootfs into NAND flash, soft-reboot fails. i.e. I can see CCCCC coming from UART0 boot and then the system hangs in XIP and doesn't get either to MMC0 or NAND. Only power down / power up helps.

    SYSBOOT register setting for the reference:

    devmem 0x44E10040 32
    0x00400304

    The problem seems to be in the booting process, as both XIP and NAND will be mapped to 0x8000000. And XIP looks, if it finds something, that is not 0xffffffff or 0x00000000 at 0x8000000. So if the last byte, that you've read  from NAND is different from 0xffffffff or 0x00000000, ROM boot will try to execute it and ends in a dead loop. So we've added pull-ups (100K or 10K) to GPMC_AD0..GPMC_AD7 and it seems to help with a Micron NAND (29F2G08ABAEA), but not with Hynix (HY27UF082G2B).

    This boot sequence is very convenient, because regardless of what you've done to NAND, you can always boot from MMC0 and fix the content.

    How to make UART0->XIP->MMC0->NAND to work reliably?

    Regards,

    Yegor

     

  • Yegor,

    Any luck with this? I am having the same exact issue. Once i flash an image to NAND i hang in the XIP boot section and never get to the MMC0 Boot.

    Thanks,
    Jarrod
  • Hi Jarrod,

    no luck with this. We had to switch to another SYSBOOT configuration, that avoids XIP. This is not perfect, but serves it's purpose. But I would really like to hear TI statement.

  • Dang, that is what i figured : (. I already made schematic changes to do the same it just isn't as convenient. Oh well.

    Thank you for the response! : )
  • Hi,Jarrod! I have the same problem. Had TI gave solutions. Thanks!

  • Yeah, there is just nothing that can really be done it seems.  The XIP boot sees data that it thinks is valid and so you are just stuck there forever.  I simply had to make adjustments to my sysboot pins so that i am using a configuration that doesn't include XIP boot.

  • Thanks, but can we do something before cpu reset to make sure that board don't have XIP?
  • Hello everyone, we are facing the same problem.did anyone find any solution without changing the boot sequence ? as we need first boot as UART then MMC0 and NAND boot as last option.

    please reply.

    thanks

  • Hello,

    No solutions here.  The best info i have found so far is in section 26.1.7 of the TRM: 

    www.ti.com/.../spruh73l.pdf

    From what i can gather when it hits XIP mode it uses the correct pins, muxing, and bus size set by your boot config pins.  It then tries to read data from a device that it expects on these pins.  If it reads data that is NOT 0x00000000 or 0xFFFFFFFF then it assumes a good image and tries to boot from it meaning you will never pass the XIP mode.

    Now for me the weird part is that i was using mode 00011 which gives me UART0, SPI, XIP(MUX2), and then MMC.  MMC is what i need to get too, but on a few boards i didn't seem to make it past the XIP boot.  Other boards did though.  My other sysboot pins are setup for non-muxed mode and an 8-bit bus, and i have a NAND and a display connected to the used pins.  So since it is basically trying to address the NAND with the LCD lines i have no idea what is actually going on but maybe it is just pulling random data from the NAND at some address??? i dunno.

    It would be really nice if I could just take a look at the Public ROM Bootloader code, that way i could see exactly what it is doing.  I wonder if this code is available anywhere?

    For me i just changed my boot config on my next rev so don't have to worry about it.  I may investigate a little more at some point though.

  • Hi Jarrod, I'm sorry the public ROM code is not available. But you are exactly right, most likely during XIP boot, the ROM is reading something other than 0x0 or all Fs and getting stuck in XIP mode and not moving to the next boot source. If you never intended to use XIP, then you made the right move to choose a different boot order.

    Regards,
    James
  • Cool, thanks for verifying this! : )

    Darn i was hoping since it was called Public ROM code it would be public haha. But i understand there are probably some security things involved there so oh well. I guess as long as i understand what is going on I don't need it anyways, not like i could change it anyways haha.

    Thanks Again!
  • Hi JJD,

    Assuming that SYSBOOT pin is setup for an 8-bit NOR boot:
    Is it enough to pull down to 0 the GPMC[AD0-AD7] pin so that RBL does not stay stuck in XIP mode?

    Thanks in advance,

    Anthony
  • Hello,

    I am interested if anyone have found a solution. We are pretty much in the same situation having a NAND onboard and SDcard slot as a dev/backup solution. The best "harmless" boot configuration might be 00100 - UART0->XIP->MMC0->NAND.

    I can understand that the ROM code is not public, but TI should share an information how to not get stuck on XIP boot source with this configuration. It seems like there should be a way how to ensure certain content at certain addresses in the NAND memory to prevent this issue.

    There is only one 00111 - EMAC1->MMC0->XIP->NAND alternative which prefer MMC0 over NAND, but again there is an issue that XIP migh interfere.

  • Really nothing you can do except avoid XIP mode unless you can pull all the lines in a way that they read F's.  Since we can't change the ROM code and it considers anything non-F to be valid there really is no other choice.  

    I also don't recommend using a boot mode with EMAC before you actual boot mode unless you are trying to boot that way because it is suuuper slow!  What i ended up doing was using 10011 - NAND->NANDI2C->MMC0->UART0  so that way if nand is programmed it runs from there and if not it will run my MMC stuff and program the NAND and if all else fails i at least get C's printing out from UART mode to verify the system is alive.  Then to implement my factory restore i attached a button to sysboot[2] so that when held i get:  10111 - MMC0->SPI0->UART0->USB0  that way it will not boot from NAND, there is no XIP and i still get C's printing out if the MMC doesn't have valid software : ).

    So that was my solution.  It has been working great for me in the field and everything.  The techs can restore a system by simply powering up with that button held.  And since none of the modes have EMAC it is fast to start and no XIP so no lockups : ).

  • Hello Jarrod,

    thank you for sharing your solution. It seems to be the best way to go also for me.

  • No Problem! I am glad it could help you : ). Good luck!!!