On Fri, Dec 4, 2009 at 19:28, Jie Zhang <wrote: > On 12/05/2009 01:44 AM, David Howells wrote: >> Mike Frysinger<vap...@gentoo.org> wrote: >>> The Blackfin port has custom program header flags/addresses for >>> automatically loading regions into the dedicated on-chip SRAM. So add a >>> hook for ports to leverage. >> >> Now that I've ACK'd this, I feel I'm going to have to NAK it. I'm not >> against >> the general concept, but: >> >>> + do_munmap(mm, *maddr, phdr->p_memsz + *disp); >> >> There needs to be a mapping covering the SRAM region for the purposes of >> the > > Our GDB is still lack of the feature to debug applications using SRAM.
semi true. L1 text appears to work fine: (gdb) stepi 0xffa02aac in moo () (gdb) dis Dump of assembler code from 0xffa02aac to 0xffa02aec: 0xffa02aac <moo+0>: LINK 0xc; /* (12) */ 0xffa02ab0 <moo+4>: [FP + 0x8] = R0; .... but L1 data doesnt seem to work (probably something simple to fix in our kernel ptrace?): (gdb) print i Cannot access memory at address 0xff803e58 the simple code: int i __attribute__((l1_data)); > So this part of code was not got exercised. So if we remove this line, can > this patch got merged? this code does get exercised -- it's run every time code is loaded from initramfs for example. the -mike _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev