-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 10, 2007 at 08:14:35AM -0500, Christopher Reder wrote: > Erik> What do you mean with "boundaries"? What locations do you mean? Could > Erik> you give an example? > > I don't have anything to base it on other than that seems to be what it is. > Almost like the kernel, for example, would think there was a block of 10 > locations. So, it goes and writes to those 10, but the hardware only has 9 > and it fails on the last one. Check out the output below from devmem2. I > would think I should be able to write to the last location in ram... You certainly are, but you have to realise that ARM is a RISC architecture and can't do unaligned memory accesses (see below). It will only allow 32 bit aligned accesses, though some ARM implementations will allow 16 or 8 bit writes to certain memory areas (usually areas reserved for I/O). Check the CPU data sheet for information about that. > > I wasn't too worried about it throwing up stuff to the terminal when I > tried > > the original. I just wanted to see if it wouldn't crash. So, you're > > suggestion was also good and yes, it crashes at the same spot. I'll > include > > the output below. The reason I picked on this is because it is crashing > in > > the same way that other programs have been crashing on me so I thought it > > may be a good and easy thing that if I can get this to work, the others > > should as well. Anything else I could try to see if things are setup > > correctly? > > Erik> OK, same place, so it might not be RAM related. Well, it still can. If > Erik> the ramdisk is always mapped at the same place (which it most probably > Erik> will) and that place is somehow corrpupt, things will go wrong. Could > Erik> you upgrade to a newer kernel and see if that solves the problem? > > I also tried removing the ramdisk from the kernel config and it acts the > same as it did before. While I could try a different kernel, I can use this > same kernel with most things the same, but on an EK board, and it works > fine, no problems. Both have 32M of ram, both have a nor flash etc. This > is what is so confusing as I have tried going through all differences etc > and it just doesn't make sense. "Similar boards" don't exist. What might look like a similar board can be completely different from a hardware point of view: different memory, different memory layout, different peripherals, different pcb design. All this can have its influence on the stability of the board. Btw, *please* try to upgrade to a newer kernel. I hate chasing already fixed bugs. > I used devmem2 and saw 1 thing that was interesting: > # ./devmem2 0x21FFFFFC > /dev/mem opened. > Memory mapped at address 0x40006000. > Value at address 0x21FFFFFC (0x40006ffc): 0x7B5EAB79 0xC = 12 = 4 bytes aligned, the CPU will allow that. > # ./devmem2 0x21FFFFFD > /dev/mem o[ 730.260000] Unhandled fault: external abort on non-linefetch > (0x01a > ) at 0x40006ffd > pened. > Memory mapped at address 0x40006000. > Bus error Bus error means unaligned memory acces. 0xD = 13 = not 4 bytes aligned, the CPU will not do that. "external abort on non-linefetch" also gives the error away. > # > > Why wouldn't this work at 0x21FFFFD ? Because the CPU can't do unaligned memory accesses, it always accesses memory 32 bit (i.e. 4 bytes) at a time. Welcome to a real architecture. Note that modern x86 chips also do aligned memory accesses, but have lots of complicated circuitry to let you think it can (expensive read-modify-write logic when you do an unaligned write). Erik - -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGvH8W/PlVHJtIto0RAnl0AJ4nojpjPKL5igiRDJX9LyuupE8g+gCbBCYs 1eEd0ZK1UqKzPUprj6wQRMg= =C0EL -----END PGP SIGNATURE----- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
