<neggles>
this is what the BeagleV turned into, it has the same rather flawed SoC as those boards - they say Q3 for the revised SoC with 4 cores and all the weird bugs fixed
srslypascal has quit [Ping timeout: 480 seconds]
<yolo>
i have a unmatched board from sifive, not impressed and it's collecting dusts for half year: 1. needs ATX power? this is not an embedded board but a x86 motherboard design in mini-itx formm 2. the small fan will make me deaf in 2 minutes, it's screaming, there is no way I can use it if it's not 30 yards away
<yolo>
actually, i would say 100 yards so I can still focus and think
<yolo>
so far it's junk for me
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<Namidairo>
you'd think they would at least throw in dual band /sarcasm
<Namidairo>
I imagine you could do some fun stuff with it connected to a few ipcams
<Namidairo>
but you'd have to see if their decoder is strictly limited to 2 2k@30fps sessions or you can tack a few more in
victhor has quit [Remote host closed the connection]
nitroshift has joined #openwrt-devel
GNUmoon has quit [Ping timeout: 480 seconds]
GNUmoon has joined #openwrt-devel
rmilecki has joined #openwrt-devel
danitool has joined #openwrt-devel
Tapper has joined #openwrt-devel
<aparcar>
jow: do we need to passt default_variant down to the package manager or is it just a build root thing?
ecloud has quit [Ping timeout: 480 seconds]
nitroshift has quit [Remote host closed the connection]
kenny has quit [Quit: WeeChat 3.3]
ecloud has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 480 seconds]
Acinonyx has joined #openwrt-devel
pmelange has joined #openwrt-devel
pmelange has left #openwrt-devel [#openwrt-devel]
nlowe has joined #openwrt-devel
<jow>
aparcar: buildroot thing
<rsalvaterra>
jow: I tried to git clone git://git.openwrt.org/project/firewall4.git, and…
<rsalvaterra>
fatal: remote error: access denied or repository not exported: /project/firewall4.git
<rsalvaterra>
Is this expected?
<jow>
yeah, kind of. We maintain git:// for backwards compatibility, it actually is a symlink tree into the git server root which needs to be manually updated
<rsalvaterra>
I worked around it by cloning via HTTPS and the manually changing the remote to git@git.openwrt.org:project/firewall4.git.
<rsalvaterra>
*then
<rsalvaterra>
Ok, understood. :)
<jow>
should work now
<rsalvaterra>
And now I have to learn ucode. xD
<jow>
its basically ES6
<jow>
just without the stdlib/object model
<jow>
you can tell your editor or IDE to use JavaScript syntax highlighting
<rsalvaterra>
Yeah, it definitely looked like JavaScript to me. :)
bluew has quit [Quit: Leaving]
<rsalvaterra>
I find it amusing that GitHub identifies the code as UnrealScript. :P
<aparcar>
rsalvaterra: suffix based I assume
<aparcar>
does it make sense to have uclient use libtls instead of openssl etc specifically
<Habbie>
github does more than look at suffixes
<rsalvaterra>
Speaking of GitHub, we're missing licenses on both fw3 and fw4. It would be wise to clarify the terms of use.
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pSych0bUNny has joined #openwrt-devel
pSych0bUNny has quit [Remote host closed the connection]
<aparcar>
mangix: how to tell meson to install to ./staging_dir/host and not to hostpkg?
<aparcar>
mangix: HOST_BUILD_PREFIX:=$(STAGING_DIR_HOST) does the trick
dangole has joined #openwrt-devel
<aparcar>
dangole: morning
f00b4r0 has joined #openwrt-devel
<mangix>
aparcar: correct
rua has quit [Ping timeout: 480 seconds]
<aparcar>
mangix: now the libapk is missing...
<aparcar>
so there seems to be more to it
<aparcar>
libapk.so.2 => not found
rua has joined #openwrt-devel
<aparcar>
with hostpkg it works just fine... libapk.so.2 => /home/user/src/openwrt/staging_dir/hostpkg/lib/libapk.so.2 (0x0000ffff9be33000)
<rsalvaterra>
aparcar: What does apk cost us (in terms of image size, for the same configuration), when compared to opkg?
<aparcar>
currently, a lot
<aparcar>
it pulls in libfetch and openssl
<rsalvaterra>
Eek!
<aparcar>
however there are plans to make it work with libtls and uclient
<rsalvaterra>
I'm assuming images built without the package manager will be the same.
<aparcar>
rsalvaterra: even smaller due to lack of package manager ;)
<rsalvaterra>
I mean, comparing a build without apk to a build without opkg. :P
<aparcar>
should be about the same
<rsalvaterra>
I never build images with opkg, since I don't have a use for it. :)
<aparcar>
mangix: never mind I mixed up HOST_LDFLAGS
checkpoint has joined #openwrt-devel
<f00b4r0>
for my education, does anyone know what "rrm_nr" stands for in the "rrm_nr_get_own"/"rrm_nr_list" hostapd ubus methods? I see I can get MAC and SSID from the former which is convenient, but I'd like to make sure I understand what this is before I use that in scripts
<dwmw2>
dansan: trying with u-boot-mtk.bin again now
<dwmw2>
er, dangole sorry
<dwmw2>
Loading Environment from MMC... MMC Device 1 not found
<dwmw2>
*** Warning - bad CRC, using default environment
<dwmw2>
MMC Device 1 not found
<dwmw2>
MMC Device 1 not found
<dwmw2>
Net:
<dwmw2>
Warning: ethernet@1b100000 (eth0) using random MAC address - 0e:75:d6:02:51:cf
<dwmw2>
eth0: ethernet@1b100000
<dwmw2>
LED 'bpi-r64:pio:blue' not found (err=-19)
<dwmw2>
## Error: "_checkbootedfrom" not defined
<dwmw2>
MT7623>
dedeckeh has joined #openwrt-devel
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: No route to host]
<dangole>
dwmw2: is that with using u-boot-mtk.bin instead? it's weird because i basically duplicated what i did for the R2 and it should work the same way...
<dwmw2>
it is, yes.
<dwmw2>
This board only has the built-in eMMC, no SD slot.
<dangole>
dwmw2: i'll push an updated tree in a moment, with the defaultenv for u7623 fixed so bootmenu should work
<dwmw2>
The R2 has both, and needs to boot from either.
<dwmw2>
Doesn't the preloader *tell* U-Boot where it got loaded from, and that's how U-Boot knows which one to look for the environment on?
<dwmw2>
I bet the preloader on the U7623 doesn't do that, since there's no point. And we're looking at some random bit of memory for this information and finding noise?
<dangole>
dwmw2: yes, that _checkbootedfrom was a left-over from R2, i've removed that now
<dwmw2>
I fixed up the merge conflicts with 2021.10 defconfig; you want that or have done it alreadfy?
<dwmw2>
Also, I'm a little reticent about dropping the 'legacy' image. That's needed for upgrading from the OpenWrt that comes on it from the factory.
<dwmw2>
The SP Flash tool is a PITA and requires that you have a copy of the preloader.
<dwmw2>
I've been reflashing mine back to the factory image and testing the upgrade from that.
<dangole>
dwmw2: hm, i see. i've updated the tree to solve the merge conflicts with defconfig and update the default environment to something more likely to work...
<dangole>
dwmw2: the follow-up commit removing the legacy image also adds the modernized single-uImage.FIT image. i can split that into two commits and keep the legacy image for now
<dangole>
dwmw2: and it adds *-emmc.bin.gz build artifact as well as scatterfile generation...
<dangole>
dwmw2: instead of relying on the vendor image sysupgrade method, could we just supply a script the user can run to replace the vendor loader and install modernized images? ie. write files to emmc with dd?
<olmari>
dangole: I'm just mainly owrt power user, but what I have understood is that at least way in the past owrt goal was not to need special loaders replacing OEM ones, but I don't know what is the stance today
<olmari>
..not that you neccesarily was talking about that...
<olmari>
sounds still highly device specific =)
<dangole>
olmari: generally yes, at least we try to preserve that option to keep the vendor loader, no matter how stupid it is.
<dangole>
olmari: sometimes the pain is too much and someone goes out and builds a replacement loader, and I'm generally in favor of doing that because in that way we open the debate and create references for future chip-vendor SDKs (based on OpenWrt) to contain better examples...
<olmari>
well... I generally won't mind replacing bootloaders etc with better ones, while I do realise where the argument against generally comes from...
<dangole>
olmari: in case of that specific U7623 devboard we have always been building the bootloader as well and you can flash the board using USB-OTG port and sp_flashtool, just like MediaTek smartphones...
checkpoint has quit [Remote host closed the connection]
<nick[m]1234>
Anyone having an idea, why I can not work with uci on a symlink?
<dwmw2>
dangole: hm, my fixes disappeared from master with a commit from ldir instead. Is github just a mirror? Where am I supposed to be pushing?
<stintel>
github is a mirror, never push to it
<dwmw2>
dangole: we don't build the preloader, only u-boot. I *have* preloader source but have never got it to build. And it's not open source.
<dwmw2>
Where do I push?
<stintel>
unless we decide to make it primary in the future
<stintel>
git.openwrt.org
<aparcar>
anyone here using external toolchains?
<dwmw2>
stintel: should I have ssh access there?
<dangole>
dwmw2: if you have ever submitted a public key, then yes, you should have git+ssh access to git.openwrt.org. if not i can push things for you for the time being, and you should send an SSH pubkey to jow.
<stintel>
doesn't look like your key is there
<aparcar>
mangix: is it possible you didn't test cmake/meson with external toolchains?
<blocktrron1>
nlowe: i'd like to reconsider the precedence of ubus consumers in case we fiddle with rssi-limits by default.
<blocktrron1>
This stuff was broken for a long time, but events will not propagate / be rated by ubus connected daemons in case limits are present in hostapds config (and the event in question would be filtered)
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nlowe has joined #openwrt-devel
<dwmw2>
dangole: your branch still uses u-boot.bin not u-boot-mtk.bin
danitool_ has joined #openwrt-devel
danitool has quit [Read error: Connection reset by peer]
<dangole>
dwmw2: yes, but did you try with both commits and the resulting *-emmc.bin.gz? i'm asking because it should be just like on the R2, right? same preloader. so I wonder why on the R2 it works and on the U7623 doesn't and you have to change uboot to use the *-mtk.bin file...
<dwmw2>
no, r2 is mt7623n and has a different preloader
<dwmw2>
we could rebuild the preloader if we must (and I'd quite like to, and teach it to pick u-boot out of the *partition* from the MBR instead of hard-coded addresses
<dwmw2>
But I never did get it to build. Dunno if blogic did.
<dangole>
dwmw2: ok, that's why then. and the preloader is of course already present in emmc hardware-partition and we never touch it. and it expects MTK header for U-Boot
<dwmw2>
Hm, it has the MTK header but it's at 0x50000 not 0x40000 as the preloader expect
<dwmw2>
Again, if we built the preloader to read the bloody MBR ... :)
<dwmw2>
The MT7622 *does* use a GPT for that, doesn't it?
<yolo>
neggles: it's for risc-v compiler work(not to productize the board), just too noisy
<dangole>
dwmw2: yes, MT7622 uses GPT because it's romloader is not as stupid as the romloader of the MT7623 (and all older ARMv7 MTK SoCs btw) and expect the Preloader at exactly the offset where GPT should start as well...
<dwmw2>
the MT7622 preloader (when I last looked) was the *same* code base as the MT7623 one. Just had the partition table stuff enabled as a config option.
<dangole>
dwmw2: i've updated the tree once again, now using u-boot-mtk.bin and not outputting mt7623n preloader for that board
<dwmw2>
It called out to ATF
<dwmw2>
I haven't looked at the new a-t-f-mediatek support. Does that do *everything* now, and pass control to u-boot?
<dwmw2>
So we ditch the mtk preloader on mt7622 completely? a-t-f-mediatek even does DRAM bringup etc?
<dangole>
dwmw2: mtk has dropped that whole codebase in favor of just using ARM Trusted Firmware on all newer ARMv8 or ARMv7a SoCs, and that works on MT7622 as well. TF-A has it's own "preloader" called bl2, and thats BSD licenced.
<dwmw2>
does that include mt7622?
<dangole>
yes
<dwmw2>
nice
<dwmw2>
So I should play with the bpi-r64 that's also in this mediatek pile on my newly cleaned up desk?
<dangole>
dwmw2: give the updated OpenWrt image a shot, so you get an idea where I'm heading with the U7623 (apart from TF-A vs. legacy preloader) and it's the same on the R2 as well.
<dwmw2>
the bpi-r2 is sitting on top of the r64 :)
<dwmw2>
Unielec were working on a mt7622 board too when I spoke to them last year.
<dangole>
dwmw2: i'm waiting for Sinovoip's new BPi-R3 board with MT7986 SoC :)
valku has joined #openwrt-devel
<dwmw2>
dangole: hm, that looks like it's at 0x50000 still
<dangole>
ah ok, that's why you had UBOOT_OFFSET build variable in first place...
<dwmw2>
:)
<dangole>
dwmw2: updated the tree, now respecting the different UBOOT_OFFSET
<wb9688>
I tried to upgrade my OpenWrt installation to a freshly compiled one, but I'm getting the following at boot time and after more than a minute a kernel panic
<wb9688>
[ 53.541646] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ea0024: 0xdf4e instead
<wb9688>
[ 53.560513] jffs2: Further such events for this erase block will not be printed
<wb9688>
[ 53.588018] jffs2: Old JFFS2 bitmask found at 0x00ea8a94
<wb9688>
[ 53.598595] jffs2: You cannot use older JFFS2 filesystems with newer kernels
<wb9688>
How can I fix this and make it work again?
<dangole>
wb9688: which device/target is this?
<wb9688>
Ramips
<nick[m]1234>
did anyone trying to debug uci? there is also a DEBUG option, but setting it, give me no additonal putput. also added several fprintf(stderr, but nothing
<wb9688>
dangole: On the HLK-7621A evaluation board
dangole has quit [Remote host closed the connection]
<dwmw2>
[ 1.746738] 11004000.serial: ttyS0 at MMIO 0x11004000 (irq = 36, base_baud = 1625000) is a 16550A
<dangole>
dwmw2: Linux reboots?! Even with your mtk-pmic-keys fix?
<dwmw2>
yeah
<dangole>
dwmw2: can you paste the complete bootlog somewhere? because reboot after probing serial is weird, unless serial init breaks console and reboot happens for something else we don't see later on...
<dangole>
dwmw2: "mtk-scpsys 10006000.power-controller: Failed to power on domain mfg"... seems to be the root cause of the reboot i suppose
<dwmw2>
was doing that before
<dangole>
dwmw2: which tty is used for console. ttyS0 or ttyS2? because in DTS, it looks like S2. but in now-obsolete mt7623a_unielec_u7623-uEnv.txt override it to ttyS0?
<dwmw2>
on phone now. half horu sory
<dangole>
dwmw2: no prob, i try to make sense of it and update the tree in the meantime
<dangole>
dwmw2: ah, ttyS0 and ttyS2 get swapped, because only serial2 is defined as alias in DTS and that now makes it end up being ttyS0 (being the only/first serial alias). this is mitigated in old uEnv by setting console=ttyS0... I'll do the same in the new env file.
ecloud has quit [Ping timeout: 480 seconds]
<dwmw2>
dunno why that make it reboot?
srslypascal has joined #openwrt-devel
<dangole>
dwmw2: that's not what makes it reboot but what hides the true cause of the reboot happening after (eg. rootfs cannot be mounted or something like that)
<dangole>
i've updated the tree, but you can just update the console env variable in U-Boot to "earlycon=uart8250,mmio32,0x11004000 console=ttyS0,115200"
danitool_ has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
ecloud has joined #openwrt-devel
<dangole>
dwmw2: that should give us working console beyond serial init
<dangole>
dwmw2: yeah, moveconfig in preinit... no longer needed now
<dangole>
dwmw2: sysupgrade and config-restore can work just like on R2 now
<dangole>
dwmw2: update tree again, now sysupgrade (incl. config restore) should work. also fixed mac address inheriting from U-Boot, so now user can set permanent MAC using `fw_setenv ethaddr 02:aa:bb:cc:dd:ee:ff` applying to U-Boot and OpenWrt as well.
mattytap_ has joined #openwrt-devel
mattytap has quit [Ping timeout: 480 seconds]
kb1sph has quit [Ping timeout: 480 seconds]
<dangole>
dwmw2: I assume the U7623 doesn't have a permanent MAC address set by the manufacturer somewhere...?
<dwmw2>
Indeed. We store it in u-boot config
<dwmw2>
this was happening automatically before (and on rpi-r2 too?) so that after first boot, it was persistent without explicit user actions
<dwmw2>
Warning: Bad CRC, using default environment
<dwmw2>
bootdelay=5
<dwmw2>
baudrate=115200
<dangole>
oh, so offset is still wrong because of different UBOOT_OFFSET presumably
rua has quit [Ping timeout: 480 seconds]
<dangole>
please edit /etc/fw_env.config and set the offset to 0xc0000 instead of 0xb0000, that should fix it
<dangole>
@dwmw2
rua has joined #openwrt-devel
mattytap_ has quit [Read error: Connection reset by peer]
<stintel>
cool with the new PSU the M300 idles just below 20W instead of ~23W
<stintel>
probably better efficiency
<dangole>
stintel: 3W your house heating has to compensate for now ;)
<f00b4r0>
this reminds me I need to hunt ebay for one of these :)
cmonroe has quit [Ping timeout: 480 seconds]
<stintel>
dangole: the AC switches on because too hot
<stintel>
so maybe it will switch on less frequently now :P
<Habbie>
lol
<Habbie>
maybe
<dangole>
dwmw2: can you retry with the fixed offset in /etc/fw_env.config (or updated build from updated tree, but that's more work, obviously...)
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
<aparcar>
is Florian Fainelli around here?
<aparcar>
jow: or do you recently used ext-toolchain.sh?
noltari_ has joined #openwrt-devel
svlobanov has joined #openwrt-devel
noltari has quit [Ping timeout: 480 seconds]
<svlobanov>
hi. Is it allowed to add Tested-by: Alozxy <alozxy@users.noreply.github.com> in commit message? (nickname instead of real name and noreply email)
kb1sph has joined #openwrt-devel
<aparcar>
using an external toolchain works for some packages but for instance ubus and uci just fail: ninja: Entering directory `/home/user/src/toolchain/build_dir/target-x86_64-openwrt-linux-musl_musl/ubus-2021-08-09-a72457b6' [1/11] Linking C executable ubusd FAILED: ubusd : && /home/user/toolchain-x86_64_gcc-11.2.0_musl/bin/x86_64-openwrt-linux-musl-gcc -Os -pipe -fno-caller-saves -fno-plt -Wformat -Werror=format-security -DPIC -fpic -fstack-p
f00b4r0 has quit [Remote host closed the connection]
<philipp64>
dangole stintel: dumb question, but what do you plug the U6-LR into? I have a Linksys LGS552P with a SFP+ port, but I'd probably need a special transceiver for that... and I'm not sure the Linksys wouldn't crap the bed trying to negotiate something other than 10/100/1000/10000 mbs
<stintel>
philipp64: I doubt there are SFP+ modules that can deliver PoE?
blocktrron1 has quit [Quit: WeeChat 3.3]
<stintel>
I'm using a Huawei S6720-32C-PWH-SI switch
Borromini has joined #openwrt-devel
blocktrron has joined #openwrt-devel
<philipp64>
right, you'd need the injector... Okay, are there PoE+ switches that will do 2.5Gb/s?
<dwmw2>
dangole: rebuild from your tree is much easier. That's just git fetch/ git reset/ make :)
<stintel>
yes, some might even run OpenWrt
<dwmw2>
building now
<philipp64>
the best I can think of is 2x 1GbE as a LAG.
<philipp64>
I've not looked at what our LAG support is like, however...
<dwmw2>
Loading Environment from MMC... MMC Device 1 not found
<dwmw2>
MMC Device 1 not found
<dwmw2>
*** Warning - bad CRC, using default environment
<jow>
svlobanov: yes, that should be no problem
<svlobanov>
joe: thanks
pmelange has joined #openwrt-devel
svlobanov has quit [Remote host closed the connection]
<dangole>
dwmw2: ah, uboot is not initializing the env properly
<dangole>
dwmw2: Saving Environment to MMC... MMC Device 1 not found
<dangole>
dwmw2: will fix in a moment
<dangole>
dwmw2: that's int mmc_get_boot_dev(void) in mt7623_rfb.c in vanilla U-Boot failing with the UniElec preloader and wrongly returning '1' (SD Card) as boot device :( I guess U-Boot needs to be fixed with some additional precompiler macros...
svlobanov has joined #openwrt-devel
<[florian]>
rmilecki: yes?
<rmilecki>
[florian]: that was a reply to: [19:12] <aparcar> is Florian Fainelli around here?
<[florian]>
rmilecki: alright, yes I am around :)
svlobanov has quit [Ping timeout: 480 seconds]
<[florian]>
rmilecki: the fixed PHY registered by bcm47xx in arch/mips/bcm47xx is kind of annoying, as it's not really up to the correct speed
<[florian]>
rmilecki: and it forces you to patch it with 700-net-bgmac-connect-to-PHY-even-if-it-is-BGMAC_PHY_NOR.patch
<rmilecki>
[florian]: i think I had problem with that already i solved by some downstream quick workaround
<rmilecki>
exactly my point
<rmilecki>
feel free to clean it up ;)
<rmilecki>
sorry but I'm too busy with way too many things at this point :/
<[florian]>
rmilecki: it's alright, I am focused on that netgear wnr3500l v2
<[florian]>
rmilecki: the proper solution would be to register the b53 switch driver (mdio or srab) via mdio_boardinfo
<rmilecki>
[florian]: i should have sent you some bcm4908 instead of that old MIPS :P
nlowe has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<[florian]>
rmilecki: this is 3 year backlog, who knows what you will be working on in 3 years from now :)
pmelange has left #openwrt-devel [#openwrt-devel]
<rmilecki>
lol :D
<[florian]>
rmilecki: I know that RDP won't ever be GPL and that bothers me
<[florian]>
rmilecki: but if the rest is usable, that could be my next home router, at some point
<rmilecki>
[florian]: what's RDP except for Remote Desktop Protocol/
danitool has joined #openwrt-devel
<[florian]>
rmilecki: runner data path, the network processor that does NAT offload and whatnot on the 4908
<rmilecki>
ah
<[florian]>
rmilecki: and 63138/48 and a bunch of other SoCs
<rmilecki>
[florian]: i know it as "runner"
<[florian]>
rmilecki: it's that division's bread and butter, so must be kept proprietary ;)
<rmilecki>
[florian]: i'd like to have it at least working in some bypass mode
<rmilecki>
[florian]: not for the offloading purposes
nlowe has joined #openwrt-devel
<rmilecki>
but to support all ports
<[florian]>
rmilecki: don't you have it working that way already?
<rmilecki>
right now I have to choose between external switch and WAN on some devices
<[florian]>
rmilecki: is there an external switch on these devices?
nlowe has quit []
<rmilecki>
[florian]: Asus GT-AC5300
<dangole>
dwmw2: patched U-Boot to always respect CONFIG_SYS_MMC_ENV_DEV if defined (and set to 0 for U7623)
<rmilecki>
[florian]: it has 8 LAN ports
<[florian]>
rmilecki: humm, OK, so they needed an external switch for that...
<rmilecki>
[florian]: right and that switch it connected to the crossbar
<rmilecki>
[florian]:just like the WAN port
<aparcar>
[florian]: I'm curious if you use external toolchains and if so how you compile e.g. ubus and uci
nlowe has joined #openwrt-devel
svlobanov has joined #openwrt-devel
<dangole>
dwmw2: in u-boot-2021.10/board/mediatek/mt7623mt7623_fb.c "if (!find_mmc_device(1)) return 0;" doesn't have the desired effect as mmc1 is defined (but disabled) in DTS (my guess)
<rmilecki>
aparcar: i'm not sure what you're working on, but you could use buildroot to use any toolchain you want and it even has uci packages (maybe ubus too)
<aparcar>
I'm trying to speedup CI build by using the pre-build toolchain offered on downloads.openwrt.org and compile packages/targets
<[florian]>
aparcar: OK, so you won't be running into most of the issues I was dealing with which were that kernel headers were old
<[florian]>
aparcar: it did require a tad too much manual configuration to my liking with external toolchains, a fair amount could be auto-detected last I remembered
<aparcar>
I'm using ext-toolchain.sh and let it create the .config file
<aparcar>
so far everything worked, like compiling kernel but now it hangs on ubus
<aparcar>
I'm sure it just requires a little bit of fixing but I thought someone may be using it and would know what to do
svlobanov has quit [Ping timeout: 480 seconds]
<[florian]>
aparcar: I doubt that anyone is using this feature on a regular basis
<[florian]>
aparcar: about 4-5 years ago I had been tasked to get OpenWrt to work with the stbgcc-6.3 toolchains (available https://github.com/Broadcom/stbgcc-6.3) committed all that was relevant and then moved on
<[florian]>
aparcar: I ran into lots of those with the external toolchain, a lot of library dependencies were pulled in automatically when using the OpenWrt toolchain, but were not when using an external toolchain
<dwmw2>
Although I've gone back to master and that doesn't seem to record the MAC any more either. I'm fairly sure this *used* to work when I added the image support.
<aparcar>
[florian]: meh that doesn't sound very promising
<aparcar>
but thank you for all the info
<[florian]>
aparcar: it's playing whack a mole, hence the various patches I came up with
<[florian]>
aparcar: once you get the OpenWrt toolchaint to work, and you get that included in the CI pipeline it is less painful to keep maintaining moving forward
<dangole>
dwmw2: can you check (using hexdump) at which offset the environment ended up in /dev/mmcblk0p1?
<aparcar>
I'm just thinking it doesn't make any sense for CI if it causes more trouble
<[florian]>
aparcar: depends what we want in the end, if building with an external toolchain is more stringent, then surely this helps our overall code quality
<dangole>
dwmw2: because this time the env was saved as least
<dangole>
dwmw2: Saving Environment to MMC... Writing to MMC(0)... OK
<dangole>
dwmw2: and it should also read back ok on reboot now
<dangole>
(ie. CRC errors should disappear after first boot)
<[florian]>
aparcar: I think there is value in making sure OpenWrt builds with an external toolchain, but it has to be tested on a regular basis otherwise it bitrots quickly
paper__ is now known as paper_
svlobanov has joined #openwrt-devel
<svlobanov>
+1 to [florian]. OpenWrt toolchain has arch specific-patches and some other patches. If we compile using external toolchain we might fail at compile time and also at runtime