Nokia IP530 finally fully working

[mbertens]

hi all,

i was to fast on the send button, the Nokia IP530 is now finally fully
working. 
-	the four on-board NICs (22143PD)
-	the 2 PCMCIA-Cardbus slots
-	the 3 compact PCI expansion slots (with 12 NICs)

I got it working with 16 ethernet controller (all 21143PD), two HDDs on
the primary IDE controller and two HDD's on the secondary controller.
The on-board CF slot works as master on the primary IDE controller. very
nice for silent running (hihi, with those 4 fan's in the back).

for the NICs i added a driver to the src/drivers/dec/21143. for the
pcmcia-cardbus controller i added a driver to the
src/drivers/ti/pcmcia-cardbus. these where required to get the devices
proberly working. These are added as drivers so that other can use then
in there configuration to. the parameters can be set in the
configuration "menuconfig", "xconfig" or "gconfig".

all this depends still on a patch to the
'src/arch/i386/boot/pirq_routing.c' to get the interrupt routing correct
working. i will look into this to fix in the near future.

I find the coreboot project a great project and i have a lot of fun
working on it. and i will do so. Next on mylist is the Nokia-IP330, yes
again a Nokia piece of hardware.

"That's all folks"

Marc

[mbertens]

Hi all,

a last update the dirty hack in the pirq_routing is not needed, therefor
i made a new diff for it. This contains just the fix in the printk call,
to keep de compiler happy, and me too :-)

Signed-off : Marc Bertens

on the following patches;
    1.	arch-pirq-rouring.diff
    2.	dec21143-driver.diff
    3.	pcmcia-cardbus-driver.diff
    4.	working-nokia.diff

Marc

On Mon, 2010-05-31 at 22:23 +0200, mbertens wrote:
> hi all,
>
> i was to fast on the send button, the Nokia IP530 is now finally fully
> working.
> the four on-board NICs (22143PD)
> the 2 PCMCIA-Cardbus slots
> the 3 compact PCI expansion slots (with 12 NICs)
>
> I got it working with 16 ethernet controller (all 21143PD), two HDDs on
> the primary IDE controller and two HDD's on the secondary controller.
> The on-board CF slot works as master on the primary IDE controller. very
> nice for silent running (hihi, with those 4 fan's in the back).
>
> for the NICs i added a driver to the src/drivers/dec/21143. for the
> pcmcia-cardbus controller i added a driver to the
> src/drivers/ti/pcmcia-cardbus. these where required to get the devices
> proberly working. These are added as drivers so that other can use then
> in there configuration to. the parameters can be set in the
> configuration "menuconfig", "xconfig" or "gconfig".
>
> all this depends still on a patch to the
> 'src/arch/i386/boot/pirq_routing.c' to get the interrupt routing correct
> working. i will look into this to fix in the near future.
>
> I find the coreboot project a great project and i have a lot of fun
> working on it. and i will do so. Next on mylist is the Nokia-IP330, yes
> again a Nokia piece of hardware.
>
> "That's all folks"
>
> Marc

[Myles Watson]

On Tue, Jun 1, 2010 at 12:30 PM, mbertens  wrote:
> Hi all,
>
> a last update the dirty hack in the pirq_routing is not needed, therefor
> i made a new diff for it. This contains just the fix in the printk call,
> to keep de compiler happy, and me too :-)
>
> Signed-off : Marc Bertens

Acked-by: Myles Watson

Rev 5604.

Thanks,
Myles

[Myles Watson]

pcmcia-cardbus-driver.diff:

I think all three chips should be handled by the same file.

Then you'll only have to duplicate this structure:

+static const struct pci_driver ti_pci1420_driver __pci_driver = {
+        .ops    = &ti_pci1420_ops,
+        .vendor = PCI_VENDOR_ID_TI,
+        .device = PCI_DEVICE_ID_TI_1420,
+};

We don't normally use CONFIG values to set registers.  Should they
really be configurable?

+pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );

Thanks,
Myles

[mbertens]

On Tue, 2010-06-01 at 14:24 -0600, Myles Watson wrote:
> pcmcia-cardbus-driver.diff:
>
> I think all three chips should be handled by the same file.
>
> Then you'll only have to duplicate this structure:
>
> +static const struct pci_driver ti_pci1420_driver __pci_driver = {
>    .ops    = &ti_pci1420_ops,
>    .vendor = PCI_VENDOR_ID_TI,
>    .device = PCI_DEVICE_ID_TI_1420,
>
> +};

hmm, when you put then in one file the image size of coreboot increases,
maybe for current systems to a problem, but there are system with less
rom space. And to create an abstraction so that later other chipset
could be easly added to it, that require some additional programming.  
Thats the reason i did it this way. But if you want then in one file no
problem.
> We don't normally use CONFIG values to set registers.  Should they
> really be configurable?
>
> +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );

On my system it was needed to set this specific value to 0, but some
will need 0x40 (64). So that why i made it configurable. As for the
registers that i made configurable is for others who have the same
chipset but need for those registers other values, without making for
each board a specific piece of code just made it generic with some
CONFIG_xx values, to my opinion it makes coreboot more flexable for
other implementations.

For the pcmcia/cardbus contollers i want to do the same thing, due to
the fact that there also are some more speficic board configuration
issues.
> Thanks,
> Myles

Let me know how to continue.

Thanks, Marc

[Myles Watson]

On Tue, Jun 1, 2010 at 3:32 PM, mbertens  wrote:
> On Tue, 2010-06-01 at 14:24 -0600, Myles Watson wrote:
> > pcmcia-cardbus-driver.diff:
> >
> > I think all three chips should be handled by the same file.
> >
> > Then you'll only have to duplicate this structure:
> >
> > +static const struct pci_driver ti_pci1420_driver __pci_driver = {
> > .ops    = &ti_pci1420_ops,
> > .vendor = PCI_VENDOR_ID_TI,
> > .device = PCI_DEVICE_ID_TI_1420,
> >
> > +};
>
> hmm, when you put then in one file the image size of coreboot increases,

Does it increase a lot? I'd rather have the simpler code if the
increase is less than a couple hundred bytes.
> maybe for current systems to a problem, but there are system with less
> rom space. And to create an abstraction so that later other chipset
> could be easly added to it, that require some additional programming.
> Thats the reason i did it this way. But if you want then in one file no
> problem.
> > We don't normally use CONFIG values to set registers.  Should they
> > really be configurable?
> >
> > +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
>
> On my system it was needed to set this specific value to 0, but some
> will need 0x40 (64). So that why i made it configurable. As for the
> registers that i made configurable is for others who have the same
> chipset but need for those registers other values, without making for
> each board a specific piece of code just made it generic with some
> CONFIG_xx values, to my opinion it makes coreboot more flexable for
> other implementations.

If I understand correctly, different boards will need different
values, but different users of the same board will always use the same
value.

In that case, the values shouldn't be visible to the user, but should
be set in the mainboard Kconfig file.  That way only the person who
ports a new board has to care about the values.
> For the pcmcia/cardbus contollers i want to do the same thing, due to
> the fact that there also are some more speficic board configuration
> issues.

If we can move them all out of the menu, that would be great.
> Let me know how to continue.

You're doing fine.  It's close.

Thanks,
Myles

[Peter Stuge]

mbertens wrote:
> > We don't normally use CONFIG values to set registers.  Should
> > they really be configurable?
> >
> > +pci_write_config8( dev, 0x0C, CONFIG_DEC21143_CACHE_LINE_SIZE );
>
> On my system it was needed to set this specific value to 0, but
> some will need 0x40 (64).

What some? Can you explain this more?

//Peter