Hi,
kragorn, have a look at
http://jeff.doozan.com/debian/uboot/build_uboot.htm. Jeff expains that copying mtd devices using dd will fail because of the applied ECC algorithm. He explains what to do instead. I can not comment on the cable you found. I am trying to use OpenOCD-USB, a small FT2232-based adapter ...
I still do not manage to get a U-boot image executed from DRAM or written to NAND. Downloading to DRAM seems to work, however, executing the image seems to fail: The status changes from halted to running, but I do not see any output on the serial console. I am trying to download an image read from mtd0 of another device using
$this->bbcode_second_pass_code('', './nanddump -nof uboot-original -s 0 -l 0x80000 /dev/mtd0')
At the moment, I do not have further ideas on that problem. Alexander: I think using the original U-Boot should ensure that it properly initializes the device, so I do not think this is the problem ...
Writing to NAND fails too, complaining that the target was not halted:
$this->bbcode_second_pass_code('', '
> poll
background polling: on
TAP: feroceon.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
>
> nand erase 0 0x0 0xa0000
erased blocks 0 to 5 on NAND flash device #0 'NAND 256MiB 3,3V 8-bit'
>
> poll
background polling: on
TAP: feroceon.cpu (enabled)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x000000d3 pc: 0xffff0000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
>
> nand write 0 nanddump/uboot-original 0 oob_softecc_kw
timed out while waiting for target halted
error executing hosted NAND write
target not halted
NAND flash access requires halted target
NAND flash access requires halted target
[...]
NAND flash access requires halted target
NAND flash access requires halted target
failed writing file nanddump/uboot-original to NAND flash 0 at offset 0x00000000>
>
> poll
background polling: on
TAP: feroceon.cpu (enabled)
target state: debug-running
>
')
The NAND problem could be related to the config registers related to NAND access. I just copied the corresponding lines from sheevaplug.cfg:
$this->bbcode_second_pass_code('', '
mww 0xD0010418 0x003E07CF # NAND Read Parameters REgister
mww 0xD001041C 0x000F0F0F # NAND Write Parameters Register
mww 0xD0010470 0x01C7D943 # NAND Flash Control Register
')
And also related to that problem: It looks like the target would change status to "running" after invocation of the nand_write command. How can that happen?
Any ideas what I should try?
Mali