On Wed, Jan 28, 2009 at 10:19:34AM +0100, Frank Neuber wrote:
>
> Am Dienstag, den 27.01.2009, 13:42 +0100 schrieb Frank Neuber:
> > Am Dienstag, den 27.01.2009, 13:11 +0100 schrieb Manuel Lauss:
> > > > I think somting is wrong with PCI resource management here.
> > > > I can't believe that nobody is using the PCI or Cardbus on the AU1550
> > > > with the current kernel.
> > >
> > > I'm no PCI expert, but I'm pretty sure resource assignment is done by
> > > generic, not mips-specific, code. Please try the linux-pci and/or
> > > linux-kernel lists.
> > At the moment I buld a matrix of working kernel versions regarding the
> > PCI stuff on the AU1550
> >
> > For now I can say that the versions
> > 2.6.18, 2.6.18-rc1
> > is crashing after showing the linux banner
> >
>
> I found the problem for this error. It is because we compare 32 and 64
> bit numbers in __request_resource.
> > 2.6.18-rc2, 2.6.18-rc4, 2.6.19, 2.6.20, 2.6.23 produce this:
> > Skipping PCI bus scan due to resource conflict
> I changed this:
>
> diff --git a/include/asm-mips/mach-au1x00/au1000.h
> b/include/asm-mips/mach-au1x00/au1000.h
> index 3bdce91..8616c09 100644
> --- a/include/asm-mips/mach-au1x00/au1000.h
> +++ b/include/asm-mips/mach-au1x00/au1000.h
> @@ -1679,12 +1679,21 @@ enum soc_au1200_ints {
> #define Au1500_PCI_MEM_START 0x440000000ULL
> #define Au1500_PCI_MEM_END 0x44FFFFFFFULL
>
> +#if 1
> +#define PCI_IO_START 0x00001000
> +#define PCI_IO_END 0x000FFFFF
> +#define PCI_MEM_START 0x40000000
> +#define PCI_MEM_END 0x4FFFFFFF
> +#define PCI_FIRST_DEVFN (0 << 3)
> +#define PCI_LAST_DEVFN (19 << 3)
> +#else
> #define PCI_IO_START (Au1500_PCI_IO_START + 0x1000)
> #define PCI_IO_END (Au1500_PCI_IO_END)
> #define PCI_MEM_START (Au1500_PCI_MEM_START)
> #define PCI_MEM_END (Au1500_PCI_MEM_END)
> #define PCI_FIRST_DEVFN (0<<3)
> #define PCI_LAST_DEVFN (19<<3)
> +#endif
>
> #define IOPORT_RESOURCE_START 0x00001000 /* skip legacy probing */
> #define IOPORT_RESOURCE_END 0xffffffff
>
>
> Now I think a have to look at 64 problems in the resource management of
> th PCI subsystem
Do hou have CONFIG_64BIT_PHYS_ADDR=y set in your .config? If I remember
correctly, __fixup_bigphys_addr() in alchemy/common/setup.c should take care
of this 36bit problem (in the same way you did, btw).
Best regards,
Manuel Lauss
