On Tuesday 15 January 2008, Sean MacLennan wrote:
> Stefan Roese wrote:
> > Right. One thing I noticed though is, that you map the NAND to
> > 0xd0000000, which is reserved for PCI in the 440EP address space. I
> > suggest you map it to 0x90000000 as done on Bamboo. Please give it a try
> > and let me know if this changes the 32bit access behavior.
>
> I think I changed it right. The following code is obviously a hack:
>
> static int warp_setup_nand_flash(void)
> {
> unsigned data;
>
> mfebc(0x1, data);
> printk("EBC0_B1CR %x\n", data); // SAM DBG
>
> data = 0x9001c000;
> mtebc(0x1, data);
>
> mfebc(0x1, data);
> printk("after EBC0_B1CR %x\n", data); // SAM DBG
>
> mfebc(0x11, data);
> printk("EBC0_B1AP %x\n", data); // SAM DBG
>
> platform_device_register(&warp_ndfc_device);
> platform_device_register(&warp_nand_device);
>
> return 0;
> }
> device_initcall(warp_setup_nand_flash);
>
>
> Then change the NAND base offset to 90000000. This change made no
> difference. It still works with 8-bit access and fails with 32-bit. The
> mtebc and mfebc macros where taken from u-boot.
Bummer! Was worth a try though. I still don't see why this should fail on your
platform. What error/exception do you get upon 32bit access btw?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED]
=====================================================================
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
