Re: OpenWrt One - celebrating 20 years of OpenWrt

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2024-02-27 10:16, Bas Mevissen wrote:

(former one escaped too quickly, please ignore)


On 2024-02-26 22:38, Paul D wrote:

On 2024-02-26 19:39, John Crispin wrote:

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done


Can it be shared already? I'm wondering whether some peripheral port 
can easily be used to configure an external switch chip. I would like 
not to have to use the mbus for that.




*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


If there is no price difference, can we have 90 degree angled pins for 
GND+TX+RX serial header, so the pins face away from the board as USB 
sockets do, and not stand up perpendicularly.


This way serial consoles are workable even when device is in a case.


Does anyone else have opinions on this?



I think the console USB connector is intended for that.



*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with 
SFC tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced 
shortly and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual 
flash, mikrobus,  s.T. I could build and test dts files. I 
ordered the RTC used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty 
elaborate uboot-env with lots of commands to provide easy 
un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the 
light blue used inside the OpenWrt logo. we are still figuring this 
out with the supplier.



In 20 years when these devices are old and need recycling, how 
recyclable are the PCBs? What substances go into it? Toxic ones?


The color pigment is probably not the biggest concern...






I should probably start building a page inside the wiki to provide 
better visibility into what is happening.




Would be great. But this mail was already great to read about the 
progress!


shout out to pepe2k, SFC and MTK for the never ending support that 
they provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi 
that has been ultra cool in making this become a reality


     John


Agree!


Bas.





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2024-02-26 22:38, Paul D wrote:

On 2024-02-26 19:39, John Crispin wrote:

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done


Can it be shared already? I'm wondering whether some peripheral port can 
easily be used to configure an external switch chip. I w


*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


If there is no price difference, can we have 90 degree angled pins for 
GND+TX+RX serial header, so the pins face away from the board as USB 
sockets do, and not stand up perpendicularly.


This way serial consoles are workable even when device is in a case.


Does anyone else have opinions on this?



I think the console USB connector is intended for that.



*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with SFC 
tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced shortly 
and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual flash, 
mikrobus,  s.T. I could build and test dts files. I ordered the 
RTC used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty 
elaborate uboot-env with lots of commands to provide easy 
un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the light 
blue used inside the OpenWrt logo. we are still figuring this out with 
the supplier.



In 20 years when these devices are old and need recycling, how 
recyclable are the PCBs? What substances go into it? Toxic ones?





I should probably start building a page inside the wiki to provide 
better visibility into what is happening.


shout out to pepe2k, SFC and MTK for the never ending support that 
they provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi 
that has been ultra cool in making this become a reality


     John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2024-01-17 16:21, John Crispin wrote:

Additional FAQ for OpenWrt One

This is a summary of some further questions regarding the OpenWrt One
project gathered so far. After OpenWrt voted to move forward, it will
be converted into a page within the OpenWrt wiki as a place for
collecting the latest information.

Q: Will the various hardware buttons and switches be fully exposed on
the outside?
A: The latest iteration of the design will fully expose all buttons
and switches.

Q: Will there be an option to purchase preassembled kits?
A: We're considering that option but still need to explore
possibilities with the manufacturer.

Q: When do you expect general availability?
A: Once we vote to move forward, it will take around 45 days until the
first PCBA engineering samples get shipped. These will be passed on to
developers for testing. Once they are verified it will probably take
another 30-45 days until they can be ordered. So we are looking at
April timeframe.

Q: What kind of power supply is needed?
A: While the initial announcement imprecisely referred to the power
supply as "USB-PD 12V" the PCB will draw its required power from a
USB-C PD 3.0/2.0 source.

Q: Why does the current design not feature any USB 3.0 connectivity?
A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We
would like to reduce risk as much as possible. Interference proofing
the board would add considerable complexity and costs.

Q: Why did you implement a M.2 slot?
A: After careful consideration we came to the conclusion that directly
exposing a PCIe 1x lane in the form of an M.2 slot provides the most
flexibility for potential expansions. It can be used for NVMe storage
(up to 2242 when using an enclosure), e.g. to host containers or media
files. It also enables the simple use of other, non-OpenWrt
distributions with larger storage footprints.

Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)?
A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor
is there a fully integrated tri-band SoC solution available right now,
let alone fully or partially supported upstream. Supporting Wi-Fi 7
would drastically increase the overall costs and make it impossible to
deliver sufficient software support in the foreseeable future.

Q: Why are there only two ethernet ports?
A: We didn't want to impose additional complexity and costs by
including an external managed switch IC. One port is 1GBit/s capable,
while the other features a speed up to 2.5GBit/s. This is a limitation
of the chosen SoC.



Makes sense. Most people already have additional switches at home to 
accommodate more than the typically 4-5 ports router have.


Will there be no limitation on which of the ports is the WAN or the LAN 
(e.g. due to offloading)?


Would it be an idea to have a connector with SPI/I2C, power and 
preferably direct access to the media interface to be able to connect 
your own switch board? Then you can still control the switch from 
OpenWRT.



Q: Why should I get the One? There are more capable, more featured
devices available!
A: The OpenWrt One is intended to serve as a robust and simple
educational platform for OpenWrt enthusiasts, it is neither intended
to be a competitor to off the shelf SOHO routers nor do we aim for the
largest possible amount of features. It also serves as a donation
vehicle for the OpenWrt project.

Q: Does that mean that OpenWrt will stop supporting other hardware?
A: There is no intention at all to change the way OpenWrt operates or
how it implements and supports current and future hardware. The
OpenWrt One device will be supported as one device among many others
and receive the same level of support.

Q: Doesn't this draw attention away from properly supporting existing 
devices?

A: The OpenWrt One project is a privately led initiative by a few
enthusiasts, there is no intent to change the focus of the OpenWrt
project in any way.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 09/01/2024 11:49, John Crispin wrote:



This is our first design, so let's KiSS!



Agreed, however as it needs to last for a long period of time, it should 
not be too under powered.




Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)


Was the MT7986AV, MT7976DA combo considered? Has 4x4 for office 
applications (MU-MIMO), so might be useful for corporate or soho use.

It also has more horse power to run some local services


* DRAM: 1 GiB DDR4


What's the price difference with 2GB? For home automation purposes and 
other virtualisation applications it might come in handy.



* Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
* Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
* USB (host): USB 2.0 (Type-A port)
* USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)


Great idea!


* Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
* Buttons: 2x (reset + user)
* Mechanical switch: 1x for boot selection (recovery, regular)
* LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
* External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
* RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
* Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
* Expansion slots: mikroBUS
* Certification: FCC/EC/RoHS compliance
* Case: PCB size is compatible to BPi-R4 and the case design can be re-used
* JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)


Nice to have the connector, would be great if a supported USB JTAG 
adapter could be supplied as an option.



* Antenna connectors: 3x MMCX for easy usage, assembly and durability
* Schematics: these will be publicly available (license TBD)
* GPL compliance: 3b. "Accompany it with a written offer ... to give any 
third party ... a complete machine-readable copy of the corresponding 
source code"

* Price: aiming for below 100$



Or just have 1 or 2 existing Banana Pi boards with OpenWRT branding? The 
schematics are not really making much difference for most people. Having 
all SW FOSS does.



Bas.




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2023-01-21 22:42, Lukas Zeller wrote:

Hi Tomasz,

thanks a lot for that hint to dtbocfg and the makefile!

On 21 Jan 2023, at 17:27, Tomasz Maciej Nowak  
wrote:


[...]

W dniu 21.01.2023 o 16:33, Lukas Zeller pisze:


So basically, I'm suggesting to revisit the decision to reject the 
patch from Daniel Golle [1].


Instead of doing it the hard way of patching, why not using 
out-of-tree kernel
module[2] for loading dtb overlay with configfs? It already exists for 
some

time.


That really looks like a great solution with all advantages combined!

I agree this is better than patching, I just did not realize it was
possible at all to modularize dt overlay functionality this way.



It is a thing very commonly done on RPi "hats" to change the pin config 
on the extension header.

You may find some documentation and examples there that may help you.


[...] Unfortunately I didn't test it, as the board I wanted to use it 
has gone
in flames. For ready to use recipe see the attachment. Feel free to 
submit it

to packages feed and take over maintainership after giving it a test.


I will certainly try that, as soon as I find some time for it, but
that's not likely to happen before ~March, unfortunately...


[...]
2. https://github.com/ikwzm/dtbocfg


Lukas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] x86: use mkfs.fat, sed, mmd and mcopy from staging_dir

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2023-01-20 13:24, Florian Eckert wrote:

On 2023-01-20 12:49, Felix Fietkau wrote:

On 20.01.23 12:42, Florian Eckert wrote:


Hello Felix,

During image generation, the host tools should not be used but the 
tools

from the staging_dir.

- mkfs.fat
- sed
- mmd
- mcopy

Why is this necessary? $STAGING_DIR_HOST/bin should already be in
$PATH before the host system parts.


I only noticed that the prefix $(STAGING_DIR_HOST) is missing for 
these

tools on x86_64 image Makefile.
If I look for this prefix in OpenWrt, it is found in some image
Makefiles commands.

For examples:
-
https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/image/Makefile
-
https://github.com/openwrt/openwrt/blob/master/target/linux/bcm63xx/image/Makefile
-
https://github.com/openwrt/openwrt/blob/master/target/linux/ath25/image/Makefile


If this is in the PATH through this line
https://github.com/openwrt/openwrt/blob/master/Makefile, then this is
not needed for the others?

I only wanted to unify this with the change and make it clear that 
the

tool from staging is used here.

Thanks. I don't have a strong opinion one way or the other, but I
think the code might be more readable without the explicit
$(STAGING_DIR_HOST)/bin prefix.


Your right It works regardless of whether the prefix is there or not.
But I would just like to note that it is easier to see whether the
tools are now used from staging or the build host.
The tool mkisofs
https://github.com/openwrt/openwrt/blob/master/target/linux/x86/image/Makefile#L100,
for example, is used from the build host!
There is indeed a guard here
https://github.com/openwrt/openwrt/blob/master/target/linux/x86/Makefile.
But I am not sure if this is the case everywhere and if it is clear to
everyone which tool is now being used during development.
I just wanted to say that I am more in favor of explicitly select
which tool is now being used.



I think the actual tool used should be in a variable, like 
$(STAGING_HOST_SED). This is very readable and it also makes the list of 
tools used explicitly known. The PATH must still be set for tools to 
find other staging dir tools.


Actually, the host path should be unset to avoid inadvertently using the 
host tools instead of the one of the staging dir.
I personally would prefer using a chroot-ed staging host to avoid any 
host interference.


Regards,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: DSA Terminology

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2022-09-13 21:56, Jo-Philipp Wich wrote:

Hi,


IMHO changing, in /etc/config/network:
"config interface" -> "config network"
"config device" -> "config interface"
would eliminate this semantic inconsistency and bring the naming
convention more in line with what Rich referred to in his comments
above.


This cannot be done in a sane manner though as it would render future 
versions

entirely backwards incompatible.

Renaming `config interface` to `config network` makes sense and can be
implemented easily. However we would still need to treat `config 
interface` as
synonym for it in the forseeable future in order to retain 
compatibility,

which means that we cannot reuse `interface` for something else.

So changing `config interface` to `config network` would be possible 
assuming
that `config device` remains `config device` (or is renamed to 
something other

than `interface`).

At the same time, the `wifi-iface` section type in /e/c/network should 
be

changed to `wifi-network` in order to remain consistent.




When you are at this level of changes and redefining and reusing names, 
normally it is time to reconsider the complete thing.
I would suggest something like a JSON file based config with versioning 
so that later changes can be done in a forward compatible way.


With some clever scripts, not too exotic existing configurations can be 
converted automatically, just like was done with the switch to DSA.


Just my 2 cents..

Bas.


~ Jo


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] build: always set CONFIG_IPV6

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 8/18/22 20:32, Robert Marko wrote:

On Thu, 18 Aug 2022 at 20:07, Enrico Mioso  wrote:


Hello all!!

In my opinion, it would be better to try keeping this option available.
Surely, !IPV6 is not a common scenario these days. But I think OpenWrt might be 
useful to catch bugs like the one fixed in commit 
77fc73ac89be96ec8f39e8efa53885caa7cb3645
in the Linux kernel's git tree.

So, for what it's worth, a NACKfrom me.


It's becoming increasingly hard to impossible to disable IPv6 in all
of the SW that OpenWrt ships, that is the reason for this.
More and more SW just doesn't have a way to disable IPv6 at all, so
unless we want to carry even more patches this is
kind of inevitable.

It is 2022 after all, so ACK from me for what it's worth.



Would it make sense to simply always build with IPV6 support and have 
the CONFIG_IPV6 flag repurposed to have the defaults for the network 
interfaces and kernel sysctls set to disable IPV6 as much as possible?


This might make sense in environments where any IPV6 support is 
unwanted. Still many people have no IPV6 at home or at work and hence 
better not have it configured at their local network nor router.


Rewgards,

Bas.


Regards,
Robert


Enrico


On Thu, 18 Aug 2022, Paul Spooren wrote:


Date: Thu, 18 Aug 2022 17:33:42
From: Paul Spooren 
To: Stijn Tintel 
Cc: Thibaut ,
 openwrt-devel 
Subject: Re: [PATCH] build: always set CONFIG_IPV6




On 18. Aug 2022, at 16:07, Stijn Tintel  wrote:

On 18/08/2022 17:03, Thibaut wrote:

Le 18 août 2022 à 15:40, Stijn Tintel  a écrit :

On 16/08/2022 20:00, Thibaut VARÈNE wrote:

Disabling this build tunable breaks build and seems unrealistically
likely to be fixed.

This patch sets the related CONFIG to always true and removes the
config prompt, keeping the change minimal, and, should !CONFIG_IPV6 ever
be fixed, easy to revert.

If we're always going to set it to yes, just drop the option entirely and 
enable it in the generic kernel configs. Aside from that:

CONFIG_IPV6 is not a kernel config, it’s a tree-wide one.

My idea was to keep the change as small as possible should we ever want to 
revert, while preventing further pointless bugreports[1].

Entirely removing the config option requires more invasive changes throughout the tree 
and the package repositories, which is significantly less trivial than this "first 
step".

Cheers,
Thibaut

[1] https://github.com/openwrt/openwrt/issues/9580


OK, in that case, let's await at least one more ACK and we can start
with this.


Per request:

Acked-by: Paul Spooren 



Thanks,
Stijn


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

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


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [sdwalker/sdwalker.github.io] 2bdb42: This week's update

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 13/05/2022 01:59, Sergey Ryazanov wrote:

Hello Jeffery,

On Fri, May 13, 2022 at 2:03 AM Jeffery To  wrote:

On Fri, May 13, 2022 at 6:26 AM Sergey Ryazanov  wrote:


+1

Stephan, may I sincerely ask you to stop spamming the list?

On Mon, May 9, 2022 at 12:08 PM  wrote:

is the below weekly message of any informational value to _all_? can someone 
maybe block this if it's not? ..thanks ede

On 08.05.2022 23:05, Stephen Walker via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.


As a package maintainer, I want to know that uscan is running
correctly. These emails are relevant to me.


Nice to hear that someone is actually using this information.

May I ask why these notifications are directed to the mailing list
that is dedicated for development talks? Such a notification just
_looks_ irrelevant to some thread, it is not even a patchwork
notification or a buildbot warning that is sent as a reply to a patch.


It would be very simple to set up any competent email client to filter
out these messages, if you so choose.


It is a matter of balance. Everyone is happy to read these
notifications, but someone will not need them and will create an
automatic filtering rule. Or someone found these notifications useful,
but everyone else wonders why they received them.


The mail itself is currently not that informing. It is a lot of boiler plate 
and repetition. Only the link to the actual commit is useful information.

I think it would be a huge improvement to have the highlights of the scan 
results posted in a nice readable format. A sort of condensed version of the 
page at https://sdwalker.github.io/uscan/index.html



Is it possible to reconfigure these notifications to send them
directly to your mailbox? Or maybe set up a dedicated mailing list? We
already have the mailing list for commit notifications. I am
subscribed and quite happy to be informed of development progress this
way - it saves me a lot of time and does not bother people who prefer
some other monitoring approach.



This is a development list where the package maintainers and devs hang out, so 
it is relevant information. Only the current form isn't optimal IMHO.

BR,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02.3 Third service release

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2022-04-21 00:21, Hauke Mehrtens wrote:

Hi,

The OpenWrt community is proud to announce the third service release
of OpenWrt 21.02. It fixes security issues, improves device support,
and brings a few bug fixes.



Thanks for all the hard work put into this!

I noticed a small issue during the upgrade using the sysupgrade in Luci. 
After the first attempt, it showed I was still running 21.02.2. Flashing 
the same file again gave me the correct version (21.02.3). (the status 
overview also showed the old kernel version and a low uptime, so there 
was a reboot and I did not misread the version).
I also only have the latest binary for a single router on my PC, so no 
mistake possible there as well.


The only difference between my first and second attempt was that I did 
not tick the box "Include in backup a list of current installed packages 
at /etc/backup/installed_packages.txt" the second time. I do have some 
extra packages installed and updated some during the 21.02.2 lifetime.


Router is a TP Link Archer C7 v5 that was running 21.02.2 before the 
upgrade.


If more people experience this, it might be worth spending time on it. 
Otherwise, it might be best to just retry and be happy!


Regards,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] toolchain/gcc: set dialects for each version

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 1/25/22 18:02, Stijn Tintel wrote:

GCC has an option "-std=" to set the language standard for C and C++.
Newer GCC versions sometimes switch to newer standards by default. This
has the potential to break the OpenWrt toolchain build whenever a distro
introduces a new GCC version that uses a newer dialect by default.

Let's set the default dialects used for each of the GCC versions we
support, to avoid these toolchain build failures in the future.



