Message-ID: <[EMAIL PROTECTED]> Finally i got around to trying out your suggestion.
I enabled the chipselect by setting the V-bit to 1. Yup - silly me... I removed the reference to m5272sim.h No good. Still no worky. Then I got to think about it - something still made the CPU decide it was handed something it wasn't allowed to do. Looking over the individual bits in CSMR2, it dawned on me: Bits 5 to 1 are mask bits, restricting access to resources governed by the chipselect. Cleared bits cause access, set bits cause - Illegal instruction? Since this is a driver module, running in Supervisor mode and i'm trying to access data, zeroing the SD-bit *only* seemed like a good idea. I also zeroed the AM-bit, so that the beforementioned bits become dont-cares during DMA - if i should ever need that :) I also disabled the Byte Enable Mode bit in CSCR2 to disable /BS activity on reads. Seemed like a good idea... Et voila :) I'm not entirely clear on which of these modifications did the trick, but it works! Actually i've reduced access granting specs - previously also User Data Acces was allowed. AM-bit? Well, i don't use DMA, so it shouldn't matter. THE BEM bit governs /BS activity. This I read as /BS[3-0], which i don't use. Hmmm... Oh well... Enough feedback for now. Thanks for your help :) //Martin Filitenborg
--------------------------------------
Did you enable the chipselect?
> CSMR2 = 0x00000074; // BAM=0, AM=1, SD=0, UD=0,
should be CSMR2 = 0x00000075; and don't use m5272sim.h which is not for 5282 _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
