Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Andrew <acmay@acmay.homeip.net>]

On Thu, 14 Sep 2006 09:40:53 -0700
"John Bonesio" <john.bonesio@xilinx.com> wrote:

> I am in the group that has control over how this is done. What would
> you propose be done different? Keep in mind that we are trying to
> support a process where someone builds a hardware design and the
> later changes it with new peripherals or perhaps makes minor tweaks.
> We want to make the updating of the Linux kernel to reflect these
> hardware changes easy for people.
> 
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

I am coming into this a bit late and it has been awhile since I worked
Virtex parts. But it doesn't look like things have changed much.

Since Linux is from a PC base, hardware changes are as rapid as
powering off and plugging a new device in the machine. Rebuilding the
kernel for this is not usually something people consider for this.
So to say Linux people aren't use to rapid hardware changes, seems
pretty backwards to me.

The static configuration of the hardware is the thing that is very
unusual for the software. And having that static hardware setup
compiled into the kernel is a real source of problems.
Typically things get probed, discovered/learned at boot time. Either by
the boot loader, pin strapping, dip switches, user config etc.

I worked on a board with 2 Virtex chips. They had some set of common IP
cores with minor differences between the two. There was no way I wanted
to build 2 sets of kernels and drivers to deal with things.
The first small difference of one chip having 2 serial ports and the
other side only having 1 serial port, rippled the entire IRQ mapping in
both xparameters.h file. There were all kinds of little changes between
the mem mapping and everything else as well.
Depending on how things were used from xparemeters.h I could change the
static numbers to function calls to get values, but most of the time I
easist to hack up the drivers to pick one of two values depending on
the chip.

At first I just used a kernel boot param saved in u-boot flash to tell
the SW which chip it was running on. Then I got our HW people to put
in a single bit in another register for SW to tell which chip was
running. That saved us setup step in production of setting up flash
with different items.

There are trade offs on how much it is worth being determined at run
time compared to compiled into the kernel, but with the current
xparemters.h you are stuck with things compiled in. Getting to a point
where anything can be learned at run time, or just pulled from flash
would be a big step forward. But at that point it should still be easy
to compile things into the kernel if someone has major sw space
constraints.

I also keep hearing about doing partial re-configuration bit streams.
Were the FPGA can change at run time as well. (ie switch from an
CAT5 ethernet IP core over to an 802.11 ethernet depending on if the
user plugs in a cable or an antenna)

How would you even plan to do that with the xparemters.h file and the
drivers as it is now?