IPQ4019: Adding support for TP-Link Deco M5

For Developers
538

Tried, still no go :frowning @dutchmill
Please build the factory image next time, it is easier for me to flash a not working unit using the tftp method. Thanks!

539

New version available - in both sysupgrade as factory format

1 Like
540

flashed the factory image with tftp, unit won't boot. @dutchmill

541

Hi @dutchmill

It seems to have a similar error

i installed v24.10.3 for deco v3 sysupgrade

deco v3 > 6.6.104-1-556fd75da718f707f45aa9a248a9428f

openwrt > 6.6.104-1-eaef302ef5ab82928154706763925f63

542

I have re-uploaded the firmware for v2 and v3 to be sure the latest are published. The version I am running has the right kernel hash (eaef302ef5ab82928154706763925f63)

2 Likes
543

@JP89 Very much so! From this we can deduce the following outcomes:

  • It failed at the spi_nor_read_sfdp_dma_unsafe step, i.e. the flash device likely doesnā€™t support the SFDP command (IIRC the last time I checked the latest kernel version I donā€™t remember there being a fallback path for non-SFDP devices)
  • It failed at the SFDP or BFPT table checks, which could either mean that the SFDP table is potentially valid but broken in some way, or if itā€™s all 0xFF then it also just doesnā€™t support SFDP at all

At the time I didnā€™t put much effort into making a hexdump of the SFDP header bytes that were read, but in hindsight I really shouldā€™ve :smile:

544

Iā€™ve rebased the last pr on main to support the kernel 6.12 push: https://github.com/openwrt/openwrt/pull/20633

It would be great if owners of v1 and v2 could test this and comment on the pr so we can finally get the support upstream.

Thanks in advance!

545

Let see how we can organize this. Having to PRs does not help. Today I will upload the 24.10.4 release for all versions. It hangs on the acceptance of a kernel patch to make some v1 devices work (note: I have a v1 device in the meantime, but it does not have Gigadevice chipset...).

1 Like
546

alright then, iā€™ll close mine and let you guys do your thing. just keep in mind that developing against 24.10 wont help with getting this into main, as the kernel is now 6.12 and not 6.6. you first need to get the changes into main and then into stable branches, not the other way around.

1 Like
547

@achterin Iā€™ve rebased my PR against the latest main + 6.12 which should fix that

@dutchmill In the Deco-M5-staging branch Iā€™ve included commits for both the flash size fix and the spi-nor hack patch, so you shouldnā€™t need to add it in yourself for the time being :slightly_smiling_face:

Iā€™ve also updated the spi-nor hack patch to include a few more diagnostic outputs, including early SFDP table dumping which should settle once and for all if there are versions of the SPI flashes out there that only support SFDP in the later revisions.

2 Likes
548

Having proof that thereā€™s e.g. a GD25Q256A/B that doesnā€™t support the RDSFDP command or a defect chip that has a weird SFDP table for whatever reason should make it easier to submit a patch upstream, and thus hopefully land a backport patch in OpenWrt.

1 Like