> Okay, I now have access to the flash memory, however when I write to
> it the writes do not take.
> (PROT_READ | PROT_WRITE), MAP_PRIVATE, fd,
MAP_SHARED. Bill told you. With MAP_PRIVATE you write to a local
in-ram copy of the data, not to the original one.
/alessandro
> I realize that. I have a driver written that does exactly that.
> However, I need to be able to write to certain registers to setup
> the erasure. The driver works perfectly in VxWorks, now I am
> porting it to Linux.
Most likey you are hit by the compiler reordering the accesses and
caching d
> asm("eieio; sync");
Hmm...
: : : "memory"
And, doesn't ";" start a comment in assembly? (no, not on powerpc it seems)
Just to make sure, if you replace msync() with another system call,
like "kill(1, 0);" you can verify wether it's really useful or if it's
only acting as a barrier.
/a
> We're dealing with some complex (3rd party) applications and I like to see a
> user task stack backtrace.
>
> (Of course the way to go here is to use a debugger (gdb) and
> do a backtrace (with the coredump file).
Actually, you can intercept SIGSEGV and print your own stack from within
the si
Disclaimer: I'm not running ppc these days
> However, having no NOR flash means:
> - NAND should be programmable via JTAG (BDI3000 doesn't support
> this, Lauterbach/trace32 does)
My personal preference for bringing up a new board is placing u-boot
in RAM using the available information to
Hello.
> I didn't hear anything from the misc device maintainer (for the FLASH ROM
> Storage Driver).
Actually, I am not acting as a maintainer. I'm not active enough nor
up to date with all the structure of kernel maintainance. So please
don't wait for me.
Actually, I tried a pair of times to
