On 2011/04/18 10:00 PM, Michael Schwingen wrote:
Any ideas why the flash unprotect might fail?
AFAIR, this is not implemented for AMD/Spansion parts, since these parts
never had any protection mechanism when they started.
In Contrast, many Intel flashes come up protected out of reset and
*need*
flash probe 0" \
> -c "flash info 0" \
> -c "flash erase_address pad unlock 0xfffd 0x3" \
> -c "flash write_image erase unlock mtdblock4 0xfffd" \
> -c "shutdown"
>
> at:
>
> http://dawes.za.net/rogan/openocd-20110418-211900.l
gt;
> openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log \
> -c "flash probe 0" \
> -c "flash info 0" \
> -c "flash erase_address pad unlock 0xfffd 0x3" \
> -c "flash write_image erase unlock mtdblock4 0xfffd" \
> -c &quo
d a debug log of the following command:
>
> openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log \
> -c "flash probe 0" \
> -c "flash info 0" \
> -c "flash erase_address pad unlock 0xfffd 0x3" \
> -c "flash write_image erase unlock m
0x3" \
-c "flash write_image erase unlock mtdblock4 0xfffd" \
-c "shutdown"
at:
http://dawes.za.net/rogan/openocd-20110418-211900.log.gz
The only difference in config files is the flash definition changed to:
flash bank eightMB cfi 0xff80 0x80 1 1 $_T
is attempting.
>
> I placed a debug log of the following command:
>
> /usr/local/bin/openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log
> -c "flash probe 0" -c "shutdown"
>
> on my website at:
>
> http://dawes.za.net/rogan/openocd-20110418-182
mpting.
I placed a debug log of the following command:
/usr/local/bin/openocd -f buspirate.cfg -f dns323.cfg -d3 -l openocd.log
-c "flash probe 0" -c "shutdown"
on my website at:
http://dawes.za.net/rogan/openocd-20110418-182940.log
Config files are:
http://dawes.za.net/rog
Hi,
I've had some similar problems like that in the past. It was about a
non-cfi x16 part connected to a x8 bus. Which flash part are you
trying to program? Can you send a verbose log of what openocd is
trying to do to detect your part?
Thanks.
On Mon, Apr 18, 2011 at 8:47 AM, Rogan Dawes wrote
Hi folks,
I have a D-Link DNS323, which has an 8MB Spansion flash chip in it.
The CPU is a Marvell Orion5x (Feroceon) MV88F5182 (CPUTAPID 0x07926041,
which is not in the existing sources, FWIW).
I can identify the CPU fine, but am unable to identify the flash part. I
suspect that part of the pro
On Sun, Apr 17, 2011 at 8:12 PM, Sébastien Farquet
wrote:
> No reaction
> So monday, I will make a commit on
> git://openocd.git.sourceforge.net/gitroot/openocd/openocd
Hello Sebastien,
no offense, but this statement shows that you do not have deeper
understanding how open-source projects work. Y
Hi folks,
I have a D-Link DNS323, which has an 8MB Spansion flash chip in it.
The CPU is a Marvell Orion5x (Feroceon) MV88F5182 (CPUTAPID 0x07926041,
which is not in the existing sources, FWIW).
I can identify the CPU fine, but am unable to identify the flash part. I
suspect that part of the pr
Øyvind Harboe wrote:
Did you read the patch ?
No. I'll leave it to others to work on the ft2232 driver.
So if you did not read the patch, why did you comment it !
I'm just trying to give him some general advice on how to
best solicit the review / help from others on the list as he
was
On Mon, Apr 18, 2011 at 11:30 AM, Øyvind Harboe wrote:
>> Did you read the patch ?
>
> No. I'll leave it to others to work on the ft2232 driver.
I should be a bit more precise here. I looked at it quickly and
decided that it would be best to have this reviewed by someone
who actually spends time
> Did you read the patch ?
No. I'll leave it to others to work on the ft2232 driver.
I'm just trying to give him some general advice on how to
best solicit the review / help from others on the list as he
was concerned about why he didn't see any yet.
I want to see a review of this change to ft22
A tip that might be applicable:
break the patch apart in multiple patches.
The first patch would rearrange the code, but essentially leave the
entire execution and behavior unchanged(bugs included).
The Sebastien's patch is already very small and is the 'rearrange the
code' part. There ar
A tip that might be applicable:
break the patch apart in multiple patches.
The first patch would rearrange the code, but essentially leave the
entire execution and behavior unchanged(bugs included).
The second patch would fix the problem.
Your chances of having the code reviewed will be much hi
16 matches
Mail list logo
