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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arnd and thanks for your quick reply.

On 27.4.2022 21.10, Arnd Bergmann wrote:
On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@xxxxxxxxxxxx> wrote:

Hello all,

I am making an attempt to create a device tree for D-Link DNS-323 devices
but I am falling short on a few specific details. I am requesting a
general review of the device tree files. I have access to DNS-323 rev A1
only and the B1 and C1 need to be tested separately, so I am reaching out
to people who might have them.

Hi Mauri,

It's really nice to see some progress on this! I don't have the hardware,
but I'll try to answer some of your questions anyway.

The questions that I have at the moment are below.

- some of resulting IRQs are different from what was requested in device tree
- logs say NR_IRQS is different from mach file one

Ok thanks, I won't worry about it anymore.

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.

- 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.

-- Mauri



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux