Magnus Lundin wrote: > Øyvind Harboe wrote: > >> On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin <lun...@mlu.mine.nu> wrote: >> >> >>> Yauheni Kaliuta wrote: >>> >>> >>>> Hi, Magnus! >>>> >>>> >>>> >>>> >>>>>>>>> "ML" == Magnus Lundin writes: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>> [...] >>>> >>>> > > I have a simple "works for me" implementation of memory access with >>>> > > cpu instead of AHB and virt2phys using cp15 for cortex_a8, but already >>>> > > got a problem with interfaces: there is only one set of functions on >>>> > > the high target level and if I switch them to mmu variants, I cannot >>>> > > enable debug on omap from tcl config, direct access is required there. >>>> >>>> > Can you post your virt2phys and read/write memory through cpu. >>>> >>>> > I think the virt2phys should be added to the trunk as soon as possible, >>>> > and it should be in armv7a.c >>>> >>>> Ok, I'll recheck it. >>>> >>>> But what do you think about having read/write_phys on target_common_t >>>> level? >>>> >>>> >>>> >>>> >>>> >>> For me that sounds good, with default implementation begin the same as >>> read/write. >>> Then we only need one implementation of the command handler for >>> read/write_phys. >>> Since this touches all targets we need input from more developers, but >>> I can see no >>> obvious problems. >>> >>> >> I don't think you need to touch all the targets? Can't you just >> provide a default implementation? >> >> > You are right it does not touch the code, but it does change the target > type structure and the corresponding entry should be set to NULL or > the default implementation. > > This can be done in target.c:target_init() before calling > target->type->init_target(cmd_ctx, target). > There are some other fields like virt2phys that should be given default > values here. > Looking at the code a little, all targets should initialize all target type fields when defining the specific target type structure. This is not true for mmu and virt2phys fields.
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development