Re: Accessing flash directly from User Space [SOLVED]
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. /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Accessing flash directly from User Space
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 data in registers. You should try to use volatile pointers (but also read the volatile considered harmful file in the kernel sources -- anyways you are doing bad things nonetheless), or add memory barriers (copy the mb() and wmb() macros defined for kernel space). Then, the first-word-access you show is wrong, as Scott Wood told you, so the fact that _that_ access is not working even across msync that's another matter. I usually have no serious problems with driving hardware from /dev/mem, although I've never done flash specifically as mtd is there. hope this helps /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can the kernel show user task stack backtrace ?
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 signal handler. You can also open /proc/self/maps and print it, to ease understanding the various pointers in there, especially if the application is using a number of shared libs. This is usually easier than getting to a core dump, although there is less information than what the core offers. I have the code for ARM and I've it on ppc once, but I must dig for the actual code. /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [U-Boot] NAND only (no NOR)
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 setup SDRAM from the jtag tool (or, better, place the initial boot code the manufacturer give you in static memory, and jump to is with a breakpoint in the right place). While my debugger is able to write flash, I've always found it easier to do that from u-boot itself. Besides, I can fix my u-boot in RAM without the lengthy erase-reprogram cycles. If you work like this, it's irrelevant whether it is nor, nand or dataflash or whatever, as long as u-boot is able to manage it. hope this helps /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/3] PS3 Storage Drivers for 2.6.23, take 5
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 have my name removed from the MAINTAINERS file over the years without success. Actually, I didn't care a lot because nobody relly used that entry. I think it's time for me to learn how to do it in the proper way. Regards /alessandro ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
