[PATCH] ARM: dts: ixp4xx: Add a devicetree for Freecom FSG-3

Marc Zyngier maz at kernel.org
Sun Aug 1 06:22:21 PDT 2021


On Thu, 29 Jul 2021 15:41:28 +0100,
Linus Walleij <linus.walleij at linaro.org> wrote:
> 
> This adds a devicetree for the Freecom FSG-3, a combined router
> and NAS.

After a bit of soldering as well as fighting with the bootloader
(which is so broken that it makes the Vulcan's version of RedBoot look
pretty sane in comparison), I've managed to successfully boot the
machine to userspace.

Networking, PCI, USB, ATA (to some extent, see below), RTC and hwmon
all see to work correctly. The switch works *sometimes*, but I haven't
worked out whether it needs some special care or it is broken.

One thing that still puzzles me is that I can't manage to get the SCSI
layer to probe the disk. The original firmware finds it perfectly, but
I'm obviously failing to select the right config option that would
make the PATA controller (which gets probed) to register as a SCSI
target:

[the PCI device is seen correctly]

pci 0000:00:0c.0: [1106:3249] type 00 class 0x010400
pci 0000:00:0c.0: reg 0x10: [io  0x0af0-0x0aff]
pci 0000:00:0c.0: reg 0x14: [io  0x0a70-0x0a7f]
pci 0000:00:0c.0: reg 0x18: [io  0x01f0-0x01ff]
pci 0000:00:0c.0: reg 0x1c: [io  0x0170-0x017f]
pci 0000:00:0c.0: reg 0x20: [io  0xcc00-0xcc1f]
pci 0000:00:0c.0: reg 0x24: [io  0x8c00-0x8cff]

[and the driver picks it up, correctly seeing the 3 ports]

sata_via 0000:00:0c.0: version 2.6
sata_via 0000:00:0c.0: enabling device (0000 -> 0001)
sata_via 0000:00:0c.0: routed to hard irq line 8
scsi host0: sata_via
scsi host1: sata_via
scsi host2: sata_via
ata1: SATA max UDMA/133 port i16 at 0x1420 bmdma 0x1400 irq 24
ata2: SATA max UDMA/133 port i16 at 0x1430 bmdma 0x1408 irq 24
ata3: PATA max UDMA/133 port i16 at 0x1440 bmdma 0x1410 irq 24

[it then realises that there is nothing on the SATA ports]

ata1: failed to resume link (SControl 0)
ata1: SATA link down (SStatus 10 SControl 0)
ata2: failed to resume link (SControl 302)
ata2: SATA link down (SStatus 2A2F SControl 302)

but ata3, which has the internal disk, never gets scanned.

If feels that this is only a matter of plumbing, but I'm out of my
depth here. Any idea?

Anyway, FWIW:

Acked-by: Marc Zyngier <maz at kernel.org>
Tested-by: Marc Zyngier <maz at kernel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list