<jow>
if you do that it should become a global generic facility and we can likely remove "option zone" handling from all shell protos
<jow>
it won't have any impact on the actual interface configuration, just on the stuff presented in the "ifstatus xxx" data: {...} object
bluew has quit [Quit: Leaving]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
Tapper has quit [Ping timeout: 480 seconds]
schwicht has joined #openwrt-devel
xdarklight_ is now known as xdarklight
schwicht_ has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
Slimey_ has joined #openwrt-devel
torv_ has quit [Remote host closed the connection]
Slimey has quit [Ping timeout: 480 seconds]
Slimey_ is now known as Slimey
torv has joined #openwrt-devel
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
valku has joined #openwrt-devel
Tapper has joined #openwrt-devel
<neggles>
i have acquired a quartzpro64 and have a mainline* kernel running on it :D RK3588 is nice! even without proper DVFS/OPP
<neggles>
*mainline in this case would be 'linux-next plus 20 patches or so from a few collabora devs'
goliath has quit [Quit: SIGSEGV]
Misanthropos has quit [Ping timeout: 480 seconds]
<philipp64>
Which is preferred? "DEPENDS:=@(TARGET_x86||TARGET_x86_64)" or "DEPENDS:=@(i386||x86_64)"? Re: PR #19055
_Lechu has joined #openwrt-devel
Lechu has quit [Ping timeout: 480 seconds]
snh has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
GNUmoon has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
snh has quit [Ping timeout: 480 seconds]
snh has joined #openwrt-devel
snh has quit [Read error: Connection reset by peer]
snh has joined #openwrt-devel
cbeznea1 has quit [Quit: Leaving.]
cbeznea has joined #openwrt-devel
floof58 has quit [Remote host closed the connection]
goliath has joined #openwrt-devel
floof58 has joined #openwrt-devel
robimarko has quit [Quit: Leaving]
<rmilecki>
jow: should I make /generic/ zone go into top-level blobmsg of ubus call network.interface status? or into "data" array?
<rmilecki>
s/array/object/
<fpsusername[m]>
Harm_: By the way, I just flashed my openwrt build on mtd6 as you showed on the openwrt forum. I flashed it with the IC on the PCB, but this time I forced the reset pin high (3.3V). Flashing + verifying works, so maybe that was the thing.
<fpsusername[m]>
I'll now boot it for the first time. Exciting
<rmilecki>
afaiu adding that into top-level will require fw4 change to look for it there
Misanthropos has joined #openwrt-devel
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
aiyion has quit [Remote host closed the connection]
aiyion has joined #openwrt-devel
philipp64 has quit [Quit: philipp64]
<jow>
rmilecki: at least for the initial rfc patch into the data array I'd say
<jow>
rmilecki: should be easy enough to move it to toplevel
Habbie has quit [Read error: Connection reset by peer]
<Harm_>
you should start ncat on your desktop first
<fpsusername[m]>
Is it possible with aftpd?
<fpsusername[m]>
Because that's already running
<Harm_>
err, then you 'd need an ftp client in your image
<Harm_>
you can also run `python -m http.server` in your directory containing the .trx file. That starts a web server
srslypascal is now known as Guest6121
srslypascal has joined #openwrt-devel
<Harm_>
and then use wget on OpenWRT to download it
danitool has joined #openwrt-devel
<Harm_>
maybe the built in wget can also download from ftp
<fpsusername[m]>
Oh, address already in use
<fpsusername[m]>
I think I should stop tftpd then
<fpsusername[m]>
nvm, that isn't it
srslypascal has quit [Remote host closed the connection]
<Harm_>
`sudo netstat -tulpen` shows you which programs are listening on which port
srslypascal has joined #openwrt-devel
<fpsusername[m]>
hmm, nothing on 1337
<Harm_>
(by the way, once you have flashed, you need to set your pootpartition U-Boot variable to 0. Boot the device, choose boot option 4. Enter `setenv bootpartition 0` and `saveenv`)
<Harm_>
ncat -l -p 1337 should be visible there. Note that it only accepts one connection and then exits
<fpsusername[m]>
oh, it doesn't show up even though it's running
<Harm_>
you miss an < before the openwrt image name
<fpsusername[m]>
aah, writes now
<Harm_>
nice
<fpsusername[m]>
In case I'd dualboot on another one, flashing updates through the web interface would overwrite the oem firmware then, right?
<Harm_>
fpsusername[m]: flashing to /dev/mtd4 will overwrite the OEM and does not allow for dual-booting.
<Harm_>
if you flash to /dev/mtd6 you can dual boot OEM firmware that is on /dev/mtd4 by switching the U-Boot bootpartition variable
<fpsusername[m]>
You misunderstood my question. If I'd use dualboot and then update firmware through LuCi, would that overwrite mtd4?
<Harm_>
yes
<fpsusername[m]>
So dualboot is just more headache :)
<Harm_>
the update scripts are hardcoded for that path
<fpsusername[m]>
I think it stopped writing or something is stuck: `Writing from <stdin> to /dev/mtd4 ... [w]`
<Harm_>
that should not be stuck. I flashed in less than a minute
<fpsusername[m]>
the pv command doesn't show anything (well, I guess since it's already copied)
<fpsusername[m]>
retrying
<Habbie>
i see Harm_ is getting plenty of input for improving the documentation?
<fpsusername[m]>
Quite so haha
<Habbie>
:)
<Harm_>
hehe, I discovered that the OpenWRT forum does not allow you to edit your post after a few days. I guess that documentation thing is on hold until we can make a wiki page :P
<fpsusername[m]>
Harm_: Should it show anything at the end?
<Harm_>
fpsusername[m]: don't remember
<Habbie>
Harm_, what's keeping you/us from making a wiki page?
<Harm_>
Habbie: when following the steps on the wiki I got the feeling that they really want a device to be supported/merged
<Habbie>
ah, might be
<Habbie>
in that case, keep improving your commit message i guess?
<Harm_>
Habbie: I guess, still working on that
<fpsusername[m]>
But hey, it's flashed and it boots now
<Harm_>
fpsusername[m]: nice!
<fpsusername[m]>
<Harm_> "ok, you can use `ip a add 192.16..." <- Very useful command for the wiki, because if you have it connected to your desktop, it's easier to configure/check things out like this
<Harm_>
Yeah, I suppose we could technically change the default IP range but I don't expect the OpenWRT folks to like that kind of diversification
<Habbie>
probably not :)
<fpsusername[m]>
Just a mention in the wiki is enough for newcomers
<Harm_>
yeah, though flashing externally is even easier than going through initramfs
<fpsusername[m]>
So far this was quite a bit complicated without following a very detailed step by step tutorial
<Harm_>
I should also add that for dual-booting the kernel cmdline should be changed, otherwise it won't find the rootfs
<fpsusername[m]>
Did you check the last message on the forum post? Apparently we can get 2GBps speeds (1GB down, 1GB up)
<Harm_>
Yeah, I was about to work on that and then saw your messages :P
<fpsusername[m]>
Not that I'm going to attach two cables or have that speed (200/200 here), but it'd be nice to have that patch imeplemented as well
<Harm_>
yup
<fpsusername[m]>
By the way, I believe we can flash the bootloader without removing the IC. You most likely have to forcefully pull the reset pin high
<Harm_>
Yeah I saw your message. So you first desoldered/flashed it and discovered that later :P?
<fpsusername[m]>
Because I flashed the image when the IC was mounted on the PCB and it was verified
<fpsusername[m]>
Well, I still have to open up the other extender so I can try the bootloader flashing
<fpsusername[m]>
I don't want to "risk" corrupting the bootloader on the now converted extender, otherwise I'll have to resolder it again
<fpsusername[m]>
* to resolder and reflash it again
<Harm_>
yeah, though it should not matter which part you are flashing. i.e. you can safely try re-flashing openwrt on /dev/mtd4
<Harm_>
So you had everything directly connected to a raspberry pi? No resistors/capacitors in between?
<fpsusername[m]>
Yep
<fpsusername[m]>
Just the programmer clip and jumper cables to the rpi
<Harm_>
Nice! A friend of mine got 3 units for €15 on Marktplaats and I'll help him flash. That will make it much easier
<fpsusername[m]>
The jumper wires add enough capacitance already (I know it's not the same as a decoupling capacitor, just making a joke)
<fpsusername[m]>
Tomorrow I'll try to flash the 2nd extender I have
<fpsusername[m]>
But I do have a question. Currently I soldered a male header so that I can get access through a serial connection
<fpsusername[m]>
Is there a way to do this without serial? Just ethernet?
<Harm_>
Yup, use `ssh root@192.168.11.1`
<fpsusername[m]>
That allows us to choose the boot mode?
<fpsusername[m]>
By the way, I have 18mb of free space
<fpsusername[m]>
Isn't that little? I mean, we have a 256MB storage IC, of which 10 is used for the image?
<Harm_>
fpsusername[m]: 256MiB (megabits)
<fpsusername[m]>
Oh, 32megabytes then
<Harm_>
ehh, sorry, MiB is MegaByte
<fpsusername[m]>
so then it's correct
<Harm_>
yeah
<fpsusername[m]>
bits bytes, same thing, but 8x bigger/smaller
<Harm_>
somehow the flash industry standardised on indicating in bits
<fpsusername[m]>
By tthe way, I did not use the default config, no idea how I should import a config in the first place
<fpsusername[m]>
So I went with the config I made, added some of the LuCi packages and what not
<Harm_>
fpsusername[m]: that's how I started as well
<Harm_>
`make menuconfig` has a load option
<Harm_>
and I guess overwriting `.config` will work as well
<fpsusername[m]>
hmm not sure if that worked
<fpsusername[m]>
but I'll try the load config
<fpsusername[m]>
Yep that works
<Harm_>
nice :)
<Harm_>
fpsusername[m]: I think your `mtd write` was stuck because some versions of `nc` do not close the connection when they deplete stdin (adding the -q0 works there)
<fpsusername[m]>
Hmm okay
<Harm_>
ncat does that by default, hence my confusion
philipp64 has quit [Quit: philipp64]
philipp64 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
Tapper has joined #openwrt-devel
<fpsusername[m]>
By the way, is there any use of updating to the newest oem firmware and then going to openwrt?
<fpsusername[m]>
A bit kike android phones where you get the latest firmware and modem updates before going to a custom rom
<fpsusername[m]>
s/kike/like/
<fpsusername[m]>
* In a sense as android phones where you get the latest firmware and modem updates before going to a custom rom
<Harm_>
fpsusername[m]: I don't think so. There is a partition on the mtd that contains the settings for the wifi chip but the actual firmware is loaded on boot when OpenWRT starts.
<Harm_>
fpsusername[m]: so there could theoretically be a change in settings they made. Would be interesting to compare that partition across different devices