Shouldn't the logic be different? It is the software that is to be 
compiled that is written in a certain version or versions of C or C++ 
language.


OpenWRT should set a default C and C++ language version and packages or 
any other software compiled with the OpenWRT build should override it 
when they need it.


A package might for example define that they can be compiled with 
version C++11 to C++20 or require at least C++17 (and hence require a 
minimum GCC version).


How does this currently work? Are packages assumed to be compilable with 
the default C or C++ language version of the default (host or target) 
GCC version?


Regards,

Bas.



Signed-off-by: Stijn Tintel 
---
  toolchain/gcc/common.mk | 8 
  1 file changed, 8 insertions(+)

diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
index bef4fa37f8..3e31a139cd 100644
--- a/toolchain/gcc/common.mk
+++ b/toolchain/gcc/common.mk
@@ -29,14 +29,20 @@ PKG_SOURCE_URL:=@GNU/gcc/gcc-$(PKG_VERSION)
  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
  
  ifeq ($(PKG_VERSION),8.4.0)

+  C_DIALECT=-std=gnu17
+  CXX_DIALECT=-std=gnu++14
PKG_HASH:=e30a6e52d10e1f27ed55104ad233c30bd1e99cfb5ff98ab022dc941edd1b2dd4
  endif
  
  ifeq ($(PKG_VERSION),10.3.0)

+  C_DIALECT=-std=gnu17
+  CXX_DIALECT=-std=gnu++14
PKG_HASH:=64f404c1a650f27fc33da242e1f2df54952e3963a49e06e73f6940f3223ac344
  endif
  
  ifeq ($(PKG_VERSION),11.2.0)

+  C_DIALECT=-std=gnu17
+  CXX_DIALECT=-std=gnu++17
PKG_HASH:=d08edc536b54c372a1010ff6619dd274c0f1603aa49212ba20f7aa2cda36fa8b
  endif
  
@@ -86,6 +92,8 @@ GCC_CONFIGURE:= \

CFLAGS="-O2 -fbracket-depth=512 -pipe" \
CXXFLAGS="-O2 -fbracket-depth=512 -pipe" \
) \
+   CFLAGS="$(CFLAGS) $(C_DIALECT)" \
+   CXXFLAGS="$(CXXFLAGS) $(CXX_DIALECT)" \
$(HOST_SOURCE_DIR)/configure \
--with-bugurl=$(BUGURL) \
--with-pkgversion="$(PKGVERSION)" \


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC] Stop providing binary package updates for release builds?

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-12-12 20:42, Jo-Philipp Wich wrote:

Hi,


(...)

Hi Jo-Philips, thanks for the detailed write-up.

As an embedded software developer, I feel much and mostly agree with 
your reasoning. However, one of the reasons I like to use OpenWRT so 
much on my production router(s) is exactly that availability of quality 
pre-build images and release branch matching up-to-date (security, bugs) 
packages.


For production use, I really love the "official" built and tested 
releases and install them to my devices, even while having my own builds 
available. Next to that, I install packages of what additional 
functionality I need. For the 20.02.1 release, it was also the way to 
get rid of a small bug, as advised in the release notes (in a matter of 
seconds):


"
The menu bar in LuCI is wrongly aligned
If this is a real problem for you update the LuCI theme: opkg upgrade 
luci-theme-bootstrap

"
(source: https://openwrt.org/releases/21.02/notes-21.02.1)

This is what, in my humble opinion, makes OpenWRT such a great piece of 
software for even not-so-technical users: you just pick the latest 
release for your router and if you need some other functionality, you 
can simply install a few packages from the web UI. And if there is a 
small security update or bugfix, it is solved in a few mouse clicks for 
everyone, independent of their technical skills.


So apart from being convenient, I feel the packages feed for release 
branches also provides easy access to stability and security to all 
users. Given all the issues found in IOT and routers with mostly 
out-of-date propriety firmware, OpenWRT in its current form is such an 
asset!


In summary, I would urge the OpenWRT devs to not too lightly drop the 
binary distribution of images and packages it has now. If, however, it 
is decided otherwise, I'm thinking of a possible solution: a docker or 
other container-like image that users can download with for example the 
host tools pre-build and an easy to use interface to update the OpenWRT 
sources, and configure and build them to their needs.


Cheers,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ar71xx: rb941-2nd support

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote:


Hi,

is there any chance of getting support for the MikroTik hAP lite 
classic back?


Best Regards
Bjoern


It only has 32MB of RAM, see 
https://openwrt.org/supported_devices/432_warning about these kind of 
devices.
You can make your own build that only includes what you need to make it 
fit the device constraints.


Regards,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ar71xx: rb941-2nd support

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-10-11 10:31, Bjoern Franke via openwrt-devel wrote:


Hi,

is there any chance of getting support for the MikroTik hAP lite 
classic back?


Best Regards
Bjoern


It only has 32MB of RAM, see 
https://openwrt.org/supported_devices/432_warning about these kind of 
devices.
You can make your own build that only includes what you need to make it 
fit the device constraints.


--
Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: add option to make /var persistent

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 8/7/21 10:40 AM, Stijn Tintel wrote:


On 7/08/2021 10:05, Alberto Bursi wrote:



On 07/08/21 02:46, Stijn Tintel wrote:

On 7/08/2021 02:56, Alberto Bursi wrote:



On 06/08/21 21:27, Stijn Tintel wrote:
In OpenWrt, /var is symlinked to /tmp by default. This is done to 
reduce

the amount of writes to the flash chip, which often don't have the
greatest durability. As a result, things like DHCP or UPnP lease 
files,

are not persistent across reboots.

Since OpenWrt can run on devices with more durable storage, it makes
sense to have an option for a persistent /var. Add an option to make
/var persistent. When enabled, /var will no longer be symlinked to 
/tmp,

but /var/run will be symlink to /tmp/run, as it should contain only
files that should not be kept during reboot. The option is off by
default, to maintain the current behaviour.



Since it does not really need to recompile anything, I think it
can/should be handled as a package, not as a compile option.

When you install the package these operations are executed, if you
remove the package they are undone.


Removing /var at runtime, which basically happens when you remove the
symlink, is very ugly and has a huge potential for breakage. Having it
as a build option also avoids users from accidentally installing it as a
package. If you disagree, please elaborate further, including measures
to avoid random breakage caused by removing /var at runtime.



My focus was more on "not using a compile option", I don't think it's 
necessary to do this at runtime.


A simple measure to avoid breakage would be to add something that runs 
on boot (either initscript or preinitscript) to do these changes 
before any other service that needs that folder is started.

So you install the package and then reboot.

This approach also allows to make this a permanent change (not an 
optional package) and control this function with UCI config, just 
change the setting and reboot.


IMHO this is good enough for most users, and much better than having 
to recompile or do the change manually.



For the sake of completeness, (also shameless plug about my project):
A more complex way to do it at runtime that avoids breakage is bind 
mounting the original folder somewhere else so you can sync the 
contents with the new/empty folder, then restarting all services that 
need it.

See
https://github.com/bobafetthotmail/folder2ram/blob/master/debian_package/sbin/folder2ram#L658 

(the service restart is not included in that script since it has no 
way of knowing what services need the folders, this operation is left 
to the user or for OpenMediaVault it's handled by the plugin that also 
writes the configuration)




Appreciate the input. It still sounds overly complex compared to my 
suggestion, especially for something that most users will probably not 
use. I don't feel comfortable implementing something like that. I'll 
just keep using my patch locally then, as I have done for almost five 
years.




I would love to see your patch it in de main tree. It is a nice addition 
for everyone using extroot (like me).


Even without extroot and current flashes, it might be worthwile to 
enable this and make thinks like dhcp leases persistent. In a soho 
network, they don't change that often to wear out a flash.



Thanks,
Stijn


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Error compiling master on WSL2 Ubuntu 20.04

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 08/06/2021 00:45, Alberto Bursi wrote:



On 07/06/21 22:35, Bas Mevissen via openwrt-devel wrote:


It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with 
spaces. I would have expected them to be quoted or escaped, but none 
of them seems to be the case.


(and shortening the path to a usual Linux path made the build finish, 
so no other issues at hand)


Having spaces in PATH is discussed here: 
https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently 
seen as OK.


If I do for example:
$ which dotnet.exe
/mnt/c/Program Files/dotnet//dotnet.exe

it seems to work fine.


Any ideas?

Cheers,

Bas.



Afaik the OpenWrt build system does not like paths and folders with 
spaces, and the documentation we have for using build system with WSL 
explains how to get rid of the Windows stuff in the path (so you don't 
have things with spaces).


See https://openwrt.org/docs/guide-developer/build-system/wsl



Thanks for the link. I wasn't aware of the existence of such a page.

I don't really like the proposed solution. The problem is not the fact 
that they are Windows directories, but that they contain spaces.


A better way would be to call OpenWRT Make with a Linux-only path like:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make

instead of modifying a global WSL setting.

BTW. As far as I could find, spaces are legal in $PATH, so I would say 
that there are bugs in OpenWRT regarding handling paths with spaces.


Thanks again,

Bas.


-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Error compiling master on WSL2 Ubuntu 20.04

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


Hi all,

In the last stages of compiling OpenWRT master on a WSL2 running Ubuntu 
20.04, I get the following error message:



sed -i "s/Installed-Time: .*/Installed-Time: 1623018311/" 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/status
rm -rf 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/boot 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/tmp/* 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/info/*.postinst*
 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/usr/lib/opkg/lists/*
 
/home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/var/lock/*.lock
find /home/bas/Workspace/openwrt/build_dir/target-mipsel_24kc_musl/root-ramips/ -mindepth 1 
-execdir touch -hcd "@1623018311" "{}" +
find: The relative path 'Files/dotnet/' is included in the PATH environment 
variable, which is insecure in combination with the -execdir action of find.  
Please remove that entry from $PATH
make[2]: *** [package/Makefile:73: package/install] Error 1
make[2]: Leaving directory '/home/bas/Workspace/openwrt'
make[1]: *** [package/Makefile:111: 
/home/bas/Workspace/openwrt/staging_dir/target-mipsel_24kc_musl/stamp/.package_install]
 Error 2
make[1]: Leaving directory '/home/bas/Workspace/openwrt'
make: *** [/home/bas/Workspace/openwrt/include/toplevel.mk:230: world] Error 2


The actual path is: $ echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/System32:/mnt/c/Windows:/mnt/c/Windows/System32/wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program
 Files/dotnet/:/mnt/c/Program Files (x86)/GnuPG/bin:/mnt/c/Program Files 
(x86)/dotnet/:/mnt/c/Program Files/WireGuard/:/mnt/c/Program 
Files/Git/cmd:/mnt/c/Program Files (x86)/AOMEI/AOMEI 
Backupper/6.5.1:/mnt/c/Program Files (x86)/Bitvise SSH 
Client:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Users/Bas
 Mevissen/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/Bas 
Mevissen/.dotnet/tools


It contains /mnt/c/Program Files/dotnet/ and other unquoted paths with 
spaces. I would have expected them to be quoted or escaped, but none of 
them seems to be the case.


(and shortening the path to a usual Linux path made the build finish, so 
no other issues at hand)


Having spaces in PATH is discussed here: 
https://github.com/Microsoft/WSL/issues/1766 in 2017 and apparently seen 
as OK.


If I do for example:
$ which dotnet.exe
/mnt/c/Program Files/dotnet//dotnet.exe

it seems to work fine.


Any ideas?

Cheers,

Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-05-28 13:55, Sergey Ryazanov wrote:

Hello Bas,

thank you for your review, please find my comments below.

On Fri, May 28, 2021 at 11:41 AM Bas Mevissen  
wrote:

On 2021-05-28 00:27, Sergey Ryazanov wrote:


[skipped]


+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+
+ /*
+  * Now we knows flash parameters and can tweak OOB the layout 
for old


Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old



Yeah, I am not happy with this comment too, but this is the best I was
able to compose at 01:00 :) I will rephrase it if V2 will be needed.

Here we need a comment that briefly and clearly states that the NAND
params become known at this particular moment of initialization.
Before this moment, we do not know the page size, after this moment it
is too late to reconfigure something. Do you have any thoughts?



The original comment with some spelling/grammar corrections looked fine. 
Having some hint that something is deliberately done at that stage is 
sufficient IMHO.



+  * (usually 64MiB) flashes.
+  *
+  * We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+  * bootloader will not be able to find the kernel that we load.
+  */
+ if (mtd->writesize == 512)
+ mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+ return 0;
+}
+
 static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
 {
  struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip
*chip)
  return gpiod_get_value_cansleep(nand->rdy);
 }

+static const struct nand_controller_ops rb4xx_nand_controller_ops = 
{

+ .attach_chip = rb4xx_nand_attach_chip,


remove the ,


I intentionally placed the comma here to make text git-friendly. If we
will need to define more callbacks here, then we will just add a new
new line, without modifying the earlier added lines.



Agreed. It actually sounds like a good practice. Learned something today 
:-)



E.g. if commit this code without the comma, then a chip detaching
callback patch will looks like this:

 static const struct nand_controller_ops rb4xx_nand_controller_ops = {
- .attach_chip = rb4xx_nand_attach_chip
+ .attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
 };

With this intentionally placed comma, the same theoretical patch will
looks like this:

 static const struct nand_controller_ops rb4xx_nand_controller_ops = {
  .attach_chip = rb4xx_nand_attach_chip,
+ .detach_chip = rb4xx_nand_detach_chip,
 };

So this comma is my investment in the future ;)


+};
+
 static int rb4xx_nand_probe(struct platform_device *pdev)
 {
  struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct 
platform_device

*pdev)
  mtd->dev.parent = dev;
  mtd_set_of_node(mtd, dev->of_node);

- if (mtd->writesize == 512)
- mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
  nand->chip.ecc.mode = NAND_ECC_SOFT;
  nand->chip.ecc.algo = NAND_ECC_HAMMING;
  nand->chip.options  = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct 
platform_device

*pdev)
  nand->chip.legacy.cmd_ctrl  = rb4xx_nand_cmd_ctrl;
  nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
  nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = 
_nand_controller_ops;


Fix indentation for all nand->something assignments to line up the =
sign


I do not think that this is a good idea for this patch. Here we add
one line that configures the single field deep inside the structure.
The line is placed after the configuration of "surface" fields. So the
overall look should not be harmed dreadfully.

In case we will rework the indentation with this patch, the 57 lines
patch will become a ~70 lines patch. Where at least 12 lines will
rework indentation, so the functional part could be easily lost. Also
the moving text back and forth within an item line, turns the history
to the white noise and makes git-blame(1) usage a pain.

If you prefer, then I could insert an empty line before the ops setup
to make it nice looking. E.g. turn this hunk:

@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device 
*pdev)

  nand->chip.legacy.cmd_ctrl  = rb4xx_nand_cmd_ctrl;
  nand->chip.legacy.dev_ready = rb4xx_nand_dev_ready;
  nand->chip.legacy.chip_delay= 25;
+ nand->chip.legacy.dummy_controller.ops = 
_nand_controller_ops;


into this:

@@ -199,6 +217,7 @@ static int rb4x

Re: [PATCH] ath79: rb4xx-nand: fix 512 byte pages compatibility

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


A few nitpicks:

On 2021-05-28 00:27, Sergey Ryazanov wrote:

MikroTik boards with 512 byte NAND pages require the old YAFFS1 OOB
layout for compatibility with the RouterBoot bootloader. The RB4xx NAND
driver supports such OOB layout, but checks a NAND page size too early
before the flash identification, what effectively preventing the old 
OOB

layout from being used.

To fix this issue, move the page size check and OOB layout 
configuration

to the chip attaching hook, which is specially intorduced for ECC and
OOB tweaking.

While at it, copy a comment from the old AR71xx driver to make it 
clear,

why do we need this OOB layout tweaking.

Run tested with MikroTik RB411U board.

Signed-off-by: Sergey Ryazanov 
---
 .../files/drivers/mtd/nand/raw/nand_rb4xx.c   | 25 ---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git
a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
index 50bd69f6a4..00c65d14ae 100644
--- a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
+++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb4xx.c
@@ -81,6 +81,23 @@ static const struct mtd_ooblayout_ops
rb4xx_nand_ecclayout_ops = {
.free = rb4xx_ooblayout_free,
 };

+static int rb4xx_nand_attach_chip(struct nand_chip *chip)
+{
+   struct mtd_info *mtd = nand_to_mtd(chip);
+
+   /*
+* Now we knows flash parameters and can tweak OOB the layout for old


Rephrase to something like:
Knowing the flash parameters, we can tweak the OOB layout for old


+* (usually 64MiB) flashes.
+*
+* We need to use the OLD Yaffs-1 OOB layout, otherwise the RB
+* bootloader will not be able to find the kernel that we load.
+*/
+   if (mtd->writesize == 512)
+   mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
+
+   return 0;
+}
+
 static u8 rb4xx_nand_read_byte(struct nand_chip *chip)
 {
struct rb4xx_nand *nand = chip->priv;
@@ -135,6 +152,10 @@ static int rb4xx_nand_dev_ready(struct nand_chip 
*chip)

return gpiod_get_value_cansleep(nand->rdy);
 }

+static const struct nand_controller_ops rb4xx_nand_controller_ops = {
+   .attach_chip = rb4xx_nand_attach_chip,


remove the ,

+};
+
 static int rb4xx_nand_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -185,9 +206,6 @@ static int rb4xx_nand_probe(struct platform_device 
*pdev)

mtd->dev.parent  = dev;
mtd_set_of_node(mtd, dev->of_node);

-   if (mtd->writesize == 512)
-   mtd_set_ooblayout(mtd, _nand_ecclayout_ops);
-
nand->chip.ecc.mode  = NAND_ECC_SOFT;
nand->chip.ecc.algo  = NAND_ECC_HAMMING;
nand->chip.options   = NAND_NO_SUBPAGE_WRITE;
@@ -199,6 +217,7 @@ static int rb4xx_nand_probe(struct platform_device 
*pdev)

