<lu_zero>
the 23.05 rc4 does not seem to bring up all the wireless devices with wpad-openssl
<Znevna>
?
<lu_zero>
it is even stranger the 2GHZ does not work 5GHZ does...
<PaulFertser>
lu_zero: do you see errors in dmesg? Do you see the device in "iw list"?
Tapper has joined #openwrt-devel
<lu_zero>
PaulFertser: I don't see errors, I'll try to redo from scratch the configuration since it scans just fine
<lu_zero>
it is fairly strange
<fioriceta>
I am so fucking done with mainline kernel
<fioriceta>
I just hope poettering is skinned alive, I am so fucking done with fucking everything
<fioriceta>
torvalds is a sellout for not relicensing under gplv3
ptudor has quit [Ping timeout: 480 seconds]
<Znevna>
you ok bruh
<Tapper>
fioriceta Hi hun you OK?
<fioriceta>
well, I wonder if CIP is going to actually get maintained tbh
<Tapper>
I don't know anything about that mate sorry.
<fioriceta>
civil infrastructure project, 2029 support for v4.x.x
<Tapper>
I am looking for a upgrade for one of my APs. Don't know what is the new AP on the block to give me stable AX wifi.
<Tapper>
My r6260 is crap. rradios are week
<fioriceta>
I think ath11k might be ok
<Tapper>
The forums are saying that it crashes all the time.
<fioriceta>
oh, dear...
fakuivan has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
danitool has joined #openwrt-devel
<robimarko>
fioriceta: Are you ok?
<fioriceta>
hmm?
<robimarko>
Well, I got worried by some of your mainline kernel remarks today
<fioriceta>
oh, don't worry about it tbh
<fioriceta>
robimarko: I noticed that there seems to be some phy issue with rb3011 some time ago
<fioriceta>
maybe it was my setup at the time, but it wasn't possible to set an interface up/down
<robimarko>
Well, I dont have RB3011 at all
<fioriceta>
ah, well, I used to see you in the thread
<robimarko>
Yeah, it overlapped with one of the hAP series but
<robimarko>
It was jailbreaking only
<fioriceta>
it doesn't bother me anymore cause I switched back to my L3/L4 switch
<fioriceta>
I had to put in an stm32 board to trick some pwm circuitry
<fioriceta>
I swear vendors are fucking evil
<lu_zero>
today it frustrating, I see
<KanjiMonster>
fioriceta: switching the kernel to GPLv3 is likely impossible since it uses GPLv2-only. You would need the okay for switching the licence from everyone having contributed code, or remove their contributions. Good luck with >1m commits and >10k contributers, some of them already dead.
<fioriceta>
yeah, but back then, though...
<Tapper>
fioriceta Spilt milk mate! Best just to move on.
<Tapper>
My dad told me "You cant live life on would of, could of, should of."
<Tapper>
Best thing I was ever told!
hitech95 has joined #openwrt-devel
<lu_zero>
also switching to GPLv3 would not improve anything
SpectreDev_01 has joined #openwrt-devel
<fioriceta>
yeah, but then you could go after vendors for restricted bootloaders
<SpectreDev_01>
robimarko: well i was able to boot on MTD22 (rootfs) by setenv partbootargs 'ubi.mtd=alt_rootfs ubi.block=0,alt_rootfs root=/dev/ubiblock0_1 rootfstype=squashfs rootwait ro'
<KanjiMonster>
vendors would just stay at the pre-GPLv3 version
<SpectreDev_01>
Here's the log
<fioriceta>
and continue to maintain v2.x.x forever?
<robimarko>
And they are using state of the art bootloaders now?
<fioriceta>
robimarko: you seen what BOLT is like?
<robimarko>
Also, who would sue everyone breaking the license?
<robimarko>
fioriceta: I decided not to touch anything BCM related ages ago and just dont care about their existance
<robimarko>
I dont see how GPLv3 would make it better
<KanjiMonster>
robimarko: wise choice
<fioriceta>
well, tbh, the hw isn't that bad
<robimarko>
There is plenty of good HW hidden behind piles of crap vendor driver blobs
<fioriceta>
how long did it take for the QCA accel stuff or did they do that?
<fioriceta>
but that's far away if basic shit isn't even working
<robimarko>
In what sense?
<robimarko>
None of the NSS stuff is upstream nor in OpenWrt
<fioriceta>
huh, really?
<SpectreDev_01>
So uh I have a weird issue
<fioriceta>
but in terms of hw, bcm is actually expensive now
<fioriceta>
found mtk smartphones or whatever, to be far cheaper
<robimarko>
Its not upstream as the code is a huge mess with plenty of kernel hacks
<robimarko>
And I dont want to maintain that crap in OpenWrt
<fioriceta>
but yeah, you might be right tbh
<fioriceta>
marvell is 100% backdoored, so I don't know what's better
<fioriceta>
(dual EC)
<robimarko>
Well, what do you want to use the HW for?
<fioriceta>
I don't even know, I just like cheap garbage
<fioriceta>
ARMv8 with the newer SoCs is interesting, it has vt-x
<fioriceta>
but most of these boards don't have enough memory
<robimarko>
Look at MochaBin
<fioriceta>
ah, solidrun, hard pass
<robimarko>
Armada 7040 with plenty of RAM
<robimarko>
Globalscale, so even worse than Solidrun
<fioriceta>
oh
<fioriceta>
interesting option, thanks
<fioriceta>
cause the only other ARMv8 options I found were solidrun (israel) or a rack mount NAS that is way overpriced
<robimarko>
Machiatobin maybe?
<fioriceta>
nah, that's solidrun, lol
<robimarko>
And solidrun is bad because?
<fioriceta>
hmm
<fioriceta>
I don't see enough SATA ports on that board
<robimarko>
Hence why I asked what the HW is for
<fioriceta>
cause x1 PCIe is only going to get you like 250MiB/s
<fioriceta>
have there been any high-end qca options?
<fioriceta>
oh, forget that, it's not going to work with a router...
<robimarko>
Nope, they are all router/AP focused
<robimarko>
Again, what do you want to do, make a NAS or?
<fioriceta>
hypervisor host
<robimarko>
Cause that kind of limits you to Marvell stuff
<fioriceta>
well, there were some new bcm SoCs
<fioriceta>
but good luck with that...
<fioriceta>
I think they pulled SATA from them mostly, and it was only a single phy
<robimarko>
Octeon TX2 would be great for you, but that is not cheap as the older 7040 stuff
<fioriceta>
yeah, it's probably going to be better to hold out on x86_64
<fioriceta>
you know, stb units have SATA ports and all
<fioriceta>
cause dreambox isn't a bad option if you could source one
rua has joined #openwrt-devel
_lore_ has quit [Ping timeout: 480 seconds]
rua is now known as Guest1747
rua has joined #openwrt-devel
rua has quit []
Guest1747 has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
Daanct12 has quit [Ping timeout: 480 seconds]
filimonic has joined #openwrt-devel
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
rua is now known as Guest1754
rua has joined #openwrt-devel
filimonic has quit [Remote host closed the connection]
Guest1754 has quit [Ping timeout: 480 seconds]
filimonic has joined #openwrt-devel
rua has quit [Quit: Leaving.]
raenye has joined #openwrt-devel
rua has joined #openwrt-devel
<raenye>
Hello. Any idea where iwinfo assoc gets the data? it's fine on my mt76 devices but not on my brcmfmac device
<raenye>
let me rephrase the question. how can I tell whether the backend is wext, nl80211 or something else?
rua is now known as Guest1762
rua has joined #openwrt-devel
Guest1762 has quit [Ping timeout: 480 seconds]
<robimarko>
It should be nl80211
rua has quit [Remote host closed the connection]
<stintel>
Ansuel: thanks for net-snmp pcre2, I have finally finished a horrible migration from invoice ninja v4 to v5, probably lost all the time I won by using this tool instead of simple libreoffice document for the past 8 years or so
<stintel>
but that means I have some time to test your PR
mentalow has quit [Read error: Connection reset by peer]
scr4tchy has joined #openwrt-devel
<raenye>
@robimarko Thanks, it is nl80211, I checked the compiled packages. Now I need to understand why survey data is missing (also via iw phy0-ap0 survey dump)
SpectreDev_01 has quit [Quit: Connection closed for inactivity]
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
bbezak has quit [Ping timeout: 480 seconds]
bbezak has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<hitech95>
robimarko, I've seen that you know a lot more than me about uboot and how it boot. Does you know what the following command does esxpecially the "fit" part?
<hitech95>
command: ubi read $loadaddr fit
<hitech95>
I supposed it is some sort of partition name
<hitech95>
but I cannot figure out how it is defined in the make image or whatever
<hitech95>
My last uboot worked fine until the third reboot than the board bricked itself so I no longer can test until my clamp arrives in 2 weeks
danitool has joined #openwrt-devel
raenye has joined #openwrt-devel
<raenye>
robimarko: I made some progress. First, upstream dump_survey patches are not present in 5.15 and 6.'s brcmfmac/cfg80211.c
<raenye>
Next, the dump_obss feature is not enabled in iovar (whatever that means) on my device
<raenye>
time for hacky patches
<linusw>
Is somone here able to add the D-Link DIR-890L to toh now that it's working with OpenWrt so I can fix up a Wiki page for it?
<robimarko>
hitech95: That should be the UBI volume name
<hitech95>
robimarko, so the nand should have an ubi volume called fit and inside the fit volume there should be one called kernel and one called rootfs? or the kernel volume is the fit volume?
<linusw>
rmilecki: what's your take on ^ I have no better ideas and it fixes the default build...
<raenye>
linusw: that works when building dir-890l, but all other bcm53xx targets are botched unless uboot for dir-890l is built
<linusw>
raenye: what do you think about Jonas' suggestion to mark it HIDDEN?
<raenye>
linusw: what does it do?
<linusw>
raenye: hide it from menuconfig and make it rely on defaults.
<linusw>
I guess he thinks maybe menuconfig is interfering?
<raenye>
I'm still not sure why building one specific profile creates builds for all bcm53xx devices
<raenye>
that is the real bug IMHO
<linusw>
right hm
<linusw>
Was it always like that?
<raenye>
everything seems OK with build-bot since it always builds everything
<linusw>
heh
<raenye>
I started playing with a bcm53xx device a few days ago
<raenye>
so no idea here
<fioriceta>
raenye: what's the exact SoC?
<linusw>
I kicked a build on my big machine so trying to reproduce and see if I can figure this out...
<raenye>
fioriceta: bcm4709a1, that's a Linksys EA9200
<fioriceta>
ARM, right?
<raenye>
Yes, ARM A9
<fioriceta>
hmm
<raenye>
It's already supported, but ethernet got broken between rc2 and rc3
<raenye>
rmilecki helped me fix it
<raenye>
and then I went to fix the DTS and whatnot
tidalf has joined #openwrt-devel
<raenye>
fioriceta: anyway, most things are fine in my self-built firmware, I just want the build to be not broken
<fioriceta>
yeah, I don't know about mainline tbh
<fioriceta>
so, does that line-up have u-boot or cfe?
<raenye>
fioriceta: you were referring to the brcmfmac issues or the build issue?
<fioriceta>
oh, never mind, I see, but is it just u-boot or cfe?
<fioriceta>
*u-boot or cfe -> u-boot
<fioriceta>
build issue
<raenye>
Linksys ea9200 and ea9500 are cfe
<raenye>
vendor u-boot is ok
<fioriceta>
ah, yeah, second stage crap...
<KanjiMonster>
linusw: you shouldn't need the device packages thing when using the HIDDEN attribute for u-boot, since (AFAIU the code) the package then defaults to the device selection
<raenye>
not too bad, I managed to lock myself a few times out of openwrt and booting to vendor firmware (it's an A/B device) saved my @$$
<fioriceta>
there is another recovery interface, you know
<fioriceta>
protocol is not documented
<fioriceta>
well, no, I guess that's not true, but there's like two versions of it
<raenye>
fioriceta: not when the kernel has the switch disconnected from the cpu
<fioriceta>
no, it's low-level stuff
<fioriceta>
all over i2c
<raenye>
I couldn't get TFTP working
<fioriceta>
well, can be over i2c or spi, but that doesn't matter
<fioriceta>
you'd need to strap it down iirc
<raenye>
Already had to open it for UART
<fioriceta>
I want to get mainline support for 63xx going at some point
<fioriceta>
well, the ARM SoCs
<raenye>
(at that point I might as well reprogram the nand)
<raenye>
63xx is arm64?
<fioriceta>
the newer SoCs are ARM, yeah
<raenye>
A53 vs A9 is quite a difference
<fioriceta>
nah, I think it was an A9 in my case
<fioriceta>
you could replace cfe with u-boot and all
<raenye>
the EA9200 with a dual core 1GHz A9 barely handles 700Mbps iperf3
<fioriceta>
well, you need the packet runner
<raenye>
A53 saturate GbE easily
<fioriceta>
I think that'd only work for WAN -> LAN
<raenye>
The switch by itself can do GbE, I'm testing the CPU
<raenye>
routing does not interfere here, it's LAN-LAN
<KanjiMonster>
raenye: linusw: I see one small issue in bcm53xx that might be related; the u-boot (package config) stuff assumes the default/generic profile is called "Default", but for bcm53xx it is called Generic
<raenye>
KanjiMonster: my builds don't need u-boot
<raenye>
the question is why all devices are getting built
<KanjiMonster>
which profile are you using?
<raenye>
EA9200
<raenye>
and I get 18 TRXs
<KanjiMonster>
"default y if (TARGET_bcm53xx_generic_Default || TARGET_bcm53xx_generic_DEVICE_dlink_dir-885l || TARGET_DEVICE_bcm53xx_generic_DEVICE_dlink_dir-885l)" <- there is no TARGET_bcm53xx_generic_Default, only TARGET_bcm53xx_generic_Generic
<KanjiMonster>
raenye: all images being built always might be because bcm53xx device profiles don't set PROFILES which I think controls for which profiles it should be built, and the default value for PROFILES is "$CONFIG_TARGET_PROFILE" (so always ;)
<raenye>
KanjiMonster: so how to make it only build the selected profile?
<Ansuel>
stintel sorry checking only now IRC. I have fixed the thing hope it will pass your tests
<KanjiMonster>
most targets do "PROFILES := Default", some do "PROFILES := Default $$(DEVICE_NAME)" - no idea if the latter is required
<KanjiMonster>
(maybe not quite so) obviously since the default profile for bcm53xx is called Generic this should be then "PROFILES := Generic"
<KanjiMonster>
for the $$(DEVICE_MAME) case you want = only, not :=, for the lazy evaluation. for a constant value it doesn't matter
<fioriceta>
people who actually follow licenses are probably the biggest idiots out there
<schmars[m]>
how do i find out if a device can do DSA? i guess i look at the DTS, see what's the switch-chip and check if there's a matching DSA driver?
<schmars[m]>
(native DSA that is, not software)
<fioriceta>
copyright only exists in the US, with the dmca mafia
<raenye>
KanjiMonster: I added this to the default device in image/Makefile, let's see if this works. Thanks.
<raenye>
PROFILES = Generic $$(DEVICE_NAME) in target/linux/bcm53xx/image/Makefile did it
<robimarko>
fioriceta: Its using FIT images, but there is no "fit" volume
<fioriceta>
oh, I don't really remember FIT tbh
<fioriceta>
I just remember sdk hell with some platform
<fioriceta>
somehow rmilecki fucking got it to work, but only the sdk-produced image worked on my end
<fioriceta>
who knows, I don't have another board
<raenye>
schmars[m]: usually it's per arch. What is the device's SoC?
<fioriceta>
then I bricked it ._.
<fioriceta>
I swear the US just ruins everything
<schmars[m]>
raenye not any device in particular - i'm maintaining a kind of openwrt distribution for a community network and usually build images for any device supported by openwrt. i'm just wondering if there's a way to query DSA yes/no for each device
<fioriceta>
literally go for any euro vendor, avoid the US for sure
<schmars[m]>
raenye oh well i guess i could check if CONFIG_SWCONFIG is enabled
<robimarko>
That would only tell you if target still uses it
<robimarko>
Some are mixed with DSA and swconfig
<fioriceta>
robimarko: with DSA, would there be a perf overhead with bridges?
<schmars[m]>
is port@0 { compatible = "swconfig,port"; ... } a common thing in DTS's?
<fioriceta>
cause I noticed that compared to swconfig, switch vlans weren't being done?
<fioriceta>
*switch-based
<robimarko>
schmars[m]: I havent seen that in any DTS
<schmars[m]>
ar9344_pcs_cr5000.dts
<robimarko>
fioriceta: Can I ask what is up with the negative attitude against everything?
<robimarko>
Look up VLAN filtering for the "switch VLAN-s"
<fioriceta>
I don't think I'm being negative, I'm fucking tired
<fioriceta>
oh, yeah, that, well, I didn't see it on the wiki
<fioriceta>
since it seems like you all keep ruining netifd every other week
<fioriceta>
e.g. renaming stuff for literally no reason
<fioriceta>
then v6.x.x is sucking up all of the memory and now 8/64MiB is being destroyed
<fioriceta>
so fucking sick of this
<schmars[m]>
the forum is a good place for venting and discussion
<fioriceta>
I'm not using the forum where it's stored forever
<fioriceta>
_whitelogger is already in here
<robimarko>
For your information, IRC is logged as well
<fioriceta>
10 years ago, whitequark was male
<Ansuel>
about netifd... honestly everyone is around the idea that snapshot is stable and have minor changes... quite the contrary
<robimarko>
And please Google stuff before claiming that somebody is ruining anything
<fioriceta>
oh, hello Ansuel
<Ansuel>
had a similar complain today about packages... like devs couldn't mark a package broken while it been worked on for a changes on a higher level
<fioriceta>
so, you're from sicily?
<Ansuel>
i understand it's annoying but snapshot is there just to permit these changes and major reorg
<Ansuel>
(probably you are referring to recent changes about wifi interface?)
<fioriceta>
nah, ifname, I think
<Ansuel>
no i'm not from scicly
<schmars[m]>
Ansuel totally with you - if you want to use snapshot, expect to put work in following everyday development and adjust to changes
<robimarko>
There havent been any kind of "breaking" changes in netifd
<fioriceta>
well, compared to v19.x.x...
<Ansuel>
19.....
<fioriceta>
I forked v19.x.x and switched over to CIP kernel
<fioriceta>
rebasing that was really fun
<robimarko>
To put it mildly, who cares about 19.07?
<Ansuel>
you forked 19.x that was the first mistake
<fioriceta>
anything later is backdoored tbh
<fioriceta>
well, no, just bad
<Ansuel>
backdoored ???
<fioriceta>
v5.x.x sucks up memory, doesn't feel the same on the console
<fioriceta>
like, v4.x.x feels more responsive, and it uses less memory
<Ansuel>
sure and you can find a RCE pretty much everywhere
<schmars[m]>
give me the IP of that 19.x box and i'll fix it without asking for a login :D
<robimarko>
I am sure kernel used less memory
<fioriceta>
good idea tbh
<fioriceta>
I have 16MiB of RAM devices
<fioriceta>
Ansuel: well, maybe that's the fault of ubus/luci?
<fioriceta>
if your code has RCE in it, then that's your own fault
<fioriceta>
what, are you doing gets() or something?
<Ansuel>
i wasn't talking about userspace... but kernel and drivers :D
<fioriceta>
oh, well, updated tree means it'd be fine
<Ansuel>
suuure ;)
<fioriceta>
CIP means support until 2029
<fioriceta>
and no, I am not talking about v4.14
<Ansuel>
3.18 ?
<robimarko>
Great if that works for you, but 4.4 kernel kind of doesnt work on new HW
<fioriceta>
nah, I'm not doxing my infrastructure
<fioriceta>
yeah, that's the thing I found
<fioriceta>
I tried to backport noltari's DSA stuff
<fioriceta>
found kernel was missing way too much stuff
<robimarko>
4.4 doesnt even have the concept of DSA
<fioriceta>
fine, v4.19
<fioriceta>
Ansuel: can you just not use wolfssl?
<fioriceta>
mbedtls is way better, wolfssl really is bad stuff
<fioriceta>
like, the API is good
<Ansuel>
and now you are again with pointing at devs....
<fioriceta>
heard of ARM PSA?
<Ansuel>
also we just did that LOL
<fioriceta>
oh, good
<fioriceta>
not pointing at anyone, would see you complain about it in threads
<fioriceta>
see, mbedtls was written by people in europe
<Ansuel>
andd?
<fioriceta>
so, it's going to probably work, wolfssl has `MADE IN THE USA` on the site
<fioriceta>
big no-no, probably has dual EC
<fioriceta>
*rng
<Ansuel>
....
<robimarko>
Ok, if that is the argument then I will just stop replying until you go away
<robimarko>
At this point you are just polluting the IRC
<Ansuel>
that is bad...
<fioriceta>
robimarko: do you know how much shit I have dealt with?
<Ansuel>
so the big conspiracy that USA put backdoor?
<fioriceta>
did you ever make progress on that technicolor device, Ansuel?
<Ansuel>
broadcom... a war lost from the start :(
<fioriceta>
bcm is great hw
<Ansuel>
they set private key in efuse and didn't want to waste my life in searching vulnerability in a broadcom + technicolor bootloader to bypass the lock
<fioriceta>
why not load it in from kernelspace?
<Ansuel>
SURE SO GREAT THAT YOU HAVE NO IDEA WTF IT RUNS ON IT GOD DAMN -.- you talk about eu vs USA and can't see a problem in using brcm ?
<fioriceta>
you are unlikely to find a vulnerability
<fioriceta>
I know exactly what is happening on it
<Ansuel>
good for you... i don't have an source code and i don't trust my isp
<fioriceta>
you want a schematic, even?
<Ansuel>
watched waay too much shit in firewall customized by isp to trust them
<fioriceta>
I am sure they will be going through the logs, so I don't give a shit at this point
<Ansuel>
mhhh you are sus
<fioriceta>
but bmips really is good stuff
<Ansuel>
do you have schematics my boy?
<fioriceta>
yes
<fioriceta>
what was the model number?
<Ansuel>
of what kind... confidential stuff? i don't think so
<fioriceta>
technicolor, anything
<Mangix>
fioriceta: look at ImmortalWrt if you want older kernels
<fioriceta>
I was debating as to post it onto the forum at some point
<fioriceta>
or to just dump everything, and get fucked IRL
<Mangix>
Ansuel: anyway, happy to see qca8k merged finally
<Ansuel>
ehh problem is that even with them i don't think anyboy would still use them... not that something usable can be done
<Ansuel>
Mangix i just hope the stmmac fix works and I don't have 30 issue in the next week
<fioriceta>
register maps + otp maps would be useful
<Mangix>
Ansuel: hope for 1 or 2 :)
<fioriceta>
there are these datasheets with hidden straps
<Ansuel>
still not useful if you can't disable the secure boot... even jtag have password
<fioriceta>
I know, yeah
<fioriceta>
it's uint64_t for the password
<KanjiMonster>
raenye: I think all three things should be fixed; i.e. setting PROFILES for devices (so only selected profile's images get built), renaming the default profile to Default (so the u-boot packages default to =y for it), and hide the u-boot packages so they get built (only) when needed
<raenye>
KanjiMonster: but this means u-boot is build for all profiles?
<raenye>
now it's not built for EA9200, which is the correct behaviour
<KanjiMonster>
raenye: no, both u-boots will be then built for Default (= all images), only u-boot-dir-885l when selecting dir-885l, only u-boot-dir-890l when selecting dir-890l, and neither for any other profile
<fioriceta>
I did look into SEC_CRA, I believe it couldn't be set
<linusw>
raenye: I approved your patch, good job!
<raenye>
linusw: 10q
<linusw>
Now, can someone add the D-Link DIR-890L to the toh...
<Ansuel>
guess SEC_LOCK first needs to be disabled
<fioriceta>
let me see
<fioriceta>
do you reckon it'd be in `Customer Area [Row-18 to Row-25]`?
<Mangix>
Ansuel: now that I look at these, they're using realtek drivers that are swconfig only
<fioriceta>
thinking...
<Mangix>
lame
<Ansuel>
also btw technicolor bootloader have all kind of special eth packet to trigger stuff ahahahah
<fioriceta>
think I remember that
<fioriceta>
did they modify cfe or is it something else?
<Ansuel>
one of them should be to insert the tag to unlock the bits but that tag is generated by the bek and mek
<Ansuel>
that is derived by the modem serial
<Ansuel>
it's cfe + second stage bootloader
<fioriceta>
makes sense, I remember cferom
<Ansuel>
but a very special cfe they removed any kind of access
KGB-1 has quit [Remote host closed the connection]
<fioriceta>
hmm
<fioriceta>
SOTP_PERM
<fioriceta>
> bit-0 ... read access is enabled for non-secure masters (NSR)
<fioriceta>
but then I see SOTP_DISABLED, so not sure
<fioriceta>
Ansuel: you considered fault injection?
<fioriceta>
but there must be a better way
<Ansuel>
well the fact that you can bump bootrom means you have a vulnerability that makes you access any portion of the memory and with the 2 key you pretty much destroy the chain of trust
<Ansuel>
and unlock every kind of feature
<fioriceta>
yeah, but that's read-only/is A0 only (assuming it can be even be done on consumer boards)
<Ansuel>
i bet there is also a vulnerabily to just fuse the bit to enable debug feature without even inserting the key
<fioriceta>
there is a shit ton of registers
<fioriceta>
I don't have a board to test on, though
lucenera has joined #openwrt-devel
<Ansuel>
get one should be cheap now
<fioriceta>
I've bricked a lot of them, lol, I want to do a ref board
<fioriceta>
(bad idea to talk about this, but...)
<Ansuel>
dga4130 or dga4132 that are vulnerable and you can have root access
<KanjiMonster>
Mangix: be aware that Build/lzma-no-dict is called by bmips/bcm63xx with additional arguments, you would need to convert them as well. Also IIRC CFE is very picky in which lzma options you use
<fioriceta>
KanjiMonster: yeah, and the elf loader is broken, too...
<fioriceta>
well, for old cfe
<fioriceta>
best bootloader, though
<KanjiMonster>
the elf loader isn't broken, the elf just may not be larger than ~4 MiB or so (6 MiB on newer CFes IIRC)
<fioriceta>
that's what I was implying...
<fioriceta>
hmm, 6MiB? hmm...
<KanjiMonster>
as long as you are on NOR
<fioriceta>
well, for newer ARM boards, I flashed a newer cfe, toggled on some nand write option, then flashed u-boot
<fioriceta>
I really want a SPL for bmips
<KanjiMonster>
my experience is limited to MIPS
<fioriceta>
yeah, about that
<fioriceta>
is there a way to write code to 0xbfc00000, and then jump to it?
<fioriceta>
maybe my setup was crap, I was doing sysfsgpio with openocd
<KanjiMonster>
0xbfc0000 is memory mapped flash
<fioriceta>
hmm, gotta write to it, then? hmm, that'd make sense
<fioriceta>
I didn't think about that
<fioriceta>
I have two dg834 boards (6348) for openocd, I can't recall if I had issues with cfi
<KanjiMonster>
CFE has a XIP stub which initializes memory, then loads the real CFE (well extracts it to memory), then jumps to it
<fioriceta>
yeah, I'm aware
<fioriceta>
it's cferom + cferam
raenye has quit [Ping timeout: 480 seconds]
<fioriceta>
KanjiMonster: did you ever look into u-boot spl stuff?
<KanjiMonster>
and for some unholy reason they decided for NAND the real cfe should be part of the firmware image (though I think in this case it's a three staged approach?)
<fioriceta>
oh, yes
<fioriceta>
bricked a board recently cause of that, put cferom into cferam.000...
<fioriceta>
did you figure out the nand ecc stuff?
<KanjiMonster>
never touched bmips with nand (at least not with boot nand)
<fioriceta>
I tried replacing the jffs2 structure and shit, but no luck, I can't figure out the OOB stuff despite using a sercomm tool, even
<fioriceta>
there is a 3k strap to boot from spi nor, but I don't have a cfe bin
<fioriceta>
*3k ohm
<fioriceta>
and yeah, if I could jtag it, I would, but I couldn't find any pads (well, there were a few resistors, but doubt it)
<KanjiMonster>
shouldn't cfe follow what's recommended for the NAND?
<KanjiMonster>
also be aware that jffs2 on NAND makes use of the oob
<fioriceta>
nah, well, I wasn't getting anything on the uart
<fioriceta>
>The BCM6362 performs ECC checking of each 512-byte page read from NAND Flash according to the Samsung® NAND Flash Spare Area Assignment Standard (see “Support Flash” on page 230).
<fioriceta>
none of the pins were bridged, so I really don't know
<fioriceta>
KanjiMonster: you dealt with <0.5mm pads before?
<fioriceta>
cause on another board, I want to get some thin wire before buying another tbh
<fioriceta>
but that one is ARM
<KanjiMonster>
nope
<KanjiMonster>
embarrassingly I have never soldered in my life
<fioriceta>
I do SMD without a microscope, it's not that bad
<Mangix>
KanjiMonster: so how do you get serial?
<Habbie>
70% of boards i got serial from, i managed with clips
<Habbie>
(the rest i did solder)
<KanjiMonster>
some of the boards I have do have prepoulated serial, for some I relied on friends with soldering experience
<KanjiMonster>
some very few select even have rs232
<fioriceta>
soldering is really easy
<Habbie>
last box i found rs232 on, i still had to solder
<fioriceta>
KanjiMonster: messed with ppboot before?
<KanjiMonster>
never heard of that before now
<fioriceta>
ah, yeah, it's a connexant thing
<fioriceta>
dg834v5 had it, worst purchase of my life (I thought it was bcm)
<fioriceta>
there was zero uart header
<fioriceta>
but the SoC isn't BGA, so you might be able to solder onto it (no, that killed it...)
<fioriceta>
best mips hw I got was for €0.99, mips64
<fioriceta>
too bad that was backdoored (dual EC)
<fioriceta>
snowden docs showed that, it was sigint enabled, that was disturbing
ptudor has joined #openwrt-devel
hitech95 has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
iocampomx has joined #openwrt-devel
<iocampomx>
Hi there, after some progress, I was able to run an initramfs-kernel image of OpenWRT for a new device using TFTP. Now, I'm working on the flash process. I notices the stock firmware uses the concent of "firmware_zone". Have any of you deal with such kind of examples?