• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 106 subscribers
  • Views 17558 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Initialization for the ARM Cortex A8 (AM3359) on the beaglebone

Aijaz Baig
Prodigy 130 points
Other Parts Discussed in Thread: AM3359, AM1808

Hi.

This post is related to tackle newbie questions about board level initialization on the beaglebone. I have already posted my questions on another ongoing thread but I've requested the admin to remove them since I believe having a seperate thread might be of more value for me and other people using or planning to buy a beaglebone.

So here are my questions:

  1. The manual talks about 'Public ROM' code all the time. I believe it is proprietry code hard burned into some non volatile memory which is always invoked on startup. If it is indeed TI code which is invisible to the user, what does the word 'public' mean here?
  2. The manual talks about the 'ROM reset vector'. Is it different from the reset vector for the entire system? What I mean is, when ARM is resetted, it does a number of things and then later jumps to either 0x0000'0000 or to 0xFFFF'0000 depending on whether 'high vectors' having been configured or not (ARM Architecture Reference Manual). If I am correct until here, then how does this information relate to TI's 'ROM reset vector' being at address 0x20000? Is this ROM internal to the SoC (although outside the A8 core)? So it basically means that TI has designed the SoC in such a way that this internal ROM appears to the MPU as if it is at 0x0000'0000 (referred to, at times using the word 'remapping'), isn't it?
  3. Now as per the AM335X_starterware_booting_and_flashing guide, the beaglebone has no settings to configure the boot modes (correct me if I am wrong here). So the micro SD card that is shipped with the bone is the primary boot device (as per the SRM) and it already contains the second stage bootloader isn't it?
  4. I believe the very basic bootloader is in the ROM (which is TI proprietry) and it already configures the various important peripherals including the microSD card driver and hence whatever binary files are placed in the SD Memory card is then read by this ROM bootloader right?
  5. What exactly does the TI PSP contain? As far as I have understood, it contains the second stage and the 3rd stage bootloaders (u-boot) and the Linux kernel? But I cannot seem to find the link to download it. Could you please point me to a link from where I could download it?
  6. Besides the TI PSP, I could instead use Angstrom or Android as the OS on the board right? But in that case, I would need to then configure u-boot manually and using this I can then switch over to one of these OSes I believe. Is it correct?
  7. Where can I find u-boot that has been ported to the beaglebone?
  8. Can I write my own second stage bootloader (initialization routine) instead of using u-boot, like just for the sake of study?
  9. If I can, then can I load my initialization routine into the SD Card and assume that the ARM on the am3359 will start fetching the code from here assuming it is 0x0000'0000?
  10. I cannot seem to find a clear enough memory map which tells how the memory is being played around. For instance, on the SAM7S boards from Atmel it clearly tells that 'initially the ROM is located at linked address and also at 0x0. Later one can configure RAM to be at 0x0. At any given time both the ROM and the RAM (assuming they have been initialized) can be accessed using its linked address'. Where can I find such information for the AM335x?

I hope I have been specific enough with my questions. Keen to hear from you soon.

Regards,

Aijaz

 

  • 0
    Intellectual 290 points

    Hi Aijaz,

    I'll try to shed some light on your questions.

    1.  I can't comment on TI's use of "public". I don't think the code is invisible to the user. I'm sure if you were fascinated, you could disassemble the ROM contents at 0x20100

    See figure 26-3 in the TRM.

    2. The TRM shows a reset vector for the ROM at 0x20000. As you observe, this seems to bear no relation to the A8 memory map shown in TRM section 2.1.

    You're probably right about some re-mapping going on later. Even before the MMU is turned on, the memory map may depend on the CPU mode.

    3. Check how the SYSBOOT pins are wired on the BeagleBone. I've not looked if there's scope for altering them electrically on boot.

    4. Yes. See TRM section 26.

    5. Download SDK here http://software-dl.ti.com/dsps/dsps_public_sw/am_bu/sdk/AM335xSDK/latest/index_FDS.html

    6.Substitute appropriate kernel and build a new uImage.

    7. Check SDK for details.

    8. Yes, U-Boot may be a bit heavy for some apps. You could just compile a cut-down version.

    9. See TRM section 26.1.7.2.6  It can do a raw boot or load a file called MLO from a FAT partition at the start of the card.

    There are helpful training docs in the SDK docs directory. One details the boot procedure.

    10. I agree, the picture is not entirely clear. The AM335x also seems to include a Cortex-M3 core for the PRCM. This has its own memory map too. I understand though that the A8 core runs the boot code.

    Regards

    Roger.



  • 0 in reply to Roger 8421
    Prodigy 130 points

    Hi Roger.

    Thanks for the answer mate. And a very special thanks for a point by point answer. In keeping with the theme, Ill add my comment for each point since that way it'll help us to get a more clearer picture for each point separately.

    1. I believe you meant disassemble the code from 0x20000 - 0x20100. Correct?

    2. CPU mode as in?

    3,4,5. Yep I need to look into it. But the beaglebone system reference manual explicitly says that the MMC card is the primary boot device (section 5.5; board revision a3, doc revision 1.0). And by the way, thanks for the link.

    6. I believe this assumes that I have already loaded a working u-boot on the bone right? So I basically use u-boot to boot the kernel. Correct?

    7,8,9. Thanks Roger. Ill take a look at each of those points

    Roger 8421 said:

    10. I agree, the picture is not entirely clear. The AM335x also seems to include a Cortex-M3 core for the PRCM. This has its own memory map too. I understand though that the A8 core runs the boot code.

    Yep it isnt really clear. It'd be great if some one from TI would at least give us a basic run down so as to have a more clearer picture (without of course delving into their proprietary code)

    Regards

    Aijaz

  • 0 in reply to Aijaz Baig
    Intellectual 290 points

    Aijaz Baig said:

    Hi Roger.

    Thanks for the answer mate. And a very special thanks for a point by point answer. In keeping with the theme, Ill add my comment for each point since that way it'll help us to get a more clearer picture for each point separately.

    1. I believe you meant disassemble the code from 0x20000 - 0x20100. Correct?

    No, TRM Figure 26-3 shows the main ROM code starting at 0x20100. There is a vector table, CRC and some loop forever code starting at 0x20000.

    Aijaz Baig said:

    2. CPU mode as in?

    TRM section 26.1 says "The device starts up in secure mode. The ROM Code takes care of early initialization. The ROM code switches the device into public mode. Hence the Public ROM Code provides run-time services for cache maintenance". You'll have to read up in the ARM manual about modes. I'm not knowledgeable on the details yet. The "Public" in "Public ROM" may refer to this ROM being available in CPU public mode.

    Aijaz Baig said:

    3,4,5. Yep I need to look into it. But the beaglebone system reference manual explicitly says that the MMC card is the primary boot device (section 5.5; board revision a3, doc revision 1.0). And by the way, thanks for the link.

    6. I believe this assumes that I have already loaded a working u-boot on the bone right? So I basically use u-boot to boot the kernel. Correct?

    Yes, that's right. ROM loader loads MLO(X-Loader). X-Loader loads U-Boot. Uboot loads the kernel. I believe Android loads a Linux kernel too. WINCE perhaps does not use U-Boot?

    Aijaz Baig said:

    7,8,9. Thanks Roger. Ill take a look at each of those points

    10

    Yep it isnt really clear. It'd be great if some one from TI would at least give us a basic run down so as to have a more clearer picture (without of course delving into their proprietary code)

    Regards

    Aijaz

    The TRM outlines the boot process performed by the ROM in quite a lot of detail in chapter 26. There are a few details which are perhaps not completely clear. If you're not the kind of person who finds reading assembler enjoyable, then the TRM summary is probably more useful; I like reading assembler ;-)
    Really all you need to understand is what header you need to add to your code image and where that code is loaded by the boot loader to start the second stage of boot.
    Regards
    Roger.

  • 0 in reply to Roger 8421
    TI__Genius 15510 points

    While I'm not an expert, I can try to shed a little light.

    1. The am335x has an on-chip ROM. Part secure that can only be accessed through secure monitor calls (in ARM assembly, smc) and part 'public' that you can actually see with a JTAG debugger.

    2. In Cortex-A8 (and maybe ARM11, but I'm not sure) a co-processor register was added so that through a cp15 instruction you could relocate the exception vectors to anywhere in the address space. I'm guessing the secure part of the boot ROM must set that register to 0x20000 because I started JTAG and while sitting in one of the dead loops, I read the co-processor register and see that it is 0x20000. So instead of being at 0x00000000 or 0xFFFF0000, they are at 0x20000. During Linux kernel initialization it sets the cp15 register that configures the 'high vectors' and puts the vector table there.

    3. Yes, mmc0 is the primary boot device. The beaglebone is hard wired to boot in a specific order: mmc0 -> spi0 -> uart0 -> usb0. So if no mmc card is present, the boot ROM then looks for flash on spi. If no flash is found it tries an x/y/zmodem protocol to download code. If that times out it configures usb to be an rndis device and tries to bootp/tftp the boot image. Using JTAG you can read the control_status register at 0x44E10040. The lower byte maps to the sysboot pin configuration. For beaglebone, the lower byte is 0x17.

    8. For writing your own code you might want to use the start up code from u-boot that initializes registers, and then jump to your own code. Or for other example code you might want to look at Starterware. I don't have a link handy, but if you go to www.ti.com and search for starterware you can find the link.

    I think Roger has answered your other questions in detail. If not, feel free to ask more.

    Steve K.

  • 0 in reply to Steve Kipisz
    Prodigy 130 points

    Steve Kipisz said:

    While I'm not an expert, I can try to shed a little light.

    1. The am335x has an on-chip ROM. Part secure that can only be accessed through secure monitor calls (in ARM assembly, smc) and part 'public' that you can actually see with a JTAG debugger.

    Cool..that was what I wanted to know..thanks

    Steve Kipisz said:

    2. In Cortex-A8 (and maybe ARM11, but I'm not sure) a co-processor register was added so that through a cp15 instruction you could relocate the exception vectors to anywhere in the address space. I'm guessing the secure part of the boot ROM must set that register to 0x20000 because I started JTAG and while sitting in one of the dead loops, I read the co-processor register and see that it is 0x20000. So instead of being at 0x00000000 or 0xFFFF0000, they are at 0x20000. During Linux kernel initialization it sets the cp15 register that configures the 'high vectors' and puts the vector table there.

    This looks like the most probable thing it must be doing since you have already verified it..

    Steve Kipisz said:

    3. Yes, mmc0 is the primary boot device. The beaglebone is hard wired to boot in a specific order: mmc0 -> spi0 -> uart0 -> usb0. So if no mmc card is present, the boot ROM then looks for flash on spi. If no flash is found it tries an x/y/zmodem protocol to download code. If that times out it configures usb to be an rndis device and tries to bootp/tftp the boot image. Using JTAG you can read the control_status register at 0x44E10040. The lower byte maps to the sysboot pin configuration. For beaglebone, the lower byte is 0x17.

    Did you find that information in the SRM for the bone? If yeah then I am probably not the best of readers out there...else..please do tell me where you got that information from :)

    Steve Kipisz said:

    8. For writing your own code you might want to use the start up code from u-boot that initializes registers, and then jump to your own code. Or for other example code you might want to look at Starterware. I don't have a link handy, but if you go to www.ti.com and search for starterware you can find the link.

    I think Roger has answered your other questions in detail. If not, feel free to ask more.

    Steve K.

    Yep...as Roger suggested, I cud write a trimmed down version of u-boot.  But in any case, it looks like the on chip ROM (which contains the secure part as well as the public part) does the essential memory remapping that brings the public ROM code at 0x20000 to the forefront. The need to do this suggests that perhaps the public ROM might not be a part of the same physical module as the private code...

    Nevertheless, my main concern is, the initialization.  It now looks like the remapping of the public ROM code is done by the secure boot code (secure ROM) while the initialization of the mmc, spi, uart as well as USB is done by the public ROM code. Is it correct?

    By the way, I downloaded the PSP sources for the SDK from the site which roger mentioned above and I am checking out u-boot. However, to my surprise, I do not see how one can configure it for the bone?

    I read up the android dev kit info for the bone from this page. The complete sources can be downloaded from here. It shows that in order to build the u-boot for the bone, I have to run 'make CROSS_COMPILE=arm-eabi- am335x_evm_config' but there is no 'am335x_evm_config' target in the top level makefile in the u-boot source that I downloaded from the PSP download site (previous paragraph). Is there something I am missing? Looks like the u-boot for the android is different from the one available for the SDK..is it?

    Keen to hear your comments..and thanks for the answers..

    Regards,

    Aijaz

  • 0 in reply to Aijaz Baig
    Expert 2280 points

    Hi Aijaz,

    Sorry I made a litte bit of confusion in the other thread...

    Aijaz Baig said:

    3. Yes, mmc0 is the primary boot device. The beaglebone is hard wired to boot in a specific order: mmc0 -> spi0 -> uart0 -> usb0. So if no mmc card is present, the boot ROM then looks for flash on spi. If no flash is found it tries an x/y/zmodem protocol to download code. If that times out it configures usb to be an rndis device and tries to bootp/tftp the boot image. Using JTAG you can read the control_status register at 0x44E10040. The lower byte maps to the sysboot pin configuration. For beaglebone, the lower byte is 0x17.

    Did you find that information in the SRM for the bone? If yeah then I am probably not the best of readers out there...else..please do tell me where you got that information from :)

    [/quote]

    I've not found this info anyware, probably you can get it from schematics, but I have a beaglebone and I can confirm that if micro-SD is missing it tries to boot at least from UART and USB-RNDIS (but I've not really tested booting from there).

    Aijaz Baig said:

    Nevertheless, my main concern is, the initialization.  It now looks like the remapping of the public ROM code is done by the secure boot code (secure ROM) while the initialization of the mmc, spi, uart as well as USB is done by the public ROM code. Is it correct?

    By the way, I downloaded the PSP sources for the SDK from the site which roger mentioned above and I am checking out u-boot. However, to my surprise, I do not see how one can configure it for the bone?

    I read up the android dev kit info for the bone from this page. The complete sources can be downloaded from here. It shows that in order to build the u-boot for the bone, I have to run 'make CROSS_COMPILE=arm-eabi- am335x_evm_config' but there is no 'am335x_evm_config' target in the top level makefile in the u-boot source that I downloaded from the PSP download site (previous paragraph). Is there something I am missing? Looks like the u-boot for the android is different from the one available for the SDK..is it?

    Yes, it's missing but it works. It follows %_config target, calling mkconfig and so on if I am not wrong. If you are not interested on Android but just on Sitara Linux SDK you can get info on bootloaders here, and others on main Sitara Linux Dev Guide page. There are a lot of info out there, but not so well organized.

    Regards, Max

  • 0 in reply to Qmax
    Intellectual 290 points

    Qmax said:

    Hi Aijaz,

    Sorry I made a litte bit of confusion in the other thread...

    3. Yes, mmc0 is the primary boot device. The beaglebone is hard wired to boot in a specific order: mmc0 -> spi0 -> uart0 -> usb0. So if no mmc card is present, the boot ROM then looks for flash on spi. If no flash is found it tries an x/y/zmodem protocol to download code. If that times out it configures usb to be an rndis device and tries to bootp/tftp the boot image. Using JTAG you can read the control_status register at 0x44E10040. The lower byte maps to the sysboot pin configuration. For beaglebone, the lower byte is 0x17.

    Did you find that information in the SRM for the bone? If yeah then I am probably not the best of readers out there...else..please do tell me where you got that information from :)

    [/quote]

    I've not found this info anyware, probably you can get it from schematics, but I have a beaglebone and I can confirm that if micro-SD is missing it tries to boot at least from UART and USB-RNDIS (but I've not really tested booting from there).

    [/quote]

    To make things clear: detailed information on booting is to be found in the AM335x Technical Reference manual here:

    http://www.ti.com/litv/pdf/spruh73c

    See Table 26-7 for how SYSBOOT determines boot order.

    Read chapter 26, page 4531.

    For EZSDK and StarterWare, see "Software and Development Tools" under

    http://www.ti.com/product/am3358

    Note that StarterWare, in the main, is not open source: it's distributed under TI commercial license.

    Regards

    Roger.

  • 0 in reply to Roger 8421
    Expert 2280 points

    Yes, TRM is quite clear about AM335x chip, but easy documentation about boards is poor.

    Do user need to read Beaglebone hw schematics to now about  booting sequence?

    I spent quite time to understand that boot-selector DIP switch (SW3) on AM335x EVM is labeled on the wrong side: so if you set first switch of SW3 to OFF, that means SYSBOOT[0] = 1, while ON means 0. I did not found this info in any HW EVM documents. You can find it in U-boot and Starterware user guides wiki pages, but what's the reason to put it there? It's an EVM hw related info.

  • 0 in reply to Qmax
    Intellectual 290 points

    Hi, while I completely accept your point that one might assume  positive logic i.e. that on = 1 and 0 = off, unless otherwise informed, the switch is not really mislabelled. The "on" label on the switch was placed there by the manufacturer and in that position the switch is actually closed. The reason the lines are inverted is that the EVM wires the boot pins with 100k weak pull-ups. The switches pull these down with stronger 10k pull downs when turned on. This means that the default level for a SYSBOOT line is 1 when the switch is off. Turning the switch on pulls down with 10k. Neither the pull-up nor down is so strong as to prevent these lines being over-driven by the CPU so they can be used to drive the LCD too.

    in the schematic, I see both switch 3 and switch 4 are wired like this. There's probably a good reason the pull up/down configuration wasn't reversed so that 100k pull-downs were active until 10k pull ups are switched in. This would have given on = 1 for SYSBOOT lines.

    I agree that some on-board silk screen indication and a note in the EVM guide would help.

    Regards,

    Roger.

  • 0 in reply to Roger 8421
    Expert 2280 points

    By the way, is there any AM335x EVM Guide or Manual (not the two pages QSG)? I cannot find any.

    The AM1808 Exp Kit board came with much more documents (User guide, DevKit User Manual) and materials like BSL, GEL and target configuration files for CCS. Does anybody know where I can find this materials for AM335x?

    Roger, I completely agree with you from the HW point of view. My note was just a suggestion on how little details could make things simpler. By the way TI wiki itself says "ON is labeled on the wrong side of SW3 boot mode switch." And two lines below it links to an EVM reference manual that I've not been able to find (or is it the AM335x TRM?).

    Regards, Max

  • 0 in reply to Qmax
    Expert 1835 points

    hi all,

    Regarding the AM335x on-chip ROM, the very basic bootloader (1st stage loader) is in the AM355x on-chip ROM.

    is there any way to program the AM335x on chip ROM by using JTAG or any others programmer ?

    if i buy a new AM335x processor, how i burn the 1st stage loader(the very basic bootloader) into the AM335x on-chip ROM ?

    Thanks & Regards.

    Keldy

  • 0 in reply to Keldy
    TI__Guru 58695 points

    The AM335x ROM is masked and can not be changed.  The ROM memory cells are implemented with descrete logic when the device is built.  They are not programmable memory cells.

    The ROM code will begin the system boot process by reading the SYSBOOT inputs latched during reset to determine which peripheral to use for booting.

    Regards,
    Paul