<dwmw2_gone>
I'm trying to make vrx318 work in the Netgear D7800, and trying to work out what I even need to port/update between the existing work on vrx518, and the open source netgear release.
fda has joined #openwrt-devel
<dwmw2_gone>
I enabled the PCI so I can at least *see* it now :)
<dangole>
neggles: which device is that? sounds like finally someone got it right. and btw: ubi volumes (just like LVM volumne) can easily change their size :)
<dangole>
neggles: ideally, you can use a single FIT image with kernel, dtb **and rootfs(squashfs)**, see bananapi-r64 or linksys-e8450/belkin-rt3200 for example.
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
<neggles>
dangole: sophos APX530, the other models in the same series do the same thing
<dangole>
neggles: this allows for straight forward sysupgrade using a single FIT file (instead of having to use sysupgrade.tar format)
<dangole>
neggles: very nice. though a bootloader talking to the internet is a bit scary ;)
<neggles>
it will only go direct to internet if you have some specific DHCP options set
<neggles>
otherwise it tries to discover a local Sophos XG Firewall appliance via L2 (or via those same dhcp options)
<neggles>
dangole: thankyou though! I'd worked out the first few bits of that process from looking at the buffalo wxr-2533dhp (which happens to do the same thing / have the same layout after all, but uses a legacy uimage), will check out the rt3200/bananapi to work out the rest of the details
<neggles>
aaaaaaaaaah! `external-static-with-rootfs` that's the bit i'm missing
<dangole>
neggles: you also need to enable CONFIG_FIT_PARTITION in kernel config so the rootfs inside the uImage.FIT inside ubiblock device will be mapped as mountable block device partition and also set as default rootfs (unless you specify root=... in kernel cmdline)
<neggles>
there are quite a few nice things about this AP, really. sophos provides GPL tarballs that even include full build instructions, precreated dev-mode image signing keys, a prebuilt u-boot binary with those dev keys installed in it (which you don't actually need, `setenv verify no` in u-boot console (which is not locked out on a factory-defaulted AP)
<neggles>
turns off image verification)
<stintel>
that sounds nice
<neggles>
only thing I *can't* work out so far is how to make the damn bluetooth radio wake up... I think it must have the csrmesh firmware on it instead of regular hci firmware, or there's a gpio they've not mentioned
<dangole>
neggles: so they didn't just get the software part right (using UBI on whole NAND), but seems like they are even very generous and allow you to build even signed image for their hardware. plus documentation. hard to believe all this
<neggles>
the dev mode key is not present in the factory u-boot image, but it's trivial to ssh into a running AP and overwrite, or just `fw_setenv bootdelay 5; fw_setenv verify no`
<neggles>
they even include all their patches to the qsdk kernel as actual numbered-order patch files, even though they're pre-applied, and all of their custom boot scripts etc. - the only thing that's missing is the stuff that's not in the open-source QSDK, and their own custom binaries for the capwap config / cloud stuff
<dangole>
neggles: it's some IPQ6xxx (hard to recognize on fcc internal photos), right?
<neggles>
ipq8064
<dangole>
neggles: wow, lots of juice for a wifi 5 AP
<neggles>
2x QCA9990 3x3 radio (4x4 in the APX740) CSR8311 bluetooth
<neggles>
dangole: yup! this thing was insanely good at time of launch, and not even all that expensive considering
<neggles>
their factory firmware has NSS enterprise, uses the hardware vxlan accel to tunnel packets back to the XG appliance
<neggles>
and it only bothers to actually map 512MiB of the RAM for some reason
<neggles>
so there's a few weird bits, but overall i'm really quite impressed - WNC (the ODM they used) even left comments in the u-boot source detailing gpio setup/assignments per model
<neggles>
their previous generation APs (that went EoL and almost-end-of-support june last year) are similarly well documented (and I have had a PR open to support those since october-ish)
<neggles>
anyway. would enabling CONFIG_FIT_PARTITION for the whole ipq806x target be likely to cause issues?
svanheule_ is now known as svanheule
svanheule has quit [Quit: svanheule]
svanheule has joined #openwrt-devel
<f00b4r0>
hmm wth. network_get_device dev "wan" returns empty despite wan being up and running
<neggles>
oh they also left u-boot's gunzip()/lzmadec() buffer size on the default 8MiB, so compressed FIT images don't work. using a zImage works fine, not a big deal, but annoying.
<neggles>
(that sound you just heard was hurricos yelling "AGAIN?!")
<dwmw2_gone>
dangole: thanks, yeah. I saw that. Looks like good progress on vrx518 and I'm trying to get vrx320 to work too
<dangole>
neggles: The FIT partition parser only hits in if the 'external' keyword is present, as otherwise the images are literally embedded into the FIT(=FDT binary format) and you have to page all over it to map the areas. 'external' means that instead of embedding the images into the FIT structure, only offsets are stored inside FIT (ie. more like a partition table...)
<dangole>
neggles: ie. as there are no images in that target which already use 'external-data' FIT images, nor do they contain a 'filesystem' part, I think chances for issues caused by this a very close to 0.
<neggles>
so effectively a no-op for images/devices that don't use it, cool :)
<dangole>
neggles: exactly.
<dangole>
neggles: it's kinda what kernel folks have always been asking as to do instead of all that mtd-splitting stuff. So once I find the time for it, I'll submit it to upstream Linux. I want to first convert mtdblock to use dynamic minors, as right now there can only be one additional mapped sub-partition for FIT images living on NOR flash (that's enough for OpenWrt, but not very generic)
<dangole>
neggles: when it started that people would use block2mtd to then use mtdsplit on top, that did it for me and i sat down for some days to write a proper partition parser which can work on mtdblock, ubiblock and GPT/MBR partitions on block devices.
<dangole>
neggles: that doesn't solve anything for all the existing mess, but at least now i got hope for a better future ;)
<rsalvaterra>
nbd: Just a heads up, in case you missed it, I got an RCU stall in mt76, with the latest bump from your tree plus Lorenzo's skb patch on top (no WED stuff, though). I linked the stack trace here yesterday, but it's pretty much useless, since I'm not compiling the kernel with debugging symbols.
<neggles>
dangole: yeah, I've been digging through a bit of the partition handling and rootfs mounting stuff and it's not very pretty in a few places :P at least there's a better solution things can be moved over to!
<neggles>
hmm. u-boot does not like this kernel FIT though
<neggles>
dumpimage on my build machine reads it fine, old u-boot problem?
<neggles>
that or i've goofed something
<dangole>
neggles: it's very old U-Boot? because only supported since commit a1be94b654 ("SPL: Add FIT data-position property support")
<neggles>
u-boot 2012.07 :(
<dangole>
neggles: no wait, i had it working with U-Boot 2014
<dangole>
neggles: 2012 could indeed be too old, lemme check
<neggles>
data start / data size show as unavailable for all three images in the FIT
<dangole>
neggles: no, out of luck. U-Boot 2018.01 was the first release to support this
<dangole>
neggles: (with U-Boot 2014 I was using additional initramfs image embedded in FIT, but that always worked from day 1 and there is even a legacy image format for initramfs...)
<neggles>
i'm looking at the bootloader source and yeah, it does support extracting and loading a ramdisk image, but image-fit.c hadn't even been split out
<dangole>
neggles: FIT_DATA_POSITION_PROP is undefined before that commit, so no...
<neggles>
indeed. no FIT_DATA_POSITION_PROP anywhere in this source
<dangole>
neggles: the really sad thing is that the compile-date (Nov 21 2017) is just around the time when support for this was added -- but they were using 5 years old U-Boot at this point...
<neggles>
dangole: yeah... that's QSDK for you I guess, the device itself was only released in 2016 or 17
<stintel>
so this should support it: U-Boot 2018.09 (Nov 15 2021 - 20:01:08 +0800)
* stintel
is trying this on ZR-2662
<dangole>
stintel: yes, it very much should :)
<neggles>
the commit is in the 2018.01 tag, and the 2018.09 tag
<stintel>
tried what OEM firmware does in OpenWrt (kernel / squashfs / jffs directly on NAND) but there are bad NAND blocks and things shit the bed
<stintel>
what was needed to convince iPhone to connect to psk3-mixed network ?
<stintel>
had a friend over for visit in the weekend and had to downgrade my guest ssid to psk2 :/\
<stintel>
stupid apple crap
<neggles>
so I guess I'm back to putting rootfs in a separate ubivol? though
<neggles>
it's happy to let there be filesystem images, so the FIT could be the usual kernel+initrd, then a dtb, then a rootfs image, if that's something that works - not exactly short of flash space here
<dangole>
neggles: yes, it will have to be separate volumes then and sysupgrade.tar... I didn't implement splitting UBI volumes as that seemed overkill as they are dynamically sized anyway, but yes, that would allow us to use FIT+appended rootfs like we do on NOR flash platforms...
<mrkiko>
ptpdanhi!! :D :D
<dangole>
stintel: Using UBI volumes (like @neggles is doing now) is supported in U-Boot for ages (I played with it first around 2010) -- if they just enabled support for it. so even if single-image is not an option, at least you could use UBI to store the kernel (for rootfs and rootfs_data you anyway don't depend on bootloader support)
<neggles>
dangole: darn. it would be a little redundant, but i was thinking of something like a combination of `with-rootfs` and `with-initrd` - a full kernel+initrd for u-boot, with an extra filesystem image in the FIT, just to avoid dealing with the rootfs ubivol
<neggles>
partly because the mtdpart which contains the UBI is also named 'rootfs', because of course it is
<mrkiko>
oops
<mrkiko>
dangole: hi!! :D :D
<neggles>
sophos did not have to worry about this, they run entirely out of the embedded initrd :P
<dangole>
neggles: mtdpart is defined in DTS, you can just rename it there to be called 'ubi' instead.
<dangole>
mrkiko: hi :)
<stintel>
is that ubi stuff supposed to work on the mtk nand controller ?
<stintel>
I am being flooded with [ 220.168090] mt7621-nand 1e003000.nand: Uncorrectable ECC error at page 45120.2
<neggles>
sounds like your u-boot doesn't agree with your kernel/dts on what NAND ecc params to use
<dangole>
stintel: yes, UBI generally works fine with mtk-nand controller. we are using it for various Xiaomi devices which are MT7621-based.
<neggles>
dangole: true, but u-boot passes `ubi.mtd=rootfs` in the cmdline (and modifies the /chosen/ node in the fdt appropriately) - won't that mean I have to override the cmdline?
<dangole>
neggles: if there is a mtd partition named 'ubi' then OpenWrt auto-attaches it, it's a patch we carry since modifying cmdline is not always an option.
<dangole>
neggles: (no idea how that ended up in 'pending-*' though, should be in 'hack-*')
<neggles>
"auto-attach mtd devices only if built-in to the kernel and no ubi.mtd parameter was given"
<neggles>
won't ubi.mtd=rootfs override that? (not sure it matters if the ubi mtd is named rootfs and we go looking for a rootfs ubivol - it also appears that ubi_rootfs is an acceptable alternative volume name)
<dangole>
neggles: if there is no MTD partition named 'rootfs' even existing it should work.
<neggles>
that makes sense
<neggles>
it’s almost midnight here, but I’ll give that a go tomorrow - thanks a lot! I always have trouble working out how to glue images together once nand/ubi gets involved
<mrkiko>
dangole: I debugger little bit further the problem I am having with mt7615e- after some days, the radio ends up in a state where clients can no longer send or receive traffic except for some limited set of it
lmore377_ has joined #openwrt-devel
<neggles>
stintel: do you have nand-ecc-step-size and nand-ecc-bytes (I think it’s that one) set in the DTS?
floof58 has joined #openwrt-devel
<stintel>
I do not
<mrkiko>
dangole: I debugged it with tcpdump to discover some traffic passes... but with latest driver versions no crashes, no the system reboots without goingto recovery due to pstore.
<neggles>
that’ll be it then
floof58_ has quit [Ping timeout: 480 seconds]
lmore377 has quit [Ping timeout: 480 seconds]
<stintel>
neggles: nowhere to be found in any other ramips device :(
<neggles>
it’s usually 512/8, but has to match up with whatever u-boot is already doing
<neggles>
oh wait
<neggles>
iirc on mtk nand everything uses hardware ecc?
<neggles>
yeah uncorrectable ECC error, how did you write the image to flash? uboot or ramboot?
<stintel>
sysupgrade from initramfs
<neggles>
though that looks fine actually I’d expect uncorrectable errors on bad blocks
<neggles>
that’s 5.6MiB in - bigger than your image? i suspect not
<stintel>
-EPARSE
rua has quit [Ping timeout: 480 seconds]
<dangole>
stintel: if there are actually really bad-blocks at these positions then that's the expected output and should not be a problem when using UBI.
rua has joined #openwrt-devel
<stintel>
dangole: sysupgrade with nand_do_upgrade seemingly got stuck in a loop spitting out these 4 uncorrectable ECC errors
<stintel>
I'll try again and have more patience
Piraty has quit [Remote host closed the connection]
rua has quit [Read error: Connection reset by peer]
Piraty has joined #openwrt-devel
rua has joined #openwrt-devel
<dangole>
stintel: loop after reboot or loop while sysupgrade itself was carried out?