How to dump a ROM via U-boot?

[legacy]

so, in 2005 ... guys at IBM were really really so crazy that they made the firmware of their PPC4xx evaluation boards unable to update itself.

There is an unprotected flash on their boards, but there are no functions in the firmware to write the flash or to dump it, and of course, their firmware is unable to load and bootstrap a Linux kernel correctly.

So I am going to replace the firmware with u-boot, which can be made via a Jtag cable. I don't have a BDI2000 professional one, I have a simple home-made "Wiggler cable" (sort of parallel port cable), which is able to initialize the dram controller on the PPC4xx chip, load something in the dram, initialize registers in the CPU, and force the program counter to an address to start execution.

This means that I can patch u-boot in order to obtain a version that can be uploaded in ram and can program the flash, uploading a new firmware via tftpboot.

That's is good, but ... there are certain things on the boards (FPGA implementing memory-mapped devices) that are not documented anywhere, and since they are supported by the IBM firmware I'd better make a copy in order to reverse-engineer the code so I can understand how they need to be initialized.

I was also thinking about removing the flash so it can be read in a ROM programmer, but the chip is soldered on the PCB, and there is for sure glue under the chip, just to make things harder ...

The "ram-u-boot" seems to be the right solution, just ... I have sucessfully compiled an old 2009 version, which works on the boards but it doesn't support any download via tftpboot. It can only upload, while newer versions of u-boot do support both modes, but they do not work on my boards, which are now deprecated (EOL since 2010).

Code: [Select]

tftpboot 800000 firmware
tftpboot can upload a remote file into ram

Code: [Select]

tftpboot 800000 firmware 400000
tftpboot can download a chunk of ram (size=0x40.0000) to a remote machine

The last one is not implemented, and I can only "dump" something via the command "memory dump", which "prints" hex code on the serial line ... so, I am thinking about ... using "minicom" in "stream capture" mode, so I will obtain a copy of everything will be the printed as hex code, so it can be post-processed and converted into a "binary" file by a script (python? perl?)


What do you think? Do you happen to have already done something similar?


edit:
ops, I have just realized that I did a mistake on my browser. I accidentally copied the buffer into the title area, and I can only partially fix it. Sorry for that.

[PA0PBZ]

I did similar stuff in the past. If it is a one-off and all you have is a monitor capable of dumping the memory this is the fastest way to do it. Just log the session to a file and process it anyway you feel, almost anything will work, even Excel

[nctnico]

How about adding a command to u-boot which dumps the contents of the ROM as a hex file to the serial port? Do one row per u-boot  main loop cycle. Another option is to back-port the newer tftpt software to the older u-boot.

[legacy]

How about adding a command to u-boot which dumps the contents of the ROM as a hex file to the serial port?

srec s19? I have already made something similar for my motorola board (I have rewritten the firmware from scratch), so I can reuse the C code. It seems that adding a command to u-boot is not tricky.

Good idea 

Another option is to back-port the newer tftpt software to the older u-boot.

That looks more complex, not tricky but complex, because there is a lot of code to be modified. It seems possibile, but I am afraid that it will require more effort.

Newer u-boot also implement the "device tree" blob, and they pass it to the kernel. That means that, sooner or later, I will have to migrate to a new version of u-boot. I can patch kernel 3.* in order to workaround the "device-tree" request, but I cannot do it for kernel >=4.*