On 11/13/07, Sri nava kala devi Valteti, TLS-Chennai <[EMAIL PROTECTED]> wrote: > > Hi > Thank you for your response. > > Are you *sure* it's mapped at physical address 0xe0000000? (ie. have > >you verified that you can access the device registers via u-boot or a > >debugger?) > > Yes, We have accessed the Micrel chip via U-boot setting (Micrel Chips > Base addres) 0xE0000000 to the CS1 Start address Register. > The LP_CS1 pin is configured to access the chip in U-boot. > > > LINUX: > We also probed the CS1 signal and found some noise in the signal (but > wasn't any kind of pulse). It might not be the actual Chip Select pulse. > But in U-Boot, we are getting proper Chip Select pulse.
Most likely, something in the board setup routine (in Linux) is fiddling with the CS settings (which it should not do). If you u-boot has it working, then it *should* just carry over to working in Linux. > > LINUX: > The MBAR is mapped to default 0xF0000000 value. The BAT 2 settings in > the "mpc52xx_set_bat" function, is set to map the 0xf0000000 area. > Do we need to perform any similar BAT settings or any other settings to > access the IO Device mapped at 0xE0000000 ? No. u-boot should be responsible for configuring the CS pins. Once the kernel takes over, you should only need to call ioremap() to get access to the device. mpc52xx_set_bat? You must be using arch/ppc (which is depreciated). Can you move up to a more recent kernel and use arch/powerpc instead? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