nand->chip.legacy.cmd_ctrl   = rb4xx_nand_cmd_ctrl;
nand->chip.legacy.dev_ready  = rb4xx_nand_dev_ready;
nand->chip.legacy.chip_delay = 25;
+   nand->chip.legacy.dummy_controller.ops = _nand_controller_ops;


Fix indentation for all nand->something assignments to line up the = 
sign




ret = nand_scan(>chip, 1);
if (ret)



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Flagship AX routers

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 5/18/21 11:52 PM, Philip Prindeville wrote:

Hi all,

I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. 
and some of them have even had OpenWRT ported to them.

Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm 
not seeing consensus on "the best one currently is this..."


And not to forget, which ones are affordable given the current shortages 
and are (still) available globally.





https://forum.openwrt.org/t/802-11ax-routers/10484/281

Also saw this:

https://10-0-0-0-1.org/reviews/routers/openwrt/

But it only lists AC routers.

Was looking at this:

https://www.amazon.com/TP-Link-WiFi-AX3000-Smart-Router/dp/B07YMFZ28Q/

But it doesn't call out CPU, memory, or storage.  Got there from this page:

https://www.amazon.com/OpenWrt-Routers-Networking-Products/s?k=OpenWrt=n%3A300189

Thanks,

-Philip


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



Bas.

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 19.07] tools/mklibs: Fix compile with GCC 11

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-05-16 23:57, Hauke Mehrtens wrote:

GCC 11 defaults to C++17, but mklibs does not compile when using the
C++17 standard. This patch switches back to the gnu++98 version like
done in master commit 9437012b9ee4 ("tools/mklibs: update to 0.1.44 and
convert to Python 3")

This fixes the following compile error message:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception 
specifications

   52 |   const section _section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };

Signed-off-by: Hauke Mehrtens 
---
 tools/mklibs/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/mklibs/Makefile b/tools/mklibs/Makefile
index 507c2fd394..8826840524 100644
--- a/tools/mklibs/Makefile
+++ b/tools/mklibs/Makefile
@@ -18,6 +18,7 @@ HOST_FIXUP:=autoreconf
 include $(INCLUDE_DIR)/host-build.mk

 HOST_CFLAGS += -I$(CURDIR)/include
+HOST_CPPFLAGS += -std=gnu++98

 define Host/Install
$(INSTALL_BIN) \


Thanks, this probably the best thing to do for 19.07. I overlooked the 
change above in the 9437012b9ee4 commit and assumed the mklibs 0.1.44 
was gnu++17 compliant.


Bas.




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[Q] [master][openwrt-21.02] Check on 'which' in include/prereq-build.mk fails for Fedora 34 since recently, how to fix?

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


tldr;  A recent upgrade of the which package on Fedora 34 broke the test 
in OpenWRT on 'which' being installed on the host. I would love to send 
a patch, but my question is how to fix this? Any ideas welcome!


Regards,

Bas.


I ran into the following:

$ ./scripst/feeds update -a
(...)
Checking 'rsync'... ok.
Checking 'which'... failed.
Checking 'ldconfig-stub'... ok.

Build dependency: Please install 'which'
(...)


$ rpm -qa which
which-2.21-26.fc34.x86_64

I noticed that file /etc/profile.d/which2.sh had changed recently. So I 
downloaded previous version of the package and extracted said file. 
Sourced the old file and ran update again:


$ . ~/Downloads/which2.sh
$ ./scripts/feeds update
(...)
Checking 'rsync'... ok.
Checking 'which'... ok.
Checking 'ldconfig-stub'... ok.
(...)


The relevant part in include/prereq-build.mk is:

$(eval $(call SetupHostCommand,which,Please install 'which', \
which which | grep which))


The difference between the two versions of which2.sh is:

$ diff -u ~/Downloads/which2.sh /etc/profile.d/which2.sh
--- /home/bas/Downloads/which2.sh   2021-03-23 20:22:52.0 +0100
+++ /etc/profile.d/which2.sh2021-05-04 11:52:55.0 +0200
@@ -1,18 +1,19 @@
 # shellcheck shell=sh
 # Initialization script for bash, sh, mksh and ksh

-_declare="declare -f"
-_opt="-f"
-_shell="$(basename $SHELL)"
+which_declare="declare -f"
+which_opt="-f"
+which_shell="$(cat /proc/$$/comm)"

-if [ "$_shell" = "ksh" ] || [ "$_shell" = "mksh" ] || [ "$_shell" = 
"zsh" ] ; then

-  _declare="typeset -f"
-  _opt=""
+if [ "$which_shell" = "ksh" ] || [ "$which_shell" = "mksh" ] || [ 
"$which_shell" = "zsh" ] ; then

+  which_declare="typeset -f"
+  which_opt=""
 fi

 which ()
 {
-(alias; eval ${_declare}) | /usr/bin/which --tty-only --read-alias 
--read-functions --show-tilde --show-dot "$@"
+(alias; eval ${which_declare}) | /usr/bin/which --tty-only --read-alias 
--read-functions --show-tilde --show-dot "$@"

 }

-export ${_opt} which
+export which_declare
+export ${which_opt} which

I don't see why this breaks the check. The difference is mainly in 
renaming the variables used.


As said, any hint welcome!

Regards,

Bas.


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


Hi all,


The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the 
build of host package mklibs fail. See build error below.


Obviously, least intrusive fix is to set the C++ standard to g++14 or 
lower. However, on master the problem is not there due to an upgrade of 
mklibs to version 0.1.44 (among some other changes). This is done in 
commit 9437012b9ee4dc550e42665b71902cf885169100.


Guess we best cherry-pick that commit from master to upgrade mklibs to 
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07 
and the build went fine afterwards.


(build was for TP-Link Archer C7 v5 default config with ccache enabled 
if that matters)


Regards,

Bas.



make[3]: Entering directory '/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include 
 -I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include" 
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include " 
CXXFLAGS="" 
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make 
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'

make  all-recursive
make[5]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'

Making all in lib
make[6]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

Making all in mklibs
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'

Making all in utils
make[8]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'

make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'

make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

Making all in src
make[6]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'

Making all in mklibs-readelf
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../.. 
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include   -g -O2 
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp

In file included from elf_data.hpp:24,
 from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception 
specifications
   52 |   const section _section(unsigned int i) const throw 
(std::out_of_range) { return *sections.at(i); };

  |^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception 
specifications
   62 |   static file *open(const char *filename) throw 
(std::bad_alloc, std::runtime_error);

  |   ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception 
specifications
   65 |   file(uint8_t *mem, size_t len) throw (std::bad_alloc) : 
mem(mem), len(len) { }

  |  ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception 
specifications
   68 | static file *open_class(uint8_t *, size_t) throw 
(std::bad_alloc, std::runtime_error);

  |^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception 
specifications
  131 | std::string get_string(uint32_t offset) const throw 
(std::bad_alloc)

  |   ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception 
specifications

  266 |   std::string get_version() const throw (std::bad_alloc);
  |   ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception 
specifications

  267 |   std::string get_version_file() const throw (std::bad_alloc);
  |^
elf.hpp:269:44: error: 

[FIX proposal] Build error of host mklibs pkg of openwrt-19.07 branch on Fedora 34

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

(resent as previous attempt didn't seem to get through)

Hi all,



The g++ version 11.1.1 of Fedora 34 defaults to g++17 and making the 
build of host package mklibs fail. See build error below.


Obviously, least intrusive fix is to set the C++ standard to g++14 or 
lower. However, on master the problem is not there due to an upgrade of 
mklibs to version 0.1.44 (among some other changes). This is done in 
commit 9437012b9ee4dc550e42665b71902cf885169100.


Guess we best cherry-pick that commit from master to upgrade mklibs to 
0.1.44 as well. This commit was cleanly applied on top of openwrt-19.07 
and the build went fine afterwards.


(build was for TP-Link Archer C7 v5 default config with ccache enabled 
if that matters)


Regards,

Bas.



make[3]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/tools/mklibs'
CFLAGS="-O2 -I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include 
 -I/home/bas/Workspace/openwrt-19.07/tools/mklibs/include" 
CPPFLAGS="-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include " 
CXXFLAGS="" 
LDFLAGS="-L/home/bas/Workspace/openwrt-19.07/staging_dir/host/lib " make 
-j1 -C /home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35
make[4]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'

make  all-recursive
make[5]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35'

Making all in lib
make[6]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

Making all in mklibs
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'

Making all in utils
make[8]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'

make[8]: Nothing to be done for 'all'.
make[8]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs/utils'
make[8]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'

make[8]: Nothing to be done for 'all-am'.
make[8]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib/mklibs'
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

make[7]: Nothing to be done for 'all-am'.
make[7]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'
make[6]: Leaving directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/lib'

Making all in src
make[6]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src'

Making all in mklibs-readelf
make[7]: Entering directory 
'/home/bas/Workspace/openwrt-19.07/build_dir/host/mklibs-0.1.35/src/mklibs-readelf'
ccache g++ -DHAVE_CONFIG_H -I. -I../.. 
-I/home/bas/Workspace/openwrt-19.07/staging_dir/host/include   -g -O2 
-MT elf.o -MD -MP -MF .deps/elf.Tpo -c -o elf.o elf.cpp

In file included from elf_data.hpp:24,
 from elf.cpp:21:
elf.hpp:52:56: error: ISO C++17 does not allow dynamic exception 
specifications
   52 |   const section _section(unsigned int i) const throw 
(std::out_of_range) { return *sections.at(i); };

  |^
elf.hpp:62:47: error: ISO C++17 does not allow dynamic exception 
specifications
   62 |   static file *open(const char *filename) throw 
(std::bad_alloc, std::runtime_error);

  |   ^
elf.hpp:65:38: error: ISO C++17 does not allow dynamic exception 
specifications
   65 |   file(uint8_t *mem, size_t len) throw (std::bad_alloc) : 
mem(mem), len(len) { }

  |  ^
elf.hpp:68:52: error: ISO C++17 does not allow dynamic exception 
specifications
   68 | static file *open_class(uint8_t *, size_t) throw 
(std::bad_alloc, std::runtime_error);

  |^
elf.hpp:131:55: error: ISO C++17 does not allow dynamic exception 
specifications
  131 | std::string get_string(uint32_t offset) const throw 
(std::bad_alloc)

  |   ^
elf.hpp:266:39: error: ISO C++17 does not allow dynamic exception 
specifications

  266 |   std::string get_version() const throw (std::bad_alloc);
  |   ^
elf.hpp:267:44: error: ISO C++17 does not allow dynamic exception 
specifications
  267 |   std::string get_version_file() const throw 
(std::bad_alloc);

  |   

Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


Friendly ping.

Bas.

On 2021-04-29 22:39, Bas Mevissen wrote:

On 4/29/21 11:40 AM, Paul Spooren wrote:


On 4/20/21 1:08 AM, Bas Mevissen wrote:
OpenWRT requires a number of Perl modules to be installed. It wasn't 
checking on all of them.
This patch adds checks for Perl FindBin, File::Copy, File::Compare 
and Thread::Queue modules.


Failing to install these, will have the build break at some point. By 
adding these to the

prereq-build.mk script, they are checked on forehand.

Tested on a Fedora 33 and 34 (beta) that was freshly installed. 
Fedora appears to
break up Perl modules into small packages that need to be installed 
for the build to succeed.


Signed-off-by: Bas Mevissen 
---
  include/prereq-build.mk | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 86c22f7c95..cb3dcc51e3 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \
  Please install the Perl Data::Dumper module, \
  perl -MData::Dumper -e 1))
  +$(eval $(call TestHostCommand,perl-findbin, \
+    Please install the Perl FindBin module, \
+    perl -MFindBin -e 1))
+
+$(eval $(call TestHostCommand,perl-file-copy, \
+    Please install the Perl File::Copy module, \
+    perl -MFile::Copy -e 1))
+
+$(eval $(call TestHostCommand,perl-file-compare, \
+    Please install the Perl File::Compare module, \
+    perl -MFile::Compare -e 1))
Could you please point me to where this module is required? I naively 
grepped through openwrt.git and couldn't find it. The other added 
requirements seem fine.


It is in the host autoconf build. On Fedora 34, against current
master, without the patch to test the need for File::Compare:

$ sudo rpm -e perl-File-Compare

(...)

$ make -j1 V=s

(...)

make[3]: Entering directory 
'/home/bas/Workspace/openwrt-master/tools/autoconf'

export SHELL="bash"; make -C
/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69
make[4]: Entering directory
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69'
make  all-recursive
make[5]: Entering directory
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69'
Making all in bin
make[6]: Entering directory
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin'
autom4te_perllibdir='..'/lib
AUTOM4TE_CFG='../lib/autom4te.cfg' ../bin/autom4te -B '..'/lib
-B '..'/lib --language M4sh --cache '' --melt ./autoconf.as -o
autoconf.in
Can't locate File/Compare.pm in @INC (you may need to install the
File::Compare module) (@INC contains: ../lib
/usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5) at ../lib/Autom4te/FileUtils.pm
line 166.
BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 
166.

Compilation failed in require at ../bin/autom4te line 43.
BEGIN failed--compilation aborted at ../bin/autom4te line 43.
make[6]: *** [Makefile:641: autoconf.in] Error 2

(...)

$ sudo dnf install -y perl-File-Compare

(...)

$ make -j4

(build finishes)



+
  $(eval $(call TestHostCommand,perl-thread-queue, \
  Please install the Perl Thread::Queue module, \
  perl -MThread::Queue -e 1))
  -
  $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \
  gtar --version 2>&1 | grep GNU, \
  gnutar --version 2>&1 | grep GNU, \


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---


On 4/29/21 11:40 AM, Paul Spooren wrote:


On 4/20/21 1:08 AM, Bas Mevissen wrote:
OpenWRT requires a number of Perl modules to be installed. It wasn't 
checking on all of them.
This patch adds checks for Perl FindBin, File::Copy, File::Compare 
and Thread::Queue modules.


Failing to install these, will have the build break at some point. By 
adding these to the

prereq-build.mk script, they are checked on forehand.

Tested on a Fedora 33 and 34 (beta) that was freshly installed. 
Fedora appears to
break up Perl modules into small packages that need to be installed 
for the build to succeed.


Signed-off-by: Bas Mevissen 
---
  include/prereq-build.mk | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 86c22f7c95..cb3dcc51e3 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \
  Please install the Perl Data::Dumper module, \
  perl -MData::Dumper -e 1))
  +$(eval $(call TestHostCommand,perl-findbin, \
+    Please install the Perl FindBin module, \
+    perl -MFindBin -e 1))
+
+$(eval $(call TestHostCommand,perl-file-copy, \
+    Please install the Perl File::Copy module, \
+    perl -MFile::Copy -e 1))
+
+$(eval $(call TestHostCommand,perl-file-compare, \
+    Please install the Perl File::Compare module, \
+    perl -MFile::Compare -e 1))
Could you please point me to where this module is required? I naively 
grepped through openwrt.git and couldn't find it. The other added 
requirements seem fine.


It is in the host autoconf build. On Fedora 34, against current master, 
without the patch to test the need for File::Compare:


$ sudo rpm -e perl-File-Compare

(...)

$ make -j1 V=s

(...)

make[3]: Entering directory 
'/home/bas/Workspace/openwrt-master/tools/autoconf'
export SHELL="bash"; make -C 
/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69
make[4]: Entering directory 
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69'

make  all-recursive
make[5]: Entering directory 
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69'

Making all in bin
make[6]: Entering directory 
'/home/bas/Workspace/openwrt-master/build_dir/host/autoconf-2.69/bin'
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg' 
../bin/autom4te -B '..'/lib -B '..'/lib --language M4sh --cache 
'' --melt ./autoconf.as -o autoconf.in
Can't locate File/Compare.pm in @INC (you may need to install the 
File::Compare module) (@INC contains: ../lib /usr/local/lib64/perl5/5.32 
/usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl 
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at 
../lib/Autom4te/FileUtils.pm line 166.

BEGIN failed--compilation aborted at ../lib/Autom4te/FileUtils.pm line 166.
Compilation failed in require at ../bin/autom4te line 43.
BEGIN failed--compilation aborted at ../bin/autom4te line 43.
make[6]: *** [Makefile:641: autoconf.in] Error 2

(...)

$ sudo dnf install -y perl-File-Compare

(...)

$ make -j4

(build finishes)



+
  $(eval $(call TestHostCommand,perl-thread-queue, \
  Please install the Perl Thread::Queue module, \
  perl -MThread::Queue -e 1))
  -
  $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \
  gtar --version 2>&1 | grep GNU, \
  gnutar --version 2>&1 | grep GNU, \


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] Extend checks on build prerequisites for building OpenWRT core

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



OpenWRT requires a number of Perl modules to be installed. It wasn't checking 
on all of them.
This patch adds checks for Perl FindBin, File::Copy, File::Compare and 
Thread::Queue modules.

Failing to install these, will have the build break at some point. By adding 
these to the
prereq-build.mk script, they are checked on forehand.

Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears 
to
break up Perl modules into small packages that need to be installed for the 
build to succeed.

Signed-off-by: Bas Mevissen 
---
 include/prereq-build.mk | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 86c22f7c95..cb3dcc51e3 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \
Please install the Perl Data::Dumper module, \
perl -MData::Dumper -e 1))
 
+$(eval $(call TestHostCommand,perl-findbin, \

+   Please install the Perl FindBin module, \
+   perl -MFindBin -e 1))
+
+$(eval $(call TestHostCommand,perl-file-copy, \
+   Please install the Perl File::Copy module, \
+   perl -MFile::Copy -e 1))
+
+$(eval $(call TestHostCommand,perl-file-compare, \
+   Please install the Perl File::Compare module, \
+   perl -MFile::Compare -e 1))
+
 $(eval $(call TestHostCommand,perl-thread-queue, \
Please install the Perl Thread::Queue module, \
perl -MThread::Queue -e 1))
 
