Re: makefile debugging
On 1/18/24 12:01, Tim Harvey wrote: Greetings, I seem to recall a way to ask OpenWrt's build system to output a list of all variable values used in the build but can't find it documented or in my notes. Does anyone know how to do that? Also, is there a way to output a post-processed Makefile after all the define foo gets done? I find it pretty difficult to work through the build system, especially when working with images. Best Regards, Tim This is what I use for variables. I don't know if there's a way to get a post-processed Makefile -- that could be helpful, but also sounds like a bear to parse. $(foreach v, \ $(shell echo "$(filter-out .VARIABLES,$(.VARIABLES))" | tr ' ' '\n' | sort), \ $(info /tmp/make_vars,$(shell printf "%-20s" "$(v)")= $(value $(v))) \ ) Daniel ___ 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
On 1/18/24 10:37, Chuanhong Guo wrote: MT7981 is such a chip with NAT offload capability, and the flow-offload driver mentioned in other threads is actually a driver for this hardware block. Since it's a cost-down MT7986 I would imagine this particular feature is the same between them: HW NAT − Etherent/WiFi − Wired speed − IPv4 routing, NAT, NAPT − IPv6 routing, DS-Lite, 6RD I can't find an MT7981 / Filogic 820 datasheet anywhere, but apparently MediaTek was nice enough to put out a public release for the MT7986 / Filogic 820 for the Banana Pi R3. Anybody know what the differences are? Could it just be quad vs dual core? I'm also wondering if MediaTek could be convinced to make a public release of the MT7981B for this project. To work on any MediaTek SoCs, if feels like you have to be an expert in all of them to know what microcode they're reusing for each component (peripheral interfaces, etc.) from one chip to the next, and thus the registers and behavior that had been previously published in a some other programmer's manual. It's a strange world to me. Daniel ___ 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
On 1/16/24 00:36, John Crispin wrote: And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel yeah we will add all remaining GPIO togehter with GND and 3,3V on a 2.54mm header. HELL YES! Even better! Even though it's on mikroBUS, maybe export the reset line on header as well? Daniel ___ 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
On 1/15/24 06:56, Paul D wrote: A kickstarter is a good way to forecast demand. You've captured the imagination of the geek community. Not aware of peripheral issues or complexities in doing a kickstarter, though I agree with forecasting demand. "Geeks" are good at commenting on stuff, and intellectualizing a new board: let's see how many put their money where their mouth is. And in the interest of running *my* own mouth, I'm stoked as hell -- LOVE that it will have mikroBUS! Thanks to John and everyone working on this! My only request is that any unused gpios that don't make it to mikroBUS find their way to a (possibly unpopulated) header some where for the sake of hackability. 1mm pitch is fine. I've had more than one occasion where I wanted to add something and didn't have the bus or I/O lines and then discovered that the MCU did, but they were all N/C. Hackability is what makes the FOSS / open hardware world so awesome.\! Daniel ___ 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
On 1/10/24 08:18, Forest Crossman wrote: On Tue, Jan 9, 2024 at 4:52 AM John Crispin wrote: ---SNIP--- * Why is there no USB 3.x host port on the device? - the USB 3.x and PCIe buses are shared in the selected SoC silicon, hence only a single High-Speed USB port is available Perhaps you've already considered this, but it may be possible to route the shared PCIe/USB 3 traces to both an M.2 slot and a USB 3 host port using a high-speed dual-channel differential 1:2/2:1 switch/mux. It wouldn't enable both interfaces to be used at the same time, but it would make it possible to select which interface is enabled using a GPIO pin. Then U-boot could either automatically enable one port or the other depending on what devices it detects (e.g., enable PCIe and disable USB 3 if a PCIe device is connected, otherwise enable USB 3 and disable PCIe), or it could be statically configurable via a U-boot environment variable. From some quick searching, the switches/muxes that would enable this cost less than $1 each in qty. 1000. For a <$100 product I understand that may be too much of an increase to the BoM cost and PCB complexity, but I think users would really appreciate being able to choose between being able to add an M.2 SSD, WiFi card, or SATA controller and being able to plug in a USB 3.x 2.5 GbE adapter, SSD/flash drive, WiFi dongle, or 5G modem. All the best, Forest I'm always a fan of a single PCB design that *can* be built in different configurations. So would suggest a design where differential mux can be left unpopulated to create a product w/o USB 3 support. But of course, this doesn't overcome EMI concerns Daniel Golle mentioned. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 1/22/23 12:24, Arınç ÜNAL wrote: On 22.01.2023 20:44, Daniel Santos wrote: On 1/22/23 00:23, Arınç ÜNAL wrote: On 22 January 2023 02:02:04 GMT+03:00, Daniel Santos wrote: On 1/21/23 15:19, Arınç ÜNAL wrote: On 21.01.2023 21:32, Daniel Santos wrote: ... You can use this to see what the valid values are for each group, because until this all goes yaml, there's nothing to tell you if you've used an invalid value. Speaking of which: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=4e5410668af5475681793df2bb8c7d8dc6f9c327 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=0c9a567651c3b5d433429da2c7d8e8406ddf1076 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=b4ac84395820eaa0b99ec56816e53c9386ca8b38 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=844bca60927f3aae6baafafb1edd218b624254a1 Arınç OH FUCK YES!!! Arınç, you and I are friends now!! :D Haha hello there! Arınç I don't want to spam the group with this, but you have no idea how much bullshit I've been through that turned out to be a mistake in my device tree file for which there was no warning about. I almost re-wrote the ramips arch code over it, but I had to pull myself back when it was clear that it was unnecessary for my project and hard to justify billing for it. I have that ADHD thing, so I have to stay on track. Glad to read this helps you tremendously. By the way, you didn't CC anyone else so the list didn't receive it ;). Anyway, I'm really pleased to see this and it reminds me that I have a lot of kernel patches I need to submit both to OpenWRT and upstream, including fixing a command line bug for ramips. Speaking of fixing stuff, if you take a look at the yaml for mt7620 and rt305x, some functions got multiple lists for groups. Like refclk on mt7620. Because mt7620 and mt7628/mt7688 SoCs use the same compatible string, it's impossible to differentiate on the binding which SoC your DT is actually for. Therefore, the binding will allow all groups listed for that function. For example if your SoC is mt7620, you can only use the refclk function for the mdio group. If you were to put "spi cs1" as the function there, you wouldn't get a warning. I want to fix this by actually separating mt7628/mt7688 from mt7620 on the pinctrl driver, then split the dt-binding, but I don't know C good enough to do this myself. I have a lot of things I can actually do right now on my task list which could take more than a year (if nothing new is added on top) to complete, so I'm very slowly learning it. It's also the first programming language I ever attempt to learn so understanding the logic of programming is another challenge I've got to deal with. I'd appreciate it greatly if you could help me out on this as you seem to know C. However, I have to send a mail to pinctrl mailing list, see if I can justify breaking the ABI with the maintainers since we would be changing the compatible string for certain SoCs. I've done it once. Arınç I'm not at a place where I can take a new project on as I'm going through a health problem, but let me know when your ready and I'll see if I can help. I'll have to study the code again, as I was mostly concerned with fixing my problem before and didn't look much at other SoCs. There's a lot of reused code between SoCs and that's not bad in-and-of its self, but I'll need to fully analyze them to understand where code sharing follows genuine abstractions of the family of hardware it represents and which parts are are an improper fusion. On the flip side, this would spur me to get all of my platform patches polished off and sent where they need to go as well! One thing you'll see a lot in this platform and driver code is code for one SoC and a lot of that is because the same internal hardware components are reused from one chip to another, and by "internal hardware components," I mean devices like a GPIO banks, SPI bus controllers, ethernet switches, etc. These are circuits that they can essentially copy and paste from one SoC design into another one. Some manufacturers will name and version these internal components and have separate documentation for them that applies to all of their products that contain them, but MediaTek doesn't, so we end up referring back to the code for the first SoC where that piece of hardware was used. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
On 1/21/23 15:19, Arınç ÜNAL wrote: On 21.01.2023 21:32, Daniel Santos wrote: ... You can use this to see what the valid values are for each group, because until this all goes yaml, there's nothing to tell you if you've used an invalid value. Speaking of which: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=4e5410668af5475681793df2bb8c7d8dc6f9c327 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=0c9a567651c3b5d433429da2c7d8e8406ddf1076 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=b4ac84395820eaa0b99ec56816e53c9386ca8b38 https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=d648fd64e10d9d1609146d0c4e47b0f5988e2a2b https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/commit/?h=for-next=844bca60927f3aae6baafafb1edd218b624254a1 Arınç OH FUCK YES!!! Arınç, you and I are friends now!! :D Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
Hello all,
I saw this a few days ago, but was too busy to answer then -- sorry
about that. I've dug into this code a bit, but for the mt7620.
On 1/21/23 08:51, Sergio Paracuellos wrote:
Hi,
[+cc John Crispin]
On Sat, Jan 21, 2023 at 2:45 PM Arınç ÜNAL wrote:
On 21.01.2023 10:56, Sergio Paracuellos wrote:
Hi,
On Sat, Jan 21, 2023 at 7:03 AM Arınç ÜNAL wrote:
Pins from 22 to 33 are on the rgmii2 pin group. They don't function as
GPIO by default. Requesting a gpio by either from devicetree or `echo
203 > /sys/class/gpio/export` won't change anything. You have to claim
the pin group as gpio on the devicetree.
Yes, you have to claim the pin group as gpio on the device tree to
make this work. Ralink has the concept of "GPIO mode" but actually is
just an electrical configuration for a certain device. So if the mode
(function) is not requested as a real GPIO nothing is going to work.
So in your board's dts file you have to add something like the
following with the groups you want to claim as real gpio function:
#include "mt7621.dtsi"
...
_default {
gpio {
groups = "jtag", "uart3", "wdt";
function = "gpio";
};
};
First of all, to better understand what you're working with I highly
recommend you download the mt7621 Data Sheet and took at §2.4 Pin
Sharing Schemes. Here's a link to one I've found:
https://www.t-firefly.com/download/FireWRT/hardware/MT7621.pdf .
Microcontrollers come with a lot of nifty hardware -- more than they
have external pins for. So if you don't need a piece of hardware, you
can option to use that pin as a GPIO instead.
The kernel code for the other end of this device tree snippet that
Sergio gave you is in arch/mips/ralink/mt7621.c, which you'll probably
find in your OpenWRT build tree under
build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-5.4.143/.
The various struct rt2880_pmx_func variables contain the valid values
for each of these sets of pins except for "gpio" -- which is implicit
for each one (not my favorite design choice, but oh well). Finally, each
of those are glued together with the struct rt2880_pmx_group
mt7621_pinmux_data[] array on line 96. You can use this to see what the
valid values are for each group, because until this all goes yaml,
there's nothing to tell you if you've used an invalid value.
So the point is that you can pretend to export a gpio to user space all
you like, change it's direction and value, and perhaps the
micocontroller really obeys the gpio commands you send it, but you'll
never see that outside of the silicone die if that pin group is set to a
mode that doesn't connect that pin to the internal GPIO device on the die.
Quoting my response from [0]:
state_default is there to explicitly set the function of a pin group to gpio,
this is done because the bootloader may have set the function of a pin group to
something else before booting OpenWrt which would render the pins of that group
uncontrollable for general purpose aka GPIO.
Actually I think @arinc9 did some work around that.
Not yet, I plan to modify the gpio_request_enable pinmux operation to set the
pin group as gpio when there's a gpio request for a pin in that pin group.
gpio_request_enable pinmux operation can only set the function of an individual
pin currently. Since ralink pinctrl driver can only set the function of a group
of pins, the operation currently cannot be used.
If we make it work, any GPIO defined on devicetree or exported from userspace
will automatically have the function of the pin group it's in set to gpio,
completely getting rid of the need for explicitly defining functions of certain
pin groups on the devicetree.
Of course when I said "I plan to modify this code" I actually meant I
was going to talk this through with Sergio but I never had the
opportunity to do so. I guess this thread is a good place to start
talking about this.
I had this case on a user:
They got an LED wired to wdt pin. GPIO is already exported on the DT.
However their LED just won't work.
It turns out the bootloader sets the wdt pin's function to something
other than gpio. And when OpenWrt boots, the pinctrl driver makes no
changes to the pin's function.
Bootloader always sets its own configuration for the pinctrl. The
linux pinctrl driver sets every single group default mode [0] as it is
in the Mediatek's Mt7621 datasheet.
So we had to specifically claim that pin as gpio to make the LED work.
Now there is already a solution for this which is the
gpio_request_enable pinmux operation but it's not supposed to be used on
pinctrl drivers that cannot control pins individually.
Sergio, you think we can somehow make this pinmux operation mux a pin
group as gpio instead of a single pin?
I am not an expert in pinmux drivers but I think there are strong
reasons why only a single pin is allowed to be requested.
See kernel doc about this here: [1]
Or introduce a new pinmux operation that can do
Interactive boot
Hello,
Over the past few years I've had to troubleshoot a lot of things in the
boot process and I finally decided that I need an interactive boot
feature to OpenWRT. It will make troubleshooting and debugging easier,
but it will also provide a nice way to hack the boot process and explore
how OpenWRT works and interacts with the kernel.
I have it working all through initd, kmodloader for /etc/modules-boot.d
(preinit still occurs atomically) and part of procd's init process, but
now that I better understand the whole of the init process and related
sources, it's time for me to redesign it and start over.
My current patch set is based upon v21.02.0 and is enabled by a new
CONFIG_TARGET_DIAGNOSTICS under menuconfig --> "Image configuration".
Makefiles for libubox, procd and ubox pick up this value and pass
-DDIAGNOSTICS=1 to CMake which adds the same to CPPFLAGS. Thus, when it
is not enabled, there is zero or nearly zero increase to executable size
(.text, .data, .bss, etc.) or performance degredation and I would
propose rolling failsafe boot into this option, since they are both
insecure. The feature is triggered by adding the "debug" or "debug=1"
to /proc/cmdline and I've also added options to set the debug level for
a few programs as well:
[5.384877] mtk_soc_eth 1010.ethernet eth0: port 4 link up (10Mbps/Full
duplex)
[6.578771] init: Console is alive
[6.589791] init: init_debug2
[6.590002] init: debug 1
[6.597260] init: kmod_debug2
[6.604249] init: plugd_debug 0
[6.611317] init: preinit_debug 0
[6.618390] init: procd_debug 2
[6.625462] init: nowatchdog1
[6.632533] init: Initing diagnostics
"nowatchdog" is mostly there for running kdb/kgdb and everything else
works (or eventually will) with watchdog enabled. (I'll also eventually
need a way to manage the console transition for launching kgdb over the
serial port.)
After hacking at this some, I thought that having a "diagd" daemon that
controls the console would be the best approach and using ubus would
probably be the optimal way to facilitate that, but we don't have ubus
until fairly late the STATE_UBUS stage of procd. I could possibly just
have a non-ubus daemon with it's own socket, but that seems like a waste.
I haven't dug deeply into ubus sources yet, so what does ubus need to
run aside from /tmp being mounted?
Another option is similar to what I'm doing now -- a collection of
functions in libubox that init, procd, kmodloader, udevtrigger, etc.
call to provide the functionality. But this makes state management a mess.
I use Gentoo on my workstation and my initial thought was an interactive
process similar to that -- a linear set of services that should be
started or skipped. But in OpenWRT we have several levels, more like
stepping through code in a debugger. The transition from initd to procd
with PID=1 doesn't need a logical separation, so I keep these at the
same level and end up with this:
enum initd_state {
STATE_INITD_EARLY, /* initd early() */
STATE_KMOD_BOOT,/* initd: /sbin/kmodloader /etc/modules-boot.d
*/
STATE_PLUGD,/* initd: /sbin/procd -h
/etc/hotplug-preinit.json */
STATE_PREINIT, /* initd: /bin/sh /etc/preinit */
STATE_CHECK_SYSUPGRADE, /* initd: check_sysupgrade() */
STATE_PROCD,/* execvp /sbin/procd */
STATE_PROCD_EARLY, /* procd: hotplug and coldplug */
STATE_UBUS, /* procd: start ubus and connect to it */
STATE_INITTAB, /* procd: inittab */
STATE_RUNNING,
STATE_SHUTDOWN,
STATE_HALT,
STATE_COUNT
};
So when walking through STATE_KMOD_BOOT, I have prompts something like this:
[4.320805] Run /sbin/init as init process
...
[6.632533] init: Initing diagnostics
KMOD_BOOT [y/n], [f/F]inish, [c]ontinue, [s]hell, [m]ore
y
[ 178.174792] init: Starting /sbin/kmodloader
[ 178.299030] kmodloader: Interactive mode enabled.
[ 186.055402] kmodloader: loading kernel modules from /etc/modules-boot.d/*
KMOD_BOOT: crypto_hash [y/n], [f]inish, [c]ontinue, [s]hell, [m]ore
m
KMOD_BOOT: crypto_hash [y/n], [f]inish, [c]ontinue, [s]hell, re[b]oot, debu[g],
[h]elp, [l]ess
h
[y]es start/run 'KMOD_BOOT: crypto_hash'
[n]o skip it
[f]inish finish all of KMOD_BOOT
[c]ontinue exit interactive mode and continue
[s]hellrun a shell
re[b]oot immediately reboot without syncing (requires sysrq kernel support)
[d]ebugstart kdb (requires kernel support) (FIXME: disable watchdog)
[m]ore show all options
[l]ess show fewer options
Of course, this is pretty visually ugly right now, I think it would be
easier to read if the levels were displayed something like this (and
probably with some ANSI colors):
kmodloader (modules-boot.d):
usb-common:
[y/n], [f]inish, [c]ontinue, [s]hell, [m]ore?
And for services at state STATE_INITTAB:
inittab:
sysinit:
[no subject]
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 ---
Hello Jeffery,
Thank you for the wonderful work on maintaining the Go packages!
I got a little irritated at CGo's restriction of arch flags (in the
immutable GOGCCFLAGS variable) and put together a patch set for v19.07
to override them with an environment variable and then (optionally) feed
the machine flags in the Golang build. In the OpenWRT repo, I did this
by splitting out how DEFAULT_CFLAGS are put together in order to
populate a DEFAULT_MACHINE_FLAGS, but it could probably be done with
just a $(filter -m%,$(DEFAULT_CFLAGS)) instead.
If you or others have any interest in this, I can clean them up for the
master branch. I'm probably going to submit the Golang patch upstream,
since I don't see any good reason for such a restriction. I see you've
made a lot of changes on the HEAD.
Daniel
>From f1c770216e4eadaa641fb4f9894576358df5cf74 Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Sun, 13 Sep 2020 20:49:06 -0500
Subject: Goloang: Add customizable ARCH flags via CGO_MACHINE_FLAGS
Adds the option to override Golang's choice of architecture-specific
machine flags with arbitrary values via the environment variable
CGO_MACHINE_FLAGS. Then we supply those via the MACHINE_FLAGS make
variable fed from CONFIG_MACHINE_FLAGS from .config.
Signed-off-by: Daniel Santos
---
lang/golang/golang-package.mk | 1 +
lang/golang/golang-values.mk | 2 +-
...GS-to-override-hard-coded-arch-flags.patch | 28 +++
3 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
diff --git a/lang/golang/golang-package.mk b/lang/golang/golang-package.mk
index 73c6572a9..e3bbab6bc 100644
--- a/lang/golang/golang-package.mk
+++ b/lang/golang/golang-package.mk
@@ -154,6 +154,7 @@ define GoPackage/Environment/Default
GOMIPS=$(GO_MIPS) \
GOMIPS64=$(GO_MIPS64) \
CGO_ENABLED=1 \
+ CGO_MACHINE_FLAGS="$(MACHINE_FLAGS)" \
CGO_CFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CFLAGS))" \
CGO_CPPFLAGS="$(TARGET_CPPFLAGS)" \
CGO_CXXFLAGS="$(filter-out $(GO_CFLAGS_TO_REMOVE),$(TARGET_CXXFLAGS))"
diff --git a/lang/golang/golang-values.mk b/lang/golang/golang-values.mk
index 8989a1af4..a5a8c9502 100644
--- a/lang/golang/golang-values.mk
+++ b/lang/golang/golang-values.mk
@@ -16,7 +16,7 @@ unexport \
GOARCH GOBIN GOCACHE GOFLAGS GOHOSTARCH GOOS GOPATH GORACE GOROOT GOTMPDIR GCCGO \
GOGC GODEBUG GOMAXPROCS GOTRACEBACK \
CGO_ENABLED \
- CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW \
+ CGO_CFLAGS CGO_CFLAGS_ALLOW CGO_CFLAGS_DISALLOW CGO_MACHINE_FLAGS \
CGO_CPPFLAGS CGO_CPPFLAGS_ALLOW CGO_CPPFLAGS_DISALLOW \
CGO_CXXFLAGS CGO_CXXFLAGS_ALLOW CGO_CXXFLAGS_DISALLOW \
CGO_FFLAGS CGO_FFLAGS_ALLOW CGO_FFLAGS_DISALLOW \
diff --git a/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
new file mode 100644
index 0..377c0a447
--- /dev/null
+++ b/lang/golang/golang/patches/400-Add-CGO_MACHINE_FLAGS-to-override-hard-coded-arch-flags.patch
@@ -0,0 +1,28 @@
+From 6a5ab9c65b1930377d42b9ffeea93684586685ef Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Sun, 13 Sep 2020 20:45:55 -0500
+Subject: Add CGO_MACHINE_FLAGS to override hard-coded flags
+
+Adds CGO_MACHINE_FLAGS to add a mechanism to correct machine flags when
+the hard-coded ones chosen by Google are wrong or sub-optimal.
+---
+ src/cmd/go/internal/work/exec.go | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/cmd/go/internal/work/exec.go b/src/cmd/go/internal/work/exec.go
+index 892e3cb500..6fa050fd38 100644
+--- a/src/cmd/go/internal/work/exec.go
b/src/cmd/go/internal/work/exec.go
+@@ -2400,6 +2400,9 @@ func (b *Builder) gccSupportsFlag(compiler []string, flag string) bool {
+
+ // gccArchArgs returns arguments to pass to gcc based on the architecture.
+ func (b *Builder) gccArchArgs() []string {
++ if af := os.Getenv("CGO_MACHINE_FLAGS"); af != "" {
++ return strings.Fields(af)
++ }
+ switch cfg.Goarch {
+ case "386":
+ return []string{"-m32"}
+--
+2.24.1
+
--
2.24.1
>From 985f3a6cc0c9fe69e441f17dfb6fcc77fbef68a9 Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Sun, 13 Sep 2020 22:31:14 -0500
Subject: Add MACHINE_FLAGS for use by Golang
This splits up the DEFAULT_CFLAGS --> TARGET_OPTIMIZATIONS flag
generation process, separating out the machine-specific flags. This is
currently only used in a Golang patch to better control how CGo
generates code.
Signed-off-by: Da
Re: [PATCH] musl: fix signed compare warning
On 7/4/20 10:19 AM, Hauke Mehrtens wrote:
> On 6/25/20 1:12 AM, Daniel Santos wrote:
>> Signed-off-by: Daniel Santos
>> ---
>> .../210-Fix-signed-compare-warning.patch | 26 +++
>> 1 file changed, 26 insertions(+)
>> create mode 100644
>> toolchain/musl/patches/210-Fix-signed-compare-warning.patch
>>
>> diff --git a/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
>> b/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
>> new file mode 100644
>> index 00..5d5d2f865e
>> --- /dev/null
>> +++ b/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
>> @@ -0,0 +1,26 @@
>> +From 7627aac4e5381546baeb0d6bef6675e9107cd751 Mon Sep 17 00:00:00 2001
>> +From: Daniel Santos
>> +Date: Sat, 25 Apr 2020 12:18:15 -0500
>> +Subject: Fix signed compare warning
>> +
>> +Signed-off-by: Daniel Santos
>> +---
>> + src/thread/__timedwait.c | 2 +-
>> + 1 file changed, 1 insertion(+), 1 deletion(-)
>> +
>> +diff --git a/src/thread/__timedwait.c b/src/thread/__timedwait.c
>> +index 666093be..9829b93e 100644
>> +--- a/src/thread/__timedwait.c
>> b/src/thread/__timedwait.c
>> +@@ -38,7 +38,7 @@ int __timedwait_cp(volatile int *addr, int val,
>> +if (priv) priv = FUTEX_PRIVATE;
>> +
>> +if (at) {
>> +- if (at->tv_nsec >= 10UL) return EINVAL;
>> ++ if ((unsigned long)at->tv_nsec >= 10UL) return EINVAL;
>> +if (__clock_gettime(clk, )) return EINVAL;
>> +to.tv_sec = at->tv_sec - to.tv_sec;
>> +if ((to.tv_nsec = at->tv_nsec - to.tv_nsec) < 0) {
>> +--
>> +2.24.1
>> +
>>
> Thank you for also sending this to upstream musl.
>
> As this was rejected upstream I would also reject it for OpenWrt for now:
> https://www.openwall.com/lists/musl/2020/06/26/4
>
> Hauke
>
Thank you Hauke. It appears that the musl mailing list is "reply to
list only", so I didn't see the response! I've updated my mail filters
so I'll get them in my inbox in the future.
I'm not sure how to follow up the upstream response. I like warnings,
but I'm guessing upstream relies on rigorous scrutiny over warnings.
Either way, if we enable -Wextra in OpenWRT (or elsewhere, as I had),
we'll want to add -Wno-sign-compare. It would be good to document this
somewhere.
Anyway, thank you.
Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] musl: add debug information for mipsel syscalls
This is split into two patches to ease reviewing, as it must be renamed
to *.S in order to be preprocessed.
Co-Authored-By: Daniele Tamino
Signed-off-by: Daniel Santos
---
...ebug-information-to-__syscall_cp_asm.patch | 100 ++
.../221-mipsel-preprocess-syscall_cp.s.patch | 18
2 files changed, 118 insertions(+)
create mode 100644
toolchain/musl/patches/220-mipsel-Add-debug-information-to-__syscall_cp_asm.patch
create mode 100644
toolchain/musl/patches/221-mipsel-preprocess-syscall_cp.s.patch
diff --git
a/toolchain/musl/patches/220-mipsel-Add-debug-information-to-__syscall_cp_asm.patch
b/toolchain/musl/patches/220-mipsel-Add-debug-information-to-__syscall_cp_asm.patch
new file mode 100644
index 00..0aa9330bd4
--- /dev/null
+++
b/toolchain/musl/patches/220-mipsel-Add-debug-information-to-__syscall_cp_asm.patch
@@ -0,0 +1,100 @@
+From 6ce77039943af4ca51ebf1385fd6ed01ecce8159 Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Wed, 24 Jun 2020 14:45:08 -0500
+Subject: mipsel: Add debug information to __syscall_cp_asm
+
+This is the function called for interruptable / repeatable syscalls like
+nanosleep. Without this patch, attaching a debugger to a program making
+such a syscall results in the debugger being completely unable to
+perform a backtrace.
+
+Co-Authored-By: Daniele Tamino
+Signed-off-by: Daniel Santos
+---
+ src/thread/mips/syscall_cp.s | 41 +++-
+ 1 file changed, 40 insertions(+), 1 deletion(-)
+
+diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s
+index d2846264..d39bff59 100644
+--- a/src/thread/mips/syscall_cp.s
b/src/thread/mips/syscall_cp.s
+@@ -1,4 +1,14 @@
++.section .mdebug.abi32
++.previous
+ .setnoreorder
++.cfi_sections .debug_frame
++.abicalls
++#ifdef __PIC__
++ .option pic2
++#else
++ .option pic0
++#endif
++.text
+
+ .global __cp_begin
+ .hidden __cp_begin
+@@ -9,12 +19,32 @@
+ .global __cp_cancel
+ .hidden __cp_cancel
+ .type __cp_cancel,@function
+-.hidden __cancel
++.hidden __cancel /* long __cancel() in src/thread/pthread_cancel.c */
+ .global __syscall_cp_asm
+ .hidden __syscall_cp_asm
+ .type __syscall_cp_asm,@function
++
++/*
++long __syscall_cp_asm(
++ volatile int *cancel,
++ syscall_arg_t nr,
++ syscall_arg_t u,
++ syscall_arg_t v,
++ syscall_arg_t w,
++ syscall_arg_t x,
++ syscall_arg_t y,
++ syscall_arg_t z)
++*/
++
++ .ent__syscall_cp_asm
++ .frame $sp, 32, $ra
++ .mask 0x, 0
++ .fmask 0x, 0
++ .cfi_startproc
++ .cfi_return_column $ra
+ __syscall_cp_asm:
+ subu$sp, $sp, 32
++ .cfi_adjust_cfa_offset 32
+ __cp_begin:
+ lw $4, 0($4)
+ bne $4, $0, __cp_cancel
+@@ -35,14 +65,17 @@ __cp_begin:
+ __cp_end:
+ beq $7, $0, 1f
+ addu$sp, $sp, 32
++ .cfi_adjust_cfa_offset -32
+ subu$2, $0, $2
+ 1:jr $ra
+ nop
+
+ __cp_cancel:
+ move$2, $ra
++ .cfi_register $ra, $2
+ bal 1f
+ addu$sp, $sp, 32
++ .cfi_adjust_cfa_offset -32
+ .gpword .
+ .gpword __cancel
+ 1:lw $3, ($ra)
+@@ -51,3 +84,9 @@ __cp_cancel:
+ addu$25, $25, $3
+ jr $25
+ move$ra, $2
++ .cfi_restore $ra
++#ifdef __ELF__
++ .size __syscall_cp_asm,.-__syscall_cp_asm
++#endif
++ .end__syscall_cp_asm
++ .cfi_endproc
+--
+2.24.1
+
diff --git a/toolchain/musl/patches/221-mipsel-preprocess-syscall_cp.s.patch
b/toolchain/musl/patches/221-mipsel-preprocess-syscall_cp.s.patch
new file mode 100644
index 00..a4eb8fed51
--- /dev/null
+++ b/toolchain/musl/patches/221-mipsel-preprocess-syscall_cp.s.patch
@@ -0,0 +1,18 @@
+From 76cfae6e5a22dca17ff2ffa196b3ad2a3537 Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Wed, 24 Jun 2020 14:46:15 -0500
+Subject: mipsel: preprocess syscall_cp.s
+
+Signed-off-by: Daniel Santos
+---
+ src/thread/mips/{syscall_cp.s => syscall_cp.S} | 0
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename src/thread/mips/{syscall_cp.s => syscall_cp.S} (100%)
+
+diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.S
+similarity index 100%
+rename from src/thread/mips/syscall_cp.s
+rename to src/thread/mips/syscall_cp.S
+--
+2.24.1
+
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel
[PATCH] musl: fix signed compare warning
Signed-off-by: Daniel Santos
---
.../210-Fix-signed-compare-warning.patch | 26 +++
1 file changed, 26 insertions(+)
create mode 100644 toolchain/musl/patches/210-Fix-signed-compare-warning.patch
diff --git a/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
b/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
new file mode 100644
index 00..5d5d2f865e
--- /dev/null
+++ b/toolchain/musl/patches/210-Fix-signed-compare-warning.patch
@@ -0,0 +1,26 @@
+From 7627aac4e5381546baeb0d6bef6675e9107cd751 Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Sat, 25 Apr 2020 12:18:15 -0500
+Subject: Fix signed compare warning
+
+Signed-off-by: Daniel Santos
+---
+ src/thread/__timedwait.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/thread/__timedwait.c b/src/thread/__timedwait.c
+index 666093be..9829b93e 100644
+--- a/src/thread/__timedwait.c
b/src/thread/__timedwait.c
+@@ -38,7 +38,7 @@ int __timedwait_cp(volatile int *addr, int val,
+ if (priv) priv = FUTEX_PRIVATE;
+
+ if (at) {
+- if (at->tv_nsec >= 10UL) return EINVAL;
++ if ((unsigned long)at->tv_nsec >= 10UL) return EINVAL;
+ if (__clock_gettime(clk, )) return EINVAL;
+ to.tv_sec = at->tv_sec - to.tv_sec;
+ if ((to.tv_nsec = at->tv_nsec - to.tv_nsec) < 0) {
+--
+2.24.1
+
--
2.24.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Adding CONFIG_SAVE_DEBUG
Hello, I'm developing commercial hardware using OpenWRT, so there are a lot of things we need to be able to do that any commercial product should have, like to be able to save debug symbols for remote debugging, even though all executables in the firmware are stripped. Invariably, things blow up and we need to be able to debug those. The first challenge seem to be that the stripping is done prior to installing, so that action is not connected with the location the binary is going to end up. The second is that the way packages are installed varies -- rather than using the autotools install target, some are calling $(CP) to do it, which isn't so easy to hook. Given this, what would be a good way to get debug symbols for everything? Maybe clear STRIP and RSTRIP, but then hook the phase that installs packages into rootfs and strip them there? If so, are we saving data anywhere in the package builds that say which are binaries and which aren't? I know that's easy enough to sniff, but I would rather a package say how each file should be treated. Any guidance appreciated!! Thanks, Daniel PS: I'm working with Global Satellite Engineering these days, but I'm subscribed to all of my mailing lists on my personal account. PPS: In 2018, they sent OpenWRT into space on a Blue Origin rocket as part of a pilot program! :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] mt7620/1, mt7530: Where are these MAC and MII registers documented?
I've been told in #openwrt-devel on freenode that this is from an
OpenWRT SDK that MediaTek has released. Does anybody know the link on
their web site for this?
On 6/28/19 4:55 PM, Daniel Santos wrote:
> Hello,
>
> I'm looking at the mt7620 Ethernet driver and I see a lot of magic
> happening for which I cannot find documentation anywhere. Can anybody
> tell me where I can get the datasheets / programmer's guide that
> document these registers please?
>
> Examples:
> I/O to 0x7830, 0x7a40 -- Entries in the WAPI table? That seems strange.
>
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf); The mt7620
> programming guide only documents 0-6, while the 802.3-2005 has
> everything from 16-31 marked as "vendor specific". Also, what does port
> 31 do?
>
> From the current OpenWRT head:
>
> static void mt7620_hw_init(struct mt7620_gsw *gsw, int mdio_mode)
> {
> u32 i;
> u32 val;
> u32 is_BGA = (rt_sysc_r32(0x0c) >> 16) & 1;
>
> rt_sysc_w32(rt_sysc_r32(SYSC_REG_CFG1) | BIT(8), SYSC_REG_CFG1);
> mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_CKGCR) & ~(0x3 << 4),
> GSW_REG_CKGCR);
>
> /* Enable MIB stats */
> mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_MIB_CNT_EN) | (1 << 1),
> GSW_REG_MIB_CNT_EN);
>
> if (mdio_mode) {
> u32 val;
>
> /* turn off ephy and set phy base addr to 12 */
> mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
> (0x1f << 24) | (0xc << 16),
> GSW_REG_GPC1);
>
> /* set MT7530 central align */
> val = mt7530_mdio_r32(gsw, 0x7830);
> val &= ~BIT(0);
> val |= BIT(1);
> mt7530_mdio_w32(gsw, 0x7830, val);
>
> val = mt7530_mdio_r32(gsw, 0x7a40);
> val &= ~BIT(30);
> mt7530_mdio_w32(gsw, 0x7a40, val);
>
> mt7530_mdio_w32(gsw, 0x7a78, 0x855);
> } else {
>
> if (gsw->ephy_base) {
> /* set phy base addr to ephy_base */
> mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
> (gsw->ephy_base << 16),
> GSW_REG_GPC1);
> fe_reset(BIT(24)); /* Resets the Ethernet PHY block. */
> }
>
> /* global page 4 */
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x4000);
>
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x7444);
> if (is_BGA)
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0114);
> else
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0117);
>
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x6212);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0777);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 29, 0x4000);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 28, 0xc077);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x);
>
> /* global page 3 */
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x3000);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x4838);
>
> /* global page 2 */
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x2000);
> if (is_BGA) {
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0515);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0053);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aaf);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x0fad);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fc1);
> } else {
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0517);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0fd2);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aab);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x00ae);
> _mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fff);
> }
>
[OpenWrt-Devel] mt7620/1, mt7530: Where are these MAC and MII registers documented?
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 ---
Hello,
I'm looking at the mt7620 Ethernet driver and I see a lot of magic
happening for which I cannot find documentation anywhere. Can anybody
tell me where I can get the datasheets / programmer's guide that
document these registers please?
Examples:
I/O to 0x7830, 0x7a40 -- Entries in the WAPI table? That seems strange.
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf); The mt7620
programming guide only documents 0-6, while the 802.3-2005 has
everything from 16-31 marked as "vendor specific". Also, what does port
31 do?
>From the current OpenWRT head:
static void mt7620_hw_init(struct mt7620_gsw *gsw, int mdio_mode)
{
u32 i;
u32 val;
u32 is_BGA = (rt_sysc_r32(0x0c) >> 16) & 1;
rt_sysc_w32(rt_sysc_r32(SYSC_REG_CFG1) | BIT(8), SYSC_REG_CFG1);
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_CKGCR) & ~(0x3 << 4),
GSW_REG_CKGCR);
/* Enable MIB stats */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_MIB_CNT_EN) | (1 << 1),
GSW_REG_MIB_CNT_EN);
if (mdio_mode) {
u32 val;
/* turn off ephy and set phy base addr to 12 */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
(0x1f << 24) | (0xc << 16),
GSW_REG_GPC1);
/* set MT7530 central align */
val = mt7530_mdio_r32(gsw, 0x7830);
val &= ~BIT(0);
val |= BIT(1);
mt7530_mdio_w32(gsw, 0x7830, val);
val = mt7530_mdio_r32(gsw, 0x7a40);
val &= ~BIT(30);
mt7530_mdio_w32(gsw, 0x7a40, val);
mt7530_mdio_w32(gsw, 0x7a78, 0x855);
} else {
if (gsw->ephy_base) {
/* set phy base addr to ephy_base */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
(gsw->ephy_base << 16),
GSW_REG_GPC1);
fe_reset(BIT(24)); /* Resets the Ethernet PHY block. */
}
/* global page 4 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x4000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x7444);
if (is_BGA)
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0114);
else
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0117);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x6212);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0777);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 29, 0x4000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 28, 0xc077);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x);
/* global page 3 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x3000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x4838);
/* global page 2 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x2000);
if (is_BGA) {
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0515);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0053);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aaf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x0fad);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fc1);
} else {
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0517);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0fd2);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aab);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x00ae);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fff);
}
/* global page 1 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x1000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0xe7f8);
/* turn on all PHYs */
for (i = 0; i <= 4; i++) {
val = _mt7620_mii_read(gsw, gsw->ephy_base + i, 0);
val &= ~BIT(11);
_mt7620_mii_write(gsw, gsw->ephy_base + i, 0, val);
}
[OpenWrt-Devel] mt7620/1, mt7530: Where are these MAC and MII registers documented?
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 ---
Hello,
I'm looking at the mt7620 Ethernet driver and I see a lot of magic
happening for which I cannot find documentation anywhere. Can anybody
tell me where I can get the datasheets / programmer's guide that
document these registers please?
Examples:
I/O to 0x7830, 0x7a40 -- Entries in the WAPI table? That seems strange.
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf); The mt7620
programming guide only documents 0-6, while the 802.3-2005 has
everything from 16-31 marked as "vendor specific". Also, what does port
31 do?
>From the current OpenWRT head:
static void mt7620_hw_init(struct mt7620_gsw *gsw, int mdio_mode)
{
u32 i;
u32 val;
u32 is_BGA = (rt_sysc_r32(0x0c) >> 16) & 1;
rt_sysc_w32(rt_sysc_r32(SYSC_REG_CFG1) | BIT(8), SYSC_REG_CFG1);
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_CKGCR) & ~(0x3 << 4),
GSW_REG_CKGCR);
/* Enable MIB stats */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_MIB_CNT_EN) | (1 << 1),
GSW_REG_MIB_CNT_EN);
if (mdio_mode) {
u32 val;
/* turn off ephy and set phy base addr to 12 */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
(0x1f << 24) | (0xc << 16),
GSW_REG_GPC1);
/* set MT7530 central align */
val = mt7530_mdio_r32(gsw, 0x7830);
val &= ~BIT(0);
val |= BIT(1);
mt7530_mdio_w32(gsw, 0x7830, val);
val = mt7530_mdio_r32(gsw, 0x7a40);
val &= ~BIT(30);
mt7530_mdio_w32(gsw, 0x7a40, val);
mt7530_mdio_w32(gsw, 0x7a78, 0x855);
} else {
if (gsw->ephy_base) {
/* set phy base addr to ephy_base */
mtk_switch_w32(gsw, mtk_switch_r32(gsw, GSW_REG_GPC1) |
(gsw->ephy_base << 16),
GSW_REG_GPC1);
fe_reset(BIT(24)); /* Resets the Ethernet PHY block. */
}
/* global page 4 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x4000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x7444);
if (is_BGA)
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0114);
else
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 19, 0x0117);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x10cf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x6212);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0777);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 29, 0x4000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 28, 0xc077);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x);
/* global page 3 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x3000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0x4838);
/* global page 2 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x2000);
if (is_BGA) {
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0515);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0053);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aaf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x0fad);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fc1);
} else {
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 21, 0x0517);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 22, 0x0fd2);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 23, 0x00bf);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 24, 0x0aab);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 25, 0x00ae);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 26, 0x0fff);
}
/* global page 1 */
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 31, 0x1000);
_mt7620_mii_write(gsw, gsw->ephy_base + 1, 17, 0xe7f8);
/* turn on all PHYs */
for (i = 0; i <= 4; i++) {
val = _mt7620_mii_read(gsw, gsw->ephy_base + i, 0);
val &= ~BIT(11);
_mt7620_mii_write(gsw, gsw->ephy_base + i, 0, val);
}
Re: [OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> MII vs I/O --> MAC) for mt7620 (OpenWRT)
Ah hah! I've found my answer on page 340 (414. PIAC: PHY Indirect Access
Control(offset:0x7004)) and in mt7620_gsw_config:
static int mt7620_gsw_config(struct fe_priv *priv)
{
struct mt7620_gsw *gsw = (struct mt7620_gsw *) priv->soc->swpriv;
/* is the mt7530 internal or external */
if (priv->mii_bus && mdiobus_get_phy(priv->mii_bus, 0x1f)) {
mt7530_probe(priv->dev, gsw->base, NULL, 0);
mt7530_probe(priv->dev, NULL, priv->mii_bus, 1);
} else {
mt7530_probe(priv->dev, gsw->base, NULL, 1);
}
return 0;
}
So priv->mii_bus is non-null when the chip's network hardware is
external because the similarly (and confusingly) named mt7530 is only
the switch hardware, where as the mt7620 is a full µC that has an mt7530
integrated into it. Which leads me to the question of what "GSW"
means? This is the name of the hardware that has the PIAC register, but
nowhere in the data sheet or programming guide can I find a definition.
Thanks,
Daniel
On 6/14/19 5:53 PM, Daniel Santos wrote:
> Hello,
>
> I'm still fairly new to Ethernet drivers and there are a lot of
> interesting pieces. What I need help with is understanding MDIO -->
> (R)MII vs direct I/O to the MAC (e.g., via ioread32, iowrite32). Why is
> there not always a struct mii_bus to talk to this hardware? Is it
> because the PHY and/or MAC hardware sometimes attached via an MDIO
> device and sometimes directly to the I/O bus? Or does some type of
> "indirect access" need to be enabled for that to work?
>
> I might be trying to do something that's unnecessary however, I'm not
> sure yet. I need to add functionality to change a port's
> auto-negotiate, duplex, etc. I'm adding it to the swconfig first and
> then will look at adding it for DSA afterwards. When I run "swconfig
> dev switch0 port 0 show", the current mt7530 / mt7620 driver is querying
> the MAC status register (at base + 0x3008 + 0x100 * port, described on
> pages 323-324 of the MT7620 Programming Guide), so I implemented the
> "set" functionality by modifying the MAC's control register (offset
> 0x3000 on page 321), but it doesn't seem to change anything. So I
> figured maybe I need to modify the MII interface's control register for
> the port (page 350), but upon debugging I can see that the struct
> mii_bus *bus member is NULL.
>
> So should I be able to change it via the MAC's control register and
> something else is wrong? Why is there no struct mii_bus? Can I talk to
> the MII hardware in some other way?
>
> Thanks,
> Daniel
>
> https://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Understanding Ethernet Architecture (I/O --> MDIO --> MII vs I/O --> MAC) for mt7620 (OpenWRT)
Hello, I'm still fairly new to Ethernet drivers and there are a lot of interesting pieces. What I need help with is understanding MDIO --> (R)MII vs direct I/O to the MAC (e.g., via ioread32, iowrite32). Why is there not always a struct mii_bus to talk to this hardware? Is it because the PHY and/or MAC hardware sometimes attached via an MDIO device and sometimes directly to the I/O bus? Or does some type of "indirect access" need to be enabled for that to work? I might be trying to do something that's unnecessary however, I'm not sure yet. I need to add functionality to change a port's auto-negotiate, duplex, etc. I'm adding it to the swconfig first and then will look at adding it for DSA afterwards. When I run "swconfig dev switch0 port 0 show", the current mt7530 / mt7620 driver is querying the MAC status register (at base + 0x3008 + 0x100 * port, described on pages 323-324 of the MT7620 Programming Guide), so I implemented the "set" functionality by modifying the MAC's control register (offset 0x3000 on page 321), but it doesn't seem to change anything. So I figured maybe I need to modify the MII interface's control register for the port (page 350), but upon debugging I can see that the struct mii_bus *bus member is NULL. So should I be able to change it via the MAC's control register and something else is wrong? Why is there no struct mii_bus? Can I talk to the MII hardware in some other way? Thanks, Daniel https://download.villagetelco.org/hardware/MT7620/MT7620_ProgrammingGuide.pdf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using ethtool or swconfig to change link settings for mt7620a?
Hello Daniel, Thanks for your help! On 6/8/19 6:51 AM, Daniel Golle wrote: > Hi Daniel, > > On Sat, Jun 08, 2019 at 04:06:54AM -0500, Daniel Santos wrote: >> Hello, >> >> I need to change auto-negotiate, speed and duplex for a port on my >> mt7620a-based device, but I'm not quite certain that I understand the >> structure here. When using ethtool on eth0 I always get ENODEV, >> apparently because priv->phy_dev is always NULL in fe_get_link_ksettings >> of drivers/net/ethernet/mtk/ethtool.c. But I'm being told that eth0 is >> only an internal device between the µC and the switch hardware, so it >> isn't even the one I need to change. > That's correct. It always helps when my idea about what I'm doing matches reality. >> If this is true, then it looks like I will need to implement a >> get_port_link function for struct switch_dev_ops? Can anybody confirm >> this to be the case? Also, are there any examples aside from the >> Broadcom drivers? I have the mt7620 programmer's guide and it specifies >> the registers I need to change. > Currently MT7620 still uses our legacy swconfig switch driver, which > also doesn't support setting autoneg, speed and duplex. However, rather > than implementing it there, it'd be great to add support for the FE- > version of the MT7530 swtich found in the MT7620(A/N) WiSoC to the now > upstream DSA driver[1]. Ok, this makes much more sense now. So swconfig is on its way out in favor of DSA (which I've never heard of until now)? I presume this will also abstract away changes of ethtool to netlink-based instead of ioctl on a random socket as well? > While this driver was originally intended for > use with standalone MT7530 GE switch chip or the ARM-based MT7623 SoC, > the same switch fabric is also implemented in MT7621 and support for > that chip was added to the driver recently[2]. MT7620 basically also > features the same switch internally, however, it comes with only one > CPU port, supports only FastEthernet and lacks some of the management > counters. > > Assuming your MT7620 datasheet includes the decription of the MT7530 > switch registers, it'd be great if you can help working on supporting > MT7620 in the DSA driver as well -- gaining per-port ethtool support > as a reward :) Wonderful! So if I understand correctly, this is the same switch hardware (internally at least), so has all of the same MAC and MII registers on 7530, 7621, 7620, etc? For now I have to get a fix for a customer on a 3.18 kernel, so I'll be doing the swconfig first and then see how much time we can put into the DSA implementation. > > Cheers > > > Daniel > > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/mt7530.c > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ddda1ac116c852bb969541ed53cffef7255c4961 > Also, would you happen to know why the mt7620 mdio driver is using a 32-bit read for MII registers that are 32-bit? For example, in _mt7620_mii_read. It looks like some of this can use some improved error management, since return codes are being ignored in a few places. From what I can tell thus far, it looks like these MII registers are standardized, so the "generic" version might do most or all of what I need in some cases. But as far as implementing DSA, I guess I'll have to examine the mainlined driver and see how it works. I just didn't have a struct phy_device to work with when trying to get it to work. Thanks, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Using ethtool or swconfig to change link settings for mt7620a?
Hello, I need to change auto-negotiate, speed and duplex for a port on my mt7620a-based device, but I'm not quite certain that I understand the structure here. When using ethtool on eth0 I always get ENODEV, apparently because priv->phy_dev is always NULL in fe_get_link_ksettings of drivers/net/ethernet/mtk/ethtool.c. But I'm being told that eth0 is only an internal device between the µC and the switch hardware, so it isn't even the one I need to change. If this is true, then it looks like I will need to implement a get_port_link function for struct switch_dev_ops? Can anybody confirm this to be the case? Also, are there any examples aside from the Broadcom drivers? I have the mt7620 programmer's guide and it specifies the registers I need to change. Thanks, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH experimental] quilt: Build a kernel git tree
This is is mostly for those who've wanted something like this. It still
needs cleanup.
This patch enables OpenWRT to re-construct a kernel git tree instead of
just extracting and patching the kernel sources to an essentially
temporary directory. It's VERY helpful when you're trying to backport,
git-blame, or just understand why a change was made. Details are in the
patch message and Kconfig documentation.
If devs are interested in this patch for upstream I can clean it up.
As-is, it spits you to a shell if anything goes wrong, so only works
with -j1.
Daniel
>From 5c73c936e84b0eeb9f595b39488deceb5cb509ab Mon Sep 17 00:00:00 2001
From: Daniel Santos
Date: Tue, 30 Oct 2018 20:54:00 -0500
Subject: [PATCH] Add option to build external kernel tree (experimental)
This patch modifies quilt and adds the root .config options that can be
configured to cause the OpenWRT / quilt build to re-construct a real git
tree using a base git reference and then applying the kernel patches
using git am or git apply.
You only need to enable this and run the build one time, after which you
should generally disable the option and configure OpenWRT to *use* the
external kernel directory, which inhibits OpenWRT from reconstructing
(extracting and patching) your kernel tree.
This patch still needs cleanup (removal of commented out code, etc.)
land probably also refinement. Also, it is not perfect at
reconstructing the logical patch history due to the "files" directories
that must be applied as a set of mega-patches (one for generic and one
for the arch files), but it's step in the right direction.
Signed-off-by: Daniel Santos
---
config/Config-devel.in | 28 +
include/quilt.mk| 6 ++
scripts/patch-kernel.sh | 45 -
3 files changed, 74 insertions(+), 5 deletions(-)
diff --git a/config/Config-devel.in b/config/Config-devel.in
index fd7c3ead1e..06110a14da 100644
--- a/config/Config-devel.in
+++ b/config/Config-devel.in
@@ -73,6 +73,34 @@ menuconfig DEVEL
string "Use external kernel tree" if DEVEL
default ""
+ config EXTERNAL_KERNEL_TREE_BUILD_GIT
+ bool "Build git tree from OpenWRT patches." if DEVEL
+ depends on !KERNEL_GIT_CLONE_URI
+ default n
+ help
+ Uses git to clone the upstream kernel and then apply OpenWRT
+ patches with git-am or git-apply to create a proper Linux
+ kernel git tree.
+
+ TODO: needs more explanation.
+
+ config EXTERNAL_KERNEL_TREE_BUILD_GIT_URI
+ bool "Upstream git URI" if DEVEL
+ depends on EXTERNAL_KERNEL_TREE_BUILD_GIT
+ default "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;
+ help
+ Where to clone the Linux tree from. You probably want the
+ default unless you already have a local copy you want to
+ clone.
+
+ config EXTERNAL_KERNEL_TREE_BUILD_GIT_REF
+ bool "Local referenceBuild git tree from OpenWRT patches." if DEVEL
+ depends on EXTERNAL_KERNEL_TREE_BUILD_GIT
+ default ""
+ help
+ Use git clone --dissociate --reference-if-able
+ when cloning to reduce network traffic.
+
config KERNEL_GIT_CLONE_URI
string "Enter git repository to clone" if DEVEL
default ""
diff --git a/include/quilt.mk b/include/quilt.mk
index 61dcc7964c..1f52d53176 100644
--- a/include/quilt.mk
+++ b/include/quilt.mk
@@ -95,7 +95,13 @@ endef
kernel_files=$(foreach fdir,$(GENERIC_FILES_DIR) $(FILES_DIR),$(fdir)/.)
define Kernel/Patch/Default
$(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p $(PKG_BUILD_DIR)/patches)
+
+ #echo "copy files is next"
+ #read
$(if $(kernel_files),$(CP) $(kernel_files) $(LINUX_DIR)/)
+
+ #echo "remove (old?) rejects and patch..."
+ #read
find $(LINUX_DIR)/ -name \*.rej -or -name \*.orig | $(XARGS) rm -f
if [ -d $(GENERIC_PLATFORM_DIR)/patches$(if $(wildcard $(GENERIC_PLATFORM_DIR)/patches-$(KERNEL_PATCHVER)),-$(KERNEL_PATCHVER)) ]; then \
echo "generic patches directory is present. please move your patches to the pending directory" ; \
diff --git a/scripts/patch-kernel.sh b/scripts/patch-kernel.sh
index c2b7e72049..b52d16f61c 100755
--- a/scripts/patch-kernel.sh
+++ b/scripts/patch-kernel.sh
@@ -18,7 +18,20 @@ if [ ! -d "${patchdir}" ] ; then
echo "Aborting. '${patchdir}' is not a directory."
exit 1
fi
-
+
+fixit() {
+op="$1"
+file="$2"
+patch="$3"
+shift 3
+echo "$op failed on $file ($patch). $@"
+/bin/bash
+while [ -n "`git status --porcelain`" ]; do
+ echo "git repo not clean, please try again"
+ /bin/bash
+done
+}
+
for i in ${patchdir}/${patchpattern} ; do
case "$i" in
*.gz)
@@ -37,12 +50,34 @@ for i in ${patchdir}/${patchpattern} ; do
[ -d "${i}" ] && echo "Ignoring subdirectory ${i}" &
Re: [OpenWrt-Devel] [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage
On 11/24/18 8:05 AM, Hauke Mehrtens wrote: > On 10/19/18 10:59 AM, Daniel Santos wrote: > [snip] > We would like to reduce the number of patches we ship in OpenWrt on top > of the mainline Linux kernel. > > Please send this to the upstream Maintainer of the jffs driver in the > mainline Linux kernel for integration into the mainline Linux kernel. If > this was accepted in some maintainers tree please provide the link to > the commit. > > Hauke > Hello Hauke, Here ya go: http://git.infradead.org/linux-mtd.git/commit/a788c5272769ddbcdbab297cf386413eeac04463 Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
I have confirmation. Just commenting out the printk solves the problem. Tested with 15 WiFi connections, some watching youtube. A few better fixes to be proposed shortly. Headed off to bed now :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] build: re-enable parallelism for mksquashfs
Ahh, thank you both for the clarification. On 11/08/2018 01:35 AM, Felix Fietkau wrote: > On 2018-11-08 02:20, Daniel Santos wrote: >> On 11/07/2018 01:52 PM, Felix Fietkau wrote: >>> On 2018-11-05 00:19, Daniel Santos wrote: >>>> This was disabled by commit dcd0e4a6727611f03eb3d3a75f073235f5f1229c due >>>> to a threading bug back in 2009. The specifics of the bug are not given >>>> in the commit message and squashfs-tools has had several updates to it's >>>> parallelism since this time. There are currently no open issues related >>>> to parallelism in their issue tracker: >>>> https://github.com/plougher/squashfs-tools/issues >>>> >>>> It now "works for me" with 16 threads, and while this is a terrible test >>>> for a race condition I still propose we remove this work-around >>>> unless and until we have specific knowledge of a current bug. >>>> >>>> Signed-off-by: Daniel Santos >>> Are the images still reproducible after that change? >>> If I remember correctly, threading would break that. >> Hello. I'm not sure what you mean by the images being reproducible. >> I've been building with TARGET_ROOTFS_SQUASHFS=y and >> TARGET_ROOTFS_SQUASHFS=256 for a few weeks now without any problem. I'm >> presuming they've fixed it, but I didn't see specific mention of this >> bug in their github issue tracker. They may have discussed it elsewhere >> prior to porting to github. > Reproducible as in https://reproducible-builds.org/ > You're supposed to be able to generate the binary-identical rootfs image > on different machines, as long as you're using the same version and the > same configuration. > >From my understanding, using multiple threads for the squashfs build can > make the order in which data appears in the filesystem image > non-deterministic. > > - Felix I see. I have definitely not tested that. I would assume they could vary from one build to another based upon my understanding of how multi-threaded compression is done in general. How about a patch that allows multi-threaded compression via a .config option? Thanks, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] build: re-enable parallelism for mksquashfs
On 11/07/2018 01:52 PM, Felix Fietkau wrote: > On 2018-11-05 00:19, Daniel Santos wrote: >> This was disabled by commit dcd0e4a6727611f03eb3d3a75f073235f5f1229c due >> to a threading bug back in 2009. The specifics of the bug are not given >> in the commit message and squashfs-tools has had several updates to it's >> parallelism since this time. There are currently no open issues related >> to parallelism in their issue tracker: >> https://github.com/plougher/squashfs-tools/issues >> >> It now "works for me" with 16 threads, and while this is a terrible test >> for a race condition I still propose we remove this work-around >> unless and until we have specific knowledge of a current bug. >> >> Signed-off-by: Daniel Santos > Are the images still reproducible after that change? > If I remember correctly, threading would break that. > > - Felix > Hello. I'm not sure what you mean by the images being reproducible. I've been building with TARGET_ROOTFS_SQUASHFS=y and TARGET_ROOTFS_SQUASHFS=256 for a few weeks now without any problem. I'm presuming they've fixed it, but I didn't see specific mention of this bug in their github issue tracker. They may have discussed it elsewhere prior to porting to github. Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ralink: Add support for GPIO as interrupt-controller
On 11/05/2018 03:46 PM, Rosen Penev wrote: > On Mon, Nov 5, 2018 at 1:38 PM Daniel Santos wrote: >> Hello, >> >> First my apologies for not CCing you John, I'm not sure which address to >> use as I got a bounce from the blo...@openwrt.org address before. >> >> Rosen, >> >> I'm not too familiar with the mt7621 yet, I'm using an mt7620. All I >> know is that it has two cores and some crypto engine instead of wifi. >> Being that this is the drivers/gpio/gpio-ralink.c (a nice bland name) >> I'm going assume we're just talking about two different drivers. The >> compatible string for this one is "ralink,rt2880-gpio". > Ah I see. I think what threw me off was the patch name being 0029 as > 0028 is the mt7621 patch. Oh yeah! I should probably just rename 0028 to 0029 >> On 11/04/2018 10:27 PM, Rosen Penev wrote: >>> On Sun, Nov 4, 2018 at 6:49 PM Daniel Santos >>> wrote: >>>> The gpio-ralink driver has everything it needs to be used as an >>>> interrupt controller except for device tree support. This simple patch >>>> adds that support by configuring the irq domain to use two cells and >>>> adding the appropriate documentation to the devicetree bindings. >>> Note that there is a mainline driver that does this already: >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpio-mt7621.c?h=v4.19.1 >>> >>> I've backported it in my tree as well: >>> https://github.com/neheb/source/commit/aa3a57cdcf91a4483cfd511f8a34fb9a595f4af2 >>> >>> I have not submitted as I don't have hardware to test that uses GPIO >>> beyond a simple push button. >>> >>> I think ramips maintainer currently wants to wait until 4.19 to make >>> such changes. >> Are you referring to the rampis Linux maintainer or OpenWRT? > ramips is an OpenWrt specific platform. Not really. In fact, the goal should be getting most of these patches accepted upstream: /home/daniel/proj/kernel/next (daniel@love)$ ll arch/mips/ralink/ total 120 -rw-r--r-- 1 daniel daniel 1069 Oct 28 11:49 bootrom.c -rw-r--r-- 1 daniel daniel 3859 Oct 28 11:49 cevt-rt3352.c -rw-r--r-- 1 daniel daniel 1656 Oct 28 11:49 clk.c -rw-r--r-- 1 daniel daniel 914 Oct 28 11:49 common.h -rw-r--r-- 1 daniel daniel 2030 Oct 28 11:49 early_printk.c -rw-r--r-- 1 daniel daniel 2146 Oct 28 11:49 ill_acc.c -rw-r--r-- 1 daniel daniel 4893 Oct 28 11:49 irq.c -rw-r--r-- 1 daniel daniel 580 Oct 28 11:49 irq-gic.c -rw-r--r-- 1 daniel daniel 1590 Oct 28 11:49 Kconfig -rw-r--r-- 1 daniel daniel 861 Oct 28 11:49 Makefile -rw-r--r-- 1 daniel daniel 20178 Oct 28 11:49 mt7620.c -rw-r--r-- 1 daniel daniel 6864 Oct 28 11:49 mt7621.c -rw-r--r-- 1 daniel daniel 2557 Oct 28 11:49 of.c -rw-r--r-- 1 daniel daniel 917 Oct 28 11:49 Platform -rw-r--r-- 1 daniel daniel 1630 Oct 28 11:49 prom.c -rw-r--r-- 1 daniel daniel 2269 Oct 28 11:49 reset.c -rw-r--r-- 1 daniel daniel 3543 Oct 28 11:49 rt288x.c -rw-r--r-- 1 daniel daniel 8796 Oct 28 11:49 rt305x.c -rw-r--r-- 1 daniel daniel 4978 Oct 28 11:49 rt3883.c -rw-r--r-- 1 daniel daniel 3607 Oct 28 11:49 timer.c -rw-r--r-- 1 daniel daniel 539 Oct 28 11:49 timer-gic.c Thanks, Daniel >> Thanks, >> Daniel >> >>>> Signed-off-by: Daniel Santos >>>> --- >>>> ...-Add-support-for-GPIO-as-interrupt-contro.patch | 51 >>>> ++ >>>> 1 file changed, 51 insertions(+) >>>> create mode 100644 >>>> target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch >>>> >>>> diff --git >>>> a/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch >>>> >>>> b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch >>>> new file mode 100644 >>>> index 00..d93f39c746 >>>> --- /dev/null >>>> +++ >>>> b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch >>>> @@ -0,0 +1,51 @@ >>>> +From 57fa7f2f4ef6f78ce1d30509c0d111aa3791b524 Mon Sep 17 00:00:00 2001 >>>> +From: Daniel Santos >>>> +Date: Sun, 4 Nov 2018 20:24:32 -0600 >>>> +Subject: gpio-ralink: Add support for GPIO as interrupt-controller >>>> + >>>> +Signed-off-by: Daniel Santos >>>> +--- >>>> + Documentation/devicetree/bindings/gpio/gpio-ralink.txt | 6 ++ >>>> + drivers/gpio/gpio-ralink.c | 2 +- >>>> + 2 files changed, 7 insertio
Re: [OpenWrt-Devel] [PATCH] ralink: Add support for GPIO as interrupt-controller
Hello,
First my apologies for not CCing you John, I'm not sure which address to
use as I got a bounce from the blo...@openwrt.org address before.
Rosen,
I'm not too familiar with the mt7621 yet, I'm using an mt7620. All I
know is that it has two cores and some crypto engine instead of wifi.
Being that this is the drivers/gpio/gpio-ralink.c (a nice bland name)
I'm going assume we're just talking about two different drivers. The
compatible string for this one is "ralink,rt2880-gpio".
On 11/04/2018 10:27 PM, Rosen Penev wrote:
> On Sun, Nov 4, 2018 at 6:49 PM Daniel Santos wrote:
>> The gpio-ralink driver has everything it needs to be used as an
>> interrupt controller except for device tree support. This simple patch
>> adds that support by configuring the irq domain to use two cells and
>> adding the appropriate documentation to the devicetree bindings.
> Note that there is a mainline driver that does this already:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpio-mt7621.c?h=v4.19.1
>
> I've backported it in my tree as well:
> https://github.com/neheb/source/commit/aa3a57cdcf91a4483cfd511f8a34fb9a595f4af2
>
> I have not submitted as I don't have hardware to test that uses GPIO
> beyond a simple push button.
>
> I think ramips maintainer currently wants to wait until 4.19 to make
> such changes.
Are you referring to the rampis Linux maintainer or OpenWRT?
Thanks,
Daniel
>> Signed-off-by: Daniel Santos
>> ---
>> ...-Add-support-for-GPIO-as-interrupt-contro.patch | 51
>> ++
>> 1 file changed, 51 insertions(+)
>> create mode 100644
>> target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
>>
>> diff --git
>> a/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
>>
>> b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
>> new file mode 100644
>> index 00..d93f39c746
>> --- /dev/null
>> +++
>> b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
>> @@ -0,0 +1,51 @@
>> +From 57fa7f2f4ef6f78ce1d30509c0d111aa3791b524 Mon Sep 17 00:00:00 2001
>> +From: Daniel Santos
>> +Date: Sun, 4 Nov 2018 20:24:32 -0600
>> +Subject: gpio-ralink: Add support for GPIO as interrupt-controller
>> +
>> +Signed-off-by: Daniel Santos
>> +---
>> + Documentation/devicetree/bindings/gpio/gpio-ralink.txt | 6 ++
>> + drivers/gpio/gpio-ralink.c | 2 +-
>> + 2 files changed, 7 insertions(+), 1 deletion(-)
>> +
>> +diff --git a/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
>> b/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
>> +index 5cd17f225fe3..2775449614d4 100644
>> +--- a/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
>> b/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
>> +@@ -17,6 +17,9 @@ Required properties:
>> +
>> + Optional properties:
>> + - ralink,gpio-base : Specify the GPIO chips base number
>> ++- interrupt-controller : marks this as an interrupt controller
>> ++- #interrupt-cells : a standard two-cell interrupt flag, see
>> ++ interrupt-controller/interrupts.txt
>> +
>> + Example:
>> +
>> +@@ -28,6 +31,9 @@ Example:
>> +
>> + reg = <0x600 0x34>;
>> +
>> ++ interrupt-controller;
>> ++ #interrupt-cells = <2>;
>> ++
>> + interrupt-parent = <>;
>> + interrupts = <6>;
>> +
>> +diff --git a/drivers/gpio/gpio-ralink.c b/drivers/gpio/gpio-ralink.c
>> +index 27910e384013..b6e30083d012 100644
>> +--- a/drivers/gpio/gpio-ralink.c
>> b/drivers/gpio/gpio-ralink.c
>> +@@ -220,7 +220,7 @@ static int gpio_map(struct irq_domain *d, unsigned int
>> irq, irq_hw_number_t hw)
>> + }
>> +
>> + static const struct irq_domain_ops irq_domain_ops = {
>> +- .xlate = irq_domain_xlate_onecell,
>> ++ .xlate = irq_domain_xlate_twocell,
>> + .map = gpio_map,
>> + };
>> +
>> +--
>> +2.16.4
>> +
>> --
>> 2.16.4
>>
>>
>> ___
>> 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: [OpenWrt-Devel] Proposal for managing the kernel patches.
I had a discussion about this on irc a few weeks ago as well and I am in favor. There are just far too many reasons to list for the OpenWRT kernel to exist as a set of branches in git. Among them are the ability to move patches around, cherry-pick and git-blame. It is often very important to understand the rationale of a particular change and this is fairly easy to determine in gitk (presuming the patch was well documented). Done properly, this should greatly reduce the burden of upgrading and even backporting. There are a vast array of git tools that this would enable -- most of which kernel programmers are *used* to having and tend to feel naked without. However, there is one elephant in the living room here and it has pooped on the carpet: target/linux/*/files. These are a particular abomination because they aren't connected to any patches and have no explanation for existing. Each of these changes will need to be associated with a documented change. Which brings me to yet another reason for the OpenWRT kernel to be in git: discipline. One does not simply walk into git with a tree of 65 files that are added/overwritten without explanation. :) BTW, I have a few kernel debugging-related patches that still aren't quite ready for submission, but I think we need a HOWTO somewhere for this as I find myself trying to explain too much in the Kconfig help. Thanks, Daniel On 11/01/2018 01:20 PM, Ben Greear wrote: > I just had a good discussion with jow about this on irc, thought I'd put > my ideas in email form in case others are interested. > > In my opinion, it is difficult to develop against the current model of > local > kernel patches and backports patches. So, I am thinking something > like this > might be a better approach. > > Fork the kernel that we want to use for a base (4.19, for instance). > Apply the > existing patches one at a time to this tree. Push this tree to > github. Auto-create > tarballs as needed, put them somewhere openwrt can download them. > > Now, openwrt can select a kernel to use, which is one of these > tarballs during > compile time. > > It should be easy to select different kernels with a small makefile > tweak (and no need > to deal with local patches conflicting). And, we can do 'stable' > backport patches for > older kernels like upstream does. > > In addition, the openwrt kernel can be easily compiled for and > installed on a desktop OS which might > make debugging easier. > > > When it is time to start developing on a new kernel, clone a new one, > use 'git am' > to create the old patch-set, and then apply it on the new kernel. > Push that tree > upstream as a new github repo (so we can easily have a 4.19 kernel as > well as 4.14, etc). > > > I'd also like to somehow cram backports into this same tree, but not > sure how reasonable > that is...maybe not worth the effort. > > Thanks, > Ben > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ralink: Add support for GPIO as interrupt-controller
The gpio-ralink driver has everything it needs to be used as an
interrupt controller except for device tree support. This simple patch
adds that support by configuring the irq domain to use two cells and
adding the appropriate documentation to the devicetree bindings.
Signed-off-by: Daniel Santos
---
...-Add-support-for-GPIO-as-interrupt-contro.patch | 51 ++
1 file changed, 51 insertions(+)
create mode 100644
target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
diff --git
a/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
new file mode 100644
index 00..d93f39c746
--- /dev/null
+++
b/target/linux/ramips/patches-4.14/0029-gpio-ralink-Add-support-for-GPIO-as-interrupt-contro.patch
@@ -0,0 +1,51 @@
+From 57fa7f2f4ef6f78ce1d30509c0d111aa3791b524 Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Sun, 4 Nov 2018 20:24:32 -0600
+Subject: gpio-ralink: Add support for GPIO as interrupt-controller
+
+Signed-off-by: Daniel Santos
+---
+ Documentation/devicetree/bindings/gpio/gpio-ralink.txt | 6 ++
+ drivers/gpio/gpio-ralink.c | 2 +-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
b/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
+index 5cd17f225fe3..2775449614d4 100644
+--- a/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
b/Documentation/devicetree/bindings/gpio/gpio-ralink.txt
+@@ -17,6 +17,9 @@ Required properties:
+
+ Optional properties:
+ - ralink,gpio-base : Specify the GPIO chips base number
++- interrupt-controller : marks this as an interrupt controller
++- #interrupt-cells : a standard two-cell interrupt flag, see
++ interrupt-controller/interrupts.txt
+
+ Example:
+
+@@ -28,6 +31,9 @@ Example:
+
+ reg = <0x600 0x34>;
+
++ interrupt-controller;
++ #interrupt-cells = <2>;
++
+ interrupt-parent = <>;
+ interrupts = <6>;
+
+diff --git a/drivers/gpio/gpio-ralink.c b/drivers/gpio/gpio-ralink.c
+index 27910e384013..b6e30083d012 100644
+--- a/drivers/gpio/gpio-ralink.c
b/drivers/gpio/gpio-ralink.c
+@@ -220,7 +220,7 @@ static int gpio_map(struct irq_domain *d, unsigned int
irq, irq_hw_number_t hw)
+ }
+
+ static const struct irq_domain_ops irq_domain_ops = {
+- .xlate = irq_domain_xlate_onecell,
++ .xlate = irq_domain_xlate_twocell,
+ .map = gpio_map,
+ };
+
+--
+2.16.4
+
--
2.16.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] packages/python-idna: Add missing dependency on python(3)-codecs
Signed-off-by: Daniel Santos --- lang/python/python-idna/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lang/python/python-idna/Makefile b/lang/python/python-idna/Makefile index 47f4b9668..1f36b21e9 100644 --- a/lang/python/python-idna/Makefile +++ b/lang/python/python-idna/Makefile @@ -37,14 +37,14 @@ endef define Package/python-idna $(call Package/python-idna/Default) TITLE:=python-idna - DEPENDS:=+PACKAGE_python-idna:python-light + DEPENDS:=+PACKAGE_python-idna:python-light +python-codecs VARIANT:=python endef define Package/python3-idna $(call Package/python-idna/Default) TITLE:=python3-idna - DEPENDS:=+PACKAGE_python3-idna:python3-light + DEPENDS:=+PACKAGE_python3-idna:python3-light +python3-codecs VARIANT:=python3 endef -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC PATCH] build: re-enable parallelism for mksquashfs
This was disabled by commit dcd0e4a6727611f03eb3d3a75f073235f5f1229c due to a threading bug back in 2009. The specifics of the bug are not given in the commit message and squashfs-tools has had several updates to it's parallelism since this time. There are currently no open issues related to parallelism in their issue tracker: https://github.com/plougher/squashfs-tools/issues It now "works for me" with 16 threads, and while this is a terrible test for a race condition I still propose we remove this work-around unless and until we have specific knowledge of a current bug. Signed-off-by: Daniel Santos --- include/image.mk | 1 - 1 file changed, 1 deletion(-) diff --git a/include/image.mk b/include/image.mk index f2a85f6feb..dcf1e3572a 100644 --- a/include/image.mk +++ b/include/image.mk @@ -203,7 +203,6 @@ define Image/mkfs/squashfs $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \ -nopad -noappend -root-owned \ -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ - -processors 1 \ $(if $(SOURCE_DATE_EPOCH),-fixed-time $(SOURCE_DATE_EPOCH)) endef -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: add option to root .config for /proc/config.gz
Exports CONFIG_IKCONFIG and CONFIG_IKCONFIG_PROC to the kernel .config based upon menu choices under Global build settings --> Kernel build options. For simplicity, /proc/config.gz support is assumed, but if kernel_menuconfig has disabled CONFIG_PROC_FS it will be pruned in oldconfig. Signed-off-by: Daniel Santos --- config/Config-kernel.in | 18 ++ 1 file changed, 18 insertions(+) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index f38cc792dd..b03eb929c9 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -20,6 +20,24 @@ config KERNEL_BUILD_DOMAIN returned by 'uname -a' on running systems. If not set, uses system hostname at build time. +config KERNEL_IKCONFIG_PROC +bool +default n + +config KERNEL_IKCONFIG + bool "Kernel .config support" + select KERNEL_IKCONFIG_PROC + default n + help + This option enables the complete Linux kernel ".config" file + contents to be saved in the kernel. It provides documentation + of which kernel options are used in a running kernel or in an + on-disk kernel. This information can be extracted from the kernel + image file with the script scripts/extract-ikconfig and used as + input to rebuild the current kernel or to build another kernel. + Unless PROC_FS is disabled, it will also be exported via + /proc/config.gz. + config KERNEL_PRINTK bool "Enable support for printk" default y -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 2/2] kernel: rework module stripping, add Kconfig option
Add an option to the "Global build settings" menu to choose if and how
kernel modules are stripped. Stripping is now performed upon install
into staging, leaving modules in the kernel build tree untouched so that
they are useful for remote debugging and such.
The user will now be allowed to choose to 1.) leave modules unstripped,
2.) strip unneeded symbols and sections, or 3.) strip all -- the later
of which exposes access to Felix's hack for removing non-essential
module information. Thus, rather than having to go to the
kernel_menuconfig to disable it when not desired, it can be disabled
simply by selecting either "strip unneeded" or "strip none". The
functionality of "strip all" and Felix's patch are logical mates.
Although it is concievable that one may want to retain author, parameter
descriptions, etc., but also do a strip-all, this can still be done by
disabling Felix's patch via kernel_menuconfig.
The kernel .config option MODULE_STRIPPED is renamed to MODULE_STRIP_ALL
for disabiguation while the options to not strip or only strip-unneeded
are not exported to the kernel .config as they are only relevent to the
OpenWRT build.
Signed-off-by: Daniel Santos
---
config/Config-build.in | 29 ++
include/kernel.mk | 17 +++--
target/linux/generic/config-4.14 | 1 -
target/linux/generic/config-4.9| 1 -
.../linux/generic/hack-4.14/204-module_strip.patch | 22
.../linux/generic/hack-4.9/204-module_strip.patch | 24 +-
6 files changed, 67 insertions(+), 27 deletions(-)
diff --git a/config/Config-build.in b/config/Config-build.in
index a082a5e0e2..72076d0648 100644
--- a/config/Config-build.in
+++ b/config/Config-build.in
@@ -151,6 +151,35 @@ menu "Global build settings"
image. Note that this might make the kernel incompatible
with any kernel
modules that were not selected at the time the kernel image
was created.
+ choice
+ prompt "Kernel module stripping"
+ default KERNEL_MODULE_STRIP_ALL
+ help
+ If and how modules should be stripped upon install. Modules
+ in the Linux build tree remain unchanged.
+
+ config MODULE_STRIP_NONE
+ bool "strip none"
+ help
+ Will install modules exactly as they are built in the
+ tree, including any debug symbols if enabled in the
+ Kernel Hacking menuconfig menu.
+
+ config MODULE_STRIP_UNNEEDED
+ bool "strip unneeded"
+ help
+ Strips all unneeded symbols from modules as they are
+ installed.
+
+ config KERNEL_MODULE_STRIP_ALL
+ bool "strip all"
+ help
+ Further reduces size of kernel modules by stripping
+ all symbols, including relocations, and removing
+ customary strings such as author, version, parameter
+ descriptions, etc.
+ endchoice
+
config USE_MKLIBS
bool "Strip unnecessary functions from libraries"
help
diff --git a/include/kernel.mk b/include/kernel.mk
index 62a8e99e2d..251ac1c94c 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -122,6 +122,18 @@ ifdef CONFIG_USE_SPARSE
KERNEL_MAKEOPTS += C=1 CHECK=$(STAGING_DIR_HOST)/bin/sparse
endif
+# Define command for copying kernel modules.
+ifeq ($(CONFIG_MODULE_STRIP_NONE),y)
+ MODULE_COPY := $(CP) -L
+else
+ MODULE_COPY = $(KERNEL_CROSS)objcopy
+ ifeq ($(CONFIG_MODULE_STRIP_UNNEEDED),y)
+MODULE_COPY += --strip-unneeded
+ else # CONFIG_MODULE_STRIP_ALL
+MODULE_COPY += --strip-all
+ endif
+endif
+
PKG_EXTMOD_SUBDIRS ?= .
define populate_module_symvers
@@ -229,8 +241,9 @@ $(call KernelPackage/$(1)/config)
if grep -q "{mod##$(LINUX_DIR)/}"
"$(LINUX_DIR)/modules.builtin"; then \
echo "NOTICE: module 'mod' is
built-in."; \
elif [ -e mod ]; then \
- mkdir -p $$(1)/$(MODULES_SUBDIR) ; \
- $(CP) -L mod $$(1)/$(MODULES_SUBDIR)/ ;
\
+ mkdir -p $$(1)/$(MODULES_SUBDIR); \
+ mod_name=`basename mod`; \
+ $(MODULE_COPY) mod
$$(1)/$(MODULES_SUBDIR)/mod_name; \
else \
echo "ERROR: module 'mod' is missing.&qu
[OpenWrt-Devel] [PATCH v4 1/2] kernel: revert bad module stripping patch
This patch is wrong in several regards. 1.) It violates the the principle of least astonishment, 2.) it makes a radical change to the kernel build without informing the user, 3.) it makes the change without obtaining user consent, thus violating the spirit of free and open source software, and 4.) it not only breaks debugging, but other features such as kmemleak. Signed-off-by: Daniel Santos --- .../generic/hack-4.14/202-reduce_module_size.patch | 24 -- .../generic/hack-4.9/202-reduce_module_size.patch | 24 -- 2 files changed, 48 deletions(-) delete mode 100644 target/linux/generic/hack-4.14/202-reduce_module_size.patch delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch b/target/linux/generic/hack-4.14/202-reduce_module_size.patch deleted file mode 100644 index 2cbb6add9a..00 --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch b/target/linux/generic/hack-4.9/202-reduce_module_size.patch deleted file mode 100644 index f744b945fe..00 --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -403,7 +403,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - # Read KERNELRELEASE from include/config/kernel.release (if it exists) -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] kernel: revert bad module stripping patch
Hello Philip, On 10/29/2018 06:50 PM, Philip Prindeville wrote: > Some hardware (it’s rare but not unheard of) can only be reset by unloading > and reloading the module that controls it. Otherwise, you have to reboot the > box. If you build all of your drivers in, then rebooting is all you have. I've had to do this before as well -- also, it's sometimes much faster than trying to find the "unbind" file in sysfs and figuring out what exactly needs to be written to it. Most of the modules that are built are probably not in that category though. Still it means that the OpenWRT menuconfig would need a no, yes (built-in), yes (module), yes (module opkg) feature, probably by just adding a 'B' option. > My firewall has been up for 3 years. I update it with opkg, including > modules. > > It would have been up longer, but I have to swap out the UPS that it’s on > tomorrow. > > Well, at least now I can sysupgrade to a newer kernel… lol! A lot has changed in 3 years! :) Daniel > > >> On Oct 29, 2018, at 5:01 PM, Daniel Santos wrote: >> >> I would like to take this opportunity to mention that the best way to >> save space here is to not build modules -- make them built-ins. I did a >> quick experiment of this and instead of saving 4k, my *image* is a full >> 256k smaller. I haven't analysed the specifics, but also this means >> less RAM consumed because squashfs uses the page cache for uncompressed >> files. Further, modules inherently have greater overhead, even after >> __init sections have been discarded. >> >> sed -i 's/=m/=y/g;' >> build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-4.14.63/.config >> make >> >> The only downside is that built-ins cannot be unloaded and will always >> occupy a portion of RAM. But having them built into the kernel is far >> more efficient. >> >> Daniel >> >> On 10/29/2018 05:54 PM, Daniel Santos wrote: >>> Never EVER do this! Decades of computer science has taught us "best >>> practices" -- ways of doing things that provide an optimal outcome for >>> all parties involved. While this type of hack is fine if you're working >>> alone, it is not a "best practice" and is completely unacceptable for a >>> large FOSS project. This is especially insidious because it goes behind >>> the back of the programmer / user / hacker and makes a change without >>> their consent or direction -- this is the type of behaviour we've come >>> to expect from Google, m$, Apple and the like, not from FOSS. >>> >>> Doing --strip-all is not appropriate default behaviour as this includes >>> relocation data and breaks things like kmemleak. The presence of debug >>> information in modules is already controlled by CONFIG_DEBUG_INFO, >>> CONFIG_DEBUG_INFO_REDUCED, etc. Force-stripping just makes life crappy >>> for anybody who needs to debug the a kernel built in OpenWRT. (Some of >>> us do run gdb on the kernel.) >>> >>> If --strip-all really is desired, it should probably be added to the >>> CONFIG_MODULE_STRIPPED patch, and should be done at install time >>> (probably via objcopy), not at link time. This leaves the in-tree >>> modules useful for debugging, decompiling, diagnostics, profiling, etc. >>> >>> Signed-off-by: Daniel Santos >>> --- >>> .../generic/hack-4.14/202-reduce_module_size.patch | 24 >>> -- >>> .../generic/hack-4.9/202-reduce_module_size.patch | 24 >>> -- >>> 2 files changed, 48 deletions(-) >>> delete mode 100644 >>> target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> delete mode 100644 >>> target/linux/generic/hack-4.9/202-reduce_module_size.patch >>> >>> diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> b/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> deleted file mode 100644 >>> index 2cbb6add9a..00 >>> --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> +++ /dev/null >>> @@ -1,24 +0,0 @@ >>> -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 >>> -From: Felix Fietkau >>> -Date: Fri, 7 Jul 2017 16:56:19 +0200 >>> -Subject: kernel: strip unnecessary symbol table information from kernel >>> modules >>> - >>> -reduces default squashfs size on ar71xx by about 4k >>> - >>> -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 >>> -Signed-off-by: Felix Fietka
Re: [OpenWrt-Devel] [PATCH v3] kernel: revert bad module stripping patch
Hrm, this was my attempt to be less emotional. :( I'll try again. There is no conspiracy theory here. Nobody tries to hide it. Ever tried to completely remove the Facebook and Twitter apps from your phone? This is the growing trend in many realms of commercial software. Hell, this is why OpenWRT was started -- so we could decide what WE wanted to do with our hardware, and not be constrained to the dictates of the manufacturer. Even if it isn't needed in the patch description, there's certainly nothing ground-breaking or hypothetical in that statement. "If the users don't control the program, the program controls the users." -- RMS Daniel On 10/29/2018 06:50 PM, Philip Prindeville wrote: > Some hardware (it’s rare but not unheard of) can only be reset by unloading > and reloading the module that controls it. Otherwise, you have to reboot the > box. If you build all of your drivers in, then rebooting is all you have. > > My firewall has been up for 3 years. I update it with opkg, including > modules. > > It would have been up longer, but I have to swap out the UPS that it’s on > tomorrow. > > Well, at least now I can sysupgrade to a newer kernel… > > >> On Oct 29, 2018, at 5:01 PM, Daniel Santos wrote: >> >> I would like to take this opportunity to mention that the best way to >> save space here is to not build modules -- make them built-ins. I did a >> quick experiment of this and instead of saving 4k, my *image* is a full >> 256k smaller. I haven't analysed the specifics, but also this means >> less RAM consumed because squashfs uses the page cache for uncompressed >> files. Further, modules inherently have greater overhead, even after >> __init sections have been discarded. >> >> sed -i 's/=m/=y/g;' >> build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-4.14.63/.config >> make >> >> The only downside is that built-ins cannot be unloaded and will always >> occupy a portion of RAM. But having them built into the kernel is far >> more efficient. >> >> Daniel >> >> On 10/29/2018 05:54 PM, Daniel Santos wrote: >>> Never EVER do this! Decades of computer science has taught us "best >>> practices" -- ways of doing things that provide an optimal outcome for >>> all parties involved. While this type of hack is fine if you're working >>> alone, it is not a "best practice" and is completely unacceptable for a >>> large FOSS project. This is especially insidious because it goes behind >>> the back of the programmer / user / hacker and makes a change without >>> their consent or direction -- this is the type of behaviour we've come >>> to expect from Google, m$, Apple and the like, not from FOSS. >>> >>> Doing --strip-all is not appropriate default behaviour as this includes >>> relocation data and breaks things like kmemleak. The presence of debug >>> information in modules is already controlled by CONFIG_DEBUG_INFO, >>> CONFIG_DEBUG_INFO_REDUCED, etc. Force-stripping just makes life crappy >>> for anybody who needs to debug the a kernel built in OpenWRT. (Some of >>> us do run gdb on the kernel.) >>> >>> If --strip-all really is desired, it should probably be added to the >>> CONFIG_MODULE_STRIPPED patch, and should be done at install time >>> (probably via objcopy), not at link time. This leaves the in-tree >>> modules useful for debugging, decompiling, diagnostics, profiling, etc. >>> >>> Signed-off-by: Daniel Santos >>> --- >>> .../generic/hack-4.14/202-reduce_module_size.patch | 24 >>> -- >>> .../generic/hack-4.9/202-reduce_module_size.patch | 24 >>> -- >>> 2 files changed, 48 deletions(-) >>> delete mode 100644 >>> target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> delete mode 100644 >>> target/linux/generic/hack-4.9/202-reduce_module_size.patch >>> >>> diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> b/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> deleted file mode 100644 >>> index 2cbb6add9a..00 >>> --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >>> +++ /dev/null >>> @@ -1,24 +0,0 @@ >>> -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 >>> -From: Felix Fietkau >>> -Date: Fri, 7 Jul 2017 16:56:19 +0200 >>> -Subject: kernel: strip unnecessary symbol table information from kernel >>> modules >>> - >>&g
Re: [OpenWrt-Devel] [PATCH v3] kernel: revert bad module stripping patch
I would like to take this opportunity to mention that the best way to save space here is to not build modules -- make them built-ins. I did a quick experiment of this and instead of saving 4k, my *image* is a full 256k smaller. I haven't analysed the specifics, but also this means less RAM consumed because squashfs uses the page cache for uncompressed files. Further, modules inherently have greater overhead, even after __init sections have been discarded. sed -i 's/=m/=y/g;' build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-4.14.63/.config make The only downside is that built-ins cannot be unloaded and will always occupy a portion of RAM. But having them built into the kernel is far more efficient. Daniel On 10/29/2018 05:54 PM, Daniel Santos wrote: > Never EVER do this! Decades of computer science has taught us "best > practices" -- ways of doing things that provide an optimal outcome for > all parties involved. While this type of hack is fine if you're working > alone, it is not a "best practice" and is completely unacceptable for a > large FOSS project. This is especially insidious because it goes behind > the back of the programmer / user / hacker and makes a change without > their consent or direction -- this is the type of behaviour we've come > to expect from Google, m$, Apple and the like, not from FOSS. > > Doing --strip-all is not appropriate default behaviour as this includes > relocation data and breaks things like kmemleak. The presence of debug > information in modules is already controlled by CONFIG_DEBUG_INFO, > CONFIG_DEBUG_INFO_REDUCED, etc. Force-stripping just makes life crappy > for anybody who needs to debug the a kernel built in OpenWRT. (Some of > us do run gdb on the kernel.) > > If --strip-all really is desired, it should probably be added to the > CONFIG_MODULE_STRIPPED patch, and should be done at install time > (probably via objcopy), not at link time. This leaves the in-tree > modules useful for debugging, decompiling, diagnostics, profiling, etc. > > Signed-off-by: Daniel Santos > --- > .../generic/hack-4.14/202-reduce_module_size.patch | 24 > -- > .../generic/hack-4.9/202-reduce_module_size.patch | 24 > -- > 2 files changed, 48 deletions(-) > delete mode 100644 > target/linux/generic/hack-4.14/202-reduce_module_size.patch > delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch > > diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch > b/target/linux/generic/hack-4.14/202-reduce_module_size.patch > deleted file mode 100644 > index 2cbb6add9a..00 > --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch > +++ /dev/null > @@ -1,24 +0,0 @@ > -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 > -From: Felix Fietkau > -Date: Fri, 7 Jul 2017 16:56:19 +0200 > -Subject: kernel: strip unnecessary symbol table information from kernel > modules > - > -reduces default squashfs size on ar71xx by about 4k > - > -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 > -Signed-off-by: Felix Fietkau > > - Makefile | 2 +- > - 1 file changed, 1 insertion(+), 1 deletion(-) > - > a/Makefile > -+++ b/Makefile > -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := > - KBUILD_CFLAGS_KERNEL := > - KBUILD_AFLAGS_MODULE := -DMODULE > - KBUILD_CFLAGS_MODULE := -DMODULE > --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds > -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if > $(CONFIG_PROFILING),,-s) > - GCC_PLUGINS_CFLAGS := > - > - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS > LD > diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch > b/target/linux/generic/hack-4.9/202-reduce_module_size.patch > deleted file mode 100644 > index f744b945fe..00 > --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch > +++ /dev/null > @@ -1,24 +0,0 @@ > -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 > -From: Felix Fietkau > -Date: Fri, 7 Jul 2017 16:56:19 +0200 > -Subject: kernel: strip unnecessary symbol table information from kernel > modules > - > -reduces default squashfs size on ar71xx by about 4k > - > -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 > -Signed-off-by: Felix Fietkau > > - Makefile | 2 +- > - 1 file changed, 1 insertion(+), 1 deletion(-) > - > a/Makefile > -+++ b/Makefile > -@@ -403,7 +403,7 @@ KBUILD_AFLAGS_KERNEL := > - KBUILD_CFLAGS_KERNEL := > - KBUILD_AFLAGS_MODULE := -DMODULE > - KBUILD_CFLAGS_MODULE := -DMODULE > --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common
[OpenWrt-Devel] [PATCH v3] kernel: revert bad module stripping patch
Never EVER do this! Decades of computer science has taught us "best practices" -- ways of doing things that provide an optimal outcome for all parties involved. While this type of hack is fine if you're working alone, it is not a "best practice" and is completely unacceptable for a large FOSS project. This is especially insidious because it goes behind the back of the programmer / user / hacker and makes a change without their consent or direction -- this is the type of behaviour we've come to expect from Google, m$, Apple and the like, not from FOSS. Doing --strip-all is not appropriate default behaviour as this includes relocation data and breaks things like kmemleak. The presence of debug information in modules is already controlled by CONFIG_DEBUG_INFO, CONFIG_DEBUG_INFO_REDUCED, etc. Force-stripping just makes life crappy for anybody who needs to debug the a kernel built in OpenWRT. (Some of us do run gdb on the kernel.) If --strip-all really is desired, it should probably be added to the CONFIG_MODULE_STRIPPED patch, and should be done at install time (probably via objcopy), not at link time. This leaves the in-tree modules useful for debugging, decompiling, diagnostics, profiling, etc. Signed-off-by: Daniel Santos --- .../generic/hack-4.14/202-reduce_module_size.patch | 24 -- .../generic/hack-4.9/202-reduce_module_size.patch | 24 -- 2 files changed, 48 deletions(-) delete mode 100644 target/linux/generic/hack-4.14/202-reduce_module_size.patch delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch b/target/linux/generic/hack-4.14/202-reduce_module_size.patch deleted file mode 100644 index 2cbb6add9a..00 --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch b/target/linux/generic/hack-4.9/202-reduce_module_size.patch deleted file mode 100644 index f744b945fe..00 --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -403,7 +403,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - # Read KERNELRELEASE from include/config/kernel.release (if it exists) -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: revert evil EVIL module stripping patches
oops, I forgot to --signoff. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] kernel: revert evil EVIL module stripping patches
Don't ever EVER do this! It has taken me several hours to discover the underlying cause of my modules being mysteriously stripped, despite having made certain CONFIG_MODULE_STRIP was not enabled. This is a truely horrendous and dispicable way to strip modules. First of all, it is insideious and activates any time you aren't profiling. Second, it also brakes kmemleak. Never go behind the back of the programmer / admin / hacker and do things like this without their permission. In Free and Open Source Software, we do not force things to happen that the user has not elected to have done. If you really want excessive stripping for that extra 4k, then add a distinct option to remove all symbols. Signed-off-by: Daniel Santos --- .../generic/hack-4.14/202-reduce_module_size.patch | 24 -- .../generic/hack-4.9/202-reduce_module_size.patch | 24 -- 2 files changed, 48 deletions(-) delete mode 100644 target/linux/generic/hack-4.14/202-reduce_module_size.patch delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch b/target/linux/generic/hack-4.14/202-reduce_module_size.patch deleted file mode 100644 index 2cbb6add9a..00 --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch b/target/linux/generic/hack-4.9/202-reduce_module_size.patch deleted file mode 100644 index f744b945fe..00 --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -403,7 +403,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - # Read KERNELRELEASE from include/config/kernel.release (if it exists) -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: revert evil EVIL module stripping patches
Don't ever EVER do this! It has taken me several hours to discover the underlying cause of my modules being mysteriously stripped, despite having made certain CONFIG_MODULE_STRIP was not enabled. This is a truely horrendous and dispicable way to strip modules. First of all, it is insideious and activates any time you aren't profiling. Second, it also brakes kmemleak. Never go behind the back of the programmer / admin / hacker and do things like this without their permission. In Free and Open Source Software, we do not force things to happen that the user has not elected to have done. If you really want excessive stripping for that extra 4k, then add a distinct option to remove all symbols. --- .../generic/hack-4.14/202-reduce_module_size.patch | 24 -- .../generic/hack-4.9/202-reduce_module_size.patch | 24 -- 2 files changed, 48 deletions(-) delete mode 100644 target/linux/generic/hack-4.14/202-reduce_module_size.patch delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch b/target/linux/generic/hack-4.14/202-reduce_module_size.patch deleted file mode 100644 index 2cbb6add9a..00 --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch b/target/linux/generic/hack-4.9/202-reduce_module_size.patch deleted file mode 100644 index f744b945fe..00 --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch +++ /dev/null @@ -1,24 +0,0 @@ -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 -From: Felix Fietkau -Date: Fri, 7 Jul 2017 16:56:19 +0200 -Subject: kernel: strip unnecessary symbol table information from kernel modules - -reduces default squashfs size on ar71xx by about 4k - -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 -Signed-off-by: Felix Fietkau - Makefile | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - a/Makefile -+++ b/Makefile -@@ -403,7 +403,7 @@ KBUILD_AFLAGS_KERNEL := - KBUILD_CFLAGS_KERNEL := - KBUILD_AFLAGS_MODULE := -DMODULE - KBUILD_CFLAGS_MODULE := -DMODULE --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if $(CONFIG_PROFILING),,-s) - GCC_PLUGINS_CFLAGS := - - # Read KERNELRELEASE from include/config/kernel.release (if it exists) -- 2.16.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage
I've sent this one upstream. This patch is critical if you want to run
with "prove lock correctness" (lockdep) and you happen to have certain
mtd devices. The misuse of the uninitialized object is undefined
behaviour, but being zeroed it does not appear to have actually broken
anything other than the lockdep engine.
Signed-off-by: Daniel Santos
---
...se-of-uninitialized-delayed_work-lockdep-.patch | 64 ++
1 file changed, 64 insertions(+)
create mode 100644
target/linux/generic/pending-4.14/142-jffs2-Fix-use-of-uninitialized-delayed_work-lockdep-.patch
diff --git
a/target/linux/generic/pending-4.14/142-jffs2-Fix-use-of-uninitialized-delayed_work-lockdep-.patch
b/target/linux/generic/pending-4.14/142-jffs2-Fix-use-of-uninitialized-delayed_work-lockdep-.patch
new file mode 100644
index 00..5b2184f340
--- /dev/null
+++
b/target/linux/generic/pending-4.14/142-jffs2-Fix-use-of-uninitialized-delayed_work-lockdep-.patch
@@ -0,0 +1,64 @@
+From 1d9ab2b7c27a10acfa437c561f276d52d563e058 Mon Sep 17 00:00:00 2001
+From: Daniel Santos
+Date: Fri, 19 Oct 2018 01:50:20 -0500
+Subject: jffs2: Fix use of uninitialized delayed_work, lockdep breakage
+
+jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
+is defined then a write buffer is available and has been initialized.
+However, this does is not the case when the mtd device has no
+out-of-band buffer:
+
+int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
+{
+if (!c->mtd->oobsize)
+return 0;
+...
+
+The resulting call to cancel_delayed_work_sync passing a uninitialized
+(but zeroed) delayed_work struct forces lockdep to become disabled.
+
+[ 90.050639] overlayfs: upper fs does not support tmpfile.
+[ 90.652264] INFO: trying to register non-static key.
+[ 90.662171] the code is fine but needs lockdep annotation.
+[ 90.673090] turning off the locking correctness validator.
+[ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
+[ 90.696672] Stack : 80d8f6a2 0038 805f 80444600
8fe364f4 805dfbe7
+[ 90.713349] 80563a30 06e2 8068370c 0001 0001
8e2fdc48
+[ 90.730020] 80d9 0106
6465746e 312e3420
+[ 90.746690] 6b636f6c 03bf f800 20676e69 8000
8e2c2a90
+[ 90.763362] 80d9 0001 8e2c2a90 0003 80260dc0
08052098 8068
+[ 90.780033] ...
+[ 90.784902] Call Trace:
+[ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
+[ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
+[ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
+[ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
+[ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
+[ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
+[ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
+[ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
+[ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
+[ 90.875067] [<80014424>] syscall_common+0x34/0x58
+
+Signed-off-by: Daniel Santos
+---
+ fs/jffs2/super.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
+index 793ad30970ff..cae4ecda3c50 100644
+--- a/fs/jffs2/super.c
b/fs/jffs2/super.c
+@@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
+ struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
+
+ #ifdef CONFIG_JFFS2_FS_WRITEBUFFER
+- cancel_delayed_work_sync(>wbuf_dwork);
++ if (jffs2_is_writebuffered(c))
++ cancel_delayed_work_sync(>wbuf_dwork);
+ #endif
+
+ mutex_lock(>alloc_sem);
+--
+2.16.4
+
--
2.16.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to get OpenWRT to leave kernel .config the f alone?
On 03/09/2018 01:46 AM, Alexandru Ardelean wrote: > On Fri, Mar 9, 2018 at 7:24 AM, Daniel Santos <daniel.san...@pobox.com> wrote: >> Hello. I'm not very good with make and I need to make many changes to my >> kernel .config for debugging. I wrote a patch to add an option to tell >> OpenWRT to leave it alone, but I don't understand this build system very >> well and it seems to always prevent the kernel .config from being >> modified as well as leading to modules & kernel always being rebuilt. >> Would somebody be kind enough to fix it for me? :) >> > The problem is not the OpenWrt build system here. > It's likely the kernel's Kconfig system and dependency chain. > Your patch is going about it from the wrong angle. > > Most symbols in the .config [whether OpenWrt's .config or kernel's > .config] have a dependency chain. > Example: driver bcm2708-spi [don't remember the actual driver name > here] will not be built/installed if CONFIG_SPI is not enabled in > .config. > > So, if the symbol for building bcm2708-spi [let's call it > CONFIG_BCM2708_SPI] disappears during build, it's a symptom that the > dependency chain is not correct. > In a way, you may want this behavior, versus leaving it there and not > building it anyway. > > What you can do is [in the OpenWrt context]: > * make kernel_menuconfig > * hit the slash key " / " > * type/search for the symbol you want to enable > * once you find it, it will list all symbols it depends on ; and which > you also want enabled > * add those symbols to your kernel config, or enable them via this > menuconfig you are in > > Note that this Kconfig build-system is present in many projects [ > Linux kernel, OpenWrt, buildroot, etc ]. > So, if you learn to use it, the skill will be useful later on. > > Typically, what I've noticed, is that the Linux kernel [in newer > versions] will enforce dependencies in drivers/code that were > previously not there, and when you update your kernel, stuff > disappears/gets disabled. > So, if you using an older .config in a newer kernel, or some other > mix, this is possible. Thanks for the response. This isn't the problem however. I simply want to be able to manage my own .config separate from OpenWRT. I realize this breaks the scheme, but I'm having a lot of problems getting the kernel .config that I need using OpenWRT. Currently, after having run make kernel_menuconfig, oldconfig is now prompting me for a choice that I have attempted to already make (and I'm not sure why). This is inhibiting a parallel build. So as a work-around and also just another option, I would like to manage the .config myself. Thanks Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to get OpenWRT to leave kernel .config the f alone?
Hello. I'm not very good with make and I need to make many changes to my kernel .config for debugging. I wrote a patch to add an option to tell OpenWRT to leave it alone, but I don't understand this build system very well and it seems to always prevent the kernel .config from being modified as well as leading to modules & kernel always being rebuilt. Would somebody be kind enough to fix it for me? :) I'm new to this project and I'm working with a device that has a crappy u-boot build installed on it. I need to run a debug kernel, but any time I attempt to tftp it to the device (directly to RAM) it fails to boot. If I send the whole damn sysupgrade via lcui then it works. Thus, if I upload a bad sysupgrade, I can potentially get locked out of the device until I manually flash the SPI (and I don't know how to do that yet, I guess some type of jtag?). So rather than just manually building my kernel and building a sysupgrade by hand, I would rather the build do it out of caution for messing it up. Oh yeah, and I'm using CC at this commit: 0625aaa6f37dcf6a2ffb611245fa9b6477642b78 -- of which I have no choice about. But if anybody can get that to work for the 17.x head, I can backport it. Thanks in advance! Daniel >From 04d9b710782308106e6b37d40f3f08cba04e57fd Mon Sep 17 00:00:00 2001 From: Daniel Santos <daniel.san...@pobox.com> Date: Thu, 8 Mar 2018 22:39:33 -0600 Subject: [PATCH] external kernel .config --- config/Config-devel.in | 8 include/kernel-build.mk| 4 ++-- include/kernel-defaults.mk | 8 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/config/Config-devel.in b/config/Config-devel.in index d096c18a72..8603010485 100644 --- a/config/Config-devel.in +++ b/config/Config-devel.in @@ -65,6 +65,14 @@ menuconfig DEVEL string "Use external kernel tree" if DEVEL default "" + config EXTERNAL_KERNEL_CONFIG + bool "Use .config in external kernel tree (and do not modify it)." if DEVEL + depends on (EXTERNAL_KERNEL_TREE != "") + default N + help + If enabled, OpenWRT will not generate or modify the .config + file in the external kernel tree. + config KERNEL_GIT_CLONE_URI string "Enter git repository to clone" if DEVEL default "" diff --git a/include/kernel-build.mk b/include/kernel-build.mk index 9abfd542e8..7f19a7260e 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -126,9 +126,9 @@ define BuildKernel oldconfig menuconfig nconfig: $(STAMP_PREPARED) $(STAMP_CHECKED) FORCE rm -f $(STAMP_CONFIGURED) - $(LINUX_RECONF_CMD) > $(LINUX_DIR)/.config + $(ifdef EXTERNAL_KERNEL_CONFIG,,$(LINUX_RECONF_CMD) > $(LINUX_DIR)/.config) $(_SINGLE)$(MAKE) -C $(LINUX_DIR) $(KERNEL_MAKEOPTS) $$@ - $(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config > $(LINUX_RECONFIG_TARGET) + $(ifdef EXTERNAL_KERNEL_CONFIG,,$(LINUX_RECONF_DIFF) $(LINUX_DIR)/.config > $(LINUX_RECONFIG_TARGET)) install: $(LINUX_DIR)/.image +$(MAKE) -C image compile install TARGET_BUILD= diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index 24d26308b1..454c9da53d 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -100,6 +100,7 @@ define Kernel/SetNoInitramfs echo 'CONFIG_INITRAMFS_SOURCE=""' >> $(LINUX_DIR)/.config endef +ifdef EXTERNAL_KERNEL_CONFIG define Kernel/Configure/Default $(LINUX_CONF_CMD) > $(LINUX_DIR)/.config.target # copy CONFIG_KERNEL_* settings over to .config.target @@ -114,6 +115,13 @@ define Kernel/Configure/Default $(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE) $(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install $(SH_FUNC) grep '=[ym]' $(LINUX_DIR)/.config | LC_ALL=C sort | md5s > $(LINUX_DIR)/.vermagic endef +else +define Kernel/Configure/Default + rm -rf $(KERNEL_BUILD_DIR)/modules + $(_SINGLE) [ -d $(LINUX_DIR)/user_headers ] || $(MAKE) $(KERNEL_MAKEOPTS) INSTALL_HDR_PATH=$(LINUX_DIR)/user_headers headers_install + $(SH_FUNC) grep '=[ym]' $(LINUX_DIR)/.config | LC_ALL=C sort | md5s > $(LINUX_DIR)/.vermagic +endef +endif define Kernel/Configure/Initramfs $(call Kernel/SetInitramfs) -- 2.15.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
