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.

OMAP3530: booting two different u-boots

Other Parts Discussed in Thread: OMAP3530

hi all.

we're designing an embedded system using the omap3530.

we plan to use both nor and nand flash. we will boot from the nor-flash (due to its reliability) and maybe store some more versions and many applications on the nand-flash.

we would like to be able to choose between two u-boots versions: one will be on the NOR-flash, and one on the nand-flash.

I was thinking  that maybe I could do it from the xloader: reading a gpio that will tell me where to boot from.

several questions:

1. from what I understand, xloader purpose is to boot u-boot from nand-flash. when I boot from NOR-flash, I do not need the xloader (since NOR is XIP). what will happen if I try to run xloader from nor? will it work?

2.if 1 is possible, is it suppose to be difficult to change xloader so it would be able to run u-boot from nor-flash and  from nand-flash?  wouldn't it  be hard since we have very limited resources while x-loader runs?

 

I'll be happy to hear more suggestions on how to boot omap from 2 different u-boots (and kernels..) from nor/nand

thanks,

Jose

  • Jose said:
    1. from what I understand, xloader purpose is to boot u-boot from nand-flash. when I boot from NOR-flash, I do not need the xloader (since NOR is XIP). what will happen if I try to run xloader from nor? will it work?

    You are correct about X-Loader's purpose, it has to configure the external memory and copy the U-Boot image out of NAND to execute. Unfortunately what you want to do is not really practical as the OMAP3 has a limited number of address pins on the GPMC you would be using to interface to the NOR, so limited you could address at most 2KB of contiguous space without using GPIO for paging or a multiplexed address scheme. This being said you would have to have an extremely small executable (smaller than today's X-Loader) to use the XIP capability of typical NOR flash. Also keep in mind that if you were to try to use a paging scheme you could not longer effectively use XIP anyway.

    If you could get enough space out of the NOR using a multiplexed address NOR device (I have not really looked into these myself, all NOR I have used has been directly addressed, on other devices of course) than you could certainly try running X-Loader directly on the NOR, but as it was designed for NAND it may have to be modified to do what you want successfully.

    Jose said:
    2.if 1 is possible, is it suppose to be difficult to change xloader so it would be able to run u-boot from nor-flash and  from nand-flash?  wouldn't it  be hard since we have very limited resources while x-loader runs?

    The modifications to X-Loader should be relatively simple if you could fit in NOR, you would replace the code that currently reads from the NAND interface to simply read from the NOR interface, which should actually be simpler than the original NAND implementation.

  • hi,

    thanks for the answer.

    I think I'm missing something regarding the first question. you said that i can't run x-loader from the NOR-flash due to its size. 

    So how can U-boot run from the NOR flash? U-boot is much bigger.. does U-boot use GPIO for paging and x-loader doesn't? Or if i want to run u-boot i must use address/data-multiplexed NOR?

    Do you know if such a NOR driver for OMAP3 even exists?

  • Jose said:
    So how can U-boot run from the NOR flash? U-boot is much bigger.. does U-boot use GPIO for paging and x-loader doesn't? Or if i want to run u-boot i must use address/data-multiplexed NOR?

    I apologize for the lack of clarity, you could not effectively run X-Loader or U-Boot from NOR using XIP, neither have any GPIO paging mechanism. If you want to run either XIP you would need a address/data multiplexed NOR device like you suggest.

    Jose said:
    Do you know if such a NOR driver for OMAP3 even exists?

    I have not come across any NOR drivers for OMAP3, none of the development boards for OMAP3 have NOR on board that I know of to make such a driver, though it should not be too hard to implement. I see NAND being used almost exclusively due to lower cost.

  • Actually, the LogicPD 3530 LV SOM has NOR onboard (albeit only 8MBytes), and their bootloader (LoLo) has support for reading/writing from the NOR (although the first stage boot loader still resides in NAND or on a SDCard).

    So with this board it is feasible (and fairly trivial) to boot the primary boot loader from NAND/SDCard, then get uBoot, your kernel and RFS from NOR.

    However, as far as I can tell... If you wish to put the first stage bootloader (such as X-Loader) in NOR then the NOR must be on CS0 (as this is where the Boot ROM looks, see sprufd6.pdf), however CS0 is nominally also routed to the POP-ed NAND. Hence if you boot from NOR then NAND is not accessible (at least not during boot).

    Moving away from a NAND/SDCard boot definately strays from the "normal" path.

    Hope this helps a little...

  • hi,

    I must boot from the NOR-flash, so it will be connected to CS0. from what i understand, i can set the sysboot options to boot from NOR, and not from NAND.

    I planned on connecting the NAND to a different CS, as an external NAND (not POP if that makes any different).

    What I was thinking of doing, is boot the x-loader from the NOR-flash (using the ROM-bootloader), and then if i want, initialize the NAND or continue booting from the NOR.

    this leads to two questions:

    1. How difficult would it be to continue booting from NOR? (since i need to use NOR driver, rather than the ROM-bootloader). I saw that there used to be a file named omap_nor.c, and it was replace in physmap-flash.c, but i don't know if it would work..

    2. Is the NAND initialization implementation on x-loader enough when i boot from NOR? explaination: maybe when you boot from NAND, the ROM-bootloader does some stuff and the x-loader does the rest, and now i need to do it all on the x-loader, since only the NOR init happened on the ROM-bootloader.

    thanks for the help.

  • The Initialization chapter of the TRM mentions that for XIP boot the NOR flash is required to support "asynchronous protocol and address/data multiplexed mode".  I think you would either need to find a NOR flash that supports multiplexed address/data or do something fancy in hardware to latch those pins separately to interface to a standard NOR flash.

    I've not tried NOR boot myself, but that's my take from reading the TRM...

  • FYI, here's another thread where the customer used an external latch to get around the memory limitation.  I just asked him how it went -- hopefully he will respond.

  • If I don't find such a multiplexed NOR-flash, then the other thread might be helpful. But assuming i will find such a memory, I'm more concerned about the software issues. will u-boot work just like that? maybe x-loader initializes something to make u-boot work, and I need to run x-loader from NOR first.

    the problem is that i didn't find anyone that booted u-boot from NOR.

  • Jose said:
    will u-boot work just like that?

    U-Boot itself should run if you just branch to it in an executable memory space, we used to do that with the original DM6446 EVM boards, where you would run U-Boot directly out of NOR instead of an initial boot loader like X-Loader (or in Davinci terminology UBL). The main thing that the X-Loader does that you may need to recreate in the U-Boot is DDR initialization, I am not sure if U-Boot by default will be reinitializing DDR or not, but it should not be difficult to add if it is not.

    If you wanted U-Boot to be able to write to the NOR itself than you would need to add code for that as well, for example so that you could store environment variables or write in updated U-Boot or kernel images to the NOR.