| Message ID | 20220202124421.9E1FB68AFE@verein.lst.de |
|---|---|
| Headers | show |
| Series | lantiq: initial support for x490 Fritzboxes | expand |
Hi,
I have created a new PR:
https://github.com/openwrt/openwrt/pull/5074
Which also includes a remote processor framework kernel module, which
has not been sent upstream yet. But it could be the basis to make wifi
or the secondary SoC work too.
It still misses a way of configuring the wifi part, but that can be scripted and
will neither added nor covered by this PR, because its a separate topic and
likely belongs to a feeds package.
Looking at your submitted patches, many fritzbox devices have different
NAND manufacturers. So the best way is to support all.
I created a DTB and image configuration for Micron and non Micron NAND.
This is probably the best way and not supporting just one NAND type per
device. Unfortunately auto detection was not accepted by the kernel
maintainers, so there is no other solution.
I also saw the addition of ubifs. I have not used this so far and I wonder
what the advantage is over using squashfs with overlay?
But maybe you can help working on the PR. Maybe you can have a look
if I forgot something.
-----Original-Nachricht-----
Betreff: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
Datum: 2022-02-02T13:48:05+0100
Von: "Torsten Duwe" <duwe@lst.de>
An: "openwrt-devel@lists.openwrt.org" <openwrt-devel@lists.openwrt.org>
With the latest advancements, especially the move to kernel-5.10,
basic support for the {3,5,7}490 Fritz!Boxes has become rather low
hanging fruit. Building on the previous research done by Andreas
B��hler (subscribed here), Daniel Kestrel (Cc'ed) and others, I
identified and collected all the pieces, verified and fixed the detail
information as far as I could, and refined the changes into a
hopefully acceptable patch set.
The hardware telephony on the {5,7}490 remains unsupported, of course.
The WiFi on these systems is moved to a secondary SoC; some effort has
been made to build an appropriate OpenWRT image for that as well in
one run, but I'm ignoring that here for simplicity's sake. The extra
image is a major step, which should rather be discussed and postponed,
and should IMHO not hinder the inclusion of these devices. Neither did
I consider performance patches yet.
On the plus side, thanks to the DSA move in Linux mainline, all 4 LAN
ports can be used now. Likewise, the USB3 ports are working, once an
xHCI firmware blob is provided [1].
These patches are tested on 7490 and 3490, one specimen each. I can't
verify the 5490 fiber box, but I include it here because of the
similarity. Any feedback is appreciated. Especially the GPIO lines and
switch ports remain to be filled in at the DTS. The 7490 I have uses a
Micron NAND chip with 128k PEBs and 2k IO size. The 3490 has a Toshiba
Chip with 256k PEBs and 4k IO. Anybody with a different combination
please speak up!
Torsten
[1] https://forum.openwrt.org/t/2071
Sorry, I messed up with git and this is the new PR:
https://github.com/openwrt/openwrt/pull/5075
-----Original-Nachricht-----
Betreff: AW: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
Datum: 2022-02-11T23:47:18+0100
Von: "kestrel1974@t-online.de" <kestrel1974@t-online.de>
An: "Torsten Duwe" <duwe@lst.de>, "openwrt-devel@lists.openwrt.org" <openwrt-devel@lists.openwrt.org>
Hi,
I have created a new PR:
https://github.com/openwrt/openwrt/pull/5074
Which also includes a remote processor framework kernel module, which
has not been sent upstream yet. But it could be the basis to make wifi
or the secondary SoC work too.
It still misses a way of configuring the wifi part, but that can be scripted and
will neither added nor covered by this PR, because its a separate topic and
likely belongs to a feeds package.
Looking at your submitted patches, many fritzbox devices have different
NAND manufacturers. So the best way is to support all.
I created a DTB and image configuration for Micron and non Micron NAND.
This is probably the best way and not supporting just one NAND type per
device. Unfortunately auto detection was not accepted by the kernel
maintainers, so there is no other solution.
I also saw the addition of ubifs. I have not used this so far and I wonder
what the advantage is over using squashfs with overlay?
But maybe you can help working on the PR. Maybe you can have a look
if I forgot something.
-----Original-Nachricht-----
Betreff: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
Datum: 2022-02-02T13:48:05+0100
Von: "Torsten Duwe" <duwe@lst.de>
An: "openwrt-devel@lists.openwrt.org" <openwrt-devel@lists.openwrt.org>
With the latest advancements, especially the move to kernel-5.10,
basic support for the {3,5,7}490 Fritz!Boxes has become rather low
hanging fruit. Building on the previous research done by Andreas
B��hler (subscribed here), Daniel Kestrel (Cc'ed) and others, I
identified and collected all the pieces, verified and fixed the detail
information as far as I could, and refined the changes into a
hopefully acceptable patch set.
The hardware telephony on the {5,7}490 remains unsupported, of course.
The WiFi on these systems is moved to a secondary SoC; some effort has
been made to build an appropriate OpenWRT image for that as well in
one run, but I'm ignoring that here for simplicity's sake. The extra
image is a major step, which should rather be discussed and postponed,
and should IMHO not hinder the inclusion of these devices. Neither did
I consider performance patches yet.
On the plus side, thanks to the DSA move in Linux mainline, all 4 LAN
ports can be used now. Likewise, the USB3 ports are working, once an
xHCI firmware blob is provided [1].
These patches are tested on 7490 and 3490, one specimen each. I can't
verify the 5490 fiber box, but I include it here because of the
similarity. Any feedback is appreciated. Especially the GPIO lines and
switch ports remain to be filled in at the DTS. The 7490 I have uses a
Micron NAND chip with 128k PEBs and 2k IO size. The 3490 has a Toshiba
Chip with 256k PEBs and 4k IO. Anybody with a different combination
please speak up!
Torsten
[1] https://forum.openwrt.org/t/2071
2/11/22 23:39, kestrel1974@t-online.de: > Hi, > > I have created a new PR: > https://github.com/openwrt/openwrt/pull/5074 > > Which also includes a remote processor framework kernel module, which > has not been sent upstream yet. But it could be the basis to make wifi > or the secondary SoC work too. > It still misses a way of configuring the wifi part, but that can be scripted and > will neither added nor covered by this PR, because its a separate topic and > likely belongs to a feeds package. > > Looking at your submitted patches, many fritzbox devices have different > NAND manufacturers. So the best way is to support all. > I created a DTB and image configuration for Micron and non Micron NAND. > This is probably the best way and not supporting just one NAND type per > device. Unfortunately auto detection was not accepted by the kernel > maintainers, so there is no other solution. > > I also saw the addition of ubifs. I have not used this so far and I wonder > what the advantage is over using squashfs with overlay? Let me cite https://en.wikipedia.org/wiki/UBIFS - tracking NAND flash bad blocks - providing wear leveling NAND is a rather unreliable type of flash, hence some special treatment has to be done to make it last as long as possible. Mathias
On Sat, 12 Feb 2022 02:05:17 +0100 Mathias Kresin <dev@kresin.me> wrote: > > 2/11/22 23:39, kestrel1974@t-online.de: > > Hi, > > > > I have created a new PR: > > https://github.com/openwrt/openwrt/pull/5074 > > > > Which also includes a remote processor framework kernel module, Cramming it all into one big commit makes it hard to review and test. LKML is therefore pretty strict to receive minimal changes that do not break anything (-> bisect); I tried to transform the required changes accordingly. The WiFi system has the same architecture, sure, so it can be compiled by the same toolchain. OTOH, the main system has everything but WiFi, and the secondary system has nothing but WiFi, so I doubt that compiling both kernels from one source is a good thing, unless the kernel code memory can be physically shared (haven't checked), or the whole kernel can be properly modularised. This should be discussed first, and in the meantime discrete support patches for the main system should be acceptable. [...] > > Looking at your submitted patches, many fritzbox devices have > > different NAND manufacturers. The question is, does their geometry differ across specimen of the same model? Maybe with different manufacturing runs? > > So the best way is to support all. No contradiction from my side. > > I created a DTB and image configuration for Micron and non Micron > > NAND. This is probably the best way and not supporting just one > > NAND type per device. Unfortunately auto detection was not accepted > > by the kernel maintainers, so there is no other solution. > > > > I also saw the addition of ubifs. I have not used this so far and I > > wonder what the advantage is over using squashfs with overlay? > > Let me cite https://en.wikipedia.org/wiki/UBIFS > > - tracking NAND flash bad blocks > - providing wear leveling > > NAND is a rather unreliable type of flash, hence some special > treatment has to be done to make it last as long as possible. Yes, I somehow had gotten the impression that UBI was mandatory for OpenWRT ports to new devices with NAND, so I went that way. Is sysupgrade prepared for squashfs+overlay as UBI volumes? Torsten
2/14/22 11:06, Torsten Duwe: > On Sat, 12 Feb 2022 02:05:17 +0100 > Mathias Kresin <dev@kresin.me> wrote: >> 2/11/22 23:39, kestrel1974@t-online.de: >>> I created a DTB and image configuration for Micron and non Micron >>> NAND. This is probably the best way and not supporting just one >>> NAND type per device. Unfortunately auto detection was not accepted >>> by the kernel maintainers, so there is no other solution. >>> >>> I also saw the addition of ubifs. I have not used this so far and I >>> wonder what the advantage is over using squashfs with overlay? >> >> Let me cite https://en.wikipedia.org/wiki/UBIFS >> >> - tracking NAND flash bad blocks >> - providing wear leveling >> >> NAND is a rather unreliable type of flash, hence some special >> treatment has to be done to make it last as long as possible. > > Yes, I somehow had gotten the impression that UBI was mandatory for > OpenWRT ports to new devices with NAND, so I went that way. > > Is sysupgrade prepared for squashfs+overlay as UBI volumes? Yes, sysupgrade is fine. It's used for the BT Home Hub 5A for example. Mathias
Hi, without specifying any of the options from Torstens commit, with my PR the following is printed during boot: [ 13.493508] pci 0000:02:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x801 [ 13.499854] pci 0000:02:00.0: quirk_usb_early_handoff+0x0/0x8f4 took 4894168 usecs [ 13.509105] UBI: auto-attach mtd1 [ 13.511042] ubi0: attaching mtd1 [ 13.672281] ubi0: scanning is finished [ 13.687360] ubi0: attached mtd1 (name "ubi", size 48 MiB) [ 13.691364] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes [ 13.698322] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [ 13.705011] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 [ 13.711700] ubi0: good PEBs: 384, bad PEBs: 0, corrupted PEBs: 0 [ 13.717793] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128 [ 13.724992] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 955112811 [ 13.734025] ubi0: available PEBs: 0, total reserved PEBs: 384, PEBs reserved for bad PEB handling: 80 [ 13.743384] ubi0: background thread "ubi_bgt0d" started, PID 456 [ 13.751194] block ubiblock0_0: created from ubi0:0(rootfs) [ 13.755363] ubiblock: device ubiblock0_0 (rootfs) set to be root fil[ 13.768689] Freeing unused kernel memory: 3820K [ 13.771792] This architecture does not have kernel memory protection. [ 13.778325] Run /init as init process In the Image config, $(Device/NAND) is specified, which uses the definitions from target/lantiq/image/Makefile, isn't that already ubifs enablement? It was not required to build any of the ubi images to get the messages above. So is the creation of the ubi image really neccessary? What additional benefit does building the ubi images have? And as you can see, even though $(Device/NAND) specifies 4k page size, ubi will use what the NAND chip declares. Thanks. -----Original-Nachricht----- Betreff: Re: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes Datum: 2022-02-14T23:48:41+0100 Von: "Mathias Kresin" <dev@kresin.me> An: "Torsten Duwe" <duwe@lst.de>, "openwrt-devel@lists.openwrt.org" <openwrt-devel@lists.openwrt.org> 2/14/22 11:06, Torsten Duwe: > On Sat, 12 Feb 2022 02:05:17 +0100 > Mathias Kresin <dev@kresin.me> wrote: >> 2/11/22 23:39, kestrel1974@t-online.de: >>> I created a DTB and image configuration for Micron and non Micron >>> NAND. This is probably the best way and not supporting just one >>> NAND type per device. Unfortunately auto detection was not accepted >>> by the kernel maintainers, so there is no other solution. >>> >>> I also saw the addition of ubifs. I have not used this so far and I >>> wonder what the advantage is over using squashfs with overlay? >> >> Let me cite https://en.wikipedia.org/wiki/UBIFS >> >> - tracking NAND flash bad blocks >> - providing wear leveling >> >> NAND is a rather unreliable type of flash, hence some special >> treatment has to be done to make it last as long as possible. > > Yes, I somehow had gotten the impression that UBI was mandatory for > OpenWRT ports to new devices with NAND, so I went that way. > > Is sysupgrade prepared for squashfs+overlay as UBI volumes? Yes, sysupgrade is fine. It's used for the BT Home Hub 5A for example. Mathias
2/15/22 08:56, kestrel1974@t-online.de: > Hi, > > without specifying any of the options from Torstens commit, with my PR the following is printed during boot: > [ 13.493508] pci 0000:02:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x801 > [ 13.499854] pci 0000:02:00.0: quirk_usb_early_handoff+0x0/0x8f4 took 4894168 usecs > [ 13.509105] UBI: auto-attach mtd1 > [ 13.511042] ubi0: attaching mtd1 > [ 13.672281] ubi0: scanning is finished > [ 13.687360] ubi0: attached mtd1 (name "ubi", size 48 MiB) > [ 13.691364] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes > [ 13.698322] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 > [ 13.705011] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 > [ 13.711700] ubi0: good PEBs: 384, bad PEBs: 0, corrupted PEBs: 0 > [ 13.717793] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128 > [ 13.724992] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 955112811 > [ 13.734025] ubi0: available PEBs: 0, total reserved PEBs: 384, PEBs reserved for bad PEB handling: 80 > [ 13.743384] ubi0: background thread "ubi_bgt0d" started, PID 456 > [ 13.751194] block ubiblock0_0: created from ubi0:0(rootfs) > [ 13.755363] ubiblock: device ubiblock0_0 (rootfs) set to be root fil[ 13.768689] Freeing unused kernel memory: 3820K > [ 13.771792] This architecture does not have kernel memory protection. > [ 13.778325] Run /init as init process > > In the Image config, $(Device/NAND) is specified, which uses the definitions from target/lantiq/image/Makefile, isn't that already ubifs enablement? > It was not required to build any of the ubi images to get the messages above. > > So is the creation of the ubi image really neccessary? > What additional benefit does building the ubi images have? > > And as you can see, even though $(Device/NAND) specifies 4k page size, ubi will use what the NAND chip declares. > > Thanks. Please do not top post! Yes the way you are doing it is correct. I got confused by ubi image vs. using ubi. An ubi image is only required for boards which do not have an ubi partition from the beginning. Back in the days, yaffs or squashfs on raw nand was used by some vendors. For such cases, the ubi partition need to be created during first/initial flash using an ubi(nized) image. Mathias
With the latest advancements, especially the move to kernel-5.10, basic support for the {3,5,7}490 Fritz!Boxes has become rather low hanging fruit. Building on the previous research done by Andreas Böhler (subscribed here), Daniel Kestrel (Cc'ed) and others, I identified and collected all the pieces, verified and fixed the detail information as far as I could, and refined the changes into a hopefully acceptable patch set. The hardware telephony on the {5,7}490 remains unsupported, of course. The WiFi on these systems is moved to a secondary SoC; some effort has been made to build an appropriate OpenWRT image for that as well in one run, but I'm ignoring that here for simplicity's sake. The extra image is a major step, which should rather be discussed and postponed, and should IMHO not hinder the inclusion of these devices. Neither did I consider performance patches yet. On the plus side, thanks to the DSA move in Linux mainline, all 4 LAN ports can be used now. Likewise, the USB3 ports are working, once an xHCI firmware blob is provided [1]. These patches are tested on 7490 and 3490, one specimen each. I can't verify the 5490 fiber box, but I include it here because of the similarity. Any feedback is appreciated. Especially the GPIO lines and switch ports remain to be filled in at the DTS. The 7490 I have uses a Micron NAND chip with 128k PEBs and 2k IO size. The 3490 has a Toshiba Chip with 256k PEBs and 4k IO. Anybody with a different combination please speak up! Torsten [1] https://forum.openwrt.org/t/2071