-

 $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \
gtar --version 2>&1 | grep GNU, \
gnutar --version 2>&1 | grep GNU, \
--
2.31.1





Friendly ping to consider this patch for 21.02.

Thanks,

--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] Extend checks on build prerequisites for building OpenWRT core

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
OpenWRT requires a number of Perl modules to be installed. It wasn't checking 
on all of them.
This patch adds checks for Perl FindBin, File::Copy, File::Compare and 
Thread::Queue modules.

Failing to install these, will have the build break at some point. By adding 
these to the
prereq-build.mk script, they are checked on forehand.

Tested on a Fedora 33 and 34 (beta) that was freshly installed. Fedora appears 
to
break up Perl modules into small packages that need to be installed for the 
build to succeed.

Signed-off-by: Bas Mevissen 
---
 include/prereq-build.mk | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 86c22f7c95..cb3dcc51e3 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -65,11 +65,22 @@ $(eval $(call TestHostCommand,perl-data-dumper, \
Please install the Perl Data::Dumper module, \
perl -MData::Dumper -e 1))
 
+$(eval $(call TestHostCommand,perl-findbin, \
+   Please install the Perl FindBin module, \
+   perl -MFindBin -e 1))
+
+$(eval $(call TestHostCommand,perl-file-copy, \
+   Please install the Perl File::Copy module, \
+   perl -MFile::Copy -e 1))
+
+$(eval $(call TestHostCommand,perl-file-compare, \
+   Please install the Perl File::Compare module, \
+   perl -MFile::Compare -e 1))
+
 $(eval $(call TestHostCommand,perl-thread-queue, \
Please install the Perl Thread::Queue module, \
perl -MThread::Queue -e 1))
 
