minimal has quit [Quit: Leaving]
Mathew has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
mcbridematt has quit [Ping timeout: 480 seconds]
Mathew is now known as mcbridematt
floof58 is now known as Guest11297
floof58 has joined #openwrt-devel
Guest11297 has quit [Ping timeout: 480 seconds]
Danct12 is now known as Guest11299
Danct12 has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #openwrt-devel
T-Bone has quit [Read error: Connection reset by peer]
Danct12 has quit [Read error: Connection reset by peer]
valku has quit [Quit: valku]
Danct12 has joined #openwrt-devel
<rmilecki> mrnuke: did you manage to flash firmware using U-Boot and TFTP on WAX218?
<rmilecki> mrnuke: i interrupt booting by pressing 2:
<rmilecki> 2: System Load Linux System then write to Flash via TFTP.
<rmilecki> then I tell U-Boot IP addresses and ask to flash WAX218_V2.0.1.0_firmware.bin
<rmilecki> Load address: 0x44000000
<rmilecki> Loading: TFTP server dies: print the pkt buffer
<rmilecki> TFTP server died; starting again
<rmilecki> ipq807x_eth_halt: done
<rmilecki> ipq807x_eth_halt: done
<rmilecki> The Linux System Image size Zero !!
<rmilecki> but previously (with different image) it worked - just U-BOot didn't accept raw ubi format
<rmilecki> "Wrong image format for "source" command"
Danct12 is now known as Guest11303
Danct12 has joined #openwrt-devel
Guest11303 has quit [Ping timeout: 480 seconds]
<rmilecki> mrnuke: it seems I get "Wrong image format for "source" command" for every firmware format: UBI, FIT, Netgear's XORed image
MaxSoniX has joined #openwrt-devel
danitool has quit [Ping timeout: 480 seconds]
bluew_ has quit [Quit: Leaving]
goliath has joined #openwrt-devel
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #openwrt-devel
Danct12 is now known as Guest11311
Danct12 has joined #openwrt-devel
Guest11311 has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
<nick[m]1234> this is fixing a cve:
<nick[m]1234> please merge asap ;)
<gch981213> nick[m]1234: Merged :)
<nick[m]1234> gch981213: thanks!
Danct12 is now known as Guest11314
Danct12 has joined #openwrt-devel
Guest11314 has quit [Ping timeout: 480 seconds]
lmore377 has joined #openwrt-devel
lmore377_ has quit [Ping timeout: 480 seconds]
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #openwrt-devel
guerby_ has quit [Remote host closed the connection]
romany04 has quit [Quit: Ping timeout (120 seconds)]
romany04 has joined #openwrt-devel
takimata has quit [Quit: wat?]
takimata has joined #openwrt-devel
guerby_ has joined #openwrt-devel
rsalvaterra has quit []
rsalvaterra has joined #openwrt-devel
robimarko has joined #openwrt-devel
christophe has joined #openwrt-devel
christop1e has quit [Ping timeout: 480 seconds]
MaxSoniX has quit [Remote host closed the connection]
MaxSoniX has joined #openwrt-devel
karlp has quit [Quit: WeeChat 3.5]
karlp has joined #openwrt-devel
f00b4r0 has quit [Quit: Textual IRC Client:]
danitool has joined #openwrt-devel
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?
<djfe> I can set one nmbm bmt-remap-range in the dtsi and overwrite it in the dts without it affecting partitions:
<rmilecki> djfe: building DTS files works indepndently
<rmilecki> if x.dts overwrites or deletes nodes from .dtsi it *does not* affect building other .dts files
<djfe> that's good to know :)
<djfe> are the dts files collected first -> is it possible for me to look at the full dts file of a device after compiling to see if it looks right?
<rmilecki> djfe: you can decompile .dtb files
<rmilecki> dtc -I dtb -O dts -o verify.dts built.dtb
<djfe> <3
<Znevna> ERROR: tools/elfutils failed to build.
<Znevna> boo x.x
<Znevna> guess I'm late to the party
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<rmilecki> mrnuke: i've managed to get OpenWrt booting from any rootfs partition
<rmilecki> (WAX218)
<rmilecki> i've just sent [PATCH] mtd: parsers: qcom: deal with partitions names on Netgear WAX218
<rmilecki> robimarko: maybe I should have cc-ed you too
romany04 has quit [Quit: The Lounge -]
romany047 has joined #openwrt-devel
<robimarko> rmilecki: There are more devices with the same issue
<robimarko> I think we had similar issue on other devices, but its been a while
<rmilecki> robimarko: most likey, i checked few, but it wasn't clear to me if they use active_fw or another method
<robimarko> rmilecki: Well, there isnt any uniformity
<robimarko> Vendors seem to love to reinvent things
<rmilecki> robimarko: somewhere I read that active_fw may be Senao thing
<rmilecki> Senao seems to be some hw manufacturer building devices for multiple vendors
<rmilecki> so it's probably a matter of who built hardware (Senao vs. other providers) and what vendor decided to do with it
<rmilecki> so yeah, rather messy
romany047 has quit [Quit: The Lounge -]
romany047 has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
goliath has quit [Quit: SIGSEGV]
anh has joined #openwrt-devel
Ryncewynd has quit [Quit: Leaving]
<anh> hello
<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:;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> also:;a=commitdiff;h=35f2510e3ea943c7ec95ea7cef5a5e66e240182d >:O
<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:
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> was the commit where I forced requiring a patched u-boot.
<hurricos> There is an 8MiB kernel partition limit, and kernel needs to be placed at AH_FLASHBOOT_KERNEL_ADDR_IN_FLASH per, but otherwise it does a bootm right out of IO-mapped flash
<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
<blocktrron> whcih one?
<blocktrron> Also please do not remove it. Add a note updating why you imagine it to be false.
<blocktrron> People can learn from that
<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
<KGB-1> has been updated. (11.1% images and 100.0% packages reproducible in our current test framework.)
<blocktrron> you are from the states?
<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> so IDK. We'll see.
nixuser has joined #openwrt-devel
Borromini has quit [Quit: Lost terminal]
Ansuel has quit [Quit: ZNC 1.8.2 -]
Ansuel has joined #openwrt-devel
AtomiclyCursed has quit [Quit: ZNC 1.8.2 -]
floof58 is now known as Guest11382
floof58 has joined #openwrt-devel
AtomiclyCursed has joined #openwrt-devel
Guest11382 has quit [Ping timeout: 480 seconds]
<Ansuel> hauke sent a pm
<Ansuel> (sorry for the delay)
<hurricos> blocktrron: tested ap175 with rebuilt u-boot using your diff for ap105 -- works:
<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
sauce has quit []
<nick[m]1234> or we update tcpdump to latest version
nixuser has quit [Remote host closed the connection]
Misanthropos has quit [Ping timeout: 480 seconds]
madwoota has quit [Ping timeout: 480 seconds]