<swiftgeek>
it used kernel.bin as input to create kernel.bin
<tmn505>
the resulting loader is in KDIR with the name loader-$board_name.whatever_extension_you_used. Keep in mind that loader has hardcoded location where it searches for uImage with OKLI magic.
<swiftgeek>
not here ;D
<swiftgeek>
in this instance it seems to be passed via makefile
<swiftgeek>
and yes there is no loader binary left after it's done, other than inside embedded image
<swiftgeek>
this is very different to what i saw on ath79 tplink
<tmn505>
maybe it gets auto cleaned? Anyway You shuld be able to dd it from resultin image
<swiftgeek>
if there is auto clean, no idea how to disable it ;D
<tmn505>
check .config for auto clean, don't remeber the symbol
<swiftgeek>
anyway inserted plain lzma compressed vmlinux as kernel.bin in first pass, i will see what it does
<tmn505>
CONFIG_AUTOREMOVE is the symbol
<swiftgeek>
yep it's set
<swiftgeek>
still no luck lol
minimal has joined #openwrt-devel
<swiftgeek>
i will try removing autoremove then
<swiftgeek>
yep no change so far, still removing loader xD
<swiftgeek>
ah i should probably comment it out instead of setting to n lol
<swiftgeek>
commented out in makefiles and .config and still no luck xD
<swiftgeek>
that binary doesn't want to be seen
<swiftgeek>
ah yeah
<swiftgeek>
target/linux/ramips/image/Makefile Build/loader-common has rm and mv inside of it
<swiftgeek>
loader.bin / loader.elf are already big fat 1.5MiB files with vmlinuz in it
<swiftgeek>
*vmlinux
<swiftgeek>
lol
<tmn505>
btw which version are You using? Need to go to sleep, if You won't report success, I'll whip something after waking up.
<swiftgeek>
21.02.3
<swiftgeek>
ok so lmao
<swiftgeek>
i have the dir, yet loader is nowhere to be found there
<swiftgeek>
xD
<swiftgeek>
i have the C file and it immediately is embedding vmlinux somehow
<swiftgeek>
i expected to see .o with just the loader.c compiled
<swiftgeek>
and somehow loader.o doesn't have strings from loader.c , but those big 1.5MiB files do xD
goliath has quit [Quit: SIGSEGV]
<swiftgeek>
ok i presume that if loader.o is big i have made it do something extremely wrong
<swiftgeek>
only data.o should be big right?
<swiftgeek>
ugh i can't really read makefiles properly, but it looks like it really wants to embed LZMA data to everything in sight since it's in top level
philipp64 has joined #openwrt-devel
<swiftgeek>
i guess next step is to move to SDK, get anything that boots, and observe those loader files for valid build
<swiftgeek>
same thing happening on SDK
<swiftgeek>
not a single small loader file exist
<swiftgeek>
but resulting image from SDK at the very least jumps into linux and SPI flash is detected including partition scheme
<swiftgeek>
and passing that kernel to imagebuilder makes it almost boot, if not for that it's a different kernel build, that makes it tainted, incompatible and panicky franken monster :D
<swiftgeek>
but i get to the point of > Please press Enter to activate this console.
<dwfreed>
yeah, you can't combine self-built kernel and imagebuilder
<dwfreed>
at that point just build from source
<swiftgeek>
but that's the exact thing i don't want to do :D
<swiftgeek>
i just want to assemble the image from binary parts
<swiftgeek>
(that are not there)
<dwfreed>
so then you need to get your fixes into master and/or 22.03
<swiftgeek>
so far i have no fix lol
<dwfreed>
I mean, it sounds like you got a working system from the sdk
<swiftgeek>
i just noticed that my ath79 tplink and ralink experience are vastly different with imagebuilder
<swiftgeek>
like ath79 has actual loader in imagebuilder
<swiftgeek>
with ralink has C sources in imagebuilder :)
<swiftgeek>
*ramips
<swiftgeek>
and ultimately it's an uboot issue, somewhere
minimal has quit [Quit: Leaving]
<Slimey>
hello
<swiftgeek>
so SDK pulls this as data.o if i'm reading logs correctly build_dir/target-mipsel_24kc_musl/linux-ramips_rt305x/tmp/openwrt-ramips-rt305x-unbranded_a5-v11-initramfs-kernel.bin
<swiftgeek>
but that makes no sense, that exact file already has a loader xD
<swiftgeek>
i can't locate vmlinux-initramfs or any interaction with it
<swiftgeek>
like i have line that copies vmlinux-initramfs to openwrt-ramips-rt305x-unbranded_a5-v11-initramfs-kernel.bin
<swiftgeek>
and vmlinux-initrd seems to be crated immediately after leaving linux-5.4.188
<swiftgeek>
err
<swiftgeek>
* vmlinux-initramfs
<swiftgeek>
$(call Kernel/CopyImage,-initramfs)
<swiftgeek>
i think this thing
<gch981213>
Oh. I broke the build...
<russell-->
a friend is building on centos 7, they are getting build prerequisite errors for things like gcc, despite compatible gcc's being available in their path
<russell-->
make seems to be ignoring their PATH
<dwfreed>
make --eval='print-% : ; $(info $* is a $(flavor $*) variable set to [$($*)]) @true' print-PATH ?
<swiftgeek>
i'm trying to add some echo to Device/Build/kernel and failing spectacularly xD
srslypascal has quit [Ping timeout: 480 seconds]
danitool has quit [Ping timeout: 480 seconds]
<neggles>
hurricos: hey don't be mean! the switch part of the switch is great, it's just a shame the COMe management board is a disaster :P
<neggles>
it might be fun to try and make OFED run on openwrt :P I do have a suitable test subject, that partially-broken SX6012...
srslypascal has joined #openwrt-devel
mangix has joined #openwrt-devel
<swiftgeek>
Used Image/BuildDTB instead to copy vmlinux/vmlinux-initramfs , and got kernel image that somewhat works xD
ekathva has joined #openwrt-devel
mangix has quit [Remote host closed the connection]
<swiftgeek>
yeah everything works fine, even wifi
<swiftgeek>
so now i know that individual components are fine, i just need to get loader to do the same thing on ImageBuilder as on SDK
Piraty has quit [Remote host closed the connection]
Piraty has joined #openwrt-devel
Atomicly- has joined #openwrt-devel
Atomicly| has quit [Ping timeout: 480 seconds]
<swiftgeek>
i guess i can try using binwalk until it starts looking like the same thing, which should be faster than reflashing
pepe2k has joined #openwrt-devel
<grift_>
in my experience that is some times the best approach. things arent always what they seem
<grift_>
i had that just the other day's were i got reminded of an old outstanding issue. it was outstanding because i got tired of brute forcing a solution. all it took in the end was a little looking into what actually happens. but yes thats usually in hindsight because intuition is to rely on confidence and just follow your gut
<mangix>
mrkiko: used to
<mrkiko>
Mangix: do you have it around still and maybe can test the latest snapshot ?
<mangix>
i do not
<mangix>
what issues are you having?
<mrkiko>
Mangix: just to confirm it's a LZMA error 1 stopping the device from booting. Of course if you want / have the time and an UART converter :D
<mangix>
kernel 5.15?
<mrkiko>
I have one here and it doesn't boot up with latest master snapshot, so at some point I will need to connect the UART cable and test it, but since I am being slow in getting to it, wondered if you could help out :D
<mrkiko>
5.10
<mangix>
if I had to guess, $(Device/uimage-lzma-loader) needs to be added in target/linux/ramips/image/mt7621.mk in the gnubee section.
<neggles>
swiftgeek: why not just use the buildsystem to make an imagebuilder rather than hacking up the imagebuilder?
<neggles>
is your kernel image >8MiB decompressed? :P
<swiftgeek>
neggles: too much effort in proving and verifying entire thing
<neggles>
you've put more effort into this than it would've been to just use buildsystem/sdk ¯\_(ツ)_/¯
<swiftgeek>
lol no xD
<swiftgeek>
actual fix on that angle would be to make SDK produce exactly the same binaries
<swiftgeek>
as release
<swiftgeek>
and ideally process of changing kcmdline should be selfhosted
<swiftgeek>
and I still have to fix uboot early init and make it actual source code, both RT5350 and AR724x/AR9132
<swiftgeek>
at least RT5350 has plenty of SRAM accessible early on, but locking caches would still expose more than enough
<swiftgeek>
and this is especially important for messing around with crazier memory configurations (either 2x32MiB or messing with DDR2 chips on DDR1 board)
<swiftgeek>
i recently finally figured out how to reflash atheros ISP, so that certainly helps (ignore that one wrong cut)
<rsalvaterra>
Speaking of Wi-Fi 6, I've been unknowingly running my RT3200 in ac mode for several days… because I copy-pasted my previous configuration and forgot to change VHT80 to HE80. :P
<dwfreed>
ooof
<neggles>
I have a cambium XV3-8 coming in next week, IPQ8078A + QCN5124 + QCN5154 x2 + QCA9889 (scan)
<robimarko_>
Ohh, thats a fancy one
<neggles>
not the absolute fanciest, but the XE5-8 isn't regulatory approved here yet
<robimarko_>
No idea why QCA9889 is popular for IoT etc
<neggles>
it's single chain rx-only
<neggles>
my guess is "it's cheap"
<robimarko_>
Thats for sure
<robimarko_>
You know that its cheap when Xiaomi has ben putting them on AX3600 which at one point was like 50 EUR
<neggles>
it can run the two 5154s as a pair of 4x4 or together as an 8x8
<robimarko_>
Yeah, that is why 8078A
<robimarko_>
So "virtual" 8x8
<neggles>
the XE5-8 has 4x4 2.4GHz + dual 4x4 5GHz + dual 4x4 5/6GHz
<neggles>
they're sending me one once the ACMA approves them :D
<robimarko_>
Oh, so they crammed multiple QCN9074 cards as well
<neggles>
(6GHz band was only standardized/approved here last month)
<olmari>
In totally unrelated to anything things: I kinda suprised that some of Aruba stuff I admin has BLE/zigbee radio too
<robimarko_>
Dont be
<robimarko_>
Everybody has been cramming TI based bluetooth for years
<neggles>
i've seen more CSR8811s than anything else
<neggles>
sophos APX530 has one but i can't seem to make the damn thing respond, OEM firmware doesn't use it
<rsalvaterra>
neggles: QCA makes me want to cry.
<olmari>
I mean obviously datasheet would reveal that, but I was admining something and I was wondering "TF this 3rd radio is" :D
<robimarko_>
I have seen CC25xx-s for bluetooth
<neggles>
robimarko_: looks like cambium got the full-feature nss package on these too
<robimarko_>
Yeah, thats must have
<neggles>
they do an awful lot of shit internal to the AP
<neggles>
so im not shocked
<neggles>
regional sales manager called today and i mentioned wanting to buy an NFR XE5-8 / XV3-8 to play around with
<robimarko_>
rsalvaterra: Why?
<neggles>
"the XE5 isn't approved yet, but I can just send you a 'demo' XV3-8 if you want"
<neggles>
"why yes. yes i do want that."
<neggles>
didn't think it would be that easy
<neggles>
but we have a lot of ubiquiti wifi gear deployed that we're considering replacing with cambium, and those guys *hate* each other
<rsalvaterra>
robimarko_: After ath9k hardware, my experience with QCA stuff has been mostly horrible.
<neggles>
it'd be nice if they put together a team of reasonably competent developers and tasked them with upstreaming shit.
<robimarko_>
Cant say that they have been any worse than the others
<neggles>
better than broadcom! (a very low bar)
minimal has joined #openwrt-devel
<robimarko_>
If you want pain while using WLAN, try NXP, former Marvell cards
<robimarko_>
Cant tell whether their "propriatery" or open source drivers are worse
<neggles>
marvell: only marginally better than broadcom
<dwfreed>
neggles: Broadcom: the bar was on the ground, and you brought a shovel
<neggles>
MOOD.
<robimarko_>
In the open-source, we are left basically with Mediatek and QCA
<neggles>
dwfreed: the pi CM4 has an ethernet PHY with hardware timestamping for PTPv2. this was a selling point on the datasheet, and still is. as of today, there is a just barely mostly working driver for timestamping with that PHY available but only because a bunch of us started kicking up a fuss about it
<neggles>
broadcom still refuse to release the register map to the public
<neggles>
it's a goddamn PHY! 90% of the registers are already publicly documented in mainline!
<neggles>
it's not even new!
<dwfreed>
neggles: yeah, broadcom is the worst, and the pi foundation are horrible stewards
<neggles>
i don't blame RPF really, they're doing what they can with the resources etc. they have
<robimarko_>
I am following the FW saga for Zero 2
<dwfreed>
like, it's great that you got broadcom to donate all this hardware for cheap, now get them to fucking opensource their shit
<dwfreed>
neggles: even the stuff RPF does control they don't mainline
<dwfreed>
neggles: RPi OS should not be this far from Debian *10 years* later
<neggles>
i agree, and they've been mainlining bits here and there, but AIUI (and as described by gordon hollingworth)
<robimarko_>
Well, it only took them like 7+ years to have a 64 bit version
<neggles>
their license with broadcom is
<dwfreed>
"no"
<neggles>
very, very draconian about what they can and can't upstream
<neggles>
they essentially have to get approval
<neggles>
for every patch they want to send up
<robimarko_>
?
<dwfreed>
robimarko_: to be fair, rpi3 was the first 64 bit capable
<robimarko_>
Whats the purpose if their tree is public?
<neggles>
what a good question, robimarko_
<neggles>
what *is* the purpose?
<neggles>
gordon does not know either
<dwfreed>
answer: Broadcom are dicks
<neggles>
^
<robimarko_>
dwfreed: Well, Its been a long time since RPi3 launched
<neggles>
to be fair
srslypascal is now known as Guest3168
<neggles>
they've had 64-bit kernel with 32-bit userland for quite a long time
srslypascal has joined #openwrt-devel
<neggles>
and the 64-bit userland is significantly slower on the sub-4GB units
<dwfreed>
robimarko_: 6 years
<dwfreed>
3 B+ is 4 years
<robimarko_>
Basically a lifetime in electronics
<dwfreed>
4 B will be 3 years in June
<dwfreed>
but also 2 years ago was yesterday
<robimarko_>
Hehe, feels like i
<robimarko_>
*it
<neggles>
eh, rockchip were showing off the rk3588 in 2020 and it's only just now making it into the world
<neggles>
cheap embedded moves slower than the rest of the world
<neggles>
case in point: ipq8078 still cortex-a53
<robimarko_>
Well, they move when the next IC production process becomes cheaper than the current one they are using
<dwfreed>
neggles: to rockchip's credit, the last 2 years have been a pandemic
<neggles>
oh yeah the last couple years have been slower than usual thanks to [series of problems]
<neggles>
robimarko_: yah, and with all the NSS offload it barely matters how fast the cpu cores are
<neggles>
(from their perspective)
<dwfreed>
now if nss was open-source...
<robimarko_>
It is
<neggles>
it is yah
<robimarko_>
All of the drivers are public
<neggles>
and some of the firmware builders even
<robimarko_>
But that aint worth sh*t due to amount of hacks in the kernel to get it working properly
Guest3168 has quit [Ping timeout: 480 seconds]
<neggles>
yah, hence why it'd be nice if they hired a team dedicated to upstreaming things...
<dwfreed>
s/open-source/mainline/ there, how about that
<dwfreed>
iirc, the nbg6817 has nss?
<robimarko_>
Haha, upstreaming
<robimarko_>
Yeah, IPQ806x has two NSS cores
<robimarko_>
It was the first one to actually have them
<dwfreed>
nice
<neggles>
mainline moves too slowly in a lot of ways
<dwfreed>
I have one sitting about 6 feet away from me
<robimarko_>
To their credit, they are upstreaming ath11k
<robimarko_>
And actually faster than what I thought
<neggles>
like, even if they hired a dozen developers and dedicated them to upstreaming NSS it'd take a _while_
<robimarko_>
But other than that, its good when clock and pinctrl get upstreamed
<dwfreed>
will it have multiple AP support, or will we need -ct still?
<robimarko_>
Multiple AP in which sense?
<robimarko_>
Multiple SSID or?
<dwfreed>
SSID, yeah
<robimarko_>
The WFA fancy crap
<robimarko_>
Yeah, multiple SSID-s work fine
<dwfreed>
iirc, that's the primary point of ath10k-ct, is multi-SSID on one radio
<neggles>
primary point of ath10k-ct is not crashing all the time...
<dwfreed>
also that :D
<robimarko_>
Thats just added bonus
<neggles>
i think some of the lack of upstreaming is, afaik the infrastructure for plugging a lot of this stuff into the kernel in a relatively straightforward fashion just didn't exist until recently
<dwfreed>
I should rig up netconsole on my nbg6817
<dwfreed>
figure out why it's crashing
<neggles>
i know working on drivers and device support etc. for embedded devices these days is orders of magnitude simpler / easier than it was five years ago
<robimarko_>
* When you have the datasheet
<neggles>
yeah
<robimarko_>
* And the datasheet doesnt conventiently leave out the magic bits that make it work
<neggles>
but not too long ago i wouldn't have been able to do half the shit i've done in the last year even *with* the datasheets
<neggles>
i discovered the other day
<neggles>
that the fan control driver I made for the pi CM4 IO board's fan control chip, the EMC2301
<neggles>
(which I mostly did not write and borrowed from traverse technologies' repo for the ten64, i just fixed up a couple bugs and made it a DKMS package + pi dtoverlay)
<robimarko_>
Can you share?
<robimarko_>
Cause, I have been postponing writing one
<tmn505>
swiftgeek: this will need some prep; download and unpack IB (imagebuilder) and SDK of version 21.02.3, link toolchain from SDK staging_dir to the same location of IB, link kernel includes from SDK build_dir to the same location of IB, apply to IB this patch: https://paste.debian.net/1239429, adjust dts with whatever You need and build image with make image PROFILE="vocore_vocore-8m" (or
shibboleth has quit [Remote host closed the connection]
<mangix>
anyone use hfsprogs?
<hurricos>
df
<hurricos>
... Mangix: Occasionally. I had to recover a very odd RAID setup pair of drives for a coworker with a hacked QNAP.
<hurricos>
Oh, not the package, though, it appears
<mangix>
I ask as I'm going to push a version update
<mangix>
current version is from macOS 10.4...
<hurricos>
Funny, I don't even see the hfsprogs *package*, just some related utilities
<mangix>
sounds about right
<hurricos>
Go, push. When I eventually have to touch hfs again I'll remember you and tell you what you broke.
<hurricos>
Probably.
<hurricos>
s/hfs/hfs on OpenWrt/
ekathva has quit [Remote host closed the connection]
<Slimey>
zfs is where its at
bluew has joined #openwrt-devel
<Slimey>
This section highlights the major features and enhancements in vWLAN 4.1.0:
<Slimey>
AD-195377 Added software support for the new WiFi-6 BSAP 6000 Series APs. Hardware is not yet available.
T-Bone has joined #openwrt-devel
f00b4r__ has quit [Ping timeout: 480 seconds]
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<swiftgeek>
oh so that's what IB stands for in makefiles :D
<swiftgeek>
tmn505: thanks, i will start poking around those paths, i already removed that "rm" line and loader isn't there on its own, and Makefile of that looks to me like it's always adding image on top of it (but i can't really read makefiles yet)
robimarko_ has quit [Quit: Leaving]
<swiftgeek>
IB sadly isn't the easiest thing to grep :D
<swiftgeek>
and i thought that IB is for some strange industrial device that needs special paths in openwrt, yeah that was stupid xD
<swiftgeek>
that's too high up to have device specific things
dansan has quit [Remote host closed the connection]
dansan has joined #openwrt-devel
<rsalvaterra>
Mangix: hfsprogs? Yes, but not on OpenWrt. I have an iBook G4 running Debian Sid (port). Haven't booted it in a while, though.
<mangix>
rsalvaterra: debian sid uses this version