-
 $(eval $(call SetupHostCommand,tar,Please install GNU 'tar', \
gtar --version 2>&1 | grep GNU, \
gnutar --version 2>&1 | grep GNU, \
-- 
2.31.1


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02-rc1

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---

On 2021-04-07 20:07, John Crispin wrote:

On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote:


Will Wifi 6 support be added to the interface? We have some support 
for a couple of AX routers, so it would be nice if they can work 
without manually tweaking things.


The underlying structure seems to support it already:
https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533


I  have a couple of patches pending that I will post the next few days
that will make the primary HE features work on 21.02. I converged my
home to 3xe8450



Good to hear. I've an X5000R waiting to be converted to OpenWRT. The 
E8450 or RT3200 would have been a better choice, but at the time I 
wanted to order a supported AX router, it was only the X5000R or the 
UniFi 6 Lite to choose from.


The X5000R unfortunately cannot max out the Killer Wifi card in my 
notebook, but it still makes around 800Mbit/s with iperf3 though.



Bas.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02-rc1

[Bas Mevissen via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



On 4/7/21 12:29 AM, Hauke Mehrtens wrote:

Hi,

How do we want to go forward with OpenWrt 21.02-rc1?

* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged 
into master some time ago as far as I understood.


Jow reported this end of March:
 > I found some serious regressions in the luci device config support.
 > not sure yet how long it'll take to sort out. The netifd uci config
 > grew so complex that it'll take a while to try all cases
 > * changing interface settings after previously enabling certain
 >   options results in a brick
 > * wireless networks with custom ifnames are improperly bridged
 > * option ipv6 for ppp based protocols is broken because it clashes
 >   with option ipv6 in device sections

I would like to merge this update of iproute2 if Russel is fine with it, 
but I do not see this blocking 21.02-rc1:

https://github.com/openwrt/openwrt/pull/4025

If there are some other bugs in the 21.02 branch which are fixed in 
master, we can backport the fixed as long as they are not so big. If 
there is something missing, just ask on the mainling list.


In would like to get 21.02-rc1 soon, so more users start testing it and 
we get more bug reports.


How should we continue?
1. Tag 21.02-rc1 and do the release in the next days with the current
    state.

2. Merge the LuCI DSA changes from master to 21.02 branch now and do
    21.02-rc1 ~3 days to see if some big problems come up.



Will Wifi 6 support be added to the interface? We have some support for 
a couple of AX routers, so it would be nice if they can work without 
manually tweaking things.


The underlying structure seems to support it already:
https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533



3. Wait till the problems reported by jow are fixed and do the 21.02-rc1
    them.

4. Wait an other 2 weeks and see how it looks them.


I would prefer if we merge the LuCI DSA changes from master to 21.02 
branch now and do 21.02-rc1 soon. We should list the problems as known 
problems.


It would be nice if someone else could also look into these problems and 
propose fixes.


Hauke

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: add support for TOTOLINK X5000R

[Bas Mevissen]

Hi,


On 3/13/21 3:21 AM, Chuanhong Guo wrote:

Hi!

On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen  wrote:


Hi,

Thanks for creating this patch. Got my X5000R today. Before flashing it
to OpenWRT, can you please tell me whether you (or anyone else) did
performance measurements with the original and the OpenWRT firmware?


The wifi chip used in this router wasn't supported by mt76 when I created
this patch, so my X5000R has no wifi now and I don't have any
wireless performance numbers.
My X5000R has been sitting on the shelf since I posted this patch, and
I don't even know whether the mt7915d used in this router is supported
now or not. You should probably ask TOTOLINK for a copy of the original
firmware image before trying OpenWrt, so that you can go back to the
original firmware if needed. (A forced sysupgrade from OpenWrt using
their firmware image should work.)



Thanks for the detailed explanation!

As probably no one tried reverting to the stock firmware, I'm a bit 
reluctant to do so. Although I intended this router as a playground, I 
now consider using it as AP for a while. As my TP-Link Archer C7's wifi 
isn't performing that well with OpenWRT as I hoped, I want the X5000R to 
take its place with the factory firmware until that gets sorted out.
I might even end up buying another X5000R if the Archer cannot be 
faster, but it takes 6 weeks for the Totolink to arrive.


So would you be so kind to flash your X5000R with a recent build and 
check whether the wifi performs well? It would help me a lot. I can 
supply you with a build if that helps.



Many thanks in advance,

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ramips: add support for TOTOLINK X5000R

[Bas Mevissen]

Hi,

Thanks for creating this patch. Got my X5000R today. Before flashing it 
to OpenWRT, can you please tell me whether you (or anyone else) did 
performance measurements with the original and the OpenWRT firmware?


I measured over 600mbit/s with WPA3 when on my desk, next to a notebook 
with Intel WiFi6 AX200 card. So I hope I can keep that performance when 
on OpenWRT.


(measured with iperf3, tcp default settings, from wireless 5GHz to PC 
wired to WAN in both directions)


Many thanks in advance,

Bas.


On 10/21/20 7:21 AM, Chuanhong Guo wrote:

Specifications:
- SoC: MT7621AT
- RAM: 256MB
- Flash: 16MB (EN25QH128A)
- Ethernet: 5xGbE
- WiFi: MT7915 2x2 2.4G 573.5Mbps + 2x2 5G 1201Mbps

Known issue:
MT7915 DBDC variant isn't supported yet.

Flash instruction:
Upload the sysupgrade firmware to the firmware upgrade page in
vendor fw.

Other info:
MT7915 seems to have two PCIEs connected to MT7621. Card detected on
PCIE0 has an ID of 14c3:7916 and the other one on PCIE1 has 14c3:7915.

Signed-off-by: Chuanhong Guo 
---
  .../ramips/dts/mt7621_totolink_x5000r.dts | 139 ++
  target/linux/ramips/image/mt7621.mk   |  10 ++
  2 files changed, 149 insertions(+)
  create mode 100644 target/linux/ramips/dts/mt7621_totolink_x5000r.dts

diff --git a/target/linux/ramips/dts/mt7621_totolink_x5000r.dts 
b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
new file mode 100644
index 00..b05d83978d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "totolink,x5000r", "mediatek,mt7621-soc";
+   model = "TOTOLINK X5000R";
+
+   aliases {
+   led-boot = _sys;
+   led-failsafe = _sys;
+   led-running = _sys;
+   led-upgrade = _sys;
+   label-mac-device = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   bootargs = "console=ttyS0,115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_sys: sys {
+   label = "blue:sys";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+   label = "reset";
+   gpios = < 4 GPIO_ACTIVE_LOW>;
+   debounce-interval = <60>;
+   linux,code = ;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+   m25p,fast-read;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   compatible = "denx,uimage";
+   label = "firmware";
+   reg = <0x5 0xfb>;
+   };
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   wifi@0,0 {
+   compatible = "mediatek,mt76";
+   reg = <0x 0 0 0 0>;
+   mediatek,mtd-eeprom = < 0x>;
+   };
+};
+
+ {
+   mtd-mac-address = < 0xe000>;
+};
+
+ {
+   ports {
+   port@0 {
+   status = "okay";
+   label = "lan1";
+   };
+
+   port@1 {
+   status = "okay";
+   label = "lan2";
+   };
+
+   port@2 {
+   status = "okay";
+   label = "lan3";
+   };
+
+   port@3 {
+   status = "okay";
+   label = "lan4";
+   };
+
+   port@4 {
+   status = "okay";
+   label = "wan";
+   mtd-mac-address = < 0xe006>;
+   };
+   };
+};
+
+_default {
+   gpio {
+   groups = 

Re: Quilt and cutting down diff position lines

[Bas Mevissen]

On 2021-02-24 15:36, Adrian Schmutzler wrote:

-Original Message-
From: Adrian Schmutzler [mailto:m...@adrianschmutzler.de]
Sent: Mittwoch, 24. Februar 2021 11:50
To: 'openwrt-devel@lists.openwrt.org' 


Subject: Quilt and cutting down diff position lines

Hi,

as most are probably aware, quilt cuts down the position lines in 
patches

during refresh:

- @@ -78,7 +78,8 @@ void machine_apply_elf_rel(struct mem_ehdr
*UNUSED(ehdr),
+ @@ -78,7 +78,8 @@ void machine_apply_elf_rel(struct mem_eh

While this has no functional impact, it creates a lot of additional 
spam

during
checkpatch.pl, and it makes these lines less useful for the frequent 
cases
where the relevant (meaning "specific") information is at the end of 
that

line
(i.e. when looking at patches directly). Apart from that, this also 
bloats

diffs in
packages when people add proper patches, and quilt will then just cut 
down

these lines without a change in position.

I wonder whether quilt can be convinced to not cut this line (did not 
find

any

helpful guidance so far), and whether one wants to change that if it's
possible?


Well, after a lengthy quest into the world of quilt, I found that this 
is

actually a diff "bug", since diff hardcodes the context function to 40
characters max:

https://git.savannah.gnu.org/cgit/diffutils.git/tree/src/context.c#n156

And since this is a prerequisite the user installs on the host, we 
cannot do

much about it either, as it appears.



Openwrt could provide a host build for a patched version of diff and use 
that instead.





Best

Adrian





___
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

Host dependencies and checking them

[Bas Mevissen]

Hi all,


When starting a clean build (21.02 branch) on a clean Fedora 33 machine, 
I ran into the small issue of tools/autoconf failing to build. This was 
due to perl-File-Compare missing. I apparently missed that prerequisite. 
After installing said package, everything built fine.


Looking at the instructions at 
https://openwrt.org/docs/guide-developer/build-system/install-buildsystem#prerequisites, 
listing all prerequisites, I at first did not find perl-File-Compare. It 
was only at the distribution specific instructions for CentOS/Fedora 
that it was mentioned.


The main list does specifically mention perl-ExtUtils-MakeMaker and 
perl-Thread-Queue, so I wonder whether perl-File-Compare should be added 
there as well?


Another question regarding prerequisites: is python2 still a requirement 
for master and openwrt-21.02?


Anyway, it made me wonder whether the prerequisites list and test for at 
least the core should be revised. I took a look at the current list and 
compared them to include/prereq-build.mk from current (2021-02-20) 
openwrt-21.02 branch:


PREREQ  prereq-build.mk needed  result
==
asciidocno  no? Q
bashyes yes OK
binutilsno  yes ADD
bzip2   yes yes OK
flexno  hostbuild -> no  REMOVE
git yes yes OK
g++ yes (no IB) yes OK
gcc yes (no IB) yes OK
timeno  no? Q
getopt  yes yes OK
gawkyes yes OK
help2manno  no? Q
intltool-update no  no? Q
libelf-dev  no  yes ADD
libz-devno  yes ADD
makeyes yes OK
ncurses yes yes OK
openssl no  util?   Q
patch   yes yes OK
perl ExtUtils-
  MakeMaker no  ?   Q
perl Thread-
  Queue yes ?   Q
python2-dev no  no >19.07?   Q
unzip   yes yes OK
wgetyes yes OK
xgettextno  yes ADD
xsltprocno  no  REMOVE
zlibno  yes ADD


The file prereq-build.mk does check for a number of other utilities that 
are not in the list or only in the distribution specific requirements:


Perl Data::Dumper
tar
find
xargs
seq
grep
stat
perl (5.x)
python (>=3.5)
file
rsync

Looking at the distro specific instructions, I noticed a variation in 
the advised mandatoty and optional packages to install per distro.

For example, some install asciidoc, other ccache and so on.

I would like to help cleaning this up, both the code and the 
documentation. What I need is input on what are mandatory and what are 
optional prerequisites (and a login to the wiki).


Regards,

Bas.




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Hostapd throwing warnings

[Bas Mevissen]

On 2020-10-15 19:45, Philip Prindeville wrote:
On Oct 15, 2020, at 11:32 AM, Daniel Golle  
wrote:


On Thu, Oct 15, 2020 at 11:18:24AM -0600, Philip Prindeville wrote:

Hi,

I have a WLE600VX card in an APU4 running HEAD as of a week ago.

My /etc/config/wireless file is straightforward:

config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'pci:00/:00:02.5/:05:00.0'
option htmode 'VHT80'
option disabled '0'

config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option hidden '1'
option ssid ‘xyzzy'
option encryption 'psk2+aes'
option key ‘my-passphrase-here’

But I’m seeing the following warnings:

Oct 14 18:29:23 OpenWrt2 hostapd: Configuration file: 
/var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Oct 14 18:29:23 OpenWrt2 hostapd: Line 16: unknown configuration item 
'ieee80211ac'
Oct 14 18:29:23 OpenWrt2 hostapd: Line 17: unknown configuration item 
'vht_oper_chwidth'
Oct 14 18:29:23 OpenWrt2 hostapd: Line 18: unknown configuration item 
'vht_oper_centr_freq_seg0_idx'
Oct 14 18:29:23 OpenWrt2 hostapd: Line 19: unknown configuration item 
'vht_capab'
Oct 14 18:29:23 OpenWrt2 hostapd: 4 errors found in configuration 
file '/var/run/hostapd-phy0.conf'
Oct 14 18:29:23 OpenWrt2 hostapd: Failed to set up interface with 
/var/run/hostapd-phy0.conf
Oct 14 18:29:23 OpenWrt2 netifd: radio0 (4034): Command failed: 
Invalid argument



On booting.

If I comment out these lines being generated in 
/lib/netifd/wireless/mac80211.sh then WiFi works.


Is anyone else seeing this?

I’m using:

CONFIG_PACKAGE_ath10k-firmware-qca988x-ct-full-htt=y
CONFIG_PACKAGE_wireless-regdb=y
CONFIG_PACKAGE_kmod-ath=y
CONFIG_ATH_USER_REGD=y
CONFIG_PACKAGE_ATH_DFS=y
CONFIG_PACKAGE_kmod-ath10k-ct=y
CONFIG_ATH10K-CT_LEDS=y
CONFIG_PACKAGE_kmod-cfg80211=y
CONFIG_PACKAGE_kmod-mac80211=y
CONFIG_PACKAGE_MAC80211_DEBUGFS=y
CONFIG_PACKAGE_MAC80211_MESH=y
CONFIG_PACKAGE_hostapd-common=y
CONFIG_PACKAGE_hostapd-openssl=y
CONFIG_PACKAGE_hostapd-utils=y
CONFIG_DRIVER_11N_SUPPORT=y
CONFIG_DRIVER_11AC_SUPPORT=y
CONFIG_DRIVER_11W_SUPPORT=y
CONFIG_PACKAGE_iw=y

Am I doing anything wrong?

Oh, also, in /etc/config/network, do I need to explicitly add wlan0 
to my bridge for “lan” or does that happen automatically?


Looks like CONFIG_DRIVER_11AC_SUPPORT=y isn't really set in the end,
usually it should be auto-selected based on the driver you are using,
ie. kmod-ath10k in your case. Those CONFIG_DRVIVER_* symbols are not
meant to be selected manually.
Are you using an out-of-tree WiFi driver or any changes like that?



I commented out CONFIG_DRIVER_* and reran “make defconfig oldconfig”
and those 3 got turned back on.

Is there something else I should be doing?



You might check whether the text strings of the configuration options 
mentioned in the logs are present in the binaries in the rootfs and 
object files in the build folder (assuming they are literally present in 
the source code). Additionally, add some #error statements in a few 
places in code that only gets compiled when CONFIG_DRIVER_11AC_SUPPORT 
is defined to check whether that define is effectively set at compile 
time.


It is a very basic way of debugging source code configuration, but at 
least it gives you certainty about how the code is actually compiled.




And no, not an out-of-tree build… unless it’s using backports and
that’s considered out-of-tree?

-Philip


___
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

Re: ipq806x: add support for TP-Link Talon AD7200

[Bas Mevissen]

On 2020-10-12 12:46, Daniel Golle wrote:

On Mon, Oct 12, 2020 at 11:59:17AM +0200, Bas Mevissen wrote:

On 2020-10-12 11:40, Bjørn Mork wrote:
> Bas Mevissen  writes:
>
> > Nice work, but does it make sense to add a device that is already
> > EOL'ed by the manufacturer? I guess the installed base is also rather
> > small.
>
> Definitely!
>
> IMHO, it should me enough that there is one user with enough interest to
> actually do the work, submit it and - hopefully - maintain it for a
> while.
>

The latter, maintenance, is my biggest question mark. Technically 
keeping
the sources compile is the smallest task. You need someone to actually 
use
recent builds all the time and preferably in multiple use cases to 
catch
regressions. Otherwise, it might give a false impression that the 
device is

supported and working.

> In addition,
>  - each supported device serves as a template and example for
>similar devices, simplifying support for other products.

It is not really an unique product. It looks like it was (just) 
created to

be a showcase at CES2016.


To me it makes sense to support this device because it's easier to do
than MikroTik or ubnt devices with 802.11ad which have their special
quirks for EEPROM extraction and such (but yet those are very
interesting targets imho!). Starting with a TP-Link device which more
or less implements a plain reference design is a very good start for
802.11ad in Openwrt.



OK, good point. I'll buy a few when the price drops :-)
Obviously, my concern about maintenance remains when there is support 
for a more popular equivalent device.






>  - OpenWrt support is good for the environment by increasing the usable
>lifetime of a device

True in itself. I have a very old TP-Link TL1043ND V1.x running (for 
which
support will be removed soon because it gets very difficult to keep 
them

going with current software sizes).

>  - you can still buy this device new, despite the EoL announcement
>

But should you? I would be very reluctant with buying EOL devices,
especially when being a "first" and with the price still up.

I think that OpenWRT should be careful not to spend resources on 
devices

that have no large install base nor any chance of getting it. In that
respect, I would prefer to prioritize on low RAM / low flash devices 
instead
as they are everywhere and mostly running outdated insecure software. 
With

things like ZRAM and an external flash drive, there life span could be
meaningfully extended.

>
> Bjørn

Bas.

___
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

Re: ipq806x: add support for TP-Link Talon AD7200

[Bas Mevissen]

On 2020-10-12 11:40, Bjørn Mork wrote:

Bas Mevissen  writes:


Nice work, but does it make sense to add a device that is already
EOL'ed by the manufacturer? I guess the installed base is also rather
small.


Definitely!

IMHO, it should me enough that there is one user with enough interest 
to

actually do the work, submit it and - hopefully - maintain it for a
while.



The latter, maintenance, is my biggest question mark. Technically 
keeping the sources compile is the smallest task. You need someone to 
actually use recent builds all the time and preferably in multiple use 
cases to catch regressions. Otherwise, it might give a false impression 
that the device is supported and working.



In addition,
 - each supported device serves as a template and example for
   similar devices, simplifying support for other products.


It is not really an unique product. It looks like it was (just) created 
to be a showcase at CES2016.



 - OpenWrt support is good for the environment by increasing the usable
   lifetime of a device


True in itself. I have a very old TP-Link TL1043ND V1.x running (for 
which support will be removed soon because it gets very difficult to 
keep them going with current software sizes).



 - you can still buy this device new, despite the EoL announcement



But should you? I would be very reluctant with buying EOL devices, 
especially when being a "first" and with the price still up.


I think that OpenWRT should be careful not to spend resources on devices 
that have no large install base nor any chance of getting it. In that 
respect, I would prefer to prioritize on low RAM / low flash devices 
instead as they are everywhere and mostly running outdated insecure 
software. With things like ZRAM and an external flash drive, there life 
span could be meaningfully extended.




Bjørn


Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: ipq806x: add support for TP-Link Talon AD7200

[Bas Mevissen]

On 2020-10-12 01:09, Paul Fertser wrote:

From: Gary Cooper 

Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon)

The Talon AD7200 is basically an Archer C2600 with larger flash, a
third PCIe lane and an 802.11ad radio. It comes in a different housing
reminiscent of the Archers C3200 and C5400.


Specifications
--

  - IPQ8064 dual-core 1400MHz
  - QCA9988 2.4GHz WiFi
  - QCA9888 5GHz WiFi
  - QCA9500 60GHz WiFi
  - 256MiB SPI Flash
  - 512MiB RAM
  - 5 GBit Ports (QCA8337)

Installation


Installation is possible from the OEM web interface.
Sysupgrade is possible.
TFTP recovery is possible.
  - Image: AD7200_1.0_tp_recovery.bin

Notes
  - This will be the first 802.11ad device supported by mainline.

Signed-off-by: Gary Cooper 


Nice work, but does it make sense to add a device that is already EOL'ed 
by the manufacturer? I guess the installed base is also rather small.


Reagrds,

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: A proposal of https certificate assignment system for luci

[Bas Mevissen]

On 2020-10-11 00:58, Michael Richardson wrote:

Bas Mevissen  wrote:
> A security conscious user/administrator would install a router 
without any

> untrusted computers connected to the LAN side and setup the
device properly
> before allowing others to connect. The WAN side connection is
not important,
> as Luci is not listening there by default.

sure.
What do security unconcious people do?

Just put it in use with the build-in defaults. It is not without reason 
that ISP routers nowadays come with a semi-unique SSID and securely 
generated wifi passwords. With OpenWRT we should aim to get the best 
possible security with the least effort (on user side) possible.
ISP routers usually only support HTTP or HTTPS with a self-signed bogus 
certificate for the admin interface.



> previous OpenWRT install. Then the user can setup the WAN side
if needed and
> upload (from local PC), generate (self-signed) or acquire (e.g. 
Let's

> Encrypt) the certificates for Luci. After that, the connection
is switched to
> HTTPS and HTTP switched off.

This is a a good story, but it doesn't have to be the only story.


It is the story where we can give the best out-of-the-box guidance and 
hopefully cover most installs.




> The only issue I see, is how to transfer admin, WAN and WiFi 
passwords at

> first boot in a secure way. Even though the user/admin should be
alone on the
> connection, sending those unencrypted over the line is not
desirable. Maybe
> those can be encrypted using client side javascript.

There is nothing you can with javascript here that wouldn't just be
security threatre.  If you had anchors you could trust, then it would 
be done.


The trust comes from being the only one connected to the specific box. 
If that is not guaranteed, it is very hard to impossible to be 100% 
sure. It at least requires a specific certificate being installed on a 
specific box. If you are on that level, you don't need the guided 
certificate install anyway. With my proposal and the requirement of 
being the only one on the network, you get pretty close to that level.




> The challenges IMHO are being able to safely retain previously 
installed

> certificates over OpenWRT reflashes/upgrades and having user
friendly tools
> to get new certificates uploaded, generated or acquired. For the
latter part,
> some configurable service to periodically download and install
certificates
> from an external host might be desirable (that's how I do it with 
my NAS

> boxes at home).

You need a name is DNS, then it's just a dns-01 challenge.


I believe the most common being an HTTP-01 challenge (see 
https://letsencrypt.org/docs/challenge-types/). So you need a DNS entry 
pointing to your (dynamic?) IP and a HTTP server under OpenWRT control 
running on port 80 or 443. That is not always practicable for home 
internet connections.


I found it to be much more practicable to have the certificate generated 
and renewed on an external host (with the FQDN of my NAS boxes pointing 
to that host in public DNS) and download the certificate files at 
regular intervals. Inside my network, the name of the NAS is resolved to 
its local IP address.


Anyway, the options to upload, generate or acquire will probably cover 
the most common cases and are not hard to implement.


Regards,

Bas.



--
]   Never tell me the odds! | ipv6 mesh 
networks [
]   Michael Richardson, Sandelman Software Works|IoT 
architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on 
rails[



___
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

Re: A proposal of https certificate assignment system for luci

[Bas Mevissen]

On 2020-10-09 14:33, abnoeh wrote:

20. 10. 9. 오후 8:29에 Bas Mevissen 이(가) 쓴 글:

So I think it is reasonably safe to do the initial setup over HTTP
(without the "S") at the first boot if there are no certificates
available from a previous OpenWRT install. Then the user can setup the
WAN side if needed and upload (from local PC), generate (self-signed)
or acquire (e.g. Let's Encrypt) the certificates for Luci. After that,
the connection is switched to HTTPS and HTTP switched off.

The only issue I see, is how to transfer admin, WAN and WiFi passwords
at first boot in a secure way. Even though the user/admin should be
alone on the connection, sending those unencrypted over the line is
not desirable. Maybe those can be encrypted using client side 
javascript.



For things with USB port, firstboot loader script from load ssh
autorized key/root password from usb drive and/or export script they
when there is '.whoareyou' file touched in usb drive write it's ssh 
host

key and it's self signed certificate into the usb drive? I think later
can be part of hotplug.d script.


Nice idea to be able to auto-load the config including key material. 
Might be very useful for larger installs.



The challenges IMHO are being able to safely retain previously
installed certificates over OpenWRT reflashes/upgrades and having user
friendly tools to get new certificates uploaded, generated or
acquired. For the latter part, some configurable service to
periodically download and install certificates from an external host
might be desirable (that's how I do it with my NAS boxes at home).




for sysupgrade, like save config option, add new save-keys option that
only save dropbear key and uhttpd certs?




Nice idea to save SSH server keys as well. That will avoid warnings when 
connecting to the new box (at the same IP) for the first time.
Obviously, one needs to be careful with plain text private keys and 
certs.


Cheers,

Bas.


___
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



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Fate of kernel 4.19

[Bas Mevissen]

On 2020-10-09 14:19, Adrian Schmutzler wrote:

Hi all,

in master, we currently support kernels 5.4 and 4.19.

All targets build with 5.4 by default,


In other words: 4.19 is no longer required.


so 4.19 is just there and can
theoretically be used for regression testing


In that case, one can retrieve the 4.19 files from just before the 
removal.



(if it still works).


Another argument for removal.


However, since our last release used 4.14, 4.19 effectively is just an
interim step that has never been "released".



So most likely, regressions can be tested against the maintained 4.14 
with the userspace from master as well.



Initially, my plan was to propose removing 4.19 during the RC stage of
the next release.

As the main effect of 4.19 at the moment seems to be that it's
complicating patches/changes, though, I wonder whether that option to
do regression testing is actually used by anyone, or whether it's just
a theoretical thing that's completely superfluous, as nobody will do
it anyway.

Based on the response here, one might remove 4.19 even earlier then if
nobody actually needs it anymore.

Opinions? Is anybody still using 4.19 at least occasionally?



I think the only time to support 2 kernel versions in master is when in 
transition with the targets.
Obviously, it would have been nice when 4.19 was actually used in a 
release. Now it looks like it was wasted effort.
Maybe that is a lesson for the future to only put effort in kernels that 
will be part of a maintained release.



Best

Adrian



Regards,

Bas.




___
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

Re: A proposal of https certificate assignment system for luci

[Bas Mevissen]

On 2020-10-04 15:48, abnoeh wrote:

Few months ago there was some debate for how we handle certificate for
luci page: make user to click though certificate warning is not that
great for security so here is a  proposal for autometically assign a
worldwide unique subdomain and how to make valid certificate for it, 
and

make sure we and connect to the device he is expecting.



After reading the previous debate (in part) and this one, I'm 
wonderering whether we aren't making things more difficult than they 
need to be.


A security conscious user/administrator would install a router without 
any untrusted computers connected to the LAN side and setup the device 
properly before allowing others to connect. The WAN side connection is 
not important, as Luci is not listening there by default.


So I think it is reasonably safe to do the initial setup over HTTP 
(without the "S") at the first boot if there are no certificates 
available from a previous OpenWRT install. Then the user can setup the 
WAN side if needed and upload (from local PC), generate (self-signed) or 
acquire (e.g. Let's Encrypt) the certificates for Luci. After that, the 
connection is switched to HTTPS and HTTP switched off.


The only issue I see, is how to transfer admin, WAN and WiFi passwords 
at first boot in a secure way. Even though the user/admin should be 
alone on the connection, sending those unencrypted over the line is not 
desirable. Maybe those can be encrypted using client side javascript.


The challenges IMHO are being able to safely retain previously installed 
certificates over OpenWRT reflashes/upgrades and having user friendly 
tools to get new certificates uploaded, generated or acquired. For the 
latter part, some configurable service to periodically download and 
install certificates from an external host might be desirable (that's 
how I do it with my NAS boxes at home).


Cheers,

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Transform OpenWRT to a Yocto / openembedded layer

[Bas Mevissen]

On 2020-07-30 11:15, m...@adrianschmutzler.de wrote:

-Original Message-
From: Bas Mevissen [mailto:ab...@basmevissen.nl]
Sent: Donnerstag, 30. Juli 2020 10:54
To: Thomas Petazzoni 
Cc: m...@adrianschmutzler.de; openwrt-devel@lists.openwrt.org
Subject: Transform OpenWRT to a Yocto / openembedded layer (was: Re:
dm-verity support)



(...)



Isn't there some deferred or other state that better expresses the 
actual

situation?


For me, "deferred" means essentially "we don't do it now, but we will
do it later".

However, there is no indication that the situation will be different
in a year or two. So I chose "rejected", as a waiting time of 8 months
without any response indicate that the feature is not wanted.

As Thomas stated himself, this surely is "unfortunate", but I'm just
putting into effect what's obvious here.



Yes, you probably did the best thing that can be done in this situation: 
bring it to some kind of closure and inform the submitter of the reason. 
With the latter being properly done, the actual working of the closure 
is less relevant.


Regards,

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Errors running make xconfig

[Bas Mevissen]

Hi all,

I'm trying to configure my openwrt project with xconfig. This fails with 
the errors pasted to https://pastebin.com/LJvsAhab (too long to add, 
summary below).


System is Mint 9.2 (Ubuntu Bionic based) with relevant Qt5 stuff 
installed, including libqt5* (I installed all of them...) and qtbase5-dev.


I used OpenWrt latest master, head of openwrt_19.07 branch and v18.06.4 
with the same result. I tried to figure out whether the configuration 
did function as designed:


(from scripts/config/Makefile)

$ pkg-config --exists Qt5Core && echo Ok
Ok

$ pkg-config --cflags Qt5Core Qt5Gui Qt5Widgets
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/include/x86_64-linux-gnu/qt5


$ pkg-config --libs Qt5Core Qt5Gui Qt5Widgets
-lQt5Widgets -lQt5Gui -lQt5Core

$ pkg-config --variable=host_bins Qt5Core
/usr/lib/qt5/bin

So it selects Qt5 and finds the required stuff:

$ cat scripts/config/.tmp_qtcheck
KC_QT_CFLAGS=-std=c++11 -fPIC 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/include/x86_64-linux-gnu/qt5

KC_QT_LIBS=-lQt5Widgets -lQt5Gui -lQt5Core
KC_QT_MOC=/usr/lib/qt5/bin/moc

$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


So it seems the configuration goes fine and everything should be available.

Shortened version of the error:

make[1]: Entering directory 
'/home/bas/Workspace/playground/openwrt/scripts/config'

  CHECK   qt
qconf.o: In function `ConfigList::metaObject() const':
qconf.cc:(.text+0x3ed): undefined reference to 
`QObjectData::dynamicMetaObject() const'

qconf.o: In function `ConfigList::qt_metacast(char const*)':
qconf.cc:(.text+0x446): undefined reference to 
`QTreeWidget::qt_metacast(char const*)'
qconf.o: In function `ConfigList::qt_metacall(QMetaObject::Call, int, 
void**)':
qconf.cc:(.text+0x474): undefined reference to 
`QTreeWidget::qt_metacall(QMetaObject::Call, int, void**)'

qconf.o: In function `ConfigList::menuChanged(menu*)':
qconf.cc:(.text+0x522): undefined reference to 
`QMetaObject::activate(QObject*, QMetaObject const*, int, void**)'

qconf.o: In function `ConfigList::menuSelected(menu*)':
qconf.cc:(.text+0x590): undefined reference to 
`QMetaObject::activate(QObject*, QMetaObject const*, int, void**)'

qconf.o: In function `ConfigList::parentSelected()':
qconf.cc:(.text+0x5d1): undefined reference to 
`QMetaObject::activate(QObject*, QMetaObject const*, int, void**)'

qconf.o: In function `ConfigList::gotFocus(menu*)':
qconf.cc:(.text+0x62a): undefined reference to 
`QMetaObject::activate(QObject*, QMetaObject const*, int, void**)'

qconf.o: In function `ConfigLineEdit::metaObject() const':
qconf.cc:(.text+0x695): undefined reference to 
`QObjectData::dynamicMetaObject() const'

qconf.o: In function `ConfigLineEdit::qt_metacast(char const*)':
qconf.cc:(.text+0x6ee): undefined reference to 
`QLineEdit::qt_metacast(char const*)'
qconf.o: In function `ConfigLineEdit::qt_metacall(QMetaObject::Call, 
int, void**)':
qconf.cc:(.text+0x71c): undefined reference to 
`QLineEdit::qt_metacall(QMetaObject::Call, int, void**)'

qconf.o: In function `ConfigView::metaObject() const':
qconf.cc:(.text+0x9f7): undefined reference to 
`QObjectData::dynamicMetaObject() const'

qconf.o: In function `ConfigView::qt_metacast(char const*)':
qconf.cc:(.text+0xa50): undefined reference to 
`QWidget::qt_metacast(char const*)'

(...)
qconf.o: In function `ConfigList::~ConfigList()':
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x42): 
undefined reference to `QPalette::~QPalette()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x54): 
undefined reference to `QPalette::~QPalette()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x66): 
undefined reference to `QPixmap::~QPixmap()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x78): 
undefined reference to `QPixmap::~QPixmap()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x8a): 
undefined reference to `QPixmap::~QPixmap()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0x9c): 
undefined reference to `QPixmap::~QPixmap()'
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xae): 
undefined reference to `QPixmap::~QPixmap()'
qconf.o:qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xc0): 
more undefined references to `QPixmap::~QPixmap()' follow

qconf.o: In function `ConfigList::~ConfigList()':
qconf.cc:(.text._ZN10ConfigListD2Ev[_ZN10ConfigListD5Ev]+0xfc): 
undefined reference to `QTreeWidget::~QTreeWidget()'

Re: [OpenWrt-Devel] [PATCH lede-17.01 2/4] mbedtls: Activate the session cache

[Bas Mevissen]

On 02/06/18 18:10, Hauke Mehrtens wrote:

This make sit possible to store informations about a session and reuse
it later. When used by a server it increases the time to create a new
TLS session from about 1 second to less than 0.1 seconds.



...it *decreases* the time to...


The size of the ipkg file increased by about 800 Bytes.

Signed-off-by: Hauke Mehrtens 
---
  package/libs/mbedtls/patches/200-config.patch | 10 --
  1 file changed, 10 deletions(-)

diff --git a/package/libs/mbedtls/patches/200-config.patch 
b/package/libs/mbedtls/patches/200-config.patch
index ff5d29a066..538a6d1087 100644
--- a/package/libs/mbedtls/patches/200-config.patch
+++ b/package/libs/mbedtls/patches/200-config.patch
@@ -219,16 +219,6 @@
   
   /**

* \def MBEDTLS_RSA_C
-@@ -2446,8 +2446,8 @@
-  * Caller:
-  *
-  * Requires: MBEDTLS_SSL_CACHE_C
-- */
- #define MBEDTLS_SSL_CACHE_C
-+ */
-
- /**
-  * \def MBEDTLS_SSL_COOKIE_C
  @@ -2468,8 +2468,8 @@
* Caller:
*




--
Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Moving the mailing lists

[Bas Mevissen]

On 23/05/18 17:55, Arjen de Korte wrote:

Citeren Torbjörn Jansson :


 (...)


But one thing that is a little anoying after the move is that for some 
mails I get same thing twice and I'm not sure why.


Most likely because people are still cross-posting to lede-dev and 
openwrt-devel (like you just did). Being the same list now, this means 
you'll get the same thing twice.




I would suggest closing the lede-devel mailing list with a bounce to use 
openwrt-devel instead. Or have a filter that removes the duplicates as 
it is really annoying.


--
Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Boot Time Reduction

[Bas Mevissen]

On 12/04/18 06:26, Arjav Parikh wrote:

Hi,
> (...)


Now as mentioned in previous mail only 
at that two locations I see some process consuming lot of time.

Is it possible to reduce the time consumed by the process?




Isn't the long time between pre-init and ubi mount due to the lengthy 
block scan that the ubi layer performs? In that case, switching to 
squashfs with optionally an overlay might reduce the mount time.


--
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWrt Summit CFP

[Bas Mevissen]

On 03/10/2017 02:21, Valent Turkovic wrote:

Why is http://www.openwrtsummit.org/ down for over 24h?



Site looks fine for me.

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl

[Bas Mevissen]

On 09/29/2014 04:32 PM, thomas.lan...@lantiq.com wrote:
 Hello Bas,
 

Hi Thomas,


 (...)
 
 My goal was to have the build dependencies reduced for the case no ssl  is 
 enabled.
 And that was fixed now with the help of Felix.
 It was never an issue that the libraries were included to the image.
 

Well, including unused libraries is a waste of space and might be
against the wish of the image creator. Also, it can be an unwanted
export of crypto software too. That problem did not go away after the US
changed the rules years ago.

Cheers,

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl

[Bas Mevissen]

On 09/30/2014 03:22 PM, Felix Fietkau wrote:

 I'll repeat the point for clarity: There is no inclusion of unused
 libraries going on here - at least not in the image or package repositories.
 
 uhttpd always needs the header of ustream-ssl, but it does not link
 against the library directly (it uses dlopen).
 


So they (the ssl libraries) only need to be available during build, but
don't end up in the image (only) due to this *build* dependency? That is
fine indeed.

Thanks for clarifying,

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] fix the build dependencies for uhttpd and ustream-ssl

[Bas Mevissen]

On 09/23/2014 09:36 AM, thomas.lan...@lantiq.com wrote:
 Hello,
 

Hi Thomas,

 I have to reject my own patch, uhttpd includes the header from ustream 
 unconditionally,
 so the build dependency has to stay.
 

Can't you patch uhhtpd to conditionally include the header? Would be
something to upstream as well.

Another solution would be to have the ssl libraries only build (and
packaged), but not installed in the image because of this dependency.
Not sure how to accomplish this in OpenWRT.

Cheers,

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] build failure for Asus WL-500GP

[Bas Mevissen]

On 08/28/2014 12:10 PM, Peter Münster wrote:
 Hi,
 
 With latest git version, there is a build failure:
 
 --8---cut here---start-8---
 find 
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/linux-3.14.16
  
 /home/peter/soft/wl-500gp/staging_dir/target-mipsel_mips32_uClibc-0.9.33.2/root-brcm47xx/lib/modules
  -name \*.ko | xargs mipsel-openwrt-linux-uclibc-nm | awk '$1 == U { print 
 $2 } ' | sort -u  
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/mod_symtab.txt
 mipsel-openwrt-linux-uclibc-nm -n 
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/linux-3.14.16/vmlinux.o
  | grep -F ' r __ksymtab' | sed -e 's, r __ksymtab_,,'  
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/kernel_symtab.txt
 grep -Ff 
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/mod_symtab.txt
  
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/kernel_symtab.txt
   
 /home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/sym_include.txt
 make[4]: *** 
 [/home/peter/soft/wl-500gp/build_dir/target-mipsel_mips32_uClibc-0.9.33.2/linux-brcm47xx_generic/symtab.h]
  Error 1
 make[4]: Leaving directory `/home/peter/soft/wl-500gp/target/linux/brcm47xx'
 make[3]: *** [install] Error 2
 make[3]: Leaving directory `/home/peter/soft/wl-500gp/target/linux'
 make[2]: *** [target/linux/install] Error 2
 make[2]: Leaving directory `/home/peter/soft/wl-500gp'
 make[1]: *** 
 [/home/peter/soft/wl-500gp/staging_dir/target-mipsel_mips32_uClibc-0.9.33.2/stamp/.target_install]
  Error 2
 make[1]: Leaving directory `/home/peter/soft/wl-500gp'
 make: *** [world] Error 2
 --8---cut here---end---8---
 
 linux-brcm47xx_generic/kernel_symtab.txt is empty.
 

Hi Peter,

Tried newly checked out tree (SVN r42398) with the default config for
WL500GPv1. Don't suspect any difference between SVN and GIT trees.

 make[2] package/install
 make[3] package/preconfig
 make[2] target/install
 make[3] -C target/linux install
 make[6] -C target/linux/brcm47xx/image/lzma-loader clean install
 make[2] package/index

real20m18.881s
user39m8.944s
sys 4m19.241s

Seems to build fine. Nightlies on openwrt.org
(https://downloads.openwrt.org/snapshots/trunk) are fine too. So I
suspect the problem to be on your side. Maybe clean your tree or start
all over (saving your changes and .config o/c)

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WAN bouncing at boot

[Bas Mevissen]

On 08/09/2014 04:13 AM, Weedy wrote:
 On Sun, Jul 27, 2014 at 3:31 PM, Weedy weedy2...@gmail.com wrote:
 Is there anything I can do to stop this? It started sometime in the
 last 6months of trunk.
 Right after this and couple minutes after boot my healing script fires
 and detects that WAN is broken and calls ifdown; sleep; ifup at which
 point I get an IP and keep it. But why it the WAN goinig up and down
 during boot?


Difficult to help you without any information about the platform.

You might go back in time and track down the change that caused the
issue by bisection. Can take some time to execute, but is feasible when
the problem is reproducible. Beware that when going back in time with
the sources, you must force recompilation.

 
 bump.

Not really useful to do a full quote of the original message. Waste of
bandwidth.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WPS patch set overlooked

[Bas Mevissen]

Hi Lorenzo,

Does this WPS patch set contain a way to mitigate the security design flaw?

Reading the Wikipedia article
(http://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup#Security), it looks
to me a compatible fix should be possible.

Cheers,

Bas.

On 10/13/2012 01:39 PM, Lorenzo Cappelletti wrote:
 Hi everyone,
 
 I posted  my first patch set on October 1. Since then, it hasn't been
 acknowledged. I must conclude it got overlooked.
 
 The patch set regards WPS (Wi-Fi Protected Setup) support. Could anyone
 have a look at it (maybe Felix, who recently moved hostapd directory
 under network?). It's not over yet, but I'll be submitting more patches
 if these get committed.
 
 Thanks. Lorenzo.
 
 Links to my patch set posts:
 
 https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016870.html
 https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016871.html
 https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016872.html
 https://lists.openwrt.org/pipermail/openwrt-devel/2012-October/016873.html
 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
 


-- 
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] kernels: use ccache for modules too

[Bas Mevissen]

On Wed, 03 Aug 2011 03:28:13 +, Daniel Mierswa wrote:


 KERNEL_MAKEOPTS := -C $(LINUX_DIR) \
-   CROSS_COMPILE=$(KERNEL_CROSS) \
+   CROSS_COMPILE=ccache $(KERNEL_CROSS) \
ARCH=$(LINUX_KARCH) \
KBUILD_HAVE_NLS=no \
CONFIG_SHELL=$(BASH)


Is ccache mandatory for building OpenWRT? I would advise that you need 
to use something like $(CCACHE) that can be empty when you have no 
ccache around.


Regards,

--
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Re-compiling released OpenWrt versions

[Bas Mevissen]

On Fri, 2011-03-04 at 11:05 +0100, Mark Vels wrote:

 Please add at least a revision number in feeds.conf for anything else 
 than bleeding edge! Time to grow up!
 

Yes, IMHO every OpenWRT tag and preferably every branch should contain a
feeds.conf file with revision numbers set for the trees it depends on.

Regards,

-- 
Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iptables compile fix

[Bas Mevissen]

On Tue, 23 Nov 2010 10:49:52 +0100, Maarten Bezemer
m.m.beze...@utwente.nl wrote:
 Hi,
 
 I found the problem (compile errors are back):
 When building everything from scratch with
 
 make -j 9
 
 iptables does not compile. When building (with same .config file)
 without -j it builds fine.
 
 I also believe that the problem is with the toolchain: after building
 the toolchain without -j, iptables can be build with -j without
 problems!
 
 It might be nice you (or someone else) could try building for Marvel
 Orion from scratch with parallel build to see if this can be reproduced?
 

Tested with backfire r24107:


make distclean
make menuconfig # only selected Marvell Orion
make -j 9 21 | tee build.log

builds fine here, including iptables.

Sorry again, I cannot reproduce the issue here (Fedora 14 X86_64 DomU
virtual machine).

Regards,

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iptables compile fix

[Bas Mevissen]

On Mon, 22 Nov 2010 11:51:22 +0100, Maarten Bezemer
m.m.beze...@utwente.nl wrote:
 Gr... Whatever I try it compiles now (even my own .config works)...
 Weird since there is nothing changed to the iptables package lately (or
 related things?).
 
 Only change I can think of is the update to Kubuntu 10.10 (from 10.04),
 but that was a while ago as well. Unfortunately I do not have a 10.04 to
 test this theory (and it should be be the reason as well I guess).
 
 Thanks for your help and time!

OK, Happy to hear it is solved now. These things happen now and then
and are difficult to reproduce and even more difficult to pin down to
what is actually causing it.

Anyway, thanks for the feedback.

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support

[Bas Mevissen]

On Thu, 18 Nov 2010 13:37:25 +0100, Jan Willies j...@willies.info
wrote:
 Hi Bas,
 
 2010/11/17 Bas Mevissen 
  The attached patch against trunk adds CMake host tool support.
 
 Thanks for your patch, I hope we can finally update Weechat (which
 kinda depends on cmake) to something recent.
 
 I applied your patch but building fails however:
 

It looks you are trying to cross compile something that needs to be
compiled for the host. Is there something defined in your environment
for cross compiling? 
-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support

[Bas Mevissen]

On Thu, 18 Nov 2010 14:32:36 +0100, Jan Willies j...@willies.info
wrote:

 The CFLAGS from target/linux/kirkwood/Makefile are
 overriding include/host-build.mk [3]. So removing include
 $(INCLUDE_DIR)/target.mk [4] from tools/cmake/Makefile did it for me.
 Did you include it on purpose? 
 

Ah, great. That is plain wrong. I just took the ccache Makefile as a
template for cmake. So I was quite lucky that it compiled for me. Thanks
for pointing out. I'll update my patch and check if ccache can/should do
without target.mk too.

Sorry for wasting your time.

Regards,

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Add CMake host tool support [V2]

[Bas Mevissen]

Hi all,

The attached patch against trunk adds CMake host tool support. When
CONFIG_CMAKE is set in .config, the CMake tools will be build and
installed in staging_dir/host/bin.

To enable CONFIG_CMAKE, select Advanced configuration options (for
developers) in the main menu and select Build CMake tool. When a
package needs CMake to build, it just needs to have the line

DEPENDS:=...@cmake

in the Makefile.

Please review this patch and add it to trunk. I'm working on creating 
an

OpenWRT package of Gammu (http://wammu.eu/gammu/) that needs cmake to
build, see https://dev.openwrt.org/ticket/7649

Can this patch please be added to backfire too? I'm working on a
customer project based upon backfire that needs Gammu for 
communication

with a GSM modem. It would be very nice to use backfire unmodified in
the project.

Revision history:
V1: first attempt
V2: remove target compiler flags inclusion for native build

Thanks a lot in advance,

Regards,

--
Bas


cmake.diff
Description: Binary data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add CMake host tool support

[Bas Mevissen]

On 11/18/2010 06:53 PM, Jan Willies wrote:


 Unfortunately cmake picks up the host-gcc:
 
 (cd
 /var/tmp/swjawill/openwrt-dockstar/build_dir/target-arm_v5te_uClibc-0.9.30.1_eabi/weechat-0.3.3;
 /var/tmp/swjawill/openwrt-dockstar/staging_dir/host/bin/cmake . || exit 1 );
 -- The C compiler identification is GNU
 -- Check for working C compiler: /usr/bin/gcc
 [...]
 
 Am I supposed to call it with some options or something?
 

Now the fishy part begins. :-)

We need to tell cmake that we are cross compiling. Here is a good start:

http://www.cmake.org/Wiki/CMake_Cross_Compiling

I guess we need a toolchain file. I'm wondering if we can provide one
for all packages that use cmake (it should be). So that is something
that tools/cmake/Makefile could generate.

Package should than simply call

cmake -DCMAKE_TOOLCHAIN_FILE=.../staging_dir/somewhere/tc_file.cmake

I'll take a look at it over the weekend. Hopefully, I can get the gammu
package working as well.

Thanks for your feedback so far!

Regards,

Bas.

-- 
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iptables compile fix

[Bas Mevissen]

(keeping the list in the loop)


On Tue, 2010-11-16 at 10:56 +0100, Bas Mevissen wrote:
 On Mon, 15 Nov 2010 22:45:48 +0100, Maarten Bezemer
 m.m.beze...@utwente.nl wrote:
  On Mon, 2010-11-15 at 12:08 +0100, Bas Mevissen wrote:
   I just did a build on backfire (revision 14012) for Orion (while
 checking a patch for make 3.82 for busybox). No problem at all.
   So I cannot reproduce the problem here. Can you check again and give me
 the output of svn info | grep Revision of the failing tree (assuming
 it is a checkout from svn)?
 I have just updated to Revision 24016. After rebuilding everything I
still have the error on the iptables package. I have put the last few
commands before the error and the error itself in the attached log file.


Looking at the output, I see -L/usr/lib where it should refer to the 
libraries of the cross compiled uClibc.


This problem happens on my side too (but compilation goes fine). There 
is definitely something wrong with the package and that needs a fix. 
The LDFLAGS passed to the configure script look OK, so the bug is in 
the package itself.


But the first question to answer is why you have a problem with it 
(and other people too according to the forum), while a lot of people 
have no problem at all. Just a stupid idea: do you have the openwrt SDK 
installed somewhere? What does which 
arm-openwrt-linux-uclibcgnueabi-gcc say? Can you post the .config file 
you use?


I'll take a close look at the iptables package, but don't hold your 
breath...


Regards,

--
Bas
(cd /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6; /bin/bash ./libtool --tag=CC --mode=relink arm-openwrt-linux-uclibcgnueabi-gcc -D_LARGEFILE_SOURCE=1 -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 -D_REENTRANT -Wall -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wshadow -Wstrict-prototypes -Winline -pipe -DXTABLES_LIBDIR=/usr/lib/iptables -DXTABLES_INTERNAL -I./include -I./include -I /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/linux-2.6.32.25/include -I /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/linux-2.6.32.25/include -Os -pipe -march=armv5t -mtune=xscale -funit-at-a-time -fhonour-copts -msoft-float -version-info 0:0:0 -rdynamic -static-libgcc -o libiptc/libiptc.la -rpath /usr/lib libiptc/libip4tc.la libiptc/libip6tc.la -inst-prefix-dir /home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6/ipkg-install)  
arm-openwrt-linux-uclibcgnueabi-gcc -shared   -L/home/maarten/src/openwrt-backfire/build_dir/linux-orion_generic/iptables-1.4.6/ipkg-install/usr/lib -L/usr/lib -lip4tc -lip6tc  -march=armv5t -mtune=xscale -msoft-float -Wl,-soname -Wl,libiptc.so.0 -o libiptc/.libs/libiptc.so.0.0.0
/home/maarten/src/openwrt-backfire/staging_dir/toolchain-arm_v5t_gcc-4.3.3+cs_uClibc-0.9.30.1_eabi/usr/lib/gcc/arm-openwrt-linux-uclibcgnueabi/4.3.3/../../../../arm-openwrt-linux-uclibcgnueabi/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/libc.a: could not read symbols: File format not recognized
collect2: ld returned 1 exit status
libtool: install: error: relink `libiptc/libiptc.la' with the above command before installing it
make[6]: *** [install-libLTLIBRARIES] Error 1___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] build error: mixed implicit and normal rules.

[Bas Mevissen]

On Sun, 7 Nov 2010 09:51:13 -0800, Chris Li open...@chrisli.org
wrote:
 On Sun, Nov 7, 2010 at 5:05 AM, Jo-Philipp Wich x...@subsignal.org wrote:

 Both please.
 
 Here is the patch for the busybox sub tree.
 I haven't make it a patch in openwrt so that it will automatically apply
 when compile. Is there a good example how to do that?
 
 BTW, I understand why make-3.82 want to complain. But in this case
 the fix really isn't better than the original because the duplicated
 build commands. It is just for the sake of make make-3.82 happy.
 
 Chris

Your patch seems OK to me. I tested it on current backfire branch
r24012 with both make 3.81 and 3.82.
I put your file in my local backfire tree as
package/busybox/patches/950-fix-mix-target.patch

Can an OpenWRT dev please decide whether to include this patch or
upgrade busybox to 1.17.3 (same as trunk)?

Thanks,

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iptables compile fix

[Bas Mevissen]

On Mon, 15 Nov 2010 22:45:48 +0100, Maarten Bezemer
m.m.beze...@utwente.nl wrote:
 On Mon, 2010-11-15 at 12:08 +0100, Bas Mevissen wrote:
 I guess something is wrong with your build environment. Clean it up and
 please try again.
 
 I did (of course), several times in fact.
 
 After reading your post on the forum where you told you used the trunk,
 I tried it as well and it works!
 Then I copied to iptables package from trunk to backfire it still
 compiles without problems.
 
 So, I suppose there are problems with the older version (1.4.6 compared
 to 1.4.9.1) backfire uses or with the patches/Makefile in the backfire
 package?e trunk? 
 
 Is it an idea/possible to update the backfire iptables package to the
 trunk version, since that one seems to work without problems?
 

I just did a build on backfire (revision 14012) for Orion (while
checking a patch for make 3.82 for busybox). No problem at all.

So I cannot reproduce the problem here. Can you check again and give me
the output of svn info | grep Revision of the failing tree (assuming
it is a checkout from svn)?

Regards,

-- 
Bas

-- 
Bas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] iptables compile fix

[Bas Mevissen]

On Wed, 06 Oct 2010 13:56:07 +0200, Maarten Bezemer
m.m.beze...@utwente.nl wrote:
 For the 'Marvell Orion' target the iptables package does not compile.
 See forum topic: https://forum.openwrt.org/viewtopic.php?pid=117520
 Maybe for other targets as well?
 
 In short: the problem is that /usr/lib/libc is used while linking
 instead of the cross-compiled version.
 
 I provided a patch for this problem, but I am unsure whether it is a
 correct fix or just an ugly hack. I did not check whether this patch is
 disturbing any of the other targets.
 But, with a clean checkout (with the default configuration, Broadcom
 BCM947xx/953xx) it builds fine.
 
 So could someone take a look at it and eventually provide feedback for
 improvements or tell that it is good as it is and it can be submitted?
 
 Thanks,
   Maarten

Index: package/iptables/Makefile
===
--- package/iptables/Makefile   (revision 23239)
+++ package/iptables/Makefile   (working copy)
@@ -254,7 +254,10 @@
-I$(LINUX_DIR)/arch/$(LINUX_KARCH)/include \
$(TARGET_CPPFLAGS)
 
+IPTABLES_LIBDIR=$(TOOLCHAIN_DIR)/lib/
+
 CONFIGURE_ARGS += \
+--libdir=$(IPTABLES_LIBDIR)\
--enable-shared \
--enable-devel \
--enable-ipv6 \
@@ -293,12 +296,12 @@
 

The toolchain itself should find its libc by itself. So no need to
point to it.

$(CP) $(PKG_INSTALL_DIR)/usr/include/* $(1)/usr/include/
$(INSTALL_DIR) $(1)/usr/lib
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libxtables.{a,so*} $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libip*tc.{a,so*} $(1)/usr/lib/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libipq.a $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libxtables.{a,so*}
$(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libip*tc.{a,so*}
$(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)libipq.a $(1)/usr/lib/
$(INSTALL_DIR) $(1)/usr/lib/pkgconfig
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/xtables.pc
$(1)/usr/lib/pkgconfig/
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/libiptc.pc
$(1)/usr/lib/pkgconfig/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/pkgconfig/xtables.pc
$(1)/usr/lib/pkgconfig/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/pkgconfig/libiptc.pc
$(1)/usr/lib/pkgconfig/
 endef
 
Plain wrong. The files are installed under $(PKG_INSTALL_DIR)/* and
that's where the files should be picked up after cross compilation. I
cannot imagine $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR) expanding to
something useful. It is the concatination of two absolute paths.

 define Package/iptables/install
@@ -335,20 +338,20 @@
 
 define Package/libiptc/install
$(INSTALL_DIR) $(1)/usr/lib
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libip*tc.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libip*tc.so* $(1)/usr/lib/
 endef
 
 define Package/libxtables/install
$(INSTALL_DIR) $(1)/usr/lib
-   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libxtables.so* $(1)/usr/lib/
+   $(CP) $(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/libxtables.so*
$(1)/usr/lib/
 endef
 
 define BuildPlugin
   define Package/$(1)/install
$(INSTALL_DIR) $$(1)/usr/lib/iptables
for m in $(patsubst xt_%,ipt_%,$(2)) $(patsubst ipt_%,xt_%,$(2)); do
\
-   if [ -f $(PKG_INSTALL_DIR)/usr/lib/iptables/lib{m}.so ];
then \
-   $(CP) 
$(PKG_INSTALL_DIR)/usr/lib/iptables/lib{m}.so
$$(1)/usr/lib/iptables/ ; \
+   if [ -f
$(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/iptables/lib{m}.so ]; then
\
+   $(CP)
$(PKG_INSTALL_DIR)$(IPTABLES_LIBDIR)/iptables/lib{m}.so
$$(1)/usr/lib/iptables/ ; \
fi; \
done
$(3)

Same comment as above.

I guess something is wrong with your build environment. Clean it up and
please try again.
-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] update shorewall-lite to 4.4.12.2

[Bas Mevissen]

On Fri, 8 Oct 2010 12:13:52 + (UTC), Brian J. Murrell
br...@interlinx.bc.ca wrote:
 Brian J. Murrell brian at interlinx.bc.ca writes:

 This simply updates shorewall-lite to the current 4.4.12.2
 
 I saw neither an ACK nor a NAK, nor do I see any sign that this was
 committed.
 
 Was there a problem with the submission or the patch itself?
 
 It's really quite discouraging to go to all the effort to simply have your 
 submission ignored.
 

I fully agree. I guess the only reason is time lack of the people with
commit rights.

Only advice I can give is to send a friendly reminder after a week or
so.

Regards,

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] WGT634U busted in trunk since mid-July

[Bas Mevissen]

On Thu, 30 Sep 2010 21:05:21 -0700, Russell Senior
russ...@personaltelco.net wrote:
 (...) but unfortunately, all the revisions I
 have tested after r22295 build okay but have failed to boot
 successfully.  Currently, as of r23118, I lose the serial port very
 early in the boot, immediately after:
 

From 23118 to 22295 are 823 revisions. So in less than 10 builds you
should be able to bisect the revision causing the failure. You might
even recall which earlier builds already are found to be broken.

When you find the revision that caused the breakage, I guess it will
become quite obvious why it broke your platform. You seem to be lucky
that you only have to see whether the board boots and configures its
network. That makes determining whether the build is OK or broken very
obvious.

Regards,

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Problem cross compiling gammu

[Bas Mevissen]

Hi,

I took some stuff from https://dev.openwrt.org/ticket/7649 to compile
gammu for OpenWRT on AVR32.

Most of it seems fine, but a few things fail:

- The compilation needs cmake on the host, which is not checked for.
OpenWRT does not provide support for cmake, but a host installed recent
cmake should do.

- The compilation is not cross compile aware. So the host cc is checked
for instead of the cross compiler

- Cmake fails because it cannot find libm.so. This is in
staging_dir/toolchain-*/lib. But there is no environement variable set
for this directory. The STAGING_DIR variable points to
staging_dir/target-* and something like STAGING_TOOLCHAIN_DIR is not
set. At least not when configuring the package.

- I peeked around and found that OpenEmbedded added the parameter
-DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_TARGET} to cmake. When I
manually let the root path point to the toolchain dir, it seems to
compile OK.


-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Problem cross compiling gammu

[Bas Mevissen]

On 08/16/2010 05:55 PM, Bas Mevissen wrote:
 
 Hi,
 
 I took some stuff from https://dev.openwrt.org/ticket/7649 to compile
 gammu for OpenWRT on AVR32.
 
 Most of it seems fine, but a few things fail:
 
 - The compilation needs cmake on the host, which is not checked for.
 OpenWRT does not provide support for cmake, but a host installed recent
 cmake should do.
 
 - The compilation is not cross compile aware. So the host cc is checked
 for instead of the cross compiler
 
 - Cmake fails because it cannot find libm.so. This is in
 staging_dir/toolchain-*/lib. But there is no environement variable set
 for this directory. The STAGING_DIR variable points to
 staging_dir/target-* and something like STAGING_TOOLCHAIN_DIR is not
 set. At least not when configuring the package.
 
 - I peeked around and found that OpenEmbedded added the parameter
 -DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_TARGET} to cmake. When I
 manually let the root path point to the toolchain dir, it seems to
 compile OK.
 
 

