I have recently upgraded kernel on our at91sam9260 custom-built boards. We went to 2.6.38.7 from 2.6.20. Problem is that a device (fpga) that is mapped to a certain memory address is no longer in that same memory location. I have chased many leads on this to no avail.
In short, here is what I did:
- redid board file to with new MACHINE_START params following board-sam9260ek.
- patched various other board specific files (I'll attach my kernel patch file) and successfully get uImage and rootfs that boot and appear operational.
- changed driver code to handle new structure of file_operations, device. There is a good amount of discussion regarding that here and elsewhere, in particular the change to unlocked_ioctl. I dont think I am doing the kernel_lock/unlock correctly yet for ioctl but I see problem independent of that (with ioread16, see below)

Problem is my driver is not reading fpga registers correctly as is did with 2.6.20 kernel and associated driver.

In particular fpga_proc_read (that sets /proc/fgpa file) is reading garbage. Here are a couple lines from that function:
len += sprintf(buf+len," test read 0x%04x\n",readw(iomap+FPGA_MS));
len += sprintf(buf+len," Mode Select 0x%04x\n",ioread16(iomap+FPGA_MS));
The change from readw/ioread16 is a test. No difference there.

iomap is set via
dev->iomap = ioremap(dev->iobase, dev->iosize);

iobase is set via #define FPGA_IOBASE (0x10000000)

That is physical (?) memory address of our connection to fpga via chip select 0, controlled with SMC (?) for sam9260 CPU.

All the mappings/addresses look like they used to with old kernel/driver. We are just not getting access to those fpga registers as we used to.

Any ideas?

It seems that all the SMC config is done in AT91boot and I dont see (following board-sam9260ek) anything I'm missing (there is a setup of NAND, chip select 3, in sam9260 which I dont think is relevant here)

- Does the new kernel require a different way of setting up SMC (making the bootloader setup irelevant?)
- Is SMC the relevant controller in this case? Or am I looking in wrong direction?

Thanks

Sorry, couldnt load the patch.

A possible idea on this that I will chase now, maybe others can comment:

New kernel is somehow overwriting our SMC config which is done in bootloader. That did not happen in old version. Could that be possible? Lead on code to chase?

Thanks again.

I'll just keep posting ideas as I have them... perhaps it will ring a bell with someone who can help me get answer faster:)

I am now chasing effects of CONFIG_MMU. It does some remapping in hardware.h which is slightly different in newer kernel. I have CONFIG_MMU=y in old and new kernel configs. Maybe it didnt matter in old, but screwing up mem mapping in new?

What is MMU and does SAM9260 have it? (or does that question even make sense?).

MMU Memory Management Unit

It translates virtual memory accesses (32-bit addressing, ie 4 GB), into physical placement in memory, nominally about up to 256 MB of SDRAM, and other addresses for peripherals. It also permits the kernel and user space to be separated.

It's roughly equivalent to the page tables used to do virtual memory in x86 PC's, but done more directly on the address bus, rather than through segments/selectors.

Yes the 9260 has one, it looks like a coprocessor within the ARM core. Examine the AT91SAM9260 Block Diagram in the reference manual. The peripheral, and EBICSx, space can me accessed via a virtual address provided by mmap(), and you dereference into that address space.

To end this thread:

We have had to give up on this line and go back to our 2.6.20 kernel config/rootfs as I could not get our driver to read our hardware with 2.6.38. (and we need the system to take data). Right now I have only possibilities that we will have to chase later and hopefully with help of more experts (I will have hire someone, maybe a consulting Co?).
Guesses as to problem:
- we got away with some mariginal practies in driver wrt to locking/blocking, phys memory addressing, etc and those dont wont with new kernel.
- compilation has changed from /opt/var/crosstool to that under the buildroot toolchain. I might not be grabbing correct headers or optimization is causing problems. (Is there a procedure to be sure that one is getting correct gpio.h or uaccess.h from the many versions that are in the kernel code?)
- kernel setup could be changing sys registers in a way that I cant find. I chased down that many were set as we intend (in bootloader) but didnt exhaustively do that. Might be that our gpio setup is not as before and we arent even loading fpga firmware correctly (thus hardware isnt delivery data to correct phys mem).

RT