djfe_ has quit [Read error: Connection reset by peer]
djfe has joined #openwrt-devel
<djfe>
how is the stance on merging dts files into one dtsi and two dts files if the two devices are fairly similar (same vendor, difference are in lan/wan ports and usb port)? preferred or should I rather create a new dts file?
<robimarko>
Preffered to avoid pointeless duplication
<robimarko>
So, make a common DTSI
valku has joined #openwrt-devel
floof58 is now known as Guest11331
floof58 has joined #openwrt-devel
Guest11331 has quit [Ping timeout: 480 seconds]
Ryncewynd has joined #openwrt-devel
<djfe>
robimarko: thx, there was no way to avoid nvmem duplication, right?
Danct12 has quit [Quit: WeeChat 3.8]
<robimarko>
djfe: What do you mean by NVMEM duplication?
<djfe>
I mean when the partition is at the end of the flash and flash size is different between models
<djfe>
example:
<rmilecki>
robimarko: can you explain me how OpenWrt which rootfs partitions ("rootfs1" vs. "rootfs2") to use on Edgecore ECW5410?
<robimarko>
rmilecki: Its been ages since I used one of those, but I think that bootloader passes the current one via ubi.mtd through cmdline
<djfe>
I found another commit some weeks ago that pushed nvmem components from dtsi to dts files because the partitions where defined differently even though they had the same name
<rmilecki>
robimarko: thanks
<djfe>
nvmem didn't apply unless it was specified in the dts where the partition was defined
<robimarko>
rmilecki: And it just uses a active=1 or active=2 in U-boot env
<rmilecki>
robimarko: it's nice it still passes that in bootargs
<rmilecki>
it's easier to use bootargs than parse U-Boot vars while creagin partitions ;)
<robimarko>
rmilecki: Yeah, they actually properly implemented the dual FW
<rmilecki>
djfe: if devices have different flashes & partitions, then I suggest keep that in .dts (device specific) files and NOT in .dtsi
<robimarko>
I second that
<djfe>
makes sense, the issue was: I can't refer to &bdinfo in the common dtsi, when that is defined in the dts
<robimarko>
Well yes, it also needs to be from DTS
<djfe>
If I overwrite a property of a node (present in both dtsi and dts), then it only overwrites that specific property and doesn't delete/reset other properties defined in the parent dtsi, right?
<anh>
Can help me to use SFP module of Wallys DR40x9 board?
anh has quit [Remote host closed the connection]
cbeznea has joined #openwrt-devel
goliath has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
goliath has joined #openwrt-devel
<Ansuel>
hauke ping?
<mrnuke>
rmilecki: I don't think the wax218 workaround should go into the mainline kernel.
<mrnuke>
rmilecki: The "getting the correct rootfs" is an interaction between the NAND partition scheme, bootloader, and u-boot-env. So a fix would have to look at all three rather than patch up any individual component. I call that a "layering violation"
<mrnuke>
rmilecki: I'm not sure on using "active_fw" as the condition to swap rootfs/rootfs_1."active_fw" triggers the bootloader to Use a specific partition, but the bootloader can also make up its mind if it detects a damaged UBI volume
<mrnuke>
rmilecki: Also, "active_fw" is completely irrelevant, and the wrong trigger to use when booting from any media other than rootfs/rootfs_1. For example, it would just mess up the rootfs, and the sysupgrade logic
<mrnuke>
*for example, on initramfs...
<mrnuke>
rmilecki: If we are going to architect a workaround for these device's defective bootloader, I think it should be instantiated from devicetree somehow
<mrnuke>
For example, compatible="qcom,smempart"; partitioning-fixup="senao,shitty-bootloader"; partitioning-fixup-condition=<phandle to ubootenv variable>
<Ansuel>
except Rob screaming at you and putting your email in the blocklist with proposing this ahahha
<Ansuel>
expect*
f00b4r0 has joined #openwrt-devel
<mrnuke>
Ansuel: if we wanted to fix this, what would be a sane method?
robimarko has joined #openwrt-devel
<hurricos>
blocktrron: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=commitdiff;h=6e0ab77f55d01d85dd1939725945402254fb861d: are you trying to get an image that apboot can use?
<hurricos>
I ask because I believe apboot checks that the image is signed
<hurricos>
WHAT ARE YOU DOING! YOU'RE NOT SUPPOSED TO RUN DOOM ON A ROUTER
<blocktrron>
The apboot can execute arbitrary code without issues
<hurricos>
Ah! It doesn't check signing?!
<blocktrron>
No
<hurricos>
Gah. OK.
<hurricos>
I thought it did on AP135, but I realize we have a lot of Aruba ports out there for much newer boxes
<blocktrron>
You just have to use the loader to avoid their wrapper
<hurricos>
omg. :facepalm:
<hurricos>
OK. From an organization perspective, is it reasonable to split the AP105 / AP175 into multiple images, one each for patched u-boot and not?
<blocktrron>
Why do you want to do that?
<hurricos>
I say that, but I don't know if the firmware layout varies.
<blocktrron>
You just have to prepend the loader, jump to TXT_BASE and proceed from there
<hurricos>
I suppose it doesn't matter if it *does* vary, so long as there's an image compat incrementation
<blocktrron>
Why?
<hurricos>
I'm just establishing things. I assume the devicetree firmware partition will be left in the same place, but if it isn't, we'd just need an image compat version increment
<hurricos>
I don't want to sysupgrade one of my remote devices, forgetting that its bootcmd is incorrect.
<hurricos>
(for the target sysupgrade)
<blocktrron>
You prepend the loader, create a uImage header for the legacy hacked uboot.
<hurricos>
but again, I haven't thought about it, it sounds like you're gonna use the wrapper, and not a modified bootcmd, to do your work
<blocktrron>
The partition map stays identical, the SPi flash is mapped in the IO space so you can just copy it to TEXT_BASE and jump into it with the apboot
<hurricos>
which means nothing else changes, which is exciting
<hurricos>
I appreciate your work :^)
<blocktrron>
The AP-135 can self-modify the signature check and use the original wrapper code.
<blocktrron>
The platform does not map the flash into io-space, thus you require to do that.
<blocktrron>
For the AP-105 i just want someone to verify it does not break existing installations
<hurricos>
(to be clear, AP-135 is a different board. I'm unaware of anyone who's got the avanta family working)
<blocktrron>
There's a tree on github
<hurricos>
Good lord.
<blocktrron>
Not for AP-135 but it boots on it
<hurricos>
blocktrron: I'll email Van immediately and ask he verify. Is the 6e0ab77f55d01d85dd1939725945402254fb861d OK to compile from?
<hurricos>
(Van has many of these, I do not have any)
<blocktrron>
jsut reference the branch
<hurricos>
Yes, sorry.
<hurricos>
I can test on AP175.
<hauke>
Ansuel: pong
<blocktrron>
What boggles me is someone hacked together the legacy u-boot instead of spending 10 minutes on the stock bootloader
MaxSoniX has quit [Quit: Konversation terminated!]
<hurricos>
10 minutes and years of understanding how boot wrappers work ;^)
<hurricos>
that would be riptidewave93, from whom I learned all my horrible hacks^W^Wtricks
<blocktrron>
OpenWrt has lzma-loader for a long long tie
<hurricos>
Ah, yes, but OpenWrt has had lzma-loader longer than I knew what u-boot was
djfe_ has joined #openwrt-devel
<hurricos>
again, I'm a bit boneheaded -- just wanted to make use of the hardware (brought it to be deployed yesterday: https://paste.c-net.org/ShootersQuicker)
cmonroe has quit [Read error: No route to host]
cmonroe has joined #openwrt-devel
<blocktrron>
I'm not blaming for not knowing everything, but pouring effort into hacking together a U-Boot replacement when you could archieve your goal in a more elegant way did appear weird to me
<blocktrron>
at least they should be interoperable.
<blocktrron>
I also was not able to find the patch anywhere on GitHub or on the ML.
<hurricos>
I'm slowly understanding that wrappers are the way to go.
djfe has quit [Ping timeout: 480 seconds]
<hurricos>
Do you recall if there were barriers here w.r.t. the HiveAP 330?
<hurricos>
lzma-loader is now available for mpc85xx as of the fixes for WDR4900 (it includes an spi reader .S which we don't need), so as long as a compressed kernel sits under 8MiB it should be fine.
<hurricos>
IDK how long that will be true, but probably longer than these devices will continue to be used
<hurricos>
iirc it sits well under 3MB right now
minimal has joined #openwrt-devel
nixuser has quit [Quit: Lost terminal]
danitool has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
Tapper has quit [Quit: Tapper]
<hurricos>
blocktrron: I'll avoid overwhemling you with questions in the future. Sent Van an image to test and am currently compiling an image to test on my AP175; I assume IRC is better than the ml for discussing the result once he tested.
<blocktrron>
hurricos: i have no stakes in the hiveap330
<hurricos>
... If you have no strong opinions, I *would* like to spin up a mailing list thread, but at the end of the day the workflow of "you commit, I test and ACK, you commit upstream/"
<hurricos>
.... works fine.
<blocktrron>
I have no objections against IRC nor using the list
<hurricos>
ok.
<hurricos>
as for the hiveap ...
<blocktrron>
as long as you do not expect a response by tagging me on GitHub were fine
<hurricos>
the hiveap330 is my mess, let me deal with it. You've given me enough to be faithful in using wrappers, I just need to bang my head on it for a while
<hurricos>
Sounds good, I assumed as much :^)
nixuser has joined #openwrt-devel
<blocktrron>
what the hell
<hurricos>
?
<blocktrron>
you can simply use the zImage decompressor for the kernel
<hurricos>
yes, but default bootcmd pins the location of fdt and rootfs
<hurricos>
err.
<hurricos>
OK.
<hurricos>
No, I don't know what I'm talking about.
<blocktrron>
zImage decompressor can be used with the simpleboot wrapper
<blocktrron>
It is e.g. on the ap3825
<blocktrron>
for this AP the ship has sailed the moment the partition map was changed
<blocktrron>
Well, at least theres this as a takeaway
<hurricos>
OK; yes. That sounds right. My hope was zImage + simpleboot.
<blocktrron>
Fr the limitations, neoraiders loader is probably the saner approach
<blocktrron>
at least the 60+MB image offered for the device is now over.
<blocktrron>
But lets just take this as a learning. Next time it isprobably also wiser to put the bootcmd modification to the wiki and link it in the image generation
<blocktrron>
this way the instructions can be updated after a release image is updated
<hurricos>
Yes, fair.
robimarko has quit [Quit: Leaving]
<hurricos>
I don't know, two years ago I assumed nobody had invested a bunch of time in a u-boot replacement for these boards, and that it would be easy to build an image that would support a ton of boards, all of which are derived from very similar P1020WLAN / P1020RDB.
<hurricos>
I assumed I'd be here by then, and not working with vendor u-boot, but I had no idea what I was doing.
<hurricos>
All of the decisions I've made since then have been based on that incorrect assumption
<blocktrron>
never replace the vendor bootloader if it is not absolutely necessary
<hurricos>
anyways, I learn. yes, no reason for okli on ap330 until we hit the 8mb compressed kernel limit in 2040
<hurricos>
by which point nobody will be using 80211 anyways
<hurricos>
:^)
<blocktrron>
especially as anything more modern than 2016 does not result in a working image anyways
<blocktrron>
we've gone down the road with 200+ hp APs - was not fun
<hurricos>
MSM460?
<blocktrron>
the AC ones, yes
<hurricos>
sigh.
<hurricos>
OK. Well, thanks for the reminder. Let me take down my post about u-boot replacements on forum.openwrt.org
<blocktrron>
whcih one?
<blocktrron>
Also please do not remove it. Add a note updating why you imagine it to be false.
<hurricos>
well, yes. Not take down but note the fault
nixuser has quit [Quit: leaving]
<hurricos>
It was about general cleanup, but targeted a u-boot replacement for msm460 / colubris, etc., to deal with ... I don't know what. In retrospect, it was a bad idea from the start, with those boards booting from NAND.
<blocktrron>
once you produce a working pipeline, it is okay. but getting there is the hard part
<blocktrron>
however, the wifi part itself is dated. It works for us, as we go along with 3 figure quantities which outweighs the cost of time.
<blocktrron>
But i wouldn't invest the itme if I just want to have 3 APs for myself. Rather get 3 MTK MT7915 APs from eBay for that.
<blocktrron>
The soc family is nice for operating as a Gateway, but the hardware is not available in large quantities.
Borromini has joined #openwrt-devel
<hurricos>
blocktrron: that is exactly our experience at newport wireless mesh.
<hurricos>
we're considering HP APs because they have nice outdoor cases and because the wireless cards can be swapped, but it's not cost effective at this point
<blocktrron>
lol, "nice"
<hurricos>
Is that a good or a bad statement? :^)
<blocktrron>
the mpcie slots have hard power limits
<hurricos>
Ugh
<hurricos>
Well, we're currently using MR16's in MR62 cases, so we're limited to about 19~20dBm, *and* we combine 2.4 and 5GHz chains
<hurricos>
any cheap crap is better
<blocktrron>
you will be able to run a single asiarf card in there, but once you load it up with clients and xfer traffic your mcu will die multiple times a week
<blocktrron>
you do this for mesh or client access?
<hurricos>
better than crashing and not reloading in clean state, thanks ath10k
<hurricos>
both.
<hurricos>
indoor users use regular MR16s
<blocktrron>
We use zyxel nwa55axe for outdoor
<hurricos>
it's *not* fast, but we're at 60 nodes and we share a 100Mbit upstream
<hurricos>
use ~60 on average of that across the town
<hurricos>
we also distribute the connection using 5 or 6 P2P spokes
<blocktrron>
also, don't take my comments up there about the ap330 too harsh, I'm just astounded how deep one can follow the white rabbit
<blocktrron>
I really appreciate the writeup that lead down to this decision. IÄve bumped enough at rough corners myself :)
<hurricos>
No worries. I wasn't expecting I would get away with saying everyone keeps breaking it in my commit message, and have that not break thinks a different way
<hurricos>
at least I have a writeup and I can laugh at it
<hurricos>
Yes, lots of secondhand hardware access
<hurricos>
You've saved my hide more than once, I don't really care if you're mean, as it's better than not fixing my bugs X^)
<blocktrron>
yeah, it's far better than in europe
<blocktrron>
I don't intend to be mean, I just sometimes appear as such in text-form i was told.
<hurricos>
Either way, you know enough to know what I've done is ridiculous.
<hurricos>
I do appreciate your point re: white rabbit, I already know what it's like to realize time wasted
<hurricos>
Frankly, only recently did we start using dual band for OLSR. It's amazing anything worked as well as it did.
<blocktrron>
you only recognize it as such when you once considered it for yourself
<hurricos>
Long-term plan is to find a board which can properly supply power to cards or has one builtin, and build a mounting plate into AP175 cases and reuse their power supply hardware
<hurricos>
so I think we're safe RE: long term. But then I thought that about p1020 u-boot
<hurricos>
I need to review AP175 stock u-boot. I remembered not seeing tftpboot, but I saw your commit message RE: netget, we'll see if it's available on AP175.
<blocktrron>
hurricos: the commands are omitted from the cmdlist
<blocktrron>
execute "diag" and you will see a complete list.
<blocktrron>
you do not need to execute "diag" before invoking any hidden command though