Magnus Lundin wrote: > Hi list, > > I know there is a lot of fixing to get a stable 0.2.0 so this is > clearly for next release. > But I also know that some folks wants to get going with CortexA8, so > here it comes.
Great! Many thanks! Dave, Sergey: This does look like a really *good* starting point for the last step to final OMAP3 support in OpenOCD, no? Again many thanks and best regards Dirk > Index: src/target/Makefile.am > > Index: src/target/armv7a.c > Index: src/target/armv7a.h > Index: src/target/cortex_a8.c > Index: src/target/cortex_a8.h > > Index: src/target/armv7m.c > Index: src/target/arm_adi_v5.c > Index: src/target/arm_adi_v5.h > > This code has mainly been developed and tested against R1606, it has > been built and tested against R2294 where it runs but step and resume > commands are broken due to regression in codebase, this should be fixed > in current head. > > I do have not have access to the ARMv7A/R archtecture manual so it is > hard to make a precise distinction between CorexA8 and ARMv7A features. > > The ARMv7A architecture and register set is a variant of the armv4/5/6 > and it is not a variant of the ARMv7M used by CortexM3. > The debug interface is ARM_ADI_V5, most (hopefully all) changes to > handle the differences from the CortexM3 implementation has already been > added to arm_adi_v5.c. > > This code is really written for OMAP3530. > The identification of debug resources from the ROM table is not > implemented, there is code to scan a rom table in > arm_adi_v5.c:dap_info_command but it is not used for setting adresses of > debug resources. > In the most general situation every memory mapped debug resource, > including ROM and RAM, must be associated with a dap number and a memap > address, this can, and probably most often will, be equal to the > processor memory bus address but this is not necessary. > > The OMAP3530 uses two memap access ports, dap 0 and dap 1. > dap ap #0 is connected to L3 interconnect, with passthrough to L4 Emu > dap ap #1 is connected to L4 Emu interconnect , with access to L4 Wakeup > and holds the ROM table > This means that most memory bus accesses should be done through dap ap > #0, but access to L4 Emu interconnect and scanning the ROM table should > be done through dap ap #1. > > The are at present some defines to handle this in cortex_a8.c, they > should be replaced with more general code, but that should probably be > done when we have access to other Cortexa8 implementations. > > #define swjdp_memoryap 0 > #define swjdp_debugap 1 > #define OMAP3530_DEBUG_BASE 0x54011000 > > -------------------------------------- > PATCH AGAINST 2294 > arm_adi_v7m_R2294.patch > > Index: src/target/arm_adi_v5.c > Index: src/target/arm_adi_v5.h > Index: src/target/armv7m.c > > The changes in these files move the dap command handler implementations > to arm_adi_v5.c, leaving just thin wrappers in armv7m.c. > There should be no change in functionality here. Should be harmless to > commit. > > -------------------------------------- > NEW FILES > > Index: src/target/armv7a.c > Index: src/target/armv7a.h > > Here we find the core register architecture and command line handlers > for the dap commands implemented in arm_adi_v5.c. > These fuiles does not affect any other but cortex_a8.h/c code in > OpenOCD. Should be harmless to commit. > -------------------------------------- > COMPLETE REPLACEMENT > > Index: src/target/cortex_a8.c > Index: src/target/cortex_a8.h > > This is the target implementation. This code is similar to the CortexM3 > and ARM7_9 targets. > This replaces the previous nonfunctional cortex_a8 code with something > that at least basically works even if it is incomplete. > Does not affect any other subsystem, thus harmless to commit. > -------------------------------------------------------------------------------------------------------------- > > > Comments > > This code has been tested with a Flyswatter interface and a BeagleBoard. > Under uBoot, virtual memory disabled: > + mdw/mww works > + load_image/dump_image of a 100k jpeg picture to ram > + load_image of a small application (led blink) to ram run using resume > <startaddr> > + halt/step/resum works (R1606) > + breakpoints works > Testing is not exstensive but on my system it works. > > > After Linux is started things get WEIRD !!! > > I know that there are lots of very raw edges but instead of holding off > until it is nice and clean, I submit this for everybody to play with. > > Good luck and have fun. > Magnus > > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