Oops, mail escaped before I was finished typing it.

Anyway, gammu seems to work on platform. At least, it is no worse than
on a desktop PC.

My question is: what to do? How is normally libm.so detected? Maybe
someone with more experience with cmake and cross compiling can shine a
light on it. Would be very much appreciated!

Regards,

Bas.

-- 
Bas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LibreWRT introduction patch

[Bas Mevissen]

On Mon, 19 Jul 2010 13:49:19 -0300, Antonio Grassi agras...@gmail.com
wrote:

 It would be great if some OpenWRT developer could review it and send
some
 feedback about the inclusion of this patch; probably there are things to
be
 solved or improved before inclusion, so it would be great to hear about
 that
 too.
 

I'm not an OpenWRT developer. My feeling is that non-intrusive libre
patches might get accepted by OpenWRT. Then a seperate LibreWRT archive
isn't needed.

Regarding the kernel version, I think we need to have a vanilla linux
kernel version and a libre one, but not written like 

ifneq ($(CONFIG_USE_LIBRE_KERNEL),)
LINUX_VERSION:=2.6.34.1-libre
else
LINUX_VERSION:=2.6.34.1
endif

in many makefiles as this makes them messy and grepping for the
LINUX_VERSION unclean. It does not scale well if you would like to add more
different kernel tastes.

A cleaner solution could be to have something like:

VANILLA_LINUX_VERSION:=2.6.34.1
LIBRE_LINUX_VERSION:=2.6.34.1-libre # or even
LIBRE_LINUX_VERSION:=$(VANILLA_LINUX_VERSION)-$(LIBRE)$(LIBRE_VERSION)

in the Makefiles where the VANILLA_LINUX_VERSION is maintained by OpenWRT
and LIBRE_LINUX_VERSION by LIBRE_POSTFIX LibreWRT.

In kernel.mk, we can simply assign the proper kernel to KERNEL_VERSION
with something like:

ifneq ($(CONFIG_USE_LIBRE_KERNEL),)
LINUX_VERSION:=LIBRE_LINUX_VERSION
else
LINUX_VERSION:=VANILLA_LINUX_VERSION
endif
# Fall back to vanilla
ifeq ($(LINUX_VERSION),)
LINUX_VERSION:=VANILLA_LINUX_VERSION
endif


 PS: I'm CC'ing the LibreWRT development list
 
I'm not a member of that list, so I cannot copy that list.

Regards,

-- 
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LibreWRT introduction patch

[Bas Mevissen]

On Tue, 20 Jul 2010 10:53:19 -0300, Antonio Grassi agras...@gmail.com
wrote:
 we tried a second approach, which
 is also included in the patch: instead of downloading deblobed kernel
 sources, we could deblob the vanilla kernel sources as part of the build
 process, making use of the deblobing scripts [1] provided by Libre
Linux.
 This approach requires the deblobing scripts to be downloaded at run
time
 or be included in the sources, for example, under a new sub
 directory 'scripts/deblob/'. What do you think about this?
 

I'm wondering if deblobbing is enough for the real libre people because
they will still download non-libre stuff.

In other words, I wonder why one would like to deblob. As long as you
don't install the blobs in the image, you are not using it. So if you
already downloaded it, what is the use of removing it above just not
installing and using it.

Regards,

-- 
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] LibreWRT introduction patch

[Bas Mevissen]

On Tue, 20 Jul 2010 17:37:50 +0200, Stefan Monnier
monn...@iro.umontreal.ca wrote:
 In other words, I wonder why one would like to deblob. As long as you
 don't install the blobs in the image, you are not using it. So if you
 already downloaded it, what is the use of removing it above just not
 installing and using it.
 
 IIUC the issue is not whether to download this or not, but whether it
 gets (installed and) used.  So it's mostly a matter of marking the
 un-free parts and then making them only available upon a very
 explicit request.
 
 The degree to which the request should be explicit is of course
 something that depends on how much you care about this kind of freedom.

OK, if you interpret it like that, one doesn't need to deblob the kernel
source. We only need a configuration value that avoids installing the
non-free stuff.

 I personally would really like it if OpenWRT labelled each non-free part
 and made it clear which part is free and which isn't (e.g. by placing
 all the non-free packages (i.e. packages which include some non-free
 element) in a separate (sub)menu).
 

I would recommend keeping the current menu structure based upon
functionality and not free/non-free

For non-free packages, would something like 
DEPENDS=-LIBRE 
work?

If CONFIG_LIBRE is defined, these packages would simply disappear from the
menu.

-- 
Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Openwrt package installation order

[Bas Mevissen]

On Mon, 31 May 2010 13:19:00 +0200, Filippo Sallemi tonyp...@gmail.com
wrote:
 Hi,
 could someone explain how to change the order to install certain
packages?
 
 I need to overwrite some configuration files, but the system overrides
in
 alphabetical order.
 

Use the files directory in your OpenWRT root. The contents of this
directory will be copied over the installed files just before generating
the image.

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Optware refusal

[Bas Mevissen]

On Thu, 2010-05-20 at 19:23 +0200, Benjamin Henrion wrote:
 It seems that the OpenWRT devs have entrenched views about optware packages:
 
 https://dev.openwrt.org/ticket/944
 

What's your reason for digging up a 4 year old ticket?

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU

[Bas Mevissen]

On Fri, 2010-03-19 at 16:56 +0100, Joerg Albert wrote:
 I looked closer at the PCB and it turned out that we have a voltage
 divider with two 5.6 kOhm to V_3_3 and GND (R613, R614) and a
 capacitor C496 (!) towards the CPU. The signal at the CPU looked fine
 for a 2.5V TTL.
 The voltage drift seen above is probably caused by the capacitor
 unloading when the CPU pin is driven down.
 

Curious design choice. Works fine for continuous signals at higher
frequencies, but not here.

 I removed the resitors and replaced C496 by a 1k resistor (to protect
 the CPU pin against shorts). This solved my problem.
 I guess the above schematics was meant to be a cheap TTL level
 conversion 2.5V - 3.3V.
 
 Thanks for sending me again to the oscilloscope!

I'm happy it is solved now. Maybe you can document this in relevant
places on the web.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mjpg-streamer and kernel crash again

[Bas Mevissen]

On Fri, 2010-03-19 at 22:37 +0100, Kövesdi György wrote:
 Hi,
 
 At last i could create symbolic backtrace (attached).
 
 The hardware is an Asus WL500GP-V2, a 160 Gb HD (on USB), a UVC webcam 
 (Logitech Quickcam Sphere).
 The commandline is:
 mjpg-streamer -i input_uvc.so -f 25 -r 320x240 -l off -o output_file.so -r 
 /data/jpeg
 
 128Mb swap is used.
 Some commands are executed immediately before crash (see the attached file), 
 the free memory and other things are shown.
 
 I cannot imagine that all the memory got allocated within some seconds 
 (filling 128Mb space through USB takes some time). I assume that there is a 
 problem in the kernel instead.
 

Where is the output of mjpg-streamer written to? It looks like it is
using ram disk or (slow) flash memory. Make sure it is on the hard disk.

What is the rate of data being written? If, for some reason, the disk
(flash?) is too slow, you run out of memory due to the block layer
buffering.

You can measure the USB disk performance by copying a piece of dat from
e.g. /dev/zero to the disk with dd.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mjpg-streamer and kernel crash again

[Bas Mevissen]

On Mon, 2010-03-22 at 15:30 +0100, Kövesdi György wrote:
  Where is the output of mjpg-streamer written to? It looks like it is
  using ram disk or (slow) flash memory. Make sure it is on the hard disk.
 Sorry, i forgot to mention that there is a link:
 /data - /mnt/xxx/
 which point to the HD.
 

OK, wanted to be sure that we are hunting a real bug. Did you check that
the files are actually written to that disk?

  What is the rate of data being written? If, for some reason, the disk
  (flash?) is too slow, you run out of memory due to the block layer
  buffering.
 The measured maximum recorded rate is ~23 fps. My very first try was 
 recording 
 one picture in every 15 second, which is very slow, and it also leaded to 
 crash in 3 days. Faster recording crashes sooner.
 

Sounds like a memory leak of the application. Or some (debug) log asking
too much memory. Maybe /var/log/messages is getting huge?

 --
 
 I checked some out-of-memory situations, and found strange things. You can 
 easily try it (i would like to hear if it works on your system or not): 
 create 
 a big directory (~50k...100k files) and give a simple 'ls' command:
 
 $ ls /my/big/directory
 
 No swap is in use, my physical memory is 32M.
 The 'ls' allocates very much memory, which leads to out-of-memory. AFAIK, the 
 kernel calls the oom-killer, which should kill the biggest process ('ls' in 
 this case). 

I'm not sure that it kills the biggest process first.

 It happens, but the system hangs. Some seconds later the following 
 message appears on the console:
 
 bcm47xx_wdtWatchdog will fire soon!!!
 
 This is the very last message, the system does not respond any more.
 I think this situation should be handled correctly.
 

What keeps the watchdog happy? It that still alive after the OOM-killer?

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] #6812: kamikaze trunk can't start RB433AH

[Bas Mevissen]

On Fri, 2010-03-19 at 10:12 +0800, Yongheng Qi wrote:
 Thanks Bas ,
 
 
 because kamikze trunk used linux kernel changed so faster. and my
 application depend on fixed kernel version.
 
You can keep the kernel version stable and have the other stuff up to
date. But that won't help if there is a problem with that kernel.

In general, it is better to see if you can make your application
independent of the kernel version. In the event of a kernel driver
(binary), you might not have that freedom.

 
 so I can't use svn up. only need resolve the problem. I want to know
 how to resolve the problem myself.
 
I would first recommend to check that the board boots with the version
of Kamikaze trunk mentioned in the bug report. Then you know that there
is no other problem.

Then work your way back in svn revisions until you find the change that
fixed the problem. It is some work, but you don't need to dig too deep
into code to get it.

Example: svn revision 1000 fails and 2000 works. Try 1500. If it works,
try 1250. Otherwise try 1750, etc. If you can compile fast enough, it is
just a matter of a few hours work to pinpoint the revision that fixed
the issue.

To avoid recompiling everything every time, keep a copy of every
compiled tree and only go *upwards* in svn revision number on that
particular tree. So if you want to compile revision 1500, check for the
closest lower revision you have, say 1000, copy it and update it to the
revision. 

The idea is that updated sources will be automatically recompiled. This
is not 100% guaranteed to work, but it might save you a lot of time.
Also make sure that you don't change the directory path of the tree you
are recompiling because that will break the compile. Or even worse, you
will use stuff from a different revision.

Something like:

svn up --revision 1000 openwrt-current
cd openwrt-current; make
cp -a openwrt-current openwrt-r1000

svn up --revision 2000 openwrt-current
cd openwrt-current; make
mv openwrt-current openwrt-r2000

# now I want 1500
cp -a openwrt-r1000 openwrt-current
svn up --revision 1500 openwrt-current
cd openwrt-current; make
 
Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU

[Bas Mevissen]

On Thu, 2010-03-18 at 23:04 +0100, Joerg Albert wrote:
 On 03/15/2010 09:33 AM, Bas Mevissen wrote:
 
  Do you have access to an oscilloscope? It might be that the signal
level
  or signal shape is not perfect. I've seen mixed results with various
  serial to USB adapters too.
 
 I used an oscilloscope yesterday and the signal looked fine (sharp
edges, correct timing, low noise).

What were the voltages of both 0's and 1's?

 It's a rather new device and I run the board at home at a laboratory
power supply.
 

That should be fine.

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] #6812: kamikaze trunk can't start RB433AH

[Bas Mevissen]

On Thu, 2010-03-18 at 16:25 +0800, Yongheng Qi wrote:
 anyone could tell me how to resolve the problem, I want NOT to change
 my kamikaze version.

 I used the kamikaze r19358.
 

Then find the change that fixed the issue and patch your setup yourself.

You cannot expect someone to fix your problem if you refuse to accept
the logical solution of calling svn up  make.

Kamikaze trunk is work in progress and you should be willing to upgrade
your tree to fix problems. Otherwise, you are on your own.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU

[Bas Mevissen]

On Sat, 2010-03-13 at 18:31 +0100, Joerg Albert wrote:
 
 BTW, I get some garbled chars on TX (target - PC) from the WR741ND on
 the serial line.
 Both in bootloader and Linux system, so I guess it's a hardware
 problem (especially
 as the log in
 https://forum.openwrt.org/viewtopic.php?pid=102069#p102069 looks
 fine).
 I use a Prolific PL2303 serial USB adapter which works fine with other
 hardware. Someone else?

Do you have access to an oscilloscope? It might be that the signal level
or signal shape is not perfect. I've seen mixed results with various
serial to USB adapters too.

You can also try to replace the net adapter of the board. These adapters
tend to age and perform worse.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] External toolchain cannot find -lgcc_s

[Bas Mevissen]

On Sat, 2010-03-13 at 22:22 -0500, Pawel Pastuszak wrote:

 Hi All,
 
 I am trying to split the toolchain out of my main openwrt build, after
 generating the toolchain i moved it to a new location from
 staging_dir/toolchain-powerpc_gcc-4.3.3_glibc-2.7 and set up and new
 build that points to the toolchain.
 
 I am using Revision: 20023.
 
 Is there any think that I am missing?
 
 
 powerpc-openwrt-linux-gnu-gcc -Os -pipe -funit-at-a-time -mcpu=405
 -msoft-float -Wall -Wunused -I./include/linux/include/ -Iinclude/
 -DARPTABLES_VERSION=\0.0.3-3\  -o arptables arptables-standalone.o
 arptables.o libarptc/libarptc.o extensions/arpt_standard.o
 extensions/arpt_mangle.o
 /development/external_toolchain_test/usr/bin/../lib/gcc/powerpc-openwrt-linux-gnu/4.3.3/../../../../powerpc-openwrt-linux-gnu/bin/ld:
 cannot find -lgcc_s
 collect2: ld returned 1 exit status
 make[4]: *** [arptables] Error 1
 make[4]: Leaving directory
 `/development/openwrt/build_dir/target-powerpc-openwrt-linux-gnu/arptables-v0.0.3-3'
 make[3]: *** 
 [/development/openwrt/build_dir/target-powerpc-openwrt-linux-gnu/arptables-v0.0.3-3/.built]
 Error 2
 make[3]: Leaving directory `/development/openwrt/package/arptables'
 make[2]: *** [package/arptables/compile] Error 2
 make[2]: Leaving directory `/development/openwrt'
 
 

Looks like a relocation problem. In general, gcc has a hard coded
absolute path to some libraries. Solution is to compile the cross
compiler for your new destination path or fix the binary. 

This has been discussed quite recently here in the Compiling outside of
buildroot thread.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AR7240 switch // was: TP-Link TL-WR741ND: broadcasts on ethernet not reaching CPU

[Bas Mevissen]

On Mon, 2010-03-15 at 11:31 +0100, ulf kypke wrote:

 i'm still looking for a very good 3.3v serial adapter, the prolific is
 not the best one.

Best trick is to cascade a MAX3232 level shifter with 3V3 power supply.
It will raise the signal level to just over 5V. That is enough for the
average serial-to-USB converter. It also protects the other end from
over voltage.

I once had to couple an AVR32 development board to an automotive GSM
modem using a bi-directional cascade of 3V3 and 5V powered MAX3232 level
shifters...

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Backfire 10.03-beta

[Bas Mevissen]

On 03/05/2010 09:49 PM, Stefan Monnier wrote:
 Binaries can be downloaded at
 http://downloads.openwrt.org/backfire/10.03-beta/
 
 Is there some equivalent Svn revision, branch, or the trunk rev-number
 from which it was branched?
 

Looking at the .config files, it seems to be OpenWRT trunk (and
packages) r19932.

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Backfire 10.03-beta

[Bas Mevissen]

On Thu, 2010-03-04 at 11:27 +0100, edgar.sol...@web.de wrote:
 
  Highlights:
  * brcm-2.4 updated to 2.4.37 kernel
 
 why not recent 2.4.39, the 2.4 kernel doesn't have major changes
 anymore 
 but some more bugfixes
 
 http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.37.9
 http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.37.8
 
 when I tried it compiled and ran.
 

Kernel is already the latest, 2.4.37.9.

http://downloads.openwrt.org/backfire/10.03-beta/brcm-2.4/packages/kernel_2.4.37.9-1_brcm-2.4.ipk

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured

[Bas Mevissen]

On Sun, 2010-02-28 at 11:30 +0100, Stijn Tintel wrote:
 On 28-02-10 11:28, Stijn Tintel wrote:
  This patch allows multiple listen ports to be configured for dropbear in
  /etc/config/dropbear. It renames the 'Port' option to 'Ports', so this
  will break existing configs.

What looks more useful to me, is to have multiple different dropbear
configs at the same time, e.g.

# Public key-only login port
config dropbear
  option PasswordAuth 'off'
  option Port '22'
  option BannerFile   '/etc/banner'

# Hidden password enabled fall-back
config dropbear
  option PasswordAuth 'on'
  option Port ''

Is that already supported?

I would also not see much reason to rename Port to Ports. As already
said, it is a rarely used setup and it works fine when called Port.

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured

[Bas Mevissen]

On Mon, 2010-03-01 at 15:22 +0100, Stijn Tintel wrote:

 Since the above suggestion is OK for me, I'd suggest to just forget this
 patch :-)

The patch itself is useful if someone wants to explore the possibilities
of dropbear. There is a difference between two instances and one
instance which listens on two ports. There was just some objection on
breaking the name of the port(s) option.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Compiling outside of buildroot

[Bas Mevissen]

On 02/19/2010 08:08 PM, Felix Fietkau wrote:

 I disagree with the way manufacturers typically set up board support
 packages. Often you have to install something as root, which is annoying
 for people that only have user accounts on some machines. Often you can
 only have one globally installed instance of the SDK, which makes it
 annoying to support multiple different versions, or even just multiple
 minor variations of the toolchain.
 

That's true, but for most of people it is a convenient way to just have
to install an SDK and start developing.

One issue with pre-compiled SDK's is gcc hardcoded absolute paths to
libraries that make relocation difficult. There are scripts that change
the absolute paths to relative one. Then it is possible to install a
precompiled SDK in the user accessible location you want.

With OpenWRT, it is possible to have multiple different version
installed at the same time. You can simply choose a different location
for every variant where you build OpenWRT, e.g. build one in
/opt/OpenWRT/platform/variant1 and another one in
/opt/OpenWRT/platform/variant2

By sourcing a (to be written) script say
/opt/OpenWRT/platform/the_variant/settings.rc you switch between
different variants.

 Why do you want to call it outside of the tree? You can keep your
 packages as a separate feed, which makes it easy to keep track of your
 own work without having to fully integrate it into the OpenWrt tree.
 

Personally, I like a complete separation between open source and
propriety code. So when developing propriety code which uses OpenWRT as
a platform, I prefer to use a fixed tree of OpenWRT stuff (packaged and
installed somewhere) and have an entirely separate tree of propriety
code in which I can simply call make. Then the resulting binaries,
kmods and images should land somewhere in my propriety tree.

Please note that I'm not saying that the system with the feeds is not
working properly! I just want to offer an OpenWRT based SDK for a
certain board (including kernel headers and .config actually) as an easy
to install package and an archive with only the propriety stuff.

One then only needs to install the SDK, unpack the archive with the
propriety code and run make.

Bas.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Compiling outside of buildroot

[Bas Mevissen]

On 02/21/2010 07:45 PM, Florian Fainelli wrote:
  Yes it is still supported and works well.
  It also contains a relocatable toolchain, so it doesn't matter where
  you unpack it. But it is only suitable for userspace software, iirc it
  does not ship with and is not capable of compiling the kernel sources.
 You can however, use the compiled and relocatable toolchain in the SDK to 
 compile other kernel sources (vanilla, git ...)

So if the kernel headers and config are added to the SDK, one could
compile out of tree kmods too?

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?

[Bas Mevissen]

On Fri, 2010-02-19 at 00:07 -0500, Stefan Monnier wrote:
  Linux can hardly fit in a 2MB flash device, once you have opened the
  Yes, but this text was written in the old times (2004?)
 
 I've been using OpenWRT on my WL-700gE for a while now.  That machine
 has a 2MB flash, so OpenWRT is quite usable there.  But yes, it also has
 a IDE interface, so the 2MB only serves as a sort of initramfs (indeed,
 I don't even include a jffs2 partition, only squashfs).
 

So in summary, it is IMO safe to assume that a device like a router with
only 2Mbytes of non-volatile storage (flash) does not run Linux.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?

[Bas Mevissen]

On Fri, 2010-02-19 at 16:24 +0100, Benjamin Henrion wrote:
 The Asus WL520GC I just bought is running Linux. It has 2MB of flash.

Wow, I assumed that out of the box, these devices with a small amount of
flash did not run Linux. That was true in the past at least. Things have
changed since I last checked...

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Compiling outside of buildroot

[Bas Mevissen]

On Fri, 2010-02-19 at 16:14 +0100, Felix Fietkau wrote:
 On 2010-02-19 2:53 PM, David Farrell wrote:
 (..)
  I just want to treat the OpenWrt system as a general purpose embedded linux 
  box.
 Two possibilities:
 
 a) You read about how the Linux kernel is cross compiled, how to build
 external kernel module trees and so on using variables like
 CROSS_COMPILE, ARCH, M, ...
 The kernel sources are in build_dir/linux-*/linux-*/.
 You can put the toolchain dir into your PATH and call the make commands
 there (pointing at your external tree), either manually or with your
 wrapper makefile.
 

How about the OpenWRT SDK? Is that still supported?
I never used it, but it would be useful if it would contain some
Makefiles and/or scripts to help building user space and kernel space
code outside the OpenWRT tree.

The idea is that you install a pre-compiled SDK somewhere, source a
script with settings and you can easily build your own stuff without
hassle about paths and stuff. This is how most board support packages
from hardware manufacturers work. It should be as easy as native
compilation.

b) You realize that cross-compiling an external kernel module is much
 easier with OpenWrt, and simply copy a package dir like
 package/spi-ks8995 and adjust it for your own kernel module, then run
 make oldconfig and then run make package/yourpackage/compile V=99 ;)
 

Yes, it is easy to create an external package and include it in the
OpenWRT build. Is there a way to build an OpenWRT image with calling
make outside the OpenWRT tree and have the image also outside the
OpenWRT tree?

The idea here is to keep your code and OpenWRT separated during
development.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] libconfig: update version to 1.4.2

[Bas Mevissen]

On Sun, 2010-02-14 at 21:17 +0100, Mircea Gherzan wrote:
 The 1.4.0 tarball is no longer available upstream.
 
(..)
  PKG_NAME:=libconfig
 -PKG_VERSION:=1.4
 +PKG_VERSION:=1.4.2
  PKG_RELEASE:=1
  
  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
  PKG_SOURCE_URL:=http://www.hyperrealm.com/libconfig/
 -PKG_MD5SUM:=c6b1c6ccb1a35b93ebf771779d915181
 +PKG_MD5SUM:=6bf067a7f2d432847494d1c356074c02
  

Today, a version 1.4.3 was released with a minor fix.
Modified but untested patch below.

Bas.

---
 libs/libconfig/Makefile |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libs/libconfig/Makefile b/libs/libconfig/Makefile
index ba97cbb..f3ef993 100644
--- a/libs/libconfig/Makefile
+++ b/libs/libconfig/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=libconfig
-PKG_VERSION:=1.4
+PKG_VERSION:=1.4.3
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://www.hyperrealm.com/libconfig/
-PKG_MD5SUM:=c6b1c6ccb1a35b93ebf771779d915181
+PKG_MD5SUM:=8b7a7facd8b380fdd26a4a1ea58086b9
 
 include $(INCLUDE_DIR)/package.mk



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] compression mode of jffs2

[Bas Mevissen]

On Sun, 2010-02-07 at 18:00 +0100, Matthias Buecher / Germany wrote:
 How will this affect performance (the opposite side of compression)?
 If it does, then it would be great if this would be selectable and not
 hardcoded.
 
 Just my two cents
 Maddes
 
 On 07.02.2010 17:44, edgar.sol...@web.de wrote:
  I discovered a currently not used option of jffs2. It allows the setting
  of a compression mode. Because size matters on embedded devices I wonder
  why this is not enabled. Attached a patch that does that. I tried it and
  it works.
  

My 2 cents: compare the boot time between the jffs2 with and without the
patch. Can you also give an example in the actual flash space saved by
the patch?

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] compression mode of jffs2

[Bas Mevissen]

On Mon, 2010-02-08 at 11:25 +0100, edgar.sol...@web.de wrote:
 Any idea how to measure boot time? I don't have serial console access. ede
 

some LED changing state, first respond to ping or wait for first
broadcast packet from ethernet (e.g. arp, dhcp) with wireshark.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] compression mode of jffs2

[Bas Mevissen]

On Mon, 2010-02-08 at 11:32 +0100, Bastian Bittorf wrote:
 
 boottime should'nt be affected, because bootpartition is squashfs,

Ah, I use jffs2 as root (and only) fs on my dev boards.

 only the writeable partition is jffs2. In theory i vote for default to
 size-optimization and make it menuconfig-selectable to switch to old
 mode.
 

That sounds like a good plan.

Bas.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Patches to fix AVR32 and lk 2.6.25+ stuff

[Bas Mevissen]

Bas Mevissen wrote:
 Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3755 for a
 fix for kmod-ebtables package not being built on 2.6.25+ kernels.
 

OK, comment here was the it would cause performance degradation. But is 
that also the case when the ebtables modules are not loaded? See my 
added comment on this ticket.

Another question: can you let OpenWRT configuration options depend on 
the kernel configuration? And is that something wise to do?

Idea is to disable the kmod-ebtables when ebtables is not defined in the 
kernel. Same for kmod-i2c-core.
(see https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3756)

Regards,

Bas.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Patches to fix AVR32 and lk 2.6.25+ stuff

[Bas Mevissen]

Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3755 for a
fix for kmod-ebtables package not being built on 2.6.25+ kernels.

Please check https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3756 for a
fix for a build error with kmod-i2c-core package on AVR32 2.6 kernels.
This might apply to other archs as well.

Regards,

Bas.
(yes, this e-mail address works)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel