Investigate the feasibility to have a common SPL for OMAP 3 and OMAP 4

[rsalveti, Dec 21, 2011] John, can you update the blueprint with your latest status on it? Thanks.
[jcrigby, Dec 21, 2011] No work has been done on this bp this month. There has been related discussion on u-boot mailing list about autoconfig of dram for omap using similar methods as omap4 uses. One data point is that the new beagle bone board will not use the same binary MLO as the other OMAP3 platforms because the sram address has changed in the SOC.
[rsalveti, Jan 2, 2012] Any work you think we'd be able to do for this cycle? We could have it for 12.01 but with a lower priority.
[jcrigby, Jan 3, 2012] Should be able to do enough work to decide finally if this is doable and if not document why it is not possible when the question is asked in the future.
[jcrigby, Jan 24, 2012] Ran out of time before getting to this one again this cycle.
[rsalveti, Jan 24, 2012] Np, david, can you please move this bp to 12.02? thanks.
[dzin, Jan 24, 2012] Moved to 12.02
[rsalveti, Feb 23, 2012] No progress during 12.02, moving to 12.03.
[rsalveti, Mar 29, 2012] Low priority, and still not done during 12.03, let's try 12.04 :-)
[jcrigby 30 Mar 2012] Only work on this has been in my head but my current thinking is that there will be fairly insurmountable obstacles to this. I believe shared u-boot binaries across boards using same soc is more likely than shared u-boot-spl across different soc's. I day or so of real work should confirm or refute this opinion then we can either forget about this or decide the cost of going on depending on the result.
[jcrigby 12 Apr 2012] The spl header has the length and address embedded in it. The address must be somewhere in on-chip SRAM. This means that if the address of SRAM changes across OMAP generations, one can not possibly hope to run the same SPL binary. A better implementation would be to have only the size in the header and require the code at the beginning of SPL be pic. In that case the RBL would load it into SRAM and the SPL code would figure out where it is running and relocate itself if necessary. Here are the SRAM locations for some OMAP boards:
Board:beagleC4 and xM
SOC: omap3530
SRAM:0x4020_0000-0x4020_ffff

Board:beagle bone
SOC: am3359
SRAM:0x402f_0400-0x402f_ffff

Board:panda
SOC: omap4430, omap4460
SRAM: 0x4030_0000-0x4030_dfff

Board:????
SOC: omap5
SRAM: same as omap4 based on u-boot sources

From this data boards based on omap35xx could share an SPL binary. Beagle bone could not share since its SRAM is in a different place. OMAP[45] based boards could share. So we need at least three SPL binaries just based on this SRAM issue.

A possibilty would be to have per SOC generation SPL binaries and shared u-boot binaries. But that does not get us to the shared image goal.

A status of "Implemented" probably is not a good name, but this BP is done.

Meta:
Headline: Research the possibility of a unified OMAP u-boot-spl
Acceptance: Conclusive decision on the possibility of developing a unified OMAP u-boot-spl

Work items:
Determine the areas of difference across OMAP[34] in u-boot-spl: TODO
Investigate possible "fingerprinting" strategies for determining board type with no board id provided by hw: TODO
Prototype a combined OMAP[34] u-boot-spl.bin that works without fingerprinting by using an id file of vfat partition: TODO
Time permitting, replace file based board id with fingerprinting: TODO
Document results: TODO