<torv>
dangole: How to upgrade U-Boot on RT3200? Is `mtd write $FIP /dev/mtd1` with ImageBuilder's `...-uboot.fip` sufficient?
<dangole>
torv: you need to use kmod-mtd-rw as /dev/mtd1 is read-only otherwise (as a precaution to make sure everybody understands to be only half an inch away from bricking things if not acting very carefully). if you have the serial console connected, there is also an option in the U-Boot bootmenu to update BL3 image via TFTP.
<dangole>
torv: generally there is (up to now) no good reason to update U-Boot on the RT3200, you will gain **nothing** by doing so, and you risk having to resort to JTAG if things go wrong.
<dangole>
torv: literally, the biggest difference since U-Boot 2020.10 is that now you got a more fance version string which allows identifying the OpenWrt build...
Tapper has quit [Ping timeout: 480 seconds]
<dangole>
torv: I'm only updating U-Boot on the device where I got JTAG wired up anyway already. my other device will live with the version I initially flashed for ever.
<dangole>
torv: if you have modified U-Boot to gain more fancy features (let's say: UEFI to load memtest86+) that's a different story of course. i'd be testing that on more hacker-friendly devices (like the BPi-R64) first though....
<torv>
dangole: I see, thanks. If I wanted to take the risk ImageBuilder's FIP 'd be it then?
<dangole>
torv: yes, that's the right file. FIP == BL3 of ARM Trusted Firmware which is basically BL31 and U-Boot.
isak has quit [Remote host closed the connection]
<dangole>
torv: see also https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/boot/uboot-mediatek/patches/410-add-linksys-e8450.patch;h=fde679f3863ccf2e22a3e1fd299963b66041a0b9;hb=HEAD#l375
<torv>
dangole: Yeah, lists as "bl31". Is that the 2022.01 just as in yours?
<dangole>
torv: yes, that's where it came from
<dangole>
torv: (as in: the installer uses that file from IB)
<dangole>
torb: I'm about to bump it to 2022.04, but there have been some minor regressions which still need to be sorted...
<torv>
dangole: I remembere having read you explained "there is no gppd reason to update [it]". I'll keep it as is too.
<torv>
dangole: Interesting.
<torv>
dangole: Do you have a JTAG adapter to recommend?
<dangole>
torv: I use self-made based on FT2232H breakout board and a bunch of pull-up and pull-down resistors. works good enough for me and cost about $15.
<dangole>
torv: ready-made ones based on that FT2232H chip are better, because they come with buffers and often are isolated (so you avoid ground loop problem and such)
<dangole>
torv: I avoid ground-loop problem by using my laptop battery-powered with PSU disconnected when using JTAG :)
<torv>
dangole: x) I should chalk up with a primer on e.g. thos pull-up/down resistors. To little electronics knowledge. Are FT2232HL based ones fine? See many for ~20 here.
<Namidairo>
this MT7986A board has kernel + rootfs in ubi, but has a separate overlay partition... also they have NMBM on...
<Namidairo>
;)
<dangole>
torv: yes, all those are fine. you may have to adapt openocd configuration based on what you find inside them, but that's not too hard, you will manage just trying the combinations you can find in existing configurations for that chip...
<dangole>
Namidairo: you are talking about what is commonly known as the BPi-R3? I've seen the bootlog and thought they may have learned something... but looking closer they are using vendor U-Boot and Kernel 5.4 (for which ever reason)...
<dangole>
Namidairo: there will be some cleanup before this will hit our tree, obviously...
<Namidairo>
nah, yet another Xiaomi unit
<dangole>
Namidairo: ok, that's even less surprising though. if their loader understands post-2018 uImage.FIT that'd be nice, because then it will allow to use single image approach like for the E8450/RT3200 or BPi-R64 or BPi-R2...
<Namidairo>
it's also 5.4 and u-boot 2022.01-rc1
<dangole>
Namidairo: U-Boot 2022.01-rc1 is recent enough for decent uImage.FIT support for squashfs as part of the FIT and split by partition parser :)
<Namidairo>
the only "hnnng" but would probably be the RGB led board hooked up to SPI tbh
<Namidairo>
*bit
<dangole>
Namidairo: sounds like a cool board. is it available for the general public outside of China?
<Namidairo>
I assume not, and it's locked down of course.
<Namidairo>
presumably that pairing of kernel+fip is just what the mtk sdk is at these days
<dangole>
Namidairo: kernel+fiP as in proper secure boot with ARM Trusted Firmware and OP-TEE? that's nasty...
<Namidairo>
not sure if they have secure boot since all I have to go off is their firmware image
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<dangole>
Namidairo: ok, so not that bad.... mind sharing the full bootlog inkl. U-Boot (in case you have access to the device and wired it up with serial)?
<Namidairo>
don't have access to one, just admiring from afar
<Namidairo>
they still have kexec on in their config which is funny
<mangix>
dangole: malta needs a refreshed kernel config for 5.15
<dangole>
mangix: right, i forgot to oldconfig that....
<Namidairo>
how many volumes did the ubi variant of the e8450 have, there's an issue here mentioning that the upgrade script breaks above 9
dangole has quit [Ping timeout: 480 seconds]
<Namidairo>
only 6.
<mangix>
someone needs to get an E7350 and fixup my PR.
<mangix>
in other news, as a result of the musl 1.2.3 version bump, only 1 package fails to build. That's pretty impressive
<mangix>
it was what I thought multiple packages would fail with. impressive that it's only one
Grommish has joined #openwrt-devel
<mangix>
oh surprising. gcc 7.4.0 fails to compile too
amaumene has quit [Quit: amaumene]
amaumene has joined #openwrt-devel
philipp64 has joined #openwrt-devel
philipp64 has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
<neggles>
torv: if you want a JTAG adapter, espressif's ESP-PROG is like $12 and it's an FT2232H board
<hanetzer>
good news. the kaitai yaml for the eap660hd works on the eap620hd as well :)
rua has quit [Ping timeout: 480 seconds]
<neggles>
one half in JTAG mode with a standard 10-pin pinout, the other half in UART mode, 3.3V + 5V level shift select, optional target power, and both 0.1"/0.05" headers + comes with cables
<neggles>
good stuff
<mangix>
ftdi, what a lovely company...
<neggles>
I mean your other option is basically a J-Link EDU
<neggles>
and I find those to be... troublesome at times
<mangix>
I was specifically referring to their UART chips and the Windows drivers for them.
<neggles>
heh, people are never going to let that go are they
rua has joined #openwrt-devel
<mangix>
nope. I have a NAS device with a microusb port that implements UART.
<mangix>
of course it doesn't work under Windows
<mangix>
my solution was brilliant. Connect the NAS to the router and run GNU screen
<hanetzer>
so, about `cliclientd stopcs' on tp link devices. do you still need a dummy appended signature?
<slh>
that's what svanhéùle mentioned yesterday
<slh>
the signature isn't checked anymore, but the uploaded firmware image (including the bytes for the signature) still needs to match the expected format
<hanetzer>
gotcha. whole lotta work to just write an ubi file lmao
<dansan>
Hello! There's currently no usan for mipsel and I've encountered a bug in uci intermittent :( Is there a guide anywhere for building ubox natively so I can run valgrind, et. al against it?
<dansan>
*an intermittent bug
<neggles>
dansan: build for the x86 target / x64 subtarget and run it in qemu? :P
<dansan>
Oh wait, I do recall a mips usan patch set on the gcc mailing list a few months ago, I guess I should find out if that ever got committed
<dansan>
neggles: omg, awesome! That sounds pretty easy :)
<dansan>
I sure will enjoy having usan again
<neggles>
fwiw you can build valgrind into the image as well
<neggles>
(does valgrind not run on mipsel?)
<dansan>
no, I believe it needs libusan
<dansan>
I think the same is true for the kernel sanitizer
philipp64 has joined #openwrt-devel
<dansan>
I think I had valgrind with chaos calmer
<dansan>
Oh, I guess it's actually "asan" and "ubsan"
philipp64 has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
sorinello has joined #openwrt-devel
goliath has joined #openwrt-devel
lmore377 has quit [Quit: No Ping reply in 180 seconds.]
lmore377 has joined #openwrt-devel
<jow>
I wonder if we should drop nftables-nojson
<jow>
fw4 does need nftables-json
<jow>
and I think in the long run, a lot of thiurd party utilies expect the nft json interface to be available
rua has quit [Ping timeout: 480 seconds]
indy has joined #openwrt-devel
rua has joined #openwrt-devel
amaumene has quit [Quit: amaumene]
pepe2k has joined #openwrt-devel
<stintel>
ah neat, new dropbear supports fido2 keys
<rsalvaterra>
stintel: Oh, yes. ;)
<stintel>
finally able to login to my OpenWrt devices from $corp hardware
<rsalvaterra>
Speaking of which, I updated my "dropbear diet" patch set for the latest bump, I don't know if anyone's interested in it. :P
* stintel
doesn't doe diets :P
<stintel>
apparantly also no coffee yet today
<rsalvaterra>
No coffee? That's a perfect reason to panic.
<mangix>
i'm interested in zswap patches
<rsalvaterra>
mangix: zswap…? Surely you mean swap on zram, no?
<rsalvaterra>
Because zswap is also a (completely different) thing. :)
<mangix>
i mean using a flash drive as swap
<stintel>
echo p > /proc/stintelrq-trigger
<stintel>
ehr, s/p/c/
<rsalvaterra>
mangix: We already have that, unless you're talking about zswap, or using the backing device feature of zram.
amaumene has joined #openwrt-devel
<rsalvaterra>
What we don't have (and should, in my humble opinion) is a way to swap out the compressed data to storage. It's a kernel limitation, since the swap data structures aren't prepared for storing arbitrary length data.
<rsalvaterra>
Too much dependency on PAGE_SIZE… :P
amaumene has quit [Ping timeout: 480 seconds]
amaumene has joined #openwrt-devel
danitool has joined #openwrt-devel
philipp64 has joined #openwrt-devel
Tapper has joined #openwrt-devel
philipp64 has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
gladiac has quit [Quit: k thx bye]
gladiac has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<torv>
dangole, neggles: Thanks. I'll get one of those.
<hurricos>
RTL8370N, so if you can control the switch externally over MDIO, ...
<hurricos>
but there's no serious support for that. It'll be years before OpenWrt robustly supports custom device tree overlays
<aiyion>
hurricos: the device you referenced works well for me;
<hurricos>
and even then I doubt that'll actually be something people use / suppport / share
<hurricos>
under OpenWrt?
<aiyion>
but I asked for its cousin PE
<aiyion>
wait, no not not openwrt.
<hurricos>
:P
<hurricos>
doubt they're different tbh
<aiyion>
the sg-108e was some "smart" switch
<aiyion>
fuck, thx
<aiyion>
.
<hurricos>
no problem hahah there are blog posts out there about using OpenWrt and controlling things externally over MDIO but with DSA that becomes more of a PITA because it demands to be fed a device tree to be practical
<hurricos>
speaking of device trees, if anyone has experience getting u-boot to play nicely with MII to identify an ICPLUS PHY ...
<Slimey>
Waiting for Juniper Networks Driven by Mist AI to start the webinar.
<Slimey>
gimme free ap stat
goliath has joined #openwrt-devel
<Grommish>
dangole: I'm testing the arm9/arm11 targets now.. Any recommendations or things to look out for?
<Grommish>
spcifcally ath91-sam9x-arm926ej-s and bcm27xx-arm1176jzf-s-vfp
srslypascal has joined #openwrt-devel
<dangole>
rsalvaterra: I don't own any APU devices myself, but they are used in production (running OpenWrt) in some places where I help maintaining them
<dangole>
Grommish: for ARM11 I can help testing on ARM11MPcore (oxnas/ox820), I got such a device here.
<rsalvaterra>
Would like some acks on this… quilt isn't that smart, sometimes.
<Grommish>
dangole: Ok. Assuming the arm logic handling works for the rest of the arm targets, then if you're testing, just dropping the patch files in and building out would/should work. At this point, the patch tuples are the only thing that should change
<dangole>
rsalvaterra: looks legit to me, but I can't help you testing because those APU4 boards are in use in a critical system, no way i can mess around there testing anything. and no use of GPIOs what-so-ever, they are inside racks in closed cases on ships in the Mediterranean
<rsalvaterra>
Ah, it's *those* boxes.
ecloud_quassel has quit [Ping timeout: 480 seconds]
<rsalvaterra>
Thanks for the extra pair of eyes, though. :)
<Grommish>
Oh hell.. I just realized I think rust is building the entire LLVM for all targets each time.. I just realized I'm getting warnings in building like : Building CXX object lib/Target/M68k/CMakeFiles/LLVMM68kCodeGen.dir/M68kISelLowering.cpp.o
<Grommish>
That would explan the stupid long compile times
Borromini has quit [Ping timeout: 480 seconds]
<dangole>
Grommish: I always wanted to run Rust program on my Amiga 500 :)
<Grommish>
dangole: I've got a A3000 here somewhere and donated my old A500 to a YT channel for the guy to restore :)
<Grommish>
I've still got an original 1084S monitor sitting next to me
<dangole>
Grommish: power supply of my A500 died at some point, never managed to restore it. so now it's rotting somewhere in a pile of stuff evacuated from the hackspace I used to be active
<Grommish>
dangole: I was surprised at how active the space still is.. NIC cards and Flash storage
ecloud_ has joined #openwrt-devel
<Grommish>
dangole: The caps were a huge issue with the 500/600 line :(
<dangole>
Grommish: it's the greatest computer ever made, even back then there was an optional 10MBit/s Ethernet (coax) and SCSI controller available, optional dedicated highres graphics adapter, ... and it had built-in 4 channel audio output and you could build yourself a sampler... Amiga in 1987 was like PC in 1994...
<Grommish>
dangole: *nod* I started on a signature series A1000 and didn't switch until Commodore US went bankrupt
<dangole>
Grommish: yeah, I guess bad caps were the reason for the power supply dying. but it worked well for almost 3 decades and i guess the board itself would still work
<hurricos>
A question for GNU Make wizards out there -- if Make is run in parallel, will it ever put any multiline recipes out of order?
<hurricos>
I have made a bad habit of forcing recipes to be single-line with \'s at the end of my recipe lines (to avoid possible parallelism of individual jobs), which has undesirable side effects when $(MAKE) is included on a given line.
<hurricos>
I'm almost certain, but can't think of a way to demonstrate, that
<hurricos>
Never mind. I came up with a way to demonstrate it, and started editing ~/Makefile to test it, only to find I'd already created ~/Makefile in February to test the same thing.
<hurricos>
Answer: GNU Make runs multiple-recipes in line order.
rua has quit [Ping timeout: 480 seconds]
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
rua has joined #openwrt-devel
<rsalvaterra>
So, here I was thinking of packing up nmon (the system monitor originally from AIX) for OpenWrt…
<rsalvaterra>
… until I look at the source code. And how it's developed.
<Grommish>
dangole: Is the arm1176jzf-s technically armv6?
Borromini has quit [Quit: Lost terminal]
<rsalvaterra>
Grommish: Yes.
<Grommish>
Thanks :)
<rsalvaterra>
ARM11 is ARMv6.
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
<dansan>
Hello! So I'm trying to figure out how to use a config value with validate_data that's optional -- won't error if it's not there, but will produce the output to set a shell variable if it is. I'm browsing the sources and discover this MAD robust language support: https://git.openwrt.org/?p=project/ubox.git;a=blob;f=validate/validate.c;h=e72b8117ecd8b680778b0f5c7637ed6546a7736b;hb=HEAD#l893
<dansan>
Where is this documented?
<dansan>
I dunno guys, but when I put something together that's that cool, I like to write full documentation to brag about my code.
<dansan>
hrm, I guess that's actually just some partial documentation from the perspective of LuCI. So I'm guessing this needs docs. So much to do!
goliath has quit [Quit: SIGSEGV]
<dansan>
Oh cute! I found a validate_data bug. "/sbin/validate_data a instance one foob:string argh:string" succeeds, but "/sbin/validate_data a instance one enabled:bool:0 foob:string: argh:string" fails
bluew has joined #openwrt-devel
<dansan>
ignore the "enable", it's just the trailing colon on foob
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #openwrt-devel
goliath has joined #openwrt-devel
<hanetzer>
dansan: heyo :)
cbeznea has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
Tapper has quit [Quit: Tapper]
<Grommish>
What are the valid host archs that OpenWrt can be built on? Is there a list?
<Grommish>
x86, powerpc, aarch64?
<slh>
in theory, anything you throw at it
<Grommish>
Good enough :)
<slh>
in practice, only x86_64 is used in the buildbots (yes, stıntel ran a buldbot instance on ppc64el for a short while, but as that produces 'useless' ppc64el imagebuilder binaries, that stopped rather soon)
<Grommish>
Well, with the aarch64-apple-darwin being supported now, I can see an M1 series build system
<slh>
there may be some weirdos building on the RPi4 out there
<slh>
and yes, MacOS/ x86_64
<Grommish>
I'm trying to cut down on the LLVM building by targetting single targets rather han all of them ;/ but they use different (case sensitive) conventions
<Grommish>
from either HOST_ARCH or ARCH
<slh>
it 'should' build on any host arch, but in practice most won't
robimarko_ has quit [Quit: Leaving]
<hurricos>
So ... who owns a Supermicro X9DRW and has put a SNIC10E in it? https://linux-hardware.org/?id=pci:177d-0092-177d-0001&hwid=6a1a83ebe660
<hurricos>
Oh, this is a live system.
mattytap has quit [Remote host closed the connection]