mko_ has quit [Read error: Connection reset by peer]
mko has joined #openwrt-devel
mko has quit [Read error: Connection reset by peer]
mko has joined #openwrt-devel
Sawzallz has joined #openwrt-devel
Sawzall has quit [Ping timeout: 480 seconds]
AtomiclyCursed2 has joined #openwrt-devel
AtomiclyCursed has quit [Read error: Connection reset by peer]
AtomiclyCursed2 is now known as AtomiclyCursed
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
Daanct12 has joined #openwrt-devel
sorinello has joined #openwrt-devel
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
goliath has joined #openwrt-devel
valku has quit [Quit: valku]
slingamn has quit [Quit: leaving]
slingamn has joined #openwrt-devel
plappermaul has joined #openwrt-devel
Sawzallz has quit [Remote host closed the connection]
warpme has joined #openwrt-devel
Sawzallz has joined #openwrt-devel
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
<f00b4r0>
diffing linux/drivers/net between a ramips/mt7621 build_dir and a mediatek/filogic one, I'm surprised at how big a diff there is and even moreso, at how many bits apparently unrelated to the target actually differ
<f00b4r0>
not sure it's ideal to run rather different kernels across the board
<f00b4r0>
(trying to figure out why I still observe #11650 on filogic - with mt7531 switch - but not on ramips - mt7530)
guidosarducci has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
guidosarducci has joined #openwrt-devel
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
n3ph has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
warpme has quit []
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
robimarko has joined #openwrt-devel
warpme has joined #openwrt-devel
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #openwrt-devel
goliath has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
KGB-2 has quit [Remote host closed the connection]
KGB-2 has joined #openwrt-devel
* f00b4r0
starts pulling hair again with build system. Makefile works locally, fails CI
ungeskriptet has quit [Read error: Connection reset by peer]
ungeskriptet has joined #openwrt-devel
ScrewDri- has joined #openwrt-devel
ScrewDriver1337 has quit [Ping timeout: 480 seconds]
ScrewDri- is now known as ScrewDriver1337
<aparcar[m]>
f00b4r0: i don't have to much time for CI stuff but improvements would be very welcome. I can't review a lot of your work since I'm not familiar with the topics, however please feel free to forward CI PRs to me
<f00b4r0>
aparcar: I'm not sure who's wrong: me or the CI tbh. Just confusing that the same makefile would fail in one case and not the other
<robimarko>
Its one of 2 things, config or host differences
<f00b4r0>
I usually build with CONFIG_BUILDHOST=y
<f00b4r0>
the build failed on the CI because a file wasn't found. I think it's some differing interpretation of CMAKE_SOURCE_SUBDIR wrt CompileBPF() call
<f00b4r0>
have to run, ttyl
<hauke>
f00b4r0: The CI is not very relaiable since some weeks. Kernel build randomly fail in the GPG signature check or LLVM download. build all packages failed because of autohell bugs. The autohell stuff is fixed now, thanks robimarko
GNUmoon2 has joined #openwrt-devel
<hauke>
I retriggerd some kernel builds
<hauke>
f00b4r0: which PR are you talking about?
GNUmoon has quit [Ping timeout: 480 seconds]
robimarko has quit [Remote host closed the connection]
warpme has quit []
gromero has joined #openwrt-devel
gromero_ has quit [Ping timeout: 480 seconds]
warpme has joined #openwrt-devel
warpme has quit []
valku has joined #openwrt-devel
Daanct12 has quit [Quit: WeeChat 4.7.0]
goliath has quit [Quit: SIGSEGV]
noltari is now known as Guest23669
noltari has joined #openwrt-devel
Guest23669 has quit [Ping timeout: 480 seconds]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
ssterling has quit [Ping timeout: 480 seconds]
ssterling has joined #openwrt-devel
caskd has quit [Ping timeout: 480 seconds]
lucascastro has joined #openwrt-devel
n3ph has joined #openwrt-devel
caskd has joined #openwrt-devel
n3ph has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
tohojo has joined #openwrt-devel
plappermaul has quit [Remote host closed the connection]
n3ph has joined #openwrt-devel
noltari is now known as Guest23681
noltari has joined #openwrt-devel
noltari is now known as Guest23682
noltari has joined #openwrt-devel
lucascastro has quit [Remote host closed the connection]
Guest23681 has quit [Ping timeout: 480 seconds]
Guest23682 has quit [Ping timeout: 480 seconds]
plappermaul has joined #openwrt-devel
<plappermaul>
someone with NAND ECC/OOB experience online?
<f00b4r0>
hauke: #27181 - my understanding is that it could have been a PEBKAC. I was relying on CMAKE_SOURCE_SUBDIR but it (obviously) doesn't apply to CompileBPF steps. Now I'm puzzled why it worked locally but that's another story
james_k has joined #openwrt-devel
<james_k>
snapshot repos still broken? can't seem to install anything due to a bunch of no such package and dep issues.
<james_k>
(tested on r7800)
n3ph_ has joined #openwrt-devel
n3ph has quit [Read error: Connection reset by peer]
<dwfreed>
the libc version change is probably the big problem in that output
<james_k>
this is fresh, using the latest snapshot sysupgrade image
<james_k>
33f76cb1a2b1a7abf651c579fdf6be90abf87efb0296c1c777586e9fa1eda9807690.6 KBThu Aug 7 12:57:00 2025
<james_k>
doing a clean install again now to test again
<james_k>
well, it works now
<james_k>
lol
<james_k>
maybe pebkac
lucascastro has joined #openwrt-devel
rwalker777 has joined #openwrt-devel
<rwalker777>
Hoping there is someone who can help me with a u-boot issue... When I build for a TP-Link MT7621 based access point, the DRAM won't initialize.
james_k has quit [Remote host closed the connection]
lucascastro has quit [Remote host closed the connection]
sorinello has quit [Ping timeout: 480 seconds]
noltari is now known as Guest23689
noltari has joined #openwrt-devel
<merbanan>
plappermaul: yes ?
n3ph_ has quit [Ping timeout: 480 seconds]
Guest23689 has quit [Ping timeout: 480 seconds]
<plappermaul>
merbanan: ok. to make it short
<plappermaul>
if I have a 2K + 64 byte data+oob+ecc flash area and I put an UBI on top how can I instruct it to use a special ECC software algorithm?
<merbanan>
this depends on the hardware used + nand driver, what are you using ?
<plappermaul>
My issue is: Vendor partition with UBI on Macronix Flash gives ECC uncorrectable errors. The 64 extra byte look like an 4*6 OOB + 4*10 BCH6. But the datasheet gives another layout.
<plappermaul>
I'm using the spi-realtek-nand (upstreamed with 6.12). Chris Pack just wrote something like "simply use on chip nand and not Realtek hardware ECC engine"
<merbanan>
ok, if you can disable hardware ecc you can use software instead
<merbanan>
spi-nand != parallel nand, what do you have?
<plappermaul>
It is SPI-NAND. I would do so but but how to disable Macronix ECC? At least my kernel stack assumes the error is coming from on-die nand.
<merbanan>
ok, this is kind of complex, let me try to sort it out
<merbanan>
in the beginning parallel nand with 2k blocks had 64bytes OOB to fit the ECC data
<merbanan>
Reed Solomon and BCH codes where used for ECC
<merbanan>
most ECC where implemented in hardware because of speed reasons
n3ph has joined #openwrt-devel
<merbanan>
then the kernel got a fast BCH codec and at least one vendor used it instead of implementing BCH hardware
<plappermaul>
sounds like my problem. Now my OpenWrt Image tries to use on-die nand and the OOB has been written by the vendor in software with another layout.
<merbanan>
then spi-nand got popular (less pins) and most storage chips had an internal ecc feature/function
<merbanan>
spi-nand has larger OOB, so for a 2K block there is a 64+64 bytes of ecc storage
<merbanan>
if on-chip ecc storage is activated the last 64 bytes are hidden but used internally the the spi-chip
<plappermaul>
ah see
<merbanan>
the mode the spi-chip uses must be controlled by the soc boot rom
<plappermaul>
and nanddump gives 64 extra bytes per 2K
<merbanan>
how are you writing the image ?
<merbanan>
is it an offline programmer ?
<plappermaul>
Nope it is a vendor burned image. And I'm running from initramfs. trying to attach a ubi partition ein found results in ECC errors.
<merbanan>
ok, if the system is running just strip all the OOB data and write the raw image
<merbanan>
the driver/hw will create proper ECC data on flash
<merbanan>
only offline programming needs to handle ecc data (as long as working system/uboot exist on target)
valku has quit [Ping timeout: 480 seconds]
<merbanan>
if you really really want to write the OOB/ECC data you need a hardware specific tool to generate a specific image
<plappermaul>
Understood. Is there any configuration way to tell the UBI or spinand_read_page() function that it sould ignore the on-die ECC returncode?
<plappermaul>
If not I think I must extract the UBI and mount it outside the device.
<merbanan>
no, why would it want that (that I know of)?
<merbanan>
if UBI gets a report from the nand subsystem of to many correctable ECC errors it will move the data to another block
<plappermaul>
To say it in another way. Can I instruct the system to use the software BCH6 code instead of the on-die. My assumption is, that this will fit perfectly what I found in the OOB area.
<merbanan>
you might have that option via dts or the boot loader
<plappermaul>
My little brain just thinks: Vendor wrote data plus software based oob and now I read same data and on-die ecc engine always says "uncrecoverable".
<plappermaul>
Ok I will search for a possible software ecc "hook" in the call stack.
<merbanan>
do you have the image with raw UBI+ecc on your computer ?
<plappermaul>
Can download it tomorrow.
<merbanan>
if you filter out the ecc data you dont need to mess ecc at all
<merbanan>
just write the raw image to nand and all will be fine
<plappermaul>
Yeah. Will start with this. Thanks for your time and the insight..
<merbanan>
if UBI blocks have not been reallocated you can use nandread and then write
<merbanan>
this would recreate the OOB in its proper form
<plappermaul>
and will simply use on-die nand.
<plappermaul>
ehm on die ecc.
<merbanan>
or whatever solution the system has configured
<plappermaul>
Thanks. Will try that in some uncritical area.
<plappermaul>
Sorry for consuming your time but this is all new.