Re: A Method of Breaking Git
On Tue, Oct 24, 2023 at 02:25:06PM +0200, Christian Marangi wrote: > On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote: > > Christian Marangi writes: > > > > > Anyway I have also found this [1]... if it does actually works, it might > > > be > > > THE solution to our specific problem. Wonder if someone can test it on a > > > sample repository. > > > > > > [1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904 > > > > Nice! Seems to work. Tried this in an almost uptodate OpenWrt main > > branch: > > > >git checkout -b dup > >git mv target/linux/ramips/mt7621/config-5.15 > > target/linux/ramips/mt7621/config-6.1 > >git commit -s -m 'create config-6.1 based on config-5.15' > >git checkout HEAD~ target/linux/ramips/mt7621/config-5.15 > >git commit -s -m 'restore config-5.15' > >git checkout - > >git merge --no-ff dup > > > > and ended up with > > > > bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 > > target/linux/ramips/mt7621/config-5.15 > > 6e91f43c99a7 (dup) restore config-5.15 > > 5a742b351365 create config-6.1 based on config-5.15 > > cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem > > offset patch > > 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs > > dc38199b96ee ramips/mt7621: disable the cpufreq driver > > > > bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 > > target/linux/ramips/mt7621/config-6.1 > > 5a742b351365 create config-6.1 based on config-5.15 > > cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem > > offset patch > > 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs > > dc38199b96ee ramips/mt7621: disable the cpufreq driver > > 958fdf36e35c generic: mt7530: backport support for the MT7988 built-in > > switch > > > > > > Best solution so far > > Yep only drawback is the additional commit and the merge commit but this > might be the only case where we can accept a merge commit. Might be > worth to document this in the wiki if we take a decision on this. Ironically I was thinking about solutions involving moves and merges as a potential method to reconstruct functional histories for the config files. All of these proposed strategies appear to successfully accomplish the task of keeping history attached to the configuration files. Some of the generic patches may be worthy of similar treatment. The history for the hack patches might be valuable. Likely the two bring-up steps could be done and they could share a single merge commit. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Comfast CF-E110n
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, Bill, I have a couple of them, but they're in a remote location I can't access right now. However, on one of them, I recently upgraded from OpenWrt 22.03.X to 23.05.0 and I did not experience such issues. In order to narrow down the issue, you may want to try flashing this older OpenWrt version (which one was it? CF-E110N is supported since 19.07...), then upgrade one major release at a time (first 21.02, then 22.03, until 23.05). When does this issue appear, if it does? Best, Roger El 23/10/23 a les 23:54, Bill Moffitt ha escrit: I have been using an older version of OpenWRT on my E110Ns; I loaded up the latest release to see if it would fix some "LOST BEACON" problems. Unfortunately, it didn't even boot (went into a bootloop), so I broke out the serial cable, busted open the radio, and connected it. Here's what I captured: U-Boot 1.1.4-ge619c187-dirty (Apr 12 2017 - 18:52:08) ap143 - Honey Bee 2.0 DRAM: 64 MB Flash: 16 MB dup 1 speed 100 Using eth0 device ping failed; host 192.168.1.10 is not alive Unknown command 'ERROR!' - try 'help' Hit any key to stop autoboot: 1 0 ## Booting image at 9f02 ... Image Name: MIPS OpenWrt Linux-5.15.134 Created: 2023-10-09 21:45:35 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:2328775 Bytes = 2.2 MB Load Address: 8006 Entry Point: 8006 Verifying Checksum at 0x9f020040 ...OK Uncompressing Kernel Image ... OK No initrd ## Transferring control to Linux (at address 8006) ... ## Giving linux memsize in bytes, 67108864 Starting kernel ... [0.00] Linux version 5.15.134 (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 Mon Oct 9 21:45:35 2023 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) [0.00] MIPS: machine is COMFAST CF-E110N v2 [0.00] SoC: Qualcomm Atheros QCA9533 ver 2 rev 0 [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x03ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x03ff] [0.00] Initmem setup node 0 [mem 0x-0x03ff] [0.00] Built 1 zonelists, mobility grouping on. Total pages: 16240 [0.00] Kernel command line: console=ttyS0,115200n8 rootfstype=squashfs,jffs2 [0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [0.00] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 55972K/65536K available (6077K kernel code, 591K rwdata, 780K rodata, 1184K init, 217K bss, 9564K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 51 [0.00] CPU clock: 650.000 MHz [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 5880801374 ns [0.02] sched_clock: 32 bits at 325MHz, resolution 3ns, wraps every 6607641598ns [0.008370] Calibrating delay loop... 432.53 BogoMIPS (lpj=2162688) [0.074950] pid_max: default: 32768 minimum: 301 [0.080919] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.088644] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.105660] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.116125] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [0.123566] pinctrl core: initialized pinctrl subsystem [0.131441] NET: Registered PF_NETLINK/PF_ROUTE protocol family [0.138492] thermal_sys: Registered thermal governor 'step_wise' [0.153766] clocksource: Switched to clocksource MIPS [0.167301] NET: Registered PF_INET protocol family [0.172759] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) [0.181676] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [0.190630] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [0.198823] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.206939] TCP bind hash table
Re: [PATCH v4 5/7] ixp4xx: Resurrect IXP4xx support using device tree
W dniu 23.10.2023 o 08:43, Linus Walleij pisze: > This resurrects the support for IXP4xx using device tree > rather than the old (deleted) board files. The final pieces > of IXP4xx board files were deleted in Linux v5.19. > > Ext4 root filesystems on CF and USB are supported by the > default config. > > We support these three initial targets: > > - The Gateworks Avila GW2348 reference design has 64MB of RAM > and 32MB of flash and also supports USB and CompactFlash. > > - The Gateworks Cambria GW2358 reference design has 128MB of > RAM and 32MB of flash and also supports USB and CompactFlash. > > - The old and stable Linksys NSLU2 works fine as well, albeit > it only has 32MB of RAM so it has been marked as non-default. > The 8MB of flash can only fit the kernel, so it has been > patched to boot from exteral media on USB. I have used > it successfully as a NAS with ksmbd and LUCI web API, see: > https://dflund.se/~triad/krad/ixp4xx/ > > Signed-off-by: Howard Harte > Signed-off-by: Linus Walleij Thank You for following suggestions, with that: Reviewed-by: Tomasz Maciej Nowak > --- > ChangeLog v2->v3: > - Don't add the apex package on the NSLU2, the dependency > is resolved in the other direction, apex should only build > itself for the targets that need it. > - Alter the path for the apex binaries slightly. > - Split out resurrection of the microcode package to its > own patch. > - Use only the ip command and not both ip and ifconfig in > the MAC setup script. > - Drop unsupported device from the MAC setup script. > - Name devices with device tuples like gateworks_avila. > - Fix name confusion Gateway -> Gateworks. > ChangeLog v1->v2: > - Have NSLU2 select the apex boot loader instead of having > it default built for all targets. > - SPDX header for the microcode package. > - Set microcode package version back to 1. > - Split the microcode firmware package in two, one for > just regular ethernet, one for WAN/HSS and select the > right package for each device, ridding us one useless > firmware file per device. > - Cleanup Kconfig using make kernel_oldconfig. > - Remove several surplus kernel Kconfig options, some > pointless 8250 extensions for example. > - Drop all the RTCs from the Kconfig and use the corresponding > kernel modules for each device instead, saving space. > - Drop all the HWMON drivers from the Kconfig and use the > corresponding kernel modules for each device instead. > - Use a kernel module for EEPROM access on Gateworks devices. > - Fold in an ethernet numbering fix from Howard Harte > - Activate Marvell MV88E6060 DSA switch as used by > USRobotics USR8200. > --- > target/linux/ixp4xx/Makefile | 27 +++ > .../linux/ixp4xx/base-files/etc/board.d/02_network | 21 ++ > .../base-files/lib/preinit/05_set_ether_mac_ixp4xx | 38 > target/linux/ixp4xx/config-6.1 | 252 > + > target/linux/ixp4xx/image/Makefile | 77 +++ > ...01-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++ > ...-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++ > 7 files changed, 513 insertions(+) [...] -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CI/CD failures on non-x86 platforms
On Tue, 24 Oct 2023 at 17:46, Philip Prindeville wrote: > > Hi, > > I'm seeing the following: > > https://github.com/openwrt/packages/actions/runs/6621741418/job/17986176198?pr=22362 > > Specifically: > > mips-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o > cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o > cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o > cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o > cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o > lex.cligen_parse.o cligen_parse.tab.o > -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/usr/lib > -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/lib -fuse-ld=bfd > -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. > /builder/staging_dir/host/bin/install -c -m 0755 -d > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib > /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib > strip: Unable to recognise the format of the input file > `/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' > /builder/staging_dir/host/bin/install: strip process terminated abnormally > make[3]: Leaving directory > '/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0' > make[3]: *** [Makefile:157: install-lib] Error 1 > make[2]: *** [Makefile:60: > /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/.built] Error 2 > > > It looks like it's running on an x86_64 but the version of "install" doesn't > understand MIPS binaries. Is that what's happening? And why is it only > affecting me? It's the strip tool that is complaining. Can you try making it run file before on it to see what the library .so actually is? Regards, Robert > > There's nothing particular about my packaging: > > https://github.com/pprindeville/packages/blob/clixon-initial/utils/clixon/Makefile > > What am I missing? > > Thanks, > > -Philip > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
CI/CD failures on non-x86 platforms
Hi, I'm seeing the following: https://github.com/openwrt/packages/actions/runs/6621741418/job/17986176198?pr=22362 Specifically: mips-openwrt-linux-musl-gcc -shared -o libcligen.so.6.4 cligen_object.o cligen_callback.o cligen_parsetree.o cligen_pt_head.o cligen_handle.o cligen_cv.o cligen_match.o cligen_result.o cligen_read.o cligen_io.o cligen_expand.o cligen_syntax.o cligen_print.o cligen_cvec.o cligen_buf.o cligen_util.o cligen_history.o cligen_regex.o cligen_getline.o build.o lex.cligen_parse.o cligen_parse.tab.o -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/usr/lib -L/builder/staging_dir/toolchain-mips_24kc_gcc-12.3.0_musl/lib -fuse-ld=bfd -znow -zrelro -Wl,-soname=libcligen.so.6.4 -L. /builder/staging_dir/host/bin/install -c -m 0755 -d /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib /builder/staging_dir/host/bin/install -c -m 0644 -s libcligen.so.6.4 /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib strip: Unable to recognise the format of the input file `/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/ipkg-install/usr/lib/libcligen.so.6.4' /builder/staging_dir/host/bin/install: strip process terminated abnormally make[3]: Leaving directory '/builder/build_dir/target-mips_24kc_musl/cligen-6.4.0' make[3]: *** [Makefile:157: install-lib] Error 1 make[2]: *** [Makefile:60: /builder/build_dir/target-mips_24kc_musl/cligen-6.4.0/.built] Error 2 It looks like it's running on an x86_64 but the version of "install" doesn't understand MIPS binaries. Is that what's happening? And why is it only affecting me? There's nothing particular about my packaging: https://github.com/pprindeville/packages/blob/clixon-initial/utils/clixon/Makefile What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A Method of Breaking Git
On Tue, Oct 24, 2023 at 02:21:35PM +0200, Bjørn Mork wrote: > Christian Marangi writes: > > > Anyway I have also found this [1]... if it does actually works, it might be > > THE solution to our specific problem. Wonder if someone can test it on a > > sample repository. > > > > [1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904 > > Nice! Seems to work. Tried this in an almost uptodate OpenWrt main > branch: > >git checkout -b dup >git mv target/linux/ramips/mt7621/config-5.15 > target/linux/ramips/mt7621/config-6.1 >git commit -s -m 'create config-6.1 based on config-5.15' >git checkout HEAD~ target/linux/ramips/mt7621/config-5.15 >git commit -s -m 'restore config-5.15' >git checkout - >git merge --no-ff dup > > and ended up with > > bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 > target/linux/ramips/mt7621/config-5.15 > 6e91f43c99a7 (dup) restore config-5.15 > 5a742b351365 create config-6.1 based on config-5.15 > cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem > offset patch > 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs > dc38199b96ee ramips/mt7621: disable the cpufreq driver > > bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 > target/linux/ramips/mt7621/config-6.1 > 5a742b351365 create config-6.1 based on config-5.15 > cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem > offset patch > 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs > dc38199b96ee ramips/mt7621: disable the cpufreq driver > 958fdf36e35c generic: mt7530: backport support for the MT7988 built-in switch > > > Best solution so far > Yep only drawback is the additional commit and the merge commit but this might be the only case where we can accept a merge commit. Might be worth to document this in the wiki if we take a decision on this. -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A Method of Breaking Git
Christian Marangi writes: > Anyway I have also found this [1]... if it does actually works, it might be > THE solution to our specific problem. Wonder if someone can test it on a > sample repository. > > [1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904 Nice! Seems to work. Tried this in an almost uptodate OpenWrt main branch: git checkout -b dup git mv target/linux/ramips/mt7621/config-5.15 target/linux/ramips/mt7621/config-6.1 git commit -s -m 'create config-6.1 based on config-5.15' git checkout HEAD~ target/linux/ramips/mt7621/config-5.15 git commit -s -m 'restore config-5.15' git checkout - git merge --no-ff dup and ended up with bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 target/linux/ramips/mt7621/config-5.15 6e91f43c99a7 (dup) restore config-5.15 5a742b351365 create config-6.1 based on config-5.15 cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem offset patch 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs dc38199b96ee ramips/mt7621: disable the cpufreq driver bjorn@canardo:/usr/local/src/openwrt$ git log --oneline --follow -n 5 target/linux/ramips/mt7621/config-6.1 5a742b351365 create config-6.1 based on config-5.15 cd2b74e01e8d ramips: mt7621: disable highmem support and remove highmem offset patch 39b2251cd972 treewide: remove CONFIG_FRAME_WARN from kernel configs dc38199b96ee ramips/mt7621: disable the cpufreq driver 958fdf36e35c generic: mt7530: backport support for the MT7988 built-in switch Best solution so far Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A Method of Breaking Git
On Tue, Oct 24, 2023 at 01:40:22PM +0200, Bjørn Mork wrote: > Ack on the broken history problem. > > I don't think it's necessary to keep two separate histories though. The > main issue is the periodical removal of files keeping parts of history, > resulting in an increasing number of file names to follow for the > complete history. > > Doing > > git mv config-5.15 config-6.1 > git commit -m 'move Linux 5.15 kernel configuration to Linux 6.1 > configuration' > cp config-6.1 config-5.15 > git commit -m 'resurrect Linux 5.15 kernel configuration' config-5.15 > > would make sure that config-6.1 kept all the history. It results in a > history-less config-5.15, but IMHO that's a minor issue. The point is > to maintain full history attached to one file. The name of this file is > not important. > > The duplicate history attached to the older filename is less > interesting. It will still show changes happening after the split of > course. And you'll most likely start with the "master" history in any > case, and only look at the other file in case there are differences not > explained by that history. > > (Note that two separate commits are required since git is "smart" enough > to detect what happens if you try to squash them) > Also agree that this is a problem. lost of history is problematic and I already had some problem trying to find why something was added Luckly this happen only on kernel bump so not that usual... My problem with the "copy - resurrect" is that we would still lose history (but this time on the old file) and have some bloat with an additional commit... So I would like if there was a better solution Anyway I have also found this [1]... if it does actually works, it might be THE solution to our specific problem. Wonder if someone can test it on a sample repository. [1] https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904 -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: A Method of Breaking Git
Ack on the broken history problem. I don't think it's necessary to keep two separate histories though. The main issue is the periodical removal of files keeping parts of history, resulting in an increasing number of file names to follow for the complete history. Doing git mv config-5.15 config-6.1 git commit -m 'move Linux 5.15 kernel configuration to Linux 6.1 configuration' cp config-6.1 config-5.15 git commit -m 'resurrect Linux 5.15 kernel configuration' config-5.15 would make sure that config-6.1 kept all the history. It results in a history-less config-5.15, but IMHO that's a minor issue. The point is to maintain full history attached to one file. The name of this file is not important. The duplicate history attached to the older filename is less interesting. It will still show changes happening after the split of course. And you'll most likely start with the "master" history in any case, and only look at the other file in case there are differences not explained by that history. (Note that two separate commits are required since git is "smart" enough to detect what happens if you try to squash them) Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
