Ticket #143 (new enhancement)
test NAND write/read support in OpenOCD
| Reported by: | laforge@… | Owned by: | laforge |
|---|---|---|---|
| Priority: | highest | Milestone: | |
| Component: | Host Software | Version: | current svn head |
| Severity: | minor | Keywords: | |
| Cc: | buglog@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | no | PatchReviewResult: | |
| Reproducible: |
Description
Currently we're using the wiggler with sjf2410-linux for flashing the NAND.
This takes ages, and is extremely uncomfortable.
The right way to do this, is to add NAND erase/program/read support to OpenOCD
(http://openocd.berlios.de/), and then use that with the wiggler, or any other
supported [way faster] JTAG adapter.
Change History
comment:1 Changed 6 years ago by tony_tu@…
- Status changed from new to closed
- Resolution set to fixed
comment:2 Changed 6 years ago by laforge@…
- Status changed from closed to reopened
- Resolution fixed deleted
this bug is about a native software feature in OpenOCD.
To clarify: We cannot _directly_ flash our NAND flash from OpenOCD (using JTAG
EXTEST method like sjf2410).
Since DebugBoardv2 is only supported by OpenOCD, not by sjf2410, we can only use
the indirect flashing method as described in
http://wiki.openmoko.org/wiki/Bootloader#Using_JTAG_to_boot_from_RAM
This is not a practical problem at all. But still it would be good if we'd have
the option to use EXTEST based NAND flashing in OpenOCD.
comment:3 Changed 6 years ago by laforge@…
- Status changed from reopened to new
- Owner changed from buglog@… to werner@…
- Summary changed from Implement NAND write/read support in OpenOCD to test NAND write/read support in OpenOCD
there is now a patch available at
https://lists.berlios.de/pipermail/openocd-development/2007-March/000115.html
comment:5 Changed 5 years ago by willie_chen@…
- Status changed from new to closed
- Resolution set to later
Later
comment:6 Changed 5 years ago by laforge@…
- Status changed from closed to reopened
- Resolution later deleted
this was already marked as 'enhancement'. Please leave it open.
comment:7 Changed 5 years ago by andy@…
- Status changed from reopened to new
- Owner changed from willie_chen@… to laforge@…
comment:9 Changed 5 years ago by john_lee
- HasPatchForReview unset
The latest openocd svn is 1115 now and we're using 517. I wonder if this is in upstream already?
comment:10 Changed 5 years ago by laforge
- Priority changed from high to highest
the feature is in upstream, yes. But still, it has not been tested or used by somebody within Openmoko on an openmoko device, as far as i know.
nonetheless, it is definitely not as important these days than it was some time ago.
by the way: is anyone working on s3c6410 support for openocd?
comment:11 Changed 5 years ago by andy
Why did we make this "highest" priority if it is "definitely not as important these days"... it really isn't important for us at all any more AFAIK, on any GTAxx. On GTA01 and 02 we use a scheme to push the bootloader into steppingstone the SDRAM both by JTAG for board bringup followed by DFU, for GTA03 we use direct SD Card Boot which is already working here on SMDK. So I would like to close this as WONTFIX.
Ben Dooks mentioned he has ARM1176 macrocell support (rather than SoC level s3c6410) up in openocd already.
we got the debug boardv2 with FT2232 chip, removed the wiggler already