• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: Arggg.. The state of openOCD on openRD  (Read 2318 times)

Karma: 0
Posts: 12

View Profile
« on: December 20, 2009, 10:02:36 PM »

I finally recovered my openRD's uboot after 15+ hours of hell with openOCD. In the end I managed to fix it without openOCD....

So, this leads me to my first question. Have other people managed to flash an openrd's uboot using openOCD?

The short list of problems I had were:

    * The "official" version on the CD/download is statically bound with libUSB keeping it from being able to detect the ftdi device on many (most) recent version of linux. (This is caused by libUSB not understanding how to probe USB devices)
    * The openrd.cnf file only works with a fairly narrow range of openOCD versions, and the version it works with is ancient.
    * Finally, the worst problem is that the addresses in openrd.cfg (openrd_init and nand device) appear to be totally wrong.

So, after compiling every version of openOCD from the CD, to the latest GIT, porting the openrd.cfg file, etc. I started poking around by hand on the openOCD command prompt. What I discovered was this..

OpenOCD appeared to be working just fine after I built it using a recent version of libUSB. I could manipulate memory, read processor registers, Set assorted states, etc.

What wasn't working was the whole openrd_init process of writing to registers at 0xD0001xxx. That whole memory region appeared to be invalid. Same for the nand device at 0xd8000000. Running a `nand probe 0` with the given information simply returned 0's and caused an error because openOCD couldn't detect the device type.

The openrd.cnf file has a nice comment "this assumes the hardware default peripherals location before u-boot moves it". Along with the comment in the manual about running the script immediately after a power cycle, makes me think that might have been exactly what was happening. Only, I never successfully managed to detect the nand no matter how fast I power cycled and tried to halt the device.

This leads to my only real question. Assuming the addresses are incorrect, what are the correct addresses post uboot? Can they be dynamically detected from whatever register is being used to move the nand device? Does such a register exist? (I didn't find anything in the open documentation, I guess I might have to try and get the restricted version). Why, if uboot moves the nand, isn't there a comment indicating likely locations after the move?

Finally, I guess it could be some form of flash write protection bit, that keeps the device from responding to the wakeup sequence, but why was the device protected?

Bah, what I learned is not to screw around with uboot on a $250 openRD client, get a cheaper device (cause it will likely become a paper weight), or get openOCD's flash functions working stability before experimenting with uboot.

Pages: [1]
Jump to: