AW: Mark lantiq and omap as source only
Hi, why is it not feasible to add a hack/patch, actually the suggested one in this thread: https://patchwork.kernel.org/project/netdevbpf/patch/20220630212703.3280485-1-martin.blumensti...@googlemail.com/ Yes, it is not accepted by the kernel maintainers and yes, it keeps the unwanted or undesirable behaviour of flooding that the changes in dsa should try to avoid. But that should not keep the xrx200 based devices from continuing to work with 5.15 based openwrt. The patch in the link above worked for me, I changed the line to 1344 and replaced max_ports with cpu_port. Then the error messages are gone and I guess the flooding still appears. If you look at the thread above, it looks like a tremendous amount of work that needs to be done to implement it properly. How long will that take by people doing it as a hobby and having other things in life, 2 years?! Daniel. -Original-Nachricht- Betreff: Re: Mark lantiq and omap as source only Datum: 2023-05-03T08:34:25+0200 Von: "Nick" An: "openwrt-devel@lists.openwrt.org" On 5/3/23 02:53, Alexander 'lynxis' Couzens wrote: > what are the problems with lantiq 5.15? There are some issues with the fdb entries: > lantiq_gswip driver (e.g.: gswip 1e108000.switch: port 4 failed to add > vid 1 to fdb: -22) Ansuel describes here why this is so bad: https://github.com/openwrt/openwrt/pull/12515#issuecomment-1531686673 Bests Nick ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
AW: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Hi,
I can understand that it took a long time. The wasp loader kernel module v5 is
the next in the review list of the remoteproc-linux kernel list.
I will try to deal with Haukes suggestions by the end of the week. With regards
to the packages, I think wpad is a left over from my tests and I can remove it
and I will rework the kernel patches.
But for the special packages that are not honored by the build bots, I do not
really have a solution. For now I was thinking of instructions to use the image
builder, which also means, that as a start there will not be any downloadable
images that cover all possible functionality.
Daniel.
-Original-Nachricht-
Betreff: Re: [PATCH v2 0/7] 22.03 lantiq: add support for x490 Fritzboxes
Datum: 2022-10-25T00:24:57+0200
Von: "Hauke Mehrtens"
An: "Torsten Duwe" , "openwrt-devel@lists.openwrt.org"
On 10/23/22 13:19, Torsten Duwe wrote:
> Hi all,
>
> Here is my second attempt for initial FritzBox x490 support. 22.03 now
> has all the necessary prerequisites, so support can be added according
> to the rules.
>
> The original code snippets were submitted by John Crispin (IIRC),
> Andreas Böhler and Daniel Kestrel. I carved out the changes I
> considered necessary, integrated and tested them and cleaned them up
> (hopefully ;)
>
> These are the minimal changes required to run the FB {3,7}490 as DSL
> router (tested!). The 5490 is reported to be similar, so I included
> it, but could not test it due to lack of hardware.
>
> The wireless on these boxes is offloaded to a secondary SoC which
> needs to be provided its own OS. This feature is explicitly left out
> here in order to go step by step. I kept some loose ends where they
> don't hurt, for future reference.
>
> Changes from v1:
>
>
> * return to squashfs for the rootfs; ubifs causes too much complexity
>esp. for updates, when even the same model can be equipped with
>varying flash chip geometries. UBI partitioning and volumes are kept
>though.
Hi,
How is this related to the pull request adding support for these devices
on github?
https://github.com/openwrt/openwrt/pull/5075
The pull request on github looks mostly ok to me, I just had some minor
questions.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
AW: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
Hi, without specifying any of the options from Torstens commit, with my PR the following is printed during boot: [ 13.493508] pci :02:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x801 [ 13.499854] pci :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" An: "Torsten Duwe" , "openwrt-devel@lists.openwrt.org" 2/14/22 11:06, Torsten Duwe: > On Sat, 12 Feb 2022 02:05:17 +0100 > Mathias Kresin wrote: >> 2/11/22 23:39, kestrel1...@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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
AW: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
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: "kestrel1...@t-online.de"
An: "Torsten Duwe" , "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"
An: "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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
AW: [PATCH 0/7] lantiq: initial support for x490 Fritzboxes
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"
An: "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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
