[PATCH] bcm53xx: dir885/dir890: Tag both partitions as SEAMA
The newly added D-Link DIR-890L also needs to have a seama
tag on its partition so that it will be split properly by
mtdsplit.
Signed-off-by: Linus Walleij
---
...-dts-BCM5301X-Describe-partition-formats.patch | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git
a/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
b/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
index f2861177dd1d..185db3960761 100644
---
a/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
+++
b/target/linux/bcm53xx/patches-5.15/321-ARM-dts-BCM5301X-Describe-partition-formats.patch
@@ -1,4 +1,4 @@
-From 7166207bd1d8c46d09d640d46afc685df9bb9083 Mon Sep 17 00:00:00 2001
+From a054e2fe2d00bd32f308986de654b66f054083d2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=
Date: Thu, 22 Nov 2018 09:21:49 +0100
Subject: [PATCH] ARM: dts: BCM5301X: Describe partition formats
@@ -11,7 +11,8 @@ It's needed by OpenWrt for custom partitioning.
Signed-off-by: Rafał Miłecki
---
arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 1 +
- 1 file changed, 1 insertion(+)
+ arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts | 1 +
+ 2 files changed, 2 insertions(+)
--- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
+++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
@@ -23,3 +24,13 @@ Signed-off-by: Rafał Miłecki
};
};
};
+--- a/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
b/arch/arm/boot/dts/bcm47094-dlink-dir-890l.dts
+@@ -151,6 +151,7 @@
+ firmware@0 {
+ label = "firmware";
+ reg = <0x 0x0800>;
++ compatible = "seama";
+ };
+ };
+ };
--
2.34.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
WRT54GS flash broken
Hi, I wanted to flash a recent OpenWrt onto a WRT54GS today and broke something. I used the recovery mechanism in the CFE boot loader: CFE version 1.0.37 for BCM947XX (32bit,SP,LE) Build Date: Fri Jun 25 15:49:22 CST 2004 (root@Amin) Copyright (C) 2000,2001,2002,2003 Broadcom Corporation. Initializing Arena. Initializing Devices. et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0 rndis0: Broadcom USB RNDIS Network Adapter (P-t-P) CPU type 0x29007: 200MHz Total memory: 0x200 bytes (32MB) Total memory used by CFE: 0x8030 - 0x8043DF30 (1302320) Initialized Data: 0x803381A0 - 0x8033A550 (9136) BSS Area: 0x8033A550 - 0x8033BF30 (6624) Local Heap:0x8033BF30 - 0x8043BF30 (1048576) Stack Area:0x8043BF30 - 0x8043DF30 (8192) Text (code) segment: 0x8030 - 0x803381A0 (229792) Boot area (physical): 0x0043E000 - 0x0047E000 Relocation Factor: I: - D: Boot version: v3.2 The boot is CFE mac_init(): Find mac [00:0F:66:D3:94:95] in location 1 Nothing... No eou key find Device eth0: hwaddr 00-0F-66-D3-94-95, ipaddr 192.168.1.1, mask 255.255.255.0 gateway not set, nameserver not set Reading :: CODE Pattern is CORRECT! upgrade_ver[v4.80.1] upgrade_ver[48001] 4712_ver[15000] Done. 5181472 bytes read fname=flash1.trx CODE Pattern is correct! (W54S) Programming...W The system was hanging after this operation. When I tried this again it never went further than "Programming..." I also tried to manually flash it like this: CFE> flash -ctheader : flash1.trx Reading :: CODE Pattern is CORRECT! upgrade_ver[v4.80.1] upgrade_ver[48001] 4712_ver[15000] Done. 2756640 bytes read fname=flash1.trx CODE Pattern is correct! (W54S) Programming...� I was sending the file like this: atftp --trace --option "timeout 1" --option "mode octet" --put --local-file bin/targets/bcm47xx/legacy/openwrt-bcm47xx-legacy-linksys_wrt54gs-squashfs.bin 192.168.1.1 Some old webpages said the image should be less than 3MB, so I deactivated many applications I do not need for a sysupgrade. How can I recover this device again? Currently I have UART connected only and no JTAG yet. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
X86 partition tables
Hi, Couple of questions about partition tables on x86 hardware. Do most x86 machines (an APUv6 w/ Coreboot in my case, and a Qemu/KVM VM with Bochs as well) support GPT in BIOS (CGM or whatever)? And what are the steps on a live system to (1) convert the MBR partition table to MBR, and (2) reinstall grub? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[sdwalker/sdwalker.github.io] 925b41: This week's update
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 --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 925b41337c7cb152d1c5c41f84666d65ffbcc9fc https://github.com/sdwalker/sdwalker.github.io/commit/925b41337c7cb152d1c5c41f84666d65ffbcc9fc Author: Stephen Walker Date: 2023-01-22 (Sun, 22 Jan 2023) Changed paths: M uscan/index-21.02.html M uscan/index-22.03.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] firmware-utils: tplink-safeloader: Add alternative partition table offset
Some newer OEM firmware files, even for existing devices, have the
fwup-ptn at offset 0x1050 instead of 0x1014. If the fwup-ptn header is not
found at 0x1014, the alternative offset at 0x1050 is tried.
Signed-off-by: Andreas Böhler
---
src/tplink-safeloader.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index ddb5dff..5bf62f3 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -3987,6 +3987,7 @@ static void convert_firmware(const char *input, const
char *output)
struct flash_partition_entry *flash_os_image = NULL, *flash_file_system
= NULL;
struct flash_partition_entry *fwup_partition_table = NULL;
size_t firmware_offset = 0x1014;
+ size_t firmware_offset_alt = 0x1050;
FILE *input_file, *output_file;
struct stat statbuf;
@@ -4005,7 +4006,12 @@ static void convert_firmware(const char *input, const
char *output)
error(1, 0, "Can not open output firmware %s", output);
if (read_partition_table(input_file, firmware_offset, fwup,
MAX_PARTITIONS, 0) != 0) {
- error(1, 0, "Error can not read the partition table
(fwup-ptn)");
+ fprintf(stderr, "DEBUG: can not find partition table at 0x%lx,
trying alternative location at 0x%lx\n",
+ firmware_offset, firmware_offset_alt);
+ firmware_offset = firmware_offset_alt;
+ if (read_partition_table(input_file, firmware_offset, fwup,
MAX_PARTITIONS, 0) != 0) {
+ error(1, 0, "Error can not read the partition table
(fwup-ptn)");
+ }
}
fwup_os_image = find_partition(fwup, MAX_PARTITIONS,
--
2.38.1
___
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 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ç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mt7621 GPIO mapping mystery
Hi Bas, > On 21 Jan 2023, at 22:53, Bas Mevissen wrote: > >> On 2023-01-21 22:42, Lukas Zeller wrote: >> That really looks like a great solution with all advantages combined! >> I agree this is better than patching, I just did not realize it was >> possible at all to modularize dt overlay functionality this way. > > It is a thing very commonly done on RPi "hats" to change the pin config on > the extension header. Yes, RPi has DT overlays, but AFAIK these are merged by the rpi-specific bootloader according to what config.txt says, before starting the linux kernel. I don't think RPi offers a way to add overlays after boot via configfs by default. Many other platforms don't have a bootloader which allows that pre-boot overlay loading. U-boot can do it [1], but it depends on how it is built, and replacing u-boot on a given target is more demanding than installing a kernel module. So the dtbocfg loadable module as recommended by Tomasz enables DT overlays even for targets which don't have such functionality in the boot loader, just by installing a package, which is nice and a pretty generic solution. It is not totally generic because it requires the kernel to be built with CONFIG_OF_OVERLAY set, which seems not to be the default in most targets. > You may find some documentation and examples there that may help you. Indeed, due to the popularity of overlays in the RPi space, there are a lot of examples. Lukas [1] : https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html signature.asc Description: Message signed with OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
