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.

OMAP4x series related

Hello there readers,

greetings!

i hope everyone is fine.

I have a serious question related to bootrom wrt OMAP4430 and OMAP4430 HS chips

I have gone through the documentation. and it says using jtag i can reprogram the bootrom region using jtag or icepick.

and it also says its permanently written and then it says it can be jtagged. can someone clear this confusion for me as which one is true. If the bootrom is permanently then how can it be jtagged and also what if i wish to write my own bootrom and bootloader.

i am asking this because i am working to port coreboot (www.coreboot.org) opensource firmware replacement to traditional bios.

the debug document says we can jtag it, and then it says it cant. So what are my options to port coreboot as an alternate bootrom and bootloader to this device.

and one more question i have? can i rip the chip out of the board and keep it on another board like beagle/panda and then debug it and wipe clean the cpu and then proceed with the debug process?

and lastly, hello from India, english is not my mother tongue, so i might have many mistakes while putting forward my question. kindly ignore my spelling and grammar and other mistakes. thank you.

thanks!

-paul

  • Hello Paul,

     

    I am not sure exactly which document and which section you are referring to, but the boot ROM cannot be reprogrammed.

     

    Thanks and regards,

    Koichiro

  • hello koichiro,

    i was reading the documents TI wrt omap4430 TRM and debug manual and the confidential documentation from arm.com, which said it can be done.

    am i making a mistake? or the documents are misleading me. one says yes and the other says no.

    or TI implements the register cp15 differently?

    since i dont have the HS documents from TI which are under some NDA. can i get a hold of those documents and whom to contact for that?

    arm.com generic armhf says it can be done, thats why.

    can you clear this doubt. i will give it a shot this weekend.

    thanks!

    -paul

  • Hello koichiro,

    one more thing, bootrom is stored in the emmc ssd in this device and not sd card or network boot or other media. its only the signature which is kept in the non-volatile sram like UUID + sha256 of the RSA-256 in the register. atleast thats what the mshield signing tool document says.

    so, how come i cannot reprogram the bootrom i.e. x-loader? since the register cp15 which holds this information can me modified with a jtag, why cannot the region be cleared? and i run my own bootrom.

    and each and every document says one thing bootrom is inside some other media like the emmc or sdcard or network boot, etc etc. here the NAND flash contains the bootrom.

    so i dont understand one thing how it cannot be done?

    thanks!

    -paul

  • Paul,

     

    OK. Now I understood you are talking about x-loader.

    I thought you wanted to reprogram boot ROM which is mask ROM.

     

    As you said, x-loader is written in eMMC (or SD card) in most cases.

    You can reprogram it without an issue.

    I am not sure how cp15 is related to program xloader though.

     

    How did you program the xloader in eMMC at first ?

     

    Thanks and regards,

    Koichiro

  • Hi koichiro,

    greetings!

    i am not speaking about the x-loader or u-boot. i am speaking of the volatile SRAM and SROM.

    the arm documentation says

    TZ protection controller BP 147 is 8-16 kbytes TZ boot rom.

    TZ internal memory wrapper BP 141 is 64 -97 kbytes TZ ram.

    TrustZone_Hardware_Requirements.pdf

    from arm.com tells more which TI i am afraid never documented and in that page 8,9 and page 10 gives good information. 

    and this document PRD29-GENC-009492C_trustzone_security_whitepaper.pdf

    tells me Secure privilege invasive debug (jtag) (SPIDEN) and secure privilege non-invasive debug (SPINDEN) and secure user invasive debug (SUIDEN) and secure user non invasive debug (SUINDEN) are all 2 bits flip.

    the AXI to APB bridge included a single TZPCDECPROT.

    the on-SOC is the only part which cannot be easily programmed thats what the document says. if TI implements the guidelines from arm.com then the instructions should be the similar isnt it?

    now my question will be this -> if the on-SoC OTP fuse poly silicon fuse one written can be rewritten? or wiped?

    because DDI0431C_tzasc_tzc380_r0p1_trm.pdf says something else. it says it can be. correct me of i am wrong. because i guess DDI0431C_tzasc_tzc380_r0p1_trm.pdf is the model based on which TI develops its own HS stuffs. and this contradicts what you said. it said it can be. but it also says vendor can make modifications.

    so now my question will be? if TI implements the strict guidelines from arm.com does it mean that the on-soc ROM can be reprogrammed if we send specific signals.

    since secure_boot_lock can be set to 0 = low and 1 = high

    could you please answer this question?

    thanks!

    -paul

  • hi koichiro,

    greetings,

    sorry i missed one question. how did i reprogram. no i havent done it yet. i have a bricked blackberry playbook board whose NAND flash is gone. so if i rip the NAND flash can i load any x-loader and u-boot and install an OS of my choice? say debian or netbsd/freebsd?

    i will be doing the experiment this sunday and on monday only i can give the answer to this question.

    and the document says the on-soc stores the encryption key. right?

    thanks!

    -paul

  • Paul,

     

    Ok, if you really want to reprogram internal (on-chip) ROM, it is not possible.

    The ROM is not programmable ROM. The ROM contents are hardwired.

     

    I do not have ARM documents you are referring to, and I am not a developer,

    so I am not able to answer your question how TI implemented internal ROM.

     

    Thanks and regards,

    Koichiro