<robimarko>
I just see that you loaded it, not ran bootm to actually boot it
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
<SpectreDev_01>
Oh
<neggles>
robimarko: is ipq807x still a hellscape
<robimarko>
neggles: In what sense?
<SpectreDev_01>
Yeah it works I really thought I bricked it for a second
<neggles>
I've been out of the loop for a while, last time I checked it was not a great place to be performance-wise
<neggles>
though it looks like it's actually supported in mainline openwrt now
<SpectreDev_01>
Yeah nss is the issue lol
<neggles>
nss is always the issue
<neggles>
though I've heard from a fairly reliable source that qcom are done with NSS from here on out
<robimarko>
Performance is suffering from a shitty wired networking drivers
<neggles>
source being someone near or at the top of the eero HW dev team
<SpectreDev_01>
Damn
<robimarko>
Yeah, afaik they are done with NSS as well
<robimarko>
Its become too cumbersone to maintain and extend
<SpectreDev_01>
NSS is closed source isn't it
<neggles>
Sort Of But Mostly Yes
<neggles>
iirc there's an "nvidia close source driver"-style "open source but most of it is in blobs" thing
<SpectreDev_01>
Ah I see
<SpectreDev_01>
Well I'm stuck, no UBI volume so I can't even boot
<neggles>
you can ramboot
<neggles>
you can always ramboot
<neggles>
assuming you have a kernel+initrd that functions
<SpectreDev_01>
Yeah kernel is fully functional
<SpectreDev_01>
Works when you tftpboot but doesn't boot when you install it permanently
<neggles>
but yeah NSS only really came about for the same reason that qcom made so many cursed SoCs with huge quantities of A53s in; ARM had a thing going on when they first started doing big.LITTLE where if you bought a license for a big core, you got a license for the little core for free; but they neglected to specify "you have to use the little core
<neggles>
license on the same die as the big core license"
<neggles>
so qcom found themselves with an enormous pile of free little core licenses and started shoving them everywhere
<SpectreDev_01>
Average qcom moment
<neggles>
*APQ8053 has entered the chat*
<neggles>
SpectreDev_01: if you can ramboot, you should then be able to wipe out the ubi and recreate it however the bootloader etc. expects it to look
<SpectreDev_01>
Hmm
<neggles>
you're getting an EEXIST when it tries to create the kernel vol
<neggles>
hm
<neggles>
as you might expect that indicates it's trying to create a ubiblock vol that already exists :v
goliath has joined #openwrt-devel
<neggles>
wtf is with your cmdline `init=/sbin/init rootfstype=squashfs ubi.mtd=24,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait roinit=/sbin/init rootfstype=squashfs ubi.mtd=22,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro`
<neggles>
SpectreDev_01: can you dump `printenv` from u-boot (i dont see in backscroll)
<SpectreDev_01>
You're looking at my previous mess up, theres a log without that Cmdline mess up lol
<neggles>
I see qcom's obsession with putting every single tiny little thing into its own partition hasn't changed
<neggles>
I have a strange feeling of deja vu
<neggles>
from when I was screwing around with the sophos APX530
<neggles>
might have to go digging through the logs
<SpectreDev_01>
Well it doesn't sound good lol
<neggles>
i spent like 3 days trying to work out what magic incantation i needed in the target .mk file and in the u-boot env/kernel cmdline to make it work
<neggles>
and i am 99% sure i still have that git tree, please hold, your call is important to us
<neggles>
found it
<neggles>
oh i remember what's cursed about the APX530; it's not actually cursed at all, quite the opposite
<neggles>
but apparently nobody else has done the sane and reasonable thing sophos did
<SpectreDev_01>
What did they do
<neggles>
you know how qualcomm insist on carving up the MTD into 42069 partitions
<neggles>
the APX530 has a 512MiB parallel NAND with *one partition*
<neggles>
whole nand is just one ubi partition with four volumes, `image`, `image_backup`, `config`, `download`. image/image_backup contain a FIT image with kernel + rootfs, `config` is the writable overlay, `download` is used as temp space during upgrades
<SpectreDev_01>
Quite nice compared to everyone else
<neggles>
yeah, sophos are pretty based tbh. their GPL dumps are ISO images that are auto-generated and contain the entire build system used to assemble the image along with instructions on how to build it, a list of things that won't work because they depend on closed-source components
<neggles>
and their u-boot has two secure boot keys embedded in it; the private key for one of the two is included in the GPL dump ISO; you can tell u-boot to accept images signed with that key via an env var
<neggles>
or you can `setenv verify no` and it just won't check
<SpectreDev_01>
Nice, pretty cool to have secure boot on Openwrt
<neggles>
oh and they built some neat little scripts into the u-boot on this
<neggles>
if you run `recover online` it will download the latest FIT image from a sophos server (or a local VM sophos firewall appliance, which you can get for $0 if you don't want support) and reflash it
<neggles>
as long as you don't screw around with u-boot itself, you can't really brick it
<neggles>
anyway what caused me no end of trouble was working out what commandline args i had to pass for the ubivols to get created properly so lemme just boot this up
<SpectreDev_01>
Cool
<neggles>
SpectreDev_01: so am i right in thinking that you have `kernel` and `rootfs` and `alt_kernel` and `alt_rootfs`, and you want your kernel+squashfs to be sitting in the `kernel` and `alt_kernel` partitions (assuming A/B images)?
<SpectreDev_01>
Funnily enough stock runs on a modified Openwrt lol
<robimarko>
Everything runs modified OpenWrt
<SpectreDev_01>
Oh didn't know
<robimarko>
Its a QCA product so they are just using QSDK which is hacked together OpenWrt
<neggles>
yup
<neggles>
OpenWrt runs probably 98% of the consumer routers on the planet tbh
<neggles>
well. OpenWrt or one of its many hacked up siblings
<robimarko>
Usually something just abusing the OpenWrt name
<neggles>
SpectreDev_01: are you sure it's a 512MiB NAND because those MTD partitions are adding up to 800MiB
<neggles>
which is an incredibly strange number
<SpectreDev_01>
Yeah it's 512MiB nand
<neggles>
hmm.
<neggles>
oh hey this is a Wistron NeWeb production
tidalf has quit [Ping timeout: 480 seconds]
<SpectreDev_01>
I guess they made the uboot for it
<robimarko>
They are the ODM for the board
<robimarko>
Linksys are just rebadging it
<neggles>
well, they made it *for* linksys
<neggles>
they make the APX530s too, they're fairly prolific
<robimarko>
They are old school ODM
<robimarko>
They will have multiple modems to pick off the shelf
<robimarko>
*models
<neggles>
yeah, they take one of their ref designs and shift things around a bit to fit the specific vendor's requirements
<robimarko>
Usually they have everything covered so you dont even need a custom model
<neggles>
when i say shift things around a bit I mean literally shunting things around on the PCB to make it fit whatever enclosure :P
<neggles>
but their hardware is usually quite straightforward to work with and their GPL dumps are usually alright
<SpectreDev_01>
Hmm seems like some good news
<neggles>
much nicer than @%#@ing technicolor or nokialcatel
<robimarko>
Its not hard to be better than technicolor
<neggles>
true.
<neggles>
something is definitely fucky here though; you've got 819200KiB of partitions defined on a 512MiB NAND
rua has joined #openwrt-devel
<neggles>
hmm i think the alleged sysdiag/syscfg/ETHPHYFW/WIWIFW either don't exist or are aliased
<SpectreDev_01>
I'm thinking alt_ partitions overlay on the non alt counter part from what I can see
<neggles>
hm maybe i've messed up my math somewhere
PaulFertser has joined #openwrt-devel
<robimarko>
0:WIFIFW ends at 0x000020000000 which is exactly 512MB
<neggles>
excel has lied to me
<neggles>
nvm
<neggles>
OH i see what it is
<neggles>
rootfs and alt_rootfs aren't real, per se
<SpectreDev_01>
Ah that's why smem kept patching kernel into rootfs and rootfs_1
<SpectreDev_01>
And only created 27 partitions instead of 29
<neggles>
you've really just got <system A> at 0x01080000 to 0x0a680000 and <system B> at 0x0a680000 -> 0x13c80000
<neggles>
suggest you drop `rootfs` and `alt_rootfs` from the openwrt-side partition table entirely or at least mark them as read-only
<SpectreDev_01>
Yeah I marked it as read-only this morning but uhmm still refused to boot
<neggles>
that or resize them to not overlap (move start of rootfs to end of kernel and shrink it accordingly)
<neggles>
but 6MiB is a bit small for a kernel+initrd these days
<neggles>
yeah your cmdline args are wrong
<SpectreDev_01>
I removed them entirely
<SpectreDev_01>
But let's remove rootfs and alt_rootfs and see how it goes
<neggles>
so for partbootargs
<SpectreDev_01>
Shall I rename kernel to rootfs or leave it as kernel
<neggles>
i would go with rootfs probably
<SpectreDev_01>
Only problem is the Linksys sysupgrade looks for rootfs and kernel
<neggles>
we can worry about how to handle flashing from stock later
<neggles>
and how to handle sysupgrade later
<neggles>
you should be able to boot with `setenv partbootargs "ubi.mtd=rootfs ubi.block=0,rootfs root=/dev/ubiblock0_1 rootfstype=squashfs"` once the extra partitions are gone
<neggles>
depending on what format the image it's puking out is, but you've got the same stuff in the target def as I have for a fairly similar setup
<neggles>
might need to be root=/dev/ubiblock0_0 though. think 0_1 was an apx530-ism
<SpectreDev_01>
Factory img is . bin (for flashing over stock fw)
<neggles>
yeah but .bin means nothing by itself
<neggles>
can you upload the sysupgrade and factory images somewhere so I can poke them
<neggles>
never did get the hang of the various target image build commands/variables
<SpectreDev_01>
Need to recompile and get sysupgrade
<SpectreDev_01>
I didn't make backup and did make clean which nuked sysupgrade
<neggles>
ah
<neggles>
this is pretty much exactly what i expected to see though
<neggles>
hmm
<neggles>
ok i take it back, leave kernel and rootfs parts in there but adjust them to not overlap; so just set size of kernel to 0x600000
<neggles>
might need to overlap for sysupgrade, but... either way, doing that then using `ubi.mtd=rootfs ubi.block=0,rootfs root=/dev/ubiblock0_0 rootfstype=squashfs` should work i think
<SpectreDev_01>
Oh ok
<neggles>
hm. yeah they need to overlap so you can just `nandwrite` the factory.bin to `kernel` or it'll whine. ugh.
<neggles>
why do manufacturers do this
<neggles>
c'mon guys just put the kernel+initrd into the UBI, u-boot can read UBIs
<SpectreDev_01>
So it's got be left the way it was then
<neggles>
yeah T_T
tidalf has joined #openwrt-devel
<neggles>
stupid crappy ancient vendor u-boots
<SpectreDev_01>
So sysupgrade script gotta be modified to nandwrite to kernel
<neggles>
maybe! sysupgrade can probably be a bit less stupid
rua has quit [Quit: Leaving.]
<neggles>
and have separate files for the kernel and the rootfs
<robimarko>
No, do not nandwrite anything
<SpectreDev_01>
Hm ok
<robimarko>
You can generate separate kernel and rootfs in UBI
<SpectreDev_01>
How would we do that
<robimarko>
There is even support for that in sysupgrade
<neggles>
yeah ideally we would not have "a kernel image with a UBI appended to the end of it"
<robimarko>
You need to use CI_KERNPART and CI_ROOTPART in sysupgrade
<robimarko>
So it flashes them separately
<robimarko>
Actually, CI_KERN_UBIPART and CI_ROOT_UBIPART
<neggles>
yarp; your failure to boot *appears* to be purely down to cmdline params
<SpectreDev_01>
Yeah but even when I removed them and allow uboot to pass it still doesn't want to boot lol
<robimarko>
All you need in bootargs is proper ubi.mtd and proper root= with the correct UBI block device
<neggles>
b/c your args are wrong; `partbootargs=init=/sbin/init rootfstype=squashfs ubi.mtd=22,2048 ubi.block=0,0 root=/dev/ubiblock0_0 rootwait ro` needs to be `partbootargs=ubi.mtd=rootfs ubi.block=0,rootfs root=/dev/ubiblock0_0 rootfstype=squashfs`
<neggles>
it likes names.
<robimarko>
ubi.block shouldnt even be required
<neggles>
it is in my case but i can't remember why
<neggles>
and this image build is uh. not recent
<SpectreDev_01>
Alright then bootargs = ubi.mtd=rootfs ubi.block=0,rootfs root=/dev/ubiblock0_0 rootfstype=squashfs`
<SpectreDev_01>
In DTS
<neggles>
well, no, in your u-boot env
rua has joined #openwrt-devel
<neggles>
can put in DTS later once you have the right ones, saves you from recompiling every time you want to tweak something
<neggles>
`Linux apx530-346182 5.10.90 #0 SMP Mon Jan 17 06:44:52 2022` yikes it's been that long since i touched this?
rua has quit []
<neggles>
should probably rebase on master...
<SpectreDev_01>
So then setenv and change partbootargs cool
<neggles>
`setenv partbootargs 'ubi.mtd=rootfs ubi.block=0,rootfs root=/dev/ubiblock0_0 rootfstype=squashfs'` then `saveenv` then `run bootpart1`
<neggles>
may or may not work, as said above the ubi.block shouldn't be needed but i don't *think* it'll hurt anything to have it there
<SpectreDev_01>
I hope it works
<neggles>
the only thing preventing this from working is finding the right combination of magic words for the kernel cmdline which really shouldn't be that hard
<neggles>
famous last words and all that
<SpectreDev_01>
Lol
<neggles>
see, `ubiboot=ubi read $loadaddr image;bootm $loadaddr#config@2` <-- that's how this *should* look, with a single partition that just has multiple ubivols in it, but nooooooooo
<neggles>
they just *had* to do multiple shadowed partitions and use `nand read`
<SpectreDev_01>
Now I need to fix the led lol, it's doesn't turn on lol
<SpectreDev_01>
Ok I gotta add that to dts now
<SpectreDev_01>
neggles: doesn't it needs to switch to alt_rootfs when it switches slots
schwicht has joined #openwrt-devel
<neggles>
SpectreDev_01: so for that you need to edit the params for partbootargs2
<SpectreDev_01>
We can't do that through DTS tho can we
<neggles>
don't believe so no
<neggles>
ideally you'd just use the bootargs passed by u-boot
<SpectreDev_01>
So ok that'll have to be a step in the guide
<neggles>
i *think* all you'd actually need to do for that, is put `root=/dev/ubiblock0_1` in the dts cmdline
<neggles>
that should end up appended to the u-boot ones
<neggles>
and cause it comes *after* the u-boot one it *should* override it i think?
<SpectreDev_01>
Oh yeah we could just append it
<SpectreDev_01>
I'll give it a shot
<neggles>
alternatively you could just set up /etc/fw_env.config to work with the u-boot environment and include a couple of `fw_setenv` commands in the install guide
<neggles>
IIRC there's also a way to make sysupgrade apply those
<SpectreDev_01>
Yeah but if bootargs append works would just save me time
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rua has quit [Quit: Leaving.]
<SpectreDev_01>
neggles: yep appending bootargs solves the issue
<SpectreDev_01>
neggles: robimarko: thanks a ton guys wouldn't be possible without you guys
<SpectreDev_01>
Now I need to fix led and submit
rua has joined #openwrt-devel
<SpectreDev_01>
Yeah i don't get why led doesn't work
<robimarko>
Which LED?
<SpectreDev_01>
The one power/system led
<SpectreDev_01>
I made a pull request for now, will work on led in a bit
<SpectreDev_01>
robimarko: what do you mean by nand block
<SpectreDev_01>
You mean erase block size?
<robimarko>
Please, comment in the PR directly so others can discuss as well
<SpectreDev_01>
Ok
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Danct12 has quit [Remote host closed the connection]
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
f00b4r0 has joined #openwrt-devel
Danct12 has joined #openwrt-devel
f00b4r0 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]