<csharper2005>
rmilecki: ping. I would like some advice on a patch your *.yaml in linux.
grift_ has joined #openwrt-devel
grift has quit [Ping timeout: 480 seconds]
<stintel>
neggles: that wasn't the main problem
<stintel>
neggles: I mean, after switching to FIT and hitting that problem changing loadaddr is the first thing I did. loadaddr=0x10000000 wasn't enough though so ended up going for loadaddr=0x20000000
danitool has joined #openwrt-devel
<stintel>
but my kernel is huge, has BTF enabled etc :)
<neggles>
stintel: what's the FIT image's load address (as opposed to u-boot's temp one)
<stintel>
no idea
<neggles>
m300 yeah?
<stintel>
yes
<neggles>
'KERNEL_LOADADDR := 0x00000000' h-uh
<neggles>
it shows you when it does the image summary just before booting
<stintel>
yes, I don't have that summary anymore :)
<stintel>
I'd need to reboot
<stintel>
let me replug the console cable to the backup m300 then I can check it
<stintel>
really need to get some USB -> RJ45 console cables, then I can leave all network devices in the rack connected
<stintel>
WatchGuard U-Boot 2014.07 - Aug 12 2015 13:55:34
<neggles>
*sigh* of course
<neggles>
if you're sdbooting i'd say the fix there would be to run without an initramfs entirely
<stintel>
I don't use initramfs on the sdcard
<stintel>
just squash+f2fs
<neggles>
right, so the kernel image for that should be 22mib not 175mib
<neggles>
decompressed
<neggles>
which checks out
<neggles>
but if it can't find the mmc that's problematic
<stintel>
that problem is magically solved after "reset"
<neggles>
right, so... something during shutdown is putting the mmc controller into a state that u-boot isn't expecting?
<stintel>
maybe u-boot uses some memory range somewhere that gets used after X uptime, only run into it on the main because the backup router usually doesn't do anything
<stintel>
just did a reboot on the main, comes back fine
<stintel>
maybe I can run some memory hogging thing on the backup and see if I can repro the issue on the main
grift has joined #openwrt-devel
<neggles>
u-boot completely failing to detect the card but only from a post-sysupgrade reset... yikes
<stintel>
and only on one of my 2 M300s
<stintel>
that's why I suspect it's memory related
<stintel>
maybe some memory region that is reserved in the WG kernel - no hints in oem bootlog though
<stintel>
really strange, never seen this before pushing qoriq to master
<neggles>
all the RDB/QDS envs do it, for all the boards with this controller - which to me screams "WONTFIX, here's a workaround"
<stintel>
does the GPL state a timeframe within which source has to be supplied ?
<stintel>
I really had it with WG
<jow>
stintel: iirc no. Within "reasonable" limits
<stintel>
> 6 months surely isn't within those limits :)
<stintel>
I'm going to forward some mails to SFC
<stintel>
fuck it
<jow>
the license states no limits at all
<neggles>
somehow i feel like no
<neggles>
my case is still open too
<neggles>
at this point they must just be pulling delay tactics
<jow>
GPLv2 section 3.b)
<jow>
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange
<jow>
not sure if they could claim that the written offer expired and that they're now not eligable to publish anything
<jow>
s/eligable/required/
<jow>
there's a lot of trolling potential
<neggles>
the most recently published software update is from march this year
<neggles>
so
<jow>
like using a harddisk as "medium customarily used for software interchange"
<neggles>
they're pretty SOL on a timeout
<jow>
then mail that using snail mail
<jow>
and charge USD 2000 for the mail fees and medium costs
<neggles>
I don't think a HDD qualifies as a medium customarily used for software interchange, since those are typically fixed, but you could probably get away with "here's three 3.5" magneto-optical disks"
<neggles>
in the US, anyway. if you tried to pull that here (AU) the courts would slap you upside the head
<jow>
not arguing with that
<jow>
but for that to happen it has to reach the court in the first place
<stintel>
yeah I'm just going to prepare a mail to the SFC and let them handle it
<jow>
being in the right and getting ones rights are sadly not the same things
<stintel>
I commented on the WG case that if I don't have the sources by May 6th I'll let SFC handle it, that date is exactly 6 months after my initial request
<stintel>
and added a reminder in my calendar to make sure to keep my promise
<Borromini>
jow: is there a way to get LuCI to be more verbose? It looks like the wireless page is somehow not registering on one device I have
<Borromini>
there's no menu entry under wireless and when I type the path manually I get the above ^^ clearing the caches does not help
<jow>
Borromini: that's likely caused by /etc/config/wireless being unparsable (containing syntax errors)
<jow>
check "uci show wireless >/dev/null"
<Borromini>
ok, let me check :)
<Borromini>
yep, you're right
mattytap__ has quit [Ping timeout: 480 seconds]
<Borromini>
jow: fixed, thanks a bunch.
<Borromini>
the wireless page doesn't show in the submenu yet, but i can call it directly, suppose that will be fixed with a reboot (uhttpd restart doesn't cut it)
* neggles
has updated his watchguard ticket with some appropriate levels of snark
<neggles>
Borromini: restart uhttpd
<neggles>
oh
<neggles>
i should've finished reading that message before i replied hey
<jow>
Borromini: close and reopen the browser tab
<jow>
the menu is cached in session storage
<neggles>
or if you're in chrome/edge, open dev tools, right click refresh button, 'empty cache and hard reload' :D
<Borromini>
yep, you're right - thanks :)
<Borromini>
neggles: i'm on rusty firefox, i suppose a shift+ctrl+r does the same as that though?
<neggles>
not quite
<Borromini>
ok.
<neggles>
open dev tools, network tab, check 'disable cache' box, then ctrl-shift-r
<neggles>
i should open a feature request or see if there's an addon or something
<rsalvaterra>
It's insane. This thing eats my Omnia for breakfast.
<stintel>
what Belkin is that ?
<mrkiko>
rsalvaterra: it's the RT3200, right?
<rsalvaterra>
mrkiko: Yep!
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
<mrkiko>
rsalvaterra: I guess you're on UBI layout, right? Even because there is no alternative. Are you using it's wi-fi?
<rsalvaterra>
mrkiko: Went directly from first boot of OEM firmware to UBI layout. :)
<mrkiko>
rsalvaterra: can you report me the output of dmesg|grep -i sanity
<rsalvaterra>
And this is wired. I wanted to measure the raw CPU power.
<mrkiko>
rsalvaterra: ehehe, I am a big fan of that device
<rsalvaterra>
Yeah, I saw the message.
<rsalvaterra>
[ 0.066573] CPU features: SANITY CHECK: Unexpected variation in SYS_CNTFRQ_EL0. Boot CPU: 0x00000000bebc20, CPU1: 0x00000000000000
<mrkiko>
rsalvaterra: do you think the power supplier of the omnia is compatible with the RT3200? I think so, the jack is compatible, but can you look the voltage / amperage for me?
<rsalvaterra>
Yesterday me and dangole fixed a couple of things (the GICv2 detection, for example).
<rsalvaterra>
mrkiko: 12 V, 2 A.
<rsalvaterra>
24 W.
<mrkiko>
rsalvaterra: so I can safely use omnia power supplier for the RT3200?
<mrkiko>
rsalvaterra: for the fixes, amazing! Are they going to improve stability or cpu usage?
<rsalvaterra>
Check the polarity first.
<rsalvaterra>
I haven't checked. If it's the same, sure, you can use the same PSU.
<dangole>
the RT3200 has + on the inside of the barrel and - on the outside. i'd be surprised if it's different for the omnia
<mrkiko>
rsalvaterra: I am a blind person so I can't check all of the parameters myself, but for the polarity I know it's correct because the device seems to work fine. Still I needed some assistance to confirm volts and amperage are sufficient to operatecorrectly
<rsalvaterra>
mrkiko: Oh, I had no idea, sorry about that.
<rsalvaterra>
In any case, like dangole said, they're compatible, yes.
<dangole>
12V is fine, the RT3200 takes about 1.2A peak and comes with 12V 2.0A power supply
<rsalvaterra>
dangole: I played with PCIe payload tuning this morning. :)
<mrkiko>
dangole: thanks! So I can use both !! The omnia supplier has a more confortable form factor
<rsalvaterra>
The bus accepts a packed/request size of 256 bytes, double the default. :D
<mrkiko>
rsalvaterra: dangole: sorry for the questions about power supplying, but I didn't want to fray the device long term
<dangole>
rsalvaterra: very interesting
<dangole>
mrkiko: better safe than sorry ;)
arinc9 has joined #openwrt-devel
shibboleth has joined #openwrt-devel
danitool has joined #openwrt-devel
mattytap has joined #openwrt-devel
mattytap_ has quit [Read error: Connection reset by peer]
dedeckeh has joined #openwrt-devel
arinc9 has quit [Remote host closed the connection]
arinc9 has joined #openwrt-devel
arthur_melo has joined #openwrt-devel
arinc9 has quit [Quit: Page closed]
<csharper2005>
rmilecki: hi! Glad to see you here again. I'm working under upstreaming of sercomm-partitions patch (you reviewed my PR a month ago) and guys from linux recommended me to add bindings in linux doc. You're the maintainer of these yaml files. What do you think about these changes? https://github.com/csharper2005/scmap_temp/commit/3be7d5100e71f78d7b5a30b2b4dbf7e1bbee2cfc
pepe2k has quit [Remote host closed the connection]
<mrkiko>
rsalvaterra: :D :D
<mrkiko>
rmilecki: hi
<mrkiko>
rmilecki: I answered your mail - hope the answer was clear enough
<rmilecki>
mrkiko: hey, that description needs to go into commit if it's meant to be applied
<rmilecki>
so people who look at it later can understand why it was reverted
<rmilecki>
and if they try again - they make sure to do it right that time
<rmilecki>
mrkiko: but ideally that should be debugged properly, to really understand why that commit broke anything
<rmilecki>
maybe it's driver no checking for the "pre-calibration" string? is there a typo there?
<rmilecki>
did you maybe check a driver sources for that?
<mrkiko>
rmilecki: infact, the intent of the patch wasn't to be committed necessarily, just to help spark out discussion. That said, I would hope gl-b2200 can be supported in 22.x with all three radios working
<mrkiko>
rmilecki: no, i did not look at it
cbeznea has quit [Quit: Leaving.]
<mrkiko>
rsalvaterra: I am curious to see the fixes land in master
<mrkiko>
rmilecki: what actually I checked was the file requested by driver was there, and my impression is it was present. But I may well be wrong
<robimarko_>
That will extract the BDF and provide you with a board-2.json
<robimarko_>
And bus=pci,vendor=168c,device=0056,subsystem-vendor=0000,subsystem-device=0000,variant=GL-B2200.bin
minimal has joined #openwrt-devel
<robimarko_>
Rename bus=pci,vendor=168c,device=0056,subsystem-vendor=0000,subsystem-device=0000,variant=GL-B2200.bin to bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=GL-B2200.bin as the driver wants
<robimarko_>
And update the board-2.json accordingly
<robimarko_>
Then you just use -c board-2.json and get the new BDF packaged
<mrkiko>
wondering what else is incorrect withok, will come back once I have a working .bin
<arnd>
rsalvaterra: I am not currently planning to revisit this, but feel free to pick it up and address the remaining issues
csharper2005 has quit [Quit: Page closed]
<stintel>
> Network gateway. If omitted, the gateway from the parent interface is taken if any, otherwise creates a link scope route; if set to 0.0.0.0 no gateway will be specified for the route
<stintel>
"the gateway from the parent interface is taken if any" doesn't seem to work with dhcp :/
<rsalvaterra>
arnd: Oh… I don't know which sections I should KEEP(), but I'll see what I can do…
<dwfreed>
stintel: because the static route is set up before dhcp finishes
<stintel>
yeah pretty annoying
<stintel>
I have some test devices (rpi4) that I shuffle around all the time, they connect via wifi but I want mgmt network via wired, but also that is shuffled around, so the only workable option is to use DHCP
<stintel>
but then with defaultroute 0 on the wired part you can't really access things properly :/
<arnd>
rsalvaterra: if you run into specific issues, you can ask me on #armlinux (libera.chat), most of the other folks that might be interested should be there
rua has joined #openwrt-devel
<stintel>
I would argue that netifd knows the parent interface uses dhcp, and should wait until it's been set up before adding static routes
<dwfreed>
yeah, static route at least shouldn't be set until the interface has an IP
<dwfreed>
which for dhcp comes from a proto update
<dwfreed>
(which should nominally resolve the issue for dhcp and a few other protocol handlers)
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
romany has joined #openwrt-devel
goliath has quit [Ping timeout: 480 seconds]
mattytap has quit [Ping timeout: 480 seconds]
<mrkiko>
robimarko_: any tag(s) you want me to add?
Tapper has quit [Ping timeout: 480 seconds]
goliath has joined #openwrt-devel
<robimarko_>
mrkiko: I dont have commit rights, so I dont set any standards
<robimarko_>
Just adding fixes tag should be enough along with a proper description
<csrf>
weird question somewhat related to dev: has anyone ever wired up an (FTDI) USB-TTL adapter so that it can reset the SoC? Was thinking about doing something like this in order to facilitate image loading (over serial)
<csrf>
or, is there a better/easier way to do it? basically, I need to be able build & flash my test images, and reboot the board remotely
<csrf>
I can also have someone hook up the test clip to the SPI flash chip, but figured it wouldn't work for what I'm trying to achieve
noltari has quit [Remote host closed the connection]
noltari has joined #openwrt-devel
<robimarko_>
csrf: You can probably reuse one of the RS232 signals if that FTDI board exposes them
f00b4r__ has joined #openwrt-devel
<robimarko_>
But it will need to be hooked up to the CPU reset
<csrf>
my idea was to load images over serial from uboot console, tie the DTR line from the FTDI adapter to the reset line (at the reset button) to GND, and then toggle it programmatically
<robimarko_>
Yeah, thats I had in my mind as well
<csrf>
*toggle it to GND programmatically
<robimarko_>
I think Arduino basically does that for UART programming
<csrf>
arduino does it a little bit different; they use a 'bounce' circuit to create a pulse anytime the DTR line toggles
<csrf>
I would have to manually toggle the line & bounce it myself (using picocom or whatever)
<robimarko_>
Oh yeah, they have a capacitor for that
<csrf>
just worried i might draw too much current or something by pulling it to GND, dunno
<csrf>
robimarko_, yup exactly
<csrf>
though I figure the reset button circuit should be high impedance, right?
<robimarko_>
If you tie it to the CPU reset then you shouldnt be able to damage anything
<robimarko_>
It has to be High Z anyway
<robimarko_>
I have boards that tie CPU reset to a micro push button directly and that works
<csrf>
i have to have my 'remote hands' tech look over the reset button circuit then
<csrf>
maybe it's not even tied to CPU reset
<csrf>
might just be a regular GPIO
<csrf>
ughh
<csrf>
getting the tech to solder directly to the CPU pin is going to get messy