[RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka at ext.kapsi.fi> wrote:
> On 27.4.2022 21.10, Arnd Bergmann wrote:
> > On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka at ext.kapsi.fi> wrote:
> > This is all normal: with a board file, all on-board IRQs are statically
> > assigned to fixed numbers. With DT based boot, IRQ controllers
> > usually define their own IRQ domains, which get a number space assigned
> > according to probe order, and above the preallocated IRQ numbers.
> >
> >> - sata_mv fails to initialise with -22 (-EINVAL)
> >
> > No idea, I'd try inserting a printk in every code path that can return -EINVAL
> > from there
> >
> I had something like that but I didn't get any wiser immediately. Then I
> suspected it's something to do with initialisation of the PCIe bus and
> that clashing with sata_mv initialisation and thought it's better to
> ask. The PCIe initialisation uses hardwired irq and maybe that was
> getting in the way. Is there a way to describe the PCIe bus in the
> device tree? The initalisation of that bus is done for rev A1 only.

I'm not too familiar with the platform, but my interpretation is that the
DT support here is incomplete:

The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
is not hooked up in orion5x.dtsi, and the traditional pci code does
not work with DT.

I see that orion5x has two separate blocks --  a PCIe host that is
similar to the kirkwood one, and a legacy PCI host that needs
a completely separate driver.

Which of the two do you actually need here?

> >> - there is no concensus on how to get ascii formatted MAC address from mtd
> >>    partitions so eth is not fully functional without setting the MAC from
> >>    userspace
> >
> > Ideally this is handled by the boot loader, but that requires being
> > able to update
> > it. If you cannot, this could perhaps be done using something like
> > https://github.com/zonque/pxa-impedance-matcher
>
> I had a look at the pxa-impedance-matcher but I am not sure how to use
> it. Should it be flashed on the device and then it would the boot the
> rest of the system? Maybe I'll have to add some dns323 specifics there
> too first. On the dns323 there are these mtd partitions MTD1 and MTD2,
> which I am not really sure what they are for. Maybe those could
> accommodate a 3rd stage loader. But I'll consider it as my last resort
> as they put it in their documentation too. In linux-mtd there's been a
> few attempts to find a solution and I am hoping one will be found
> eventually.
>
> Adding support in the u-boot was stalled back in the days for some
> reason and I am not sure I will be much wiser than the previous people
> that were at it. But I have jtag programmer that should be suitable.

I think the idea of the impedance-matcher is that you can combine it
with a DT-enabled kernel image into a file that looks to the existing
boot loader like an old kernel and then provides both a way for
code to run before booting the kernel, and for adding in the DT.

       Arnd