[Openocd-development] Flashing DM355 bootloader
Hello All: I'm playing with a DM355 based board, and I'm trying to flash the bootloader into its NAND flash. NAND flash is a 256MB with 2048 blocks, each block 64 pages and each page 2048+64bytes. Those chips provide an internal ROM bootloader which, among other things, should start the next stage bootloader, in this case stored into flash. I've known from the Texas Instruments documentation that the ROM bootloader embedded into chip doesn't work the way NAND manufacturers suggest. So instead of reading the OOB information from the end of the page, that information is interleaved by each 512bytes. I think this is the reason why hwecc4_infix layout for davinci nand flash driver was developed. But there's also another parameter that can be used for writing to nand: oob_softecc (and oob_softecc_kw) My question is which one of those should be used to flash the first bootloader on that cards? · Use hwecc4_infix driver mode for davinci · Use oob_softecc flag when writing to nand · Use oob_softecc_kw flag when writing to nand · A combination of any of them Thanks and regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
El Lunes, 5 de Octubre de 2009 22:07:35 David Brownell escribió: On Monday 05 October 2009, Øyvind Harboe wrote: In short, the following will happen: 1. The source will be held in git. https://sourceforge.net/projects/openocd/ !!! And if anyone objects to GIT, please speak up ASAP !!! Could have been sooner certainly. I had my doubts about even suggesting this proposal, but then I thought spending few minutes reading it wouldn't hurt much. I think mercurial [0] could be a good option. It's a well known distributed VCS, maybe not as spread or known as git, but it's fulfilling most if not all general users aspirations. I find it generally speaking easier to use than git and the move from those used to SVN should be less painful. There's at least a specific host site for mercurial projects [1] but there may be others. Mercurial provides an extension called convert able to translate from another VCS, among them SVN. But there's also a mercurial client for SVN repos [2], this should be the equivalent to git-svn. Pushes can be done, either by ssh or by https, which should address proxy issues. It also provides a graphical interface based on the spreaded TortoiseSVN, which is actually called TortoiseHg [3]. Since Mercurial is almost totally written in python, it's multiplatform, as well as TortoiseHg. Also google code is supposed to also accept Mercurial repositories [4] but I'm not sure about the state of this and the urgency suggests that this is not a clear path to follow. I could find out something about this if there is interest. I just wanted to drop this information, forgetting about typical flames, for the sake of completeness. Feel free to thrash it if you think it's too late of useless. Regarding the mailing list point, in case Google groups are found useful, something I'm not totally sure about, they may complete the total move to Google code once it provides general Mercurial hosting. Regards, [0] http://mercurial.selenic.com/wiki/ [1] http://bitbucket.org/ [2] http://bitbucket.org/durin42/hgsubversion/overview/ [3] http://bitbucket.org/tortoisehg/stable/wiki/Home [4] http://googlecode.blogspot.com/2009/04/mercurial-support-for-project- hosting.html -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm926ejs is broken in 0.2
On Monday 06 July 2009 12:11:42 Øyvind Harboe wrote: I'm trying to do a bisection. It broke somewhere between 1600 svn head. Any arm926ejs testers out there? How is it broken? I think I'm using it correctly (r2240 and others) Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 6/11] Improve standard INSTALL document with OpenOCD-specific introduction:
On Tuesday 30 June 2009 03:51:43 Zach Welch wrote: On Mon, 2009-06-29 at 18:32 -0700, David Brownell wrote: On Monday 29 June 2009, Zach Welch wrote: Attached is a new patch that can be substituted for the original #6 in the series. Cheers, Zach Don't you think asking for trunk checkout would be more convenient than whole openocd which would also include tags, branches and zy1000? Regards -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD license
Hello: I'll just participate in this horrible flame once. On Wednesday 24 June 2009 14:02:26 Ronald Vanschoren wrote: it sucks to have to be the one to push for license compliance like this Then don't! I'm just a user of OpenOCD so you have all right to ignore what I'm saying as you'll find that I'm less important, but it's about time people here start to realize the real clients are users and not developers and users don't give a sh*t about GPL violations. You are not less important, you are just another kind. Clients are important as well, just that you (we) don't pay for using the software. Having said this I don't understand how you (or anyone sensible) could support violating licenses. Do you have the habit of breaking laws for the sake of it? Why would anyone want to waste time and effort on fixing this purely theoretic issue? Use the time to implement useful features like SWD or threadsupport instead. You're acting like you have no choice but to point out this issue and write 700 mails about it. You of all people can fix it easily. Give up your copyright or allow relicensing it under anything that is not as gray and debatable as GPL. I don't think enforcing one's rights is loosing time. This is not a theoretic issue. GPL is the license and it states that whatever you link against and distribute should respect GPL freedom, among others, being able to get the source code. You can do things about this, for instance persuading FTDI to free the FTD2xx driver source and relicense it with GPL or any other compatible license for the issue: adm...@ftdichip.com As a sidenote I still don't see the issue. The spirit of GPL is to allow to make modifications to an application that is distributed in binary form. OpenOCD with FTD2xx allows this, no discussion! So stop using the FAQ of people holier then the pope to argument OpenOCD can't be released on Windows. You wouldn't be able to do modifications on the FTD2xx library, so no point for this. I really don't get it. If OpenOCD were my baby I would like to see it get popular and loved around the world. What's the use of having a super-great application that nobody will use because some people are stubborn and don't see further then idealistic BS. If OpenOCD or whatever other is my baby, I would do what I would like with it. Trying to get it popular, maybe not, give it for free, get paid for it or even license it under GPL terms. In this case rules were dictated from the beginning. Just my 2 cents but I'm quite sure a lot more people are getting tired of this. Change the license or ignore the theoretic violation and get the next version out there in binary form for Windows using FTD2xx. If you (or others) are so interested in a license change, then answer this questions: · Have you contacted every copyright holder and ask for his opinion? · if (s)he is reluctant to change license what will give you in compensation? · Are you willing to pay money for the work they have done to change license? · Are you willing to accept anyone is not going to admit a license change? License is not democracy, not even meritocracy, is consensus. License is what it is and only an agreement of all copyright holders can change that. If I had something to say I would ask every contributor to state if they allow a relicense. If not, strip out their code and rewrite it. That can't take longer then making the workarounds people are discussing now. While we're at it, demand that contributors donate their copyright to the OpenOCD foundation or whatever, so these discussions are a thing of the past. I don't want to run a 2nd application to be able to use FTD2xx on windows. I already have to run OpenOCD and gdb, more then enough to keep track off. gr. Ronald What I don't understand so far is why it is so important to add an exception to the license instead of: · Improving free FTDI library · Asking FTDI to release and free the FTD2xx library · Make people interested in running FTD2xx build his own copy/binary of openocd Most of this options requires less work than tirelessly quarreling on the list. It is possible not using FTD2xx, it is also possible using it. Whoever is interested enough on any of those aspects should care for it, but not putting pressure or insulting(*) developers to do what they claim. Why is it easier to put pressure on developers who actually does a great job and not on a company that should encourage its products to be sell? (*) I don't refer you, Ronald. Regards, Pd: This e-mail express a strictly individual position. -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https
Re: [Openocd-development] OpenOCD license vs D2XX library
On Monday 15 June 2009 20:55:00 Freddie Chopin wrote: Michael Schwingen pisze: those poor windows-only users I think that majority of OpenOCD users are on Windows... Yes, they are not as l33t as the Linux users, but still... http://developer.berlios.de/project/showfiles.php?group_id=4148 6700 d/l of the windows version, add 250 d/l from my webpage, than ask Michael Fisher about the traffic on his website and rethink the attitude towards Windows... 4\/3!! Hi: I think you overlooked a number of installations that come directly from distros like Debian and Ubuntu, and those who build themselves. Windows users just take the binary from berlios, but for other OS installation methods are more OS dependent Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
On Tuesday 02 June 2009 10:32:03 jie.zeng wrote: On Tue, 2009-06-02 at 08:37 +0200, Michael Schwingen wrote: I'm not sure. I thought that address must match the flash interface specification. In this case, from the flash's datasheet where descripted that. And also some other flash datasheet point the same thing as below: Autoselect stage (cycle, addr, data) Manfacturer ID(word) (1st, 555, AA) (2nd, 2AA, 55) (3rd, 555, 90) Manfacturer ID(byte) (1st, AAA, AA) (2nd, 555, 55) (3rd, AAA, 90) Notice the address 0x2AA and 0x555, it's not 0x2aa * bus_width, but the source code it is. Why? If you have multiple flashs wired up on 1 bus, then the address lines between CPU and flash are shifted, requiring correction. The addresses in the datasheet are *flash* addresses, not *CPU* addresses. In case flash_width == bus_width, they are the same. Maybe I got your word. Lets go on. If we want to access a register in the board, we must pass the base address which tell cpu where the register reside and a proper offset(depends on bus-width), right? If the offset is not fix the datasheet, how the cpu can access that reg correctly? In my opinion, the base is 0x1000 in this case. The offset(in fact its on-chip addr) from datasheet(flash) are 0x2aa(word) and 0x555(byte). So CPU write memory should use the address 0x12AA or 0x1555. But now cpu use a wrong address which is 0x1554. The result is that cannot get right ManufacturerID and probe failure. Regards As Michael tried to explain, you need to understand how your flash chip address bus is related to the cpu address bus. If you are writing from a 16 bit address bus to a 16bit flash chip the correspondence is 1-1 so address flash base+offset(0x2aa) will keep the same. On the contrary if the chip and cpu address width differs, you need to do a shift but _just_ on offset address. Please see pg 3 of cfi specification [0] for detailed info. 0x554 is also valid for 0x555. The former happens to be 0x2aa left shifted 1 bit. [0] http://www.jedec.org/download/search/jesd68-01.pdf -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] a minor victory
Hello: On Monday 01 June 2009 01:36:41 Zach Welch wrote: Hi all, After my patch series today, I discovered that I am finally able to flash my custom target reliably from the latest trunk. This is the _first_ time that I have seen success with a recent build. Personally, I consider this a major breakthrough in terms of stability. After over a month of debugging and patching OpenOCD, I can finally reconsider the matter of fixing my target code. :) Major congratulations and kudos to everyone in the community that helped make this minor victory possible. Cheers, Zach I wonder what was special with it? Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
Hello:
On Sunday 31 May 2009 12:58:16 jie.zeng wrote:
Hi list,
I've got a new problem. When I use the command `flash probe 0' after
telnet to the server. It cannot probe the flash.
My core is arm926ejs and flash used CFI interface, so go into the code
and I found something is not normal.
# my flash config
flash bank cfi 0x1000 0x0080 2 2 0
What is the addres at which the flash is located and what is its size?. Do
you use a 16bit bus chip/cpu?
At flash/cfi.c
cfi_probe() {
/* snip */
/* detect manufacturer ID */
unlock2 = 0x2AA;
cfi_command(bank, 0x55, command);
if((retval = write_memory(target, flash_addr(bank, 0, unlock2),
buf-width, 1, command)) != ERROR_OK)
{
return retval;
}
/* snip */
}
I can't find this exact code in the file, could you point the line number?
I found the flash_address is not correct(my fault?), and address is
0x1554.
From cfi flash spec, detect manufacturer ID, the byte addr should be
base + 0x555 I think.
The address depends on your layout, depends on the chip and bus width.
After changed manually, it unlucily... SO, in this function, I adjust
write_memory() to target_write_u8() and it can probe success.
I 've no more idea about that.
What's wrong? Is it a bug?
Regards
--
ZJ
Regards,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote: Raúl Sánchez Siles wrote: Hello all: This start a patchset series for implementing x16_as_x8 cfi compliant feature. · 01-x16_as_x8-consolidate_addresses.patch · 02-x16_as_x8-flash_address.patch · 03-x16_as_x8-multibyte_read.patch I have taken a view to the CFI specification [0] and it looks that the approach should also work for intel chips, while I had only tested it with spansion flash. That looks good to me - I would have expected a lot more changes. Some style comments: - I do not really like left shifts with what is effectively a bool variable as shift amount (bank-bus_width cfi_info-x16_as_x8). The logic is correct, but it looks strange. - In cfi.c, I think we should always use a loop of single-byte reads instead of using separate code for the x16_as_x8 and the normal case. Using the single-byte reads should be safe on wider bus/flash widths, and would make one code path that is better tested. cu Michael I see, thanks for reviewing. Now that's committed and since those comments won't change behaviour I'll review the current style I've used to take that into account. I'll see what I can do. Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
Hello all: This start a patchset series for implementing x16_as_x8 cfi compliant feature. · 01-x16_as_x8-consolidate_addresses.patch · 02-x16_as_x8-flash_address.patch · 03-x16_as_x8-multibyte_read.patch I have taken a view to the CFI specification [0] and it looks that the approach should also work for intel chips, while I had only tested it with spansion flash. FYI, I'm using this patchset all the time while working with flash on the boards I'm testing. I finally merged the command_address functionality into flash_address function. The rest is the same as I sent. I hope this patchset is considered for version 0.2.0. But a little testing should confirm this. [0] http://www.jedec.org/download/search/jesd68-01.pdf -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [1/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -2129,11 +2129,11 @@
if (bank-chip_width == 1)
{
u8 manufacturer, device_id;
- if((retval = target_read_u8(target, bank-base + 0x0, manufacturer)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x00), manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u8(target, bank-base + 0x1, device_id)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x01), device_id)) != ERROR_OK)
{
return retval;
}
@@ -2142,11 +2142,11 @@
}
else if (bank-chip_width == 2)
{
- if((retval = target_read_u16(target, bank-base + 0x0, cfi_info-manufacturer)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x00), cfi_info-manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u16(target, bank-base + 0x2, cfi_info-device_id)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x02), cfi_info-device_id)) != ERROR_OK)
{
return retval;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [2/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -112,9 +112,11 @@
/* inline u32 flash_address(flash_bank_t *bank, int sector, u32 offset) */
static __inline__ u32 flash_address(flash_bank_t *bank, int sector, u32 offset)
{
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
+
/* while the sector list isn't built, only accesses to sector 0 work */
if (sector == 0)
- return bank-base + offset * bank-bus_width;
+ return bank-base + (offset * bank-bus_width cfi_info-x16_as_x8 );
else
{
if (!bank-sectors)
@@ -122,7 +124,7 @@
LOG_ERROR(BUG: sector list not yet built);
exit(-1);
}
- return bank-base + bank-sectors[sector].offset + offset * bank-bus_width;
+ return bank-base + bank-sectors[sector].offset + (offset * bank-bus_width cfi_info-x16_as_x8 );
}
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [3/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 12:20:57 Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks that the
approach should also work for intel chips, while I had only tested it with
spansion flash.
FYI, I'm using this patchset all the time while working with flash on the
boards I'm testing.
I finally merged the command_address functionality into flash_address
function. The rest is the same as I sent.
I hope this patchset is considered for version 0.2.0. But a little
testing should confirm this.
[0] http://www.jedec.org/download/search/jesd68-01.pdf
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -204,9 +204,18 @@
static u16 cfi_query_u16(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 2];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i2;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8;
@@ -217,9 +226,18 @@
static u32 cfi_query_u32(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 4];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i4;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8 | data[bank-bus_width * 2] 16 | data[bank-bus_width * 3] 24;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC][PATCH] [0/4] x16_as_x8 tentative implementation.
Hello: On Wednesday 20 May 2009 06:36:41 Rick Altherr wrote: From my cursory reading, everything looks fine and straightforward. Since you marked this as an RFC, I'll hold off committing until it is resent to the list. Rick Thank you very much for your review, Rick. I asked for comments because I would prefer applying a cleaner patch. I would like to know if we can merge flash_address and command_address functionality, but in order to tackle this, I'd like to know if command_address would also be useful in the intel case. Another approach would be applying the patchset as I've send it temporarily while working on the above point. If you prefer this, let me know if you prefer a monolithic patch or will you apply each of them (preferred for me). I'm all ears ;) Regards On May 19, 2009, at 3:54 AM, Raúl Sánchez Siles wrote: Hello: This is my first try to implement the x16_as_x8 flash bank option. It is working for me as I would expect flash to work, but please consider this patchset as work in progress since it may still has some flaws. Al patches touch just src/flash/cfi.c file and should apply in this order to trunk. The patchset consists of 4 patches, whose interest areas I explain and comment below: [...] -- Raúl Sánchez Siles -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [RFC][PATCH] [0/4] x16_as_x8 tentative implementation.
Hello: This is my first try to implement the x16_as_x8 flash bank option. It is working for me as I would expect flash to work, but please consider this patchset as work in progress since it may still has some flaws. Al patches touch just src/flash/cfi.c file and should apply in this order to trunk. The patchset consists of 4 patches, whose interest areas I explain and comment below: 01-x16_as_x8-consolidate_addresses · Manufacturer and device id retrieval in cfi_probe function weren't using the generic flash_address. Use it there. 02-x16_as_x8-command_address · Creation of a command_address function intended as flash addresses arranger depending on the x16_as_x8 parameter existence or not. This is basically an override of flash_address function, only that takes into account the x16_as_x8 parameter. The other options for this functionality would be adding an additional parameter to flash_address function or, if it is shown that it is an equivalent of flash_address, include x16_as_x8 functionality into flash_address. 03-x16_as_x8-command_address-subst · Substitution of flash_address function for command_address function, except on code specific to intel. I have just focused on spansion flashes and I hadn't review intel flash specifications, so I decided to be conservative at first. Maybe someone can tell if the command_address function is also valid for intel chips. If so this patch could be grown to include those or eventually include the x16_as_x8 functionality into flash_address not needing this one. 04-x16_as_x8-multibyte_read · cfi_query_u16 and cfi_query_u32 function uses multibyte accesses, this is 2 or 4 byte read. This will fail in the x16_as_x8 case since this would lead reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the 16bit case. Do a byte by byte read in the x16_as_x8 case. Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC][PATCH] [1/4] x16_as_x8 tentative implementation.
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches touch just src/flash/cfi.c file and should apply in this order
to trunk.
The patchset consists of 4 patches, whose interest areas I
explain and comment below:
01-x16_as_x8-consolidate_addresses
· Manufacturer and device id retrieval in cfi_probe function weren't
using the generic flash_address. Use it there.
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -2129,11 +2129,11 @@
if (bank-chip_width == 1)
{
u8 manufacturer, device_id;
- if((retval = target_read_u8(target, bank-base + 0x0, manufacturer)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x00), manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u8(target, bank-base + 0x1, device_id)) != ERROR_OK)
+ if((retval = target_read_u8(target, flash_address(bank, 0, 0x01), device_id)) != ERROR_OK)
{
return retval;
}
@@ -2142,11 +2142,11 @@
}
else if (bank-chip_width == 2)
{
- if((retval = target_read_u16(target, bank-base + 0x0, cfi_info-manufacturer)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x00), cfi_info-manufacturer)) != ERROR_OK)
{
return retval;
}
- if((retval = target_read_u16(target, bank-base + 0x2, cfi_info-device_id)) != ERROR_OK)
+ if((retval = target_read_u16(target, flash_address(bank, 0, 0x02), cfi_info-device_id)) != ERROR_OK)
{
return retval;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC][PATCH] [2/4] x16_as_x8 tentative implementation.
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches touch just src/flash/cfi.c file and should apply in this order
to trunk.
The patchset consists of 4 patches, whose interest areas I
explain and comment below:
02-x16_as_x8-command_address
· Creation of a command_address function intended as flash addresses
arranger depending on the x16_as_x8 parameter existence or not. This is
basically an override of flash_address function, only that takes into
account the x16_as_x8 parameter. The other options for this functionality
would be adding an additional parameter to flash_address function or, if it
is shown that it is an equivalent of flash_address, include x16_as_x8
functionality into flash_address.
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -127,6 +127,26 @@
}
+/* inline u32 command_address(flash_bank_t *bank, int sector, u32 offset) */
+static __inline__ u32 command_address(flash_bank_t *bank, int sector, u32 offset)
+{
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
+
+ /* while the sector list isn't built, only accesses to sector 0 work */
+ if (sector == 0)
+ return bank-base + (offset * bank-bus_width cfi_info-x16_as_x8 );
+ else
+ {
+ if (!bank-sectors)
+ {
+ LOG_ERROR(BUG: sector list not yet built);
+ exit(-1);
+ }
+ return bank-base + bank-sectors[sector].offset + (offset * bank-bus_width cfi_info-x16_as_x8 );
+ }
+
+}
+
static void cfi_command(flash_bank_t *bank, u8 cmd, u8 *cmd_buf)
{
int i;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC][PATCH] [3/4] x16_as_x8 tentative implementation.
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches touch just src/flash/cfi.c file and should apply in this order
to trunk.
The patchset consists of 4 patches, whose interest areas I
explain and comment below:
03-x16_as_x8-command_address-subst
· Substitution of flash_address function for command_address function,
except on code specific to intel. I have just focused on spansion flashes
and I hadn't review intel flash specifications, so I decided to be
conservative at first. Maybe someone can tell if the command_address
function is also valid for intel chips. If so this patch could be grown to
include those or eventually include the x16_as_x8 functionality into
flash_address not needing this one.
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -182,7 +182,7 @@
target_t *target = bank-target;
u8 data[CFI_MAX_BUS_WIDTH];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 1, data);
+ target-type-read_memory(target, command_address(bank, sector, offset), bank-bus_width, 1, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0];
@@ -200,7 +200,7 @@
u8 data[CFI_MAX_BUS_WIDTH];
int i;
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 1, data);
+ target-type-read_memory(target, command_address(bank, sector, offset), bank-bus_width, 1, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
{
@@ -417,7 +417,7 @@
if ((pri_ext-pri[0] != 'P') || (pri_ext-pri[1] != 'R') || (pri_ext-pri[2] != 'I'))
{
cfi_command(bank, 0xf0, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
@@ -490,7 +490,7 @@
if ((atmel_pri_ext.pri[0] != 'P') || (atmel_pri_ext.pri[1] != 'R') || (atmel_pri_ext.pri[2] != 'I'))
{
cfi_command(bank, 0xf0, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
@@ -729,37 +729,37 @@
for (i = first; i = last; i++)
{
cfi_command(bank, 0xaa, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x55, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, pri_ext-_unlock2), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, pri_ext-_unlock2), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x80, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0xaa, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, pri_ext-_unlock1), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x55, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, pri_ext-_unlock2), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, 0, pri_ext-_unlock2), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x30, command);
- if((retval = target-type-write_memory(target, flash_address(bank, i, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, command_address(bank, i, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
@@ -769,7 +769,7 @@
else
{
cfi_command(bank, 0xf0, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, 0x0), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval
Re: [Openocd-development] [RFC][PATCH] [4/4] x16_as_x8 tentative implementation.
On Tuesday 19 May 2009 12:54:31 Raúl Sánchez Siles wrote:
Hello:
This is my first try to implement the x16_as_x8 flash bank option. It is
working for me as I would expect flash to work, but please consider this
patchset as work in progress since it may still has some flaws.
Al patches touch just src/flash/cfi.c file and should apply in this order
to trunk.
The patchset consists of 4 patches, whose interest areas I
explain and comment below:
04-x16_as_x8-multibyte_read
· cfi_query_u16 and cfi_query_u32 function uses multibyte accesses, this
is 2 or 4 byte read. This will fail in the x16_as_x8 case since this would
lead reading, e.g.: addresses 0x0 and 0x1 instead of 0x0 and 0x2 in the
16bit case. Do a byte by byte read in the x16_as_x8 case.
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
--- a/src/flash/cfi.c
+++ b/src/flash/cfi.c
@@ -222,9 +242,18 @@
static u16 cfi_query_u16(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 2];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i2;i++)
+ target-type-read_memory(target, command_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8;
@@ -235,9 +264,18 @@
static u32 cfi_query_u32(flash_bank_t *bank, int sector, u32 offset)
{
target_t *target = bank-target;
+ cfi_flash_bank_t *cfi_info = bank-driver_priv;
u8 data[CFI_MAX_BUS_WIDTH * 4];
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
+ if(cfi_info-x16_as_x8)
+ {
+ u8 i;
+ for(i=0;i4;i++)
+ target-type-read_memory(target, command_address(bank, sector, offset+i), bank-bus_width, 1,
+data[i*bank-bus_width] );
+ }
+ else
+ target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8 | data[bank-bus_width * 2] 16 | data[bank-bus_width * 3] 24;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] CFI driver chip/bus width.
Hello All: Thanks a lot for the prompt answers, unlike this e-mail. I've been off from the office since my post, so sorry for it. I now notice I failed to provide sufficient details about the issue at discussion. The flash uses is a 16bit data width, but it is connected using just 8 bit width. Only the lower data byte is output by the chip and the A-1 address line is used. So in summary, one 16bit width flash chip used as 8bit width by a 8bit data width processor. On Thursday 14 May 2009 22:31:08 Michael Schwingen wrote: Raúl Sánchez Siles wrote: Hello all: I have noticed some issues on CFI flash driver related to chip and bus width affecting read and writes. The system I'm dealing with is based on a Vitesse switch chip which embeds an ARM926ejs processor. It additionally provides RAM and flash controller. In this case we are using an spansion S29GL128 16MB flash chip, using a 8bit width data bus layout, so on each read/write cycle we can only retrieve 1byte at once. The flash chip data bus width is 16bit. I declare the flash like this: flash bank cfi 0x8000 0x100 1 2 0 You mean you have *two* of those flash chips, each connected to one 8-bit half of the 16-bit bus? No, read above. = 1st problem (writing): [...] I guess the x16_as_x8 option defined but not used should be aimed at handling this, but this is unimplemented currently. Um - no. The x16_as_x8 option is used for 16-bit flashes that can be used with an 8-bit data bus. The reason for that option is that in that mode, the magic address values used for commands is shifted 1 bit against what is used on real 8-bit flashs. The option should only tell that a 16-bit flash chip is connected to a 8-bit bus - having multiple such chips in parallel must be handled by the chip/bus geometry handling. And again, I think this is the point. I'll try to implement this parameter. Looks like what I only need is that magic, it's only that so far I wasn't able to make the flash work any other way. I think I aim that the following line works: flash bank cfi 0x8000 0x100 1 1 0 x16_as_x8 Please, correct me if I'm wrong. You might have a look at the CFI code in u-boot, which I *think* does handle this situation correct, however, I have no board with such a flash layout, so I can't really tell. Thanks, I'll take a look. cu Michael Regards, -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] CFI driver chip/bus width.
Hello all:
I have noticed some issues on CFI flash driver related to chip and bus width
affecting read and writes.
The system I'm dealing with is based on a Vitesse switch chip which embeds
an ARM926ejs processor. It additionally provides RAM and flash controller. In
this case we are using an spansion S29GL128 16MB flash chip, using a 8bit width
data bus layout, so on each read/write cycle we can only retrieve 1byte at
once. The flash chip data bus width is 16bit.
I declare the flash like this:
flash bank cfi 0x8000 0x100 1 2 0
= 1st problem (writing):
This clashes somehow with the current CFI driver operations as designed now.
I have discovered that when the connected flash is 8 bit, only byte writes will
be performed correctly so even this call:
target-type-write_memory(target, address, 4, 1, value_buf)
will succeed, the operation isn't carried out correctly.
I got to workaround the problem for just cfi flash probe. See attached cfi-
write-width.diff What I do there is using chip width instead of bus width for
each write. This works in my case but I'm not sure it's the general way to go.
This effect expands to larger write operations, for instance in
target_write_u32 (cfi.c:1220) you would need to repeat a byte write operation 4
times.
= 2nd problem (reading)
But writing is not the only problem. In reading, when chip width is 8bit
whereas bus width is 16bit, single byte operation could be acceptable,
whereas this is no longer valid for halfword or word operations, 16bit and
32bit, respectively. When you call, for example cfi_query_u16, expected return
is 0xAABB, where 0xAA is the MSB and 0xBB is the LSB. Current return is always
0x. Similar problem for cfi_query_u32
The solution is iterating the necessary times for a 1byte read and then
aggregate each iteration result properly. See attached cfi-read_iteration.diff
I guess the x16_as_x8 option defined but not used should be aimed at handling
this, but this is unimplemented currently.
I would like to write a patch addressing this issues, but I thought that I'd
rather bring the topic to the list so I can directly go for a ultimate
solution and not workarounds as I'm using right now.
Comments are welcome. Regards,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
Index: flash/cfi.c
===
--- flash/cfi.c (revisión: 1782)
+++ flash/cfi.c (copia de trabajo)
@@ -203,8 +203,11 @@
{
target_t *target = bank-target;
u8 data[CFI_MAX_BUS_WIDTH * 2];
+ u8 i;
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 2, data);
+ for(i=0;i2;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+ data[i*bank-bus_width] );
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8;
@@ -216,8 +219,11 @@
{
target_t *target = bank-target;
u8 data[CFI_MAX_BUS_WIDTH * 4];
+ u8 i;
- target-type-read_memory(target, flash_address(bank, sector, offset), bank-bus_width, 4, data);
+ for(i=0;i4;i++)
+ target-type-read_memory(target, flash_address(bank, sector, offset+i), bank-bus_width, 1,
+ data[i*bank-bus_width] );
if (bank-target-endianness == TARGET_LITTLE_ENDIAN)
return data[0] | data[bank-bus_width] 8 | data[bank-bus_width * 2] 16 | data[bank-bus_width * 3] 24;
Index: flash/cfi.c
===
--- flash/cfi.c (revisión: 1782)
+++ flash/cfi.c (copia de trabajo)
@@ -2111,17 +2117,17 @@
/* switch to read identifier codes mode (AUTOSELECT) */
cfi_command(bank, 0xaa, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock1), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock1), bank-chip_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x55, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock2), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock2), bank-chip_width, 1, command)) != ERROR_OK)
{
return retval;
}
cfi_command(bank, 0x90, command);
- if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock1), bank-bus_width, 1, command)) != ERROR_OK)
+ if((retval = target-type-write_memory(target, flash_address(bank, 0, unlock1), bank-chip_width, 1, command)) != ERROR_OK)
{
return retval;
}
@@ -2155,12 +2161,12 @@
LOG_INFO(Flash Manufacturer/Device: 0x%04x 0x%04x, cfi_info-manufacturer, cfi_info-device_id);
/* switch back to read array mode */
cfi_command(bank, 0xf0, command);
- if((retval = target-type-write_memory(target
[Openocd-development] Post attach event
Hello All:
Thank you very much for your work and effort on OpenOCD project which we find
way useful and interesting.
We've managed to make it work for our custom board developed based on an
ARM9 chip. My question is related to events. I'd like to take control over cpu
once the chip has been detected and the target created. This way target is
reset and halted as soon as possible.
The line I'm using is this:
target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm926ejs
Initially, I started with a reset-init hook function, declared like this:
$_TARGETNAME configure -event reset-init { init-function }
but it seems that 'reset-init' is not implemented yet, and I'm also not sure
that this is the right event to handle. I've also tried hooking 'reset-
deassert-post' but it is not called either.
I'm using Debian svn r1409 or self build r1411.
Is there an implemented event handling this situation? If so, which one
would it be?
If this requires not much complicated coding I could see the possibility to
code it myself, with some indications, of course :)
Regards,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
