x-loader, u-boot and determining boot device

burchmere said:

Is there a way for x-loader (or any code) to know which device the OMAP booted from?  The standard x-loader appears to use the sys_boot[] value to know.

see here: http://git.omapzoom.org/?p=repo/x-loader.git;a=blob;f=lib/board.c;h=9c3325a5ff096095069e6c8e3537582c816985d4;hb=HEAD#l117

What is in the register at 0x480029c0?  How does it get there?

twebb

burchmere said:

What is in the register at 0x480029c0?  How does it get there?

cant seem to find relevant data in public trm.. my best guess is romcode putting that info there.. but others in the forum might have a better idea..

I agree with Nishanth, this looks like something that would have to be written by the ROM boot loader, though it is not documented that this happens that I can find, the address seems to be a reasonable place to have this placed. That particular address is in the CONTROL_SAVE_RESTORE_MEM memory of the system control module, and happens to be just beyond the required structures that must go in this memory, as shown in section 25.5 of the TRM, so it seems reasonable that the ROM boot loader could write some status information here.

I agree that it must be the OMAP ROM that puts the info there.  Now the question is "what is the status/info it's putting there?"  (It does not appear to match sys_boot[] values in any way.)  Without details, I can't just use the code as is from that git because a) I don't know what the register location actually holds and b) it doesn't include a value related to MMC2.  Are there alternative ways for x-loader to determine from where he was booted?

Thanks,

twebb

I think I've figured it out, but I'm not sure about giving out the info, yet.  There is a section missing from the TRM that will be added and contains information about Configuration Headers that can be added to your booting image.  In there you can change the device you boot from and there are definitions for OneNAND, NAND, MMC1, MMC2, etc.  Looking at that code snippet, the numbers match the documentation I have.  I suppose the boot ROM puts the number in that location.  If/When I get confirmation of this, I'll see what I can post.

Steve K.

Configuration Header: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf section 26.4.8.2(page 3427)

I think my question has been misunderstood.  I generally understand (but not using) the Configuration Header - which allows info in the image to direct the ROM to use different memory device settings.

However, my question is how does software know where it was booted from?  For example, if sys_boot[5:0] = 010001 = memory booting w/ order MMC2, USB, UART3, MMC1.  If ROM code successfully loads and executes x-loader from MMC1, how can x-loader determine that it was loaded from MMC1 vs. MMC2 (or USB or UART3)?  Maybe I'm missing it, but I don't see that in the TRM that was referred to.

Also, if I'm working with a 35xx, does the TRM for the 34xx apply identically, or are there differences?

burchmere said:

I However, my question is how does software know where it was booted from?  For example, if sys_boot[5:0] = 010001 = memory booting w/ order MMC2, USB, UART3, MMC1.  If ROM code successfully loads and executes x-loader from MMC1, how can x-loader determine that it was loaded from MMC1 vs. MMC2 (or USB or UART3)?  Maybe I'm missing it, but I don't see that in the TRM that was referred to.

yes, as you mentioned, sysboot merely tells you which sequence the boot attempts will be done. however, the actual device the boot really happened is as pointed to by the code snipped in the previous post. the actual details are not publicly available -mentioned by steve. will wait for steve to post info

burchmere said:

Also, if I'm working with a 35xx, does the TRM for the 34xx apply identically, or are there differences?

 

Hmm... much of the concepts are the same -> much of the feature set is pretty similar. But then that is a topic of another discussion.. one salient point is the distance between each pin as i recollect from a post on the beagleboard mailing list

I am working on booting omap 3430sdp with MMC2. Could someone please guide me through the changes to be made compared to MMC1 booting?

I think it is put there by the startup code in start.S, see http://git.omapzoom.org/?p=repo/x-loader.git;a=blob;f=cpu/omap3/start.S;h=142c4256f4ccac47cbf58b092ed6acb71cc71310;hb=HEAD#l97 and note how scratchpad is mapped to 0x480029c0 at the end of the file.

Did anyone know if this would work on DM3730, not sure I'm seeing the right results on our hardware

david atkins said:

Did anyone know if this would work on DM3730, not sure I'm seeing the right results on our hardware

Some form of this should work, yes.  Note that 'omap4', 'omap3' and 'am335x' use similar mechanisms but different values for devices.  DM3730 is 'omap3' in this regard, so take a look at http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/omap_common.h;h=3f2f004afb67b5bead329aee5dde23fe0d74fc82;hb=HEAD#l48 for values and http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/omap3/lowlevel_init.S;h=a308ebdb6a37d10d9540652c80ffc1dc0d8e1beb;hb=HEAD#l38 for reading.

EDIT: Make URLs be links

Hi,

Not sure what your mean is relevant from thos e files, see a bucnh fo defines but no sign of the mntioned address or tracing vectore

can you snip the relvant bits onto the forum so we can what you mean?

david

david atkins said:

Hi,

 

Not sure what your mean is relevant from thos e files, see a bucnh fo defines but no sign of the mntioned address or tracing vectore

 

can you snip the relvant bits onto the forum so we can what you mean?

 

david

The first link is the values you will get back, for OMAP3 (so DM3730) when you do the read/save that the second link gives.  Which is to say, that when the ROM passes control to you, the address to poke is in r0 and you need to perform the load/mask that follow (lines 42, 43).  Line 44 is storing the resulting value into the omap3_boot_device variable.

So, thsdi is Uboot, but we use MLO to start with followed by Uboot, or does MLO do the same and pass it on?

David

david atkins said:

So, thsdi is Uboot, but we use MLO to start with followed by Uboot, or does MLO do the same and pass it on?

x-loader (which provides MLO for DM3730) does not.  It is however being replaced by SPL (which is part of U-Boot).  One could backport the logic from U-Boot to x-loader if needed.

so how do I go about getting SPL? for dm3730 i'm on the dvsdk version 4

david atkins said:

so how do I go about getting SPL? for dm3730 i'm on the dvsdk version 4

In a supported fashion?  Wait.  In an unsupported fashion:

1) Clone U-Boot git from git://git.denx.de/u-boot.git

2) Create a branch for the SPL series that follows based on the git hash they're built with:

$ git checkout -b spl-for-omap3_evm 5721385

3) Download the series of patches at http://patchwork.ozlabs.org/bundle/trini/add-more-framework-to-omap3-spl-v3/ (you might need to do this individually)

4) Apply each patch with 'git am'

5) Build.  Follow the instructions in the users guide for how.

6) Copy to SD card:

$ cp MLO u-boot.img /media/boot/

Then confirm you can boot from SD card.  Then, do as you need.  I made the extension bold here but it bears repeating.  You need to copy u-boot.img not u-boot.bin now.  And it also bears repeating that this isn't supported and you're going off and using the community sources.  That said, as these are my patches I'd very much welcome feedback and reports on success/failure.

So will this become the supported route in the future, if what timecsale? do you have a got that based ont the DVSDK (april release for dm3730) coudl you supply the patches so I can do this easily, up against and feeling pretty let by TI at the moment.

david atkins said:

So will this become the supported route in the future, if what timecsale? do you have a got that based ont the DVSDK (april release for dm3730) coudl you supply the patches so I can do this easily, up against and feeling pretty let by TI at the moment.

I work over on the AM side of the house, so I can't say when the DVSDK will take these changes in.  I can say that our next SDK release for the AM37x line (05.03.01.00) will have these changes included.  I can speculate that plugging U-Boot from our SDK into the DVSDK shouldn't be hard and you should have at least the same level of functionality.  I don't know if we've publicly committed to a time-frame for 05.03.01.00 but 05.03.00.00 for AM335x is out I'm pretty sure, so infer from that what you will.  I'll also note that 05.03.00.00 is based on http://arago-project.org/git/projects/?p=u-boot-am33x.git;a=shortlog;h=refs/heads/int_am335xpsp_04.06.00.01-v2011.09-for-sdk-05.03.00.00 and that you should be able to pick out the required starting point SPL patches pretty quickly as they're, iirc, at the front of the log between the v2011.09 tag and our changes.