• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 271 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP5912: Unable to soft reset on newer Linux kernel with certain flash modules.

Kevin Wertz
Prodigy 10 points
Part Number: OMAP5912

Hello,

I have two versions of an OMAP 5912 OSK board with different flash modules.  The first version uses a Macronix PC28F256P30BFE module which was marked obsolete some time ago.  The second, newer, version uses a Macronix MT28EW256ABA1LPC-0SIT flash module which is still in production.  When warm rebooting Linux 2.6.28 both boards work as expected, landing in u-boot and eventually making it into Linux.  However, when using Linux 4.18, the board using the older PC28F256P30BFE module hangs in the first stage ROM bootloader and never makes it to U-boot.  The newer flash module MT28EW256ABA1LPC-0SIT works fine with the newer kernel and is able to reboot as expected. Both boards are able to cold boot just fine, so I suspect there's some sort of reset that isn't being properly done for the older flash module, but I'm not exactly sure what that would be since I've modified the reboot routine in 4.18 to match the reboot routine in 2.6.28.  The reboot routine is also fairly straightforward, it just disables interrupts, clears cache, does a memory manager remap and then writes a value to the ARM_RSTCT1 register.  I know the reboot routine is working because I attached a JTAG debugger to the board and I can see the PC is reset to 0, and the CPU is halted in CCS, then the CPU begins executing what I can only assume is the first stage ROM bootloader.  Unfortunately, I wasn't able to figure out much from this because even on a working board the ROM bootloader doesn't want to jump to U-boot while stepping through instructions individually, only when I hit the 'Run' button will it jump to u-boot and then Linux.  I checked the schematic of the board and confirmed that nothing on the reset pin or any other pin has changed with regard to how it is connected to the OMAP processor.  Any information on how to proceed from here is appreciated.

Best,

Kelvin

  • 0
    TI__Guru** 101130 points

    Hello Kelvin,

    Unfortunately, OMAP5912 is a pretty old part. Our team no longer has HW or SW expertise on this part, so we cannot provide hardware or software design support. However, if anyone in the community reading this thread has OMAP5912 experience, please jump in!

    Regards,

    Nick

  • 0
    Prodigy 10 points

    I found the problem, and I'll post my solution here for posterity. Basically, within the cfi_cmdset_0001.c file there's a function for the mtd device rebooting called cfi_intelext_reboot. What it will do is send a command to put the flash module into its default read mode state which is asynchronous page mode read. I presume the OMAP bootloader expects the flash module to be in this mode. For whatever reason, in newer Linux versions, this mode change didn't stick, and somewhere in between the mtd driver being unloaded and the actual reset register being written to, the chip was put in a different state. Thus, when the reboot occurred the first stage bootloader couldn't do anything. My solution was to write the reset command to the flash chip right before the CPU actually resets. This second, seemingly redundant reset solved my problem. My flash chip is located at memory address 0x00000000 and being an intel NOR flash chip the reset command is 0xFF. One ioremap and a write later, I had a properly rebooting system. 

    Best,

    Kelvin