Am 25.02.2011 17:54, schrieb Michael Schwingen: > Mathias K. wrote: >> >> Am 25.02.2011 14:38, schrieb Michael Schwingen: >> >>> Mathias K. wrote: >>> >>>> I think you can't simple abstract this with 8/16/24/32bit access, because >>>> in my case the data bus >>>> has always a 24bit width and the address bus increment is always one (one >>>> address and 3 bytes of >>>> data). There is no alternative alignment how you can describe a byte of >>>> this 24bit with a bus >>>> address, thats the problem. >>>> >>> So the problem is that a word (of 24 bits) is supported as the *only* >>> access type? >>> >> >> Yes, thats true. >> >> >>> In that case, I think we should talk about unaligned accesses insteadof >>> harvard/risc. >>> >> >> Okay, sounds good. >> >> >>> Now the question is how to handle this at the higher layers: >>> - only allow word-sized accesses - ie. fail all byte-read/write attempts >>> >> >> This should work. GDB as example always read/write the memory or registers >> with a 32bit access, the >> highest byte is never used but transfered. >> > If all upper layers (including flash programming etc.) can live with that > restriction, this would be > my preferred solution - do not try to get smart and (badly) emulate things > that the platform can't > provide.
I think thats okay. Debugging already works and on my platform flash programming is another problem. There are 3 16-Bit cfi chips running in 8-Bit mode and every chip mapped to one byte in this 24-Bit data word ;-). More then one chip in a memory area is not supported by openocd, alignment is heavily used in cfi.c and the write_block functions simple wrap an unknown target pointer to armv7m (target_to_armv7m(target)). But that's another construction site. > >>> - invent virtual byte addresses (as word address * 3) and do >>> read-modify-write cycles in case a >>> single byte shall be written >>> >> >> This make the implementation very complicated and no difference to the >> outside. I think thats not >> the right way. >> > I agree - this sounds like a bad hack, but it might be necessary in case > other software that is much > more difficult to change requires such a behaviour. > > So if it is only allowing/disallowing unaligned or non-machineword-sized > accesses, I think the chip > driver should just provide 1 or 2 flags with these meanings that the upper > layers check. This is > nothing the user needs to change, right? Yes, thats right. One parameter to enable/disable alignment should be fine. I think the data bus width is not necessary here and flash programming use his own parameters. Regards, Mathias _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
