schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<RoganDawes>
PaulFertser: I suspect that you are correct about the driver for the NAND on the Wink Hub, but I'm a bit puzzled about why it is not binding. The device tree I have seems to work fine with an externally built linux-master kernel, although I have no initramfs so cannot really confirm that.
<PaulFertser>
RoganDawes: well, first thing would be to make sure the driver is present in /sys/bus/platform/drivers and that the device is present in /sys/bus/platform/devices .
<PaulFertser>
RoganDawes: then you can go to the driver subdirectory and try binding manually by doing "echo XXX > bind" and see the error code and dmesg.
<PaulFertser>
RoganDawes: I'd also check compatible string just in case, probably they're slightly different in DT and the driver you built.
<RoganDawes>
so this is the question. According to the device tree, the driver is "gpmi"
<RoganDawes>
but I don't see it in the openwrt tree at all
<RoganDawes>
this works in mainline, but I'm wondering if the name of the driver changed since 5.x?
<RoganDawes>
PaulFertser: in mainline, arch/arm/boot/dts/nxp/mxs/imx28.dtsi shows the nand controller as compatible with imx28-gpmi-nand
<PaulFertser>
RoganDawes: I'll check now and tell you for sure.
<KanjiMonster>
RoganDawes: did you enable the driver? currently it is only enabled for the imx target, but not for the mxs one (MTD_NAND_GPMI_NAND)
<PaulFertser>
If it wasn't enabled it wouldn't be present in /sys/bus/platform/drivers
<KanjiMonster>
good point
<KanjiMonster>
is the node enabled? (i.e. is its status "okay")
<RoganDawes>
checking
<KanjiMonster>
in the devicetree, there is a property called "status"
<PaulFertser>
E.g. for mir3g: /sys/firmware/devicetree/base/nand@1e003000/status
<RoganDawes>
that would need to be enabled under kernel_menuconfig?
<PaulFertser>
RoganDawes: the nand driver can be enabled in kernel_menuconfig for testing, yes.
<RoganDawes>
how would I enable it in the profile for permanent configuration?
<RoganDawes>
add to the mxs/config?
<PaulFertser>
RoganDawes: yes
<RoganDawes>
I guess it would be unfortunately to inflict that on other mxs platforms, though
<PaulFertser>
Yes. Or you would need a subtarget.
<PaulFertser>
Probably just a nand controller driver isn't much, so no real harm enabling it for everybody.
<RoganDawes>
will check how that is supposed to work, thanks for the pointer
<KanjiMonster>
mxs doesn't look like a platform strapped for space, so I don't think an extra subtarget is needed
danitool has joined #openwrt-devel
<RoganDawes>
yup! That worked! Thanks so much for your help, PaulFertser and KanjiMonster
<PaulFertser>
Cool
<RoganDawes>
Now I just need to figure out how to get a squashfs root filesystem into the UBI partition, along with a writable ubifs overlay
<PaulFertser>
Just follow what the other devices with root on NAND do.
<RoganDawes>
well, my target has all the partitions formatted as UBI
<RoganDawes>
so was trying not to deviate too much from the initial configuration
<KanjiMonster>
ubi or ubifs? these are two distinct things ;)
<KanjiMonster>
having multiple ubi partions seems weird
<PaulFertser>
Probably it's better to stick to OpenWrt common code rather than whatever vendor invented, and just provide clear instructions for those who want to downgrade back to vendor's.
<PaulFertser>
Yes, ubi is a container, kinda like LVM, and usually there's just one ubi on the device, and you create ubi volumes inside of that container, and can have different filesystems on those volumes.
<RoganDawes>
truth is the hardware is abandonware from the vendor - requires a cloud service that is down more than it is up. So it probably does make sense to follow OpenWrt standards instead.
<RoganDawes>
in this case I have 6 partitions in the nand, openwrt, updater kernel + fs, database, app kernel + fs
<PaulFertser>
So multiple _ubi_ partitions is indeed strange unless it's part of a primary/recovery dual boot mechanics.
<RoganDawes>
it is exactly that
<PaulFertser>
Not usable for OpenWrt so if you just add to the commit message a set of commands for recreating and downgrading that would be enough. And if you say it's not usable at all with vendor software already, probably even that isn't needed.
<RoganDawes>
I'm quite keen to keep the updater kernel and FS around while developing, to avoid having to use JTAG to recover (or else writing over UART to uboot for flashing)
<RoganDawes>
since there is only WiFi, no ethernet
<RoganDawes>
ok, instructions sounds like a reasonable plan
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<RoganDawes>
how much space should I allocate for a kernel? Currently there is 8MB in the app kernel partition, and then around 76MB for the root FS
<RoganDawes>
if I am making a partition for the squashfs, would dividing the 8MB as 3/5 kernel/squashfs be reasonable?
schwicht has joined #openwrt-devel
<PaulFertser>
RoganDawes: how is the bootloader fetching the kernel? Probably the size is hardcoded already?
<PaulFertser>
RoganDawes: squashfs should be dynamic normally, when you're sysupgrading, the ubi volumes get recreated so squashfs doesn't take up any more than it needs.
<RoganDawes>
uboot reads a uImage, but I have changed the size to 6MB because I was futzing with mainline kernels and such
<RoganDawes>
ah, so the space beyond the kernel would have both the squashfs and ubifs in it. Gotcha. Will look at e.g. the kirkwood targets to see how they set this up. The mxs targets all use SD cards, it seems!
<PaulFertser>
RoganDawes: you can check package/base-files/files/lib/upgrade/nand.sh to see how it's supposed to work
<PaulFertser>
RoganDawes: usually you make sysupgrade tar file, and so nand_upgrade_tar is used.
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit []
schwicht has joined #openwrt-devel
schwicht has quit []
robimarko has joined #openwrt-devel
schwicht has joined #openwrt-devel
schwicht has quit []
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<rmilecki>
nbd: pong
<nbd>
rmilecki: i'm currently working on a big rework of wifi setup / reload (in my staging tree). i think i still need to write some code to deal with a brcmfmac corner case
<nbd>
when i'm done, could you please help me test it?
<rmilecki>
nbd: absolutely
<nbd>
i don't think i have any brcmfmac hardware at home
<rmilecki>
nbd: there is actually a small bug in current implementatoin
<rmilecki>
nbd: brcmfmac doesn't allow deleting the main interface
<rmilecki>
nbd: if "iw dev X del" fails we should try renaming it and changing its type
<rmilecki>
right now we create a new interface
<rmilecki>
so we end up with wlan0 unused and phy-ap-wifi0 (or whatever it is) user
<rmilecki>
*used
<nbd>
so my current plan is this:
<nbd>
whenever it wants to create a new device, it should first look for an existing device that is not part of the current active configuration
<nbd>
and rename/re-type it
<nbd>
and not worry about error handling for vif delete
robimarko has quit [Remote host closed the connection]
<rmilecki>
that should be ok for brcmfmac
<nbd>
great, thx
robimarko has joined #openwrt-devel
<nbd>
once this is done, we can finally have proper fast config reload where most of the time only affected interfaces get reloaded/restarted
<nbd>
on non-brcmfmac hw this is already working quite well in my tests
<rmilecki>
nbd: great, that may need testing with brcmfmac though
<rmilecki>
i love that feature though
<nbd>
handling this is made so much easier by having a ucode vm inside hostapd/wpa_supplicant
<rmilecki>
nbd: if you think "eeprom" name for NVMEM cell is fine, please take this patch
<rmilecki>
if you think "precal" would be better (that is what Ansuel originally used) please let me know
<nbd>
PaulFertser: regarding your patch - i will take care of this today
<rmilecki>
nbd: i'm fine either name, but let's finally proceed with that
<mrkiko>
nbd: hi! I don't know if you already replied to me and I lost the message, or if you don't feel like replying (fine as wellin that case) - was wondering if the GH mt76 776 might be fixable somehow at driver level or not, and if it might befixedat some point
<nbd>
rmilecki: i'd prefer "eeprom" since that's more common. "precal" doesn't fit entirely, since the data does not only contain calibration data, but also things like mac address, features, etc.
<nbd>
mrkiko: i haven't had the time to reproduce the issue yet
<rmilecki>
nbd: great, can you take that patch then, please?
<nbd>
mrkiko: so i don't know what the exact cause is
<rmilecki>
nbd: it's already approved from DT side (Krzysztof)
<nbd>
rmilecki: sure
<Ansuel>
nbd yes but considering we won't use offset for nvmem cell
<Ansuel>
A more specific name might be a good idea
<nbd>
what do you mean regarding offset?
<mrkiko>
nbd: thanks!!
<Ansuel>
nbd I might be wrong but there is some code that take the mtd partition from the binding and the read data at an offset for some specific devices. That won't happen for an nvmem implementation (as we will define the cell starting at the required offset directly)
<rmilecki>
nbd: what i think Ansuel means is that nvmem-cells = <&eeprom> is not meant to refer the whole MTD partition, just a proper part of it containing expected data
<Ansuel>
yes also that. Thanks. (you can see cell as virtual sub partition printing directly at the needed data)
<Ansuel>
Pointing*
<nbd>
my point regarding mac address / features is independent of the offset aspect
<rmilecki>
nbd: Ansuel: does data loaded by mt7915_eeprom_load_precal() also contain MAC address and features?
<nbd>
mt7915_eeprom_load_precal does not load the start of the data passed in via mtd-eeprom
<nbd>
the first part in mtd-eeprom is mac address + features + various calibrations including tx power
<nbd>
on mt7915 there is optional pre-calibration data which is directly after the main block
<nbd>
and that is processed by mt7915_eeprom_load_precal
<nbd>
but it is passed to the driver as one big chunk containing all of that
<Ansuel>
nbd yes and this is why my idea about cal and precal, was to handle the optional thing that would be ideally a different cell
<nbd>
i don't think that makes sense
<nbd>
because then for each device we have to know if it has precal data or not and describe that in DT accordingly
<nbd>
instead of just passing in the big data block
<nbd>
the data inside the first chunk indicates whether there is extra pre-cal data or not
<nbd>
and so far i haven't seen any device that keeps them separate
<rmilecki>
does it mean that in factory MTD partition at 0x8000 offset there is all kinf of data? MAC, features, precal?
<nbd>
yes
<rmilecki>
then I'd say it make sense to stick with the "eeprom" name
<Ansuel>
well yes if we want to take this approach i agree on eeprom
<PaulFertser>
nbd: thank you!
<nbd>
the vendor driver also doesn't support loading the precal data separately, IIRC
<nbd>
so i don't think we should expect devices to split this
<Ansuel>
no idea the additional precal was this much optional... my idea was that it was an additional calibration required by some card
<nbd>
i think most devices don't have precal data
<Ansuel>
thanks for the clarification, rmilecki I think the idea is to create a big cell called eeprom and with the size of all the data + this optional calibration
<rmilecki>
so it seems fine to me, we probably don't want to play with creating 3 different NVMEM cells in a MTD partition ("factory" or whatever)
<rmilecki>
Ansuel: i think it's easier
<rmilecki>
Ansuel: better/easier
<rmilecki>
Ansuel: that would be a huge effort to split that eeprom data into 3 NVMEM cells for each device
<rmilecki>
Ansuel: nbd: thanks a lot for discussion that
<rmilecki>
*discussing
<Ansuel>
rmilecki sooo i have to update the pr and send to net-next
<Ansuel>
consider that it's currently closed so all RFC stuff
<rmilecki>
Ansuel: it's linux-wireless@ actually, not net-next
<rmilecki>
Ansuel: and linux-wireless@ doesn't get closed afaik
<Ansuel>
i missed the message dt is already pushed?
<rmilecki>
Ansuel: no, nbd will pick it up now
<rmilecki>
Ansuel: is approced by DT guy so it's safe to push it to nbd's mt76 development tree
<rmilecki>
Ansuel: you send mt76 to linux-wireless@ but it's actually nbd who pick up mt76 patches to his tree
<johnf>
anyone ever try to run openwrt on cradlepoint hardware?
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<johnf>
there's nothing in the ToH
minimal has joined #openwrt-devel
<johnf>
nothing in the forums either really, except people using them as modems for a openwrt router
<Ansuel>
rmilecki i changed the entry to eeprom can you check the pr one last time?
<RoganDawes>
what is the correct way to add a patch to the linux kernel as part of the build? Does it just get placed into the package/kernel/mxs/patches/ directory (created since there is none), and get picked up from there?
<tmn505>
johnf: last time I checked devices varied between ubicom32, ralink, some arm broadcom and qualcomm ipq. So check what hardware it has before investing time into it. FCC pictures will be Your guide.
<tmn505>
RoganDawes: yes
<RoganDawes>
tmn505: ok, cool
<tmn505>
to be exact patches-5.15
<RoganDawes>
do I need to create a Makefile to go along with the patch?
<RoganDawes>
right
<tmn505>
no
<RoganDawes>
ah, otherwise the patch would be applied to 6.1 as well?
<tmn505>
yes
<RoganDawes>
hmm, I don't see any other directories named that way?
<RoganDawes>
ah, was in the wrong directory :-(
<tmn505>
oh wait, wrong directory, it should be in target/linux/mxs/patches-xxx
<tmn505>
RoganDawes: ^^^
<johnf>
tmn505: hmm, so this related router (not the exact same one) https://fccid.io/UXX-IBR600E is running a rt3352f SoC
<johnf>
which looks like it would be maybe not so hard to support
<tmn505>
unless it has 32MiB RAM, then it gets rough
<RoganDawes>
tmn505: yeah, I figured that out when I found the linux-5.15 directories under there :-)
rsalvaterra has quit [Read error: Connection reset by peer]
guidosarducci has quit []
Danct12 has quit [Quit: WeeChat 4.0.0]
guidosarducci has joined #openwrt-devel
<RoganDawes>
ok, so now I am identifying the brcmfmac device on the SDIO bus, but surprisingly (for the uninitiated), it seems to be looking for a very board-specific firmware file:
<RoganDawes>
[ 1.993722] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4334-sdio for chip BCM4334/3
<RoganDawes>
[ 2.006368] brcmfmac mmc0:0001:1: Direct firmware load for brcm/brcmfmac4334-sdio.wink,imx28-wink-hub-v1.bin failed with error -2
<RoganDawes>
[ 2.018248] brcmfmac mmc0:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac4334-sdio.wink,imx28-wink-hub-v1.bin
<johnf>
tmn505: the actual device I'm interested in is a ibr600c-150m-d but I can't find it on fcc.io
<johnf>
excuse me, fccid.io
<johnf>
hmm
<johnf>
nah, even with a site: filter I can only find the 600E
<johnf>
and I don't have the device, to get the actual fccid off of it
<PaulFertser>
RoganDawes: it's usually ok, it can then read generic file.
<RoganDawes>
ok, it looks like I don't have any firmware in my initramfs anyway
<tmn505>
johnf: to identify use the FCC ID from device label, if not in possesion ask for picture of it
<RoganDawes>
I will dig to see how to add that to the image.
<RoganDawes>
But I'm also running into another problem:
<RoganDawes>
/usr/bin/ld: /home/rogan/workspace/openwrt/staging_dir/host/lib/libcrypto.a(libcrypto_la-eng_all.o): in function `ENGINE_load_builtin_engines':
<RoganDawes>
eng_all.c:(.text+0x30): undefined reference to `pthread_once'
<PaulFertser>
RoganDawes: I thought you already added the relevant packages to the list.
<RoganDawes>
I thought I had too
<PaulFertser>
And yet /lib/firmware is empty?
<RoganDawes>
yes
<RoganDawes>
I did google that pthread_once error, and the suggestions are to upgrade the host OS?
<PaulFertser>
RoganDawes: hm, probably you need to delete .config and then select your board from menuconfiig as the first thing you do, then the default packages will get included.
<PaulFertser>
RoganDawes: or just include manually.
<PaulFertser>
RoganDawes: what's your host OS?
<RoganDawes>
debian
<RoganDawes>
11.6
<PaulFertser>
RoganDawes: and do you mean your image was building fine but then you enabled something and it stopped?
<johnf>
ah, I found a label shot, that gave me the fcc id, I've got the actual FCC ID
<PaulFertser>
RoganDawes: that's wrong way for OpenWrt
<PaulFertser>
RoganDawes: because OpenWrt is using wireless drivers from backports project, so that you get latest-and-greatest on stable kernels.
<PaulFertser>
RoganDawes: please disable it back ;)
<RoganDawes>
ah, ok. It's not always obvious what the right way is :-)
<RoganDawes>
ok
<PaulFertser>
RoganDawes: package/kernel/mac80211/ is the place with them
<RoganDawes>
aha, thanks!
<PaulFertser>
And brcmfmac is already packaged, you just need to include the corresponding kmod- in your image.
<nbd>
rmilecki: the code is ready for testing on brcmfmac
<f00b4r0>
throwing a bottle at the sea: there's no possibility in dnsmasq to programmatically adjust DHCP options content when a new client is processed? e.g. send an url containing a unique UID to the new client
<f00b4r0>
(manpage doesn't suggest it can be done)
FLD is now known as Guest5145
FLD has joined #openwrt-devel
schwicht has joined #openwrt-devel
Guest5145 has quit [Ping timeout: 480 seconds]
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
<minimal>
f00b4r0: how would it know what is a new client?
<f00b4r0>
s/new client/new dhcp request/
<f00b4r0>
s/new// even
<minimal>
have you a particular DHCP option in mind that you want a URL placed into?
<f00b4r0>
I do. Option 114
<f00b4r0>
(aka RFC8910)
schwicht has quit []
<minimal>
and you read the discussion regarding this in the OpenWRT forum from earlier this year?
<f00b4r0>
I did not
<minimal>
was one of the early results an online search returned for "dhcp option 114"
<f00b4r0>
now I did. and it doesn't help :)
<minimal>
why doesn't it help?
<f00b4r0>
because it doesn't remotely answer my question.
<minimal>
well it shows how to send the 114 option in general - I'm assuming you haven't yet configured dnsmasq to do so
<f00b4r0>
I want to send a per-client, unique value. i.e. I want to implement RFC8910. The forum post shows how to send a generic value to all clients to say "you're not captive".
<f00b4r0>
that's not helpful.
<minimal>
well it is helpful if you haven't been able to send any 114 option at all - you haven't indicated whether or not you have
<f00b4r0>
thanks.
schwicht has joined #openwrt-devel
<minimal>
openwrt doesn't seem to support the dnsmasq "--dhcp-optsfile" as othewise you could kludge some sort of horrible method that way
<minimal>
f00b4r0: ^^^
<f00b4r0>
my understanding is that optsfile is also static (static text file, not a script). AFAICT dnsmasq has no mechanism to do what I want, I just asked in case there's something I'm missing. Seems there isn't, alas.
<minimal>
foob4r0: yes a optsfile is static - unless *something* (i.e. a script) changes it ;-)
<f00b4r0>
seems the RFC is one of those "nice on paper, impractical in reality" RFCs.
<minimal>
there is dhcp-script option to run a script upon every lease......which could modify any optsfile
<f00b4r0>
minimal: by the time "something" changes it upon new DHCP request (which dnsmasq can only signal via dhcp-script), dnsmasq has already read it.
<minimal>
you said you wanted unique values - so 1 optsfile per DHCP IP and a dhcp-script to change the unique value in an optsfile *after* it has been sent to a client ;-)
<minimal>
so that the next time the optsfile is used the value is different
<f00b4r0>
and of course this is completely race free.
<f00b4r0>
yeah, as I said, thanks.
<minimal>
I did say it was a kludge
<minimal>
I indicate a potential solution, I didn't say it was a "nice" solution
<f00b4r0>
it's not a solution.
<minimal>
how so?
<f00b4r0>
<f00b4r0> and of course this is completely race free.
<RoganDawes>
can someone explain how I can have BRCMFMAC_SDIO configured from a Makefile package selection? Or is there a different way to do it?
<minimal>
f00b4r0: sorry I tried to help
<RoganDawes>
so far I get CONFIG_BRCMFMAC_USB=y but that appears because it is a "default y" in tmp/.packageinfo and tmp/.config-package.in
<f00b4r0>
hmm. segfault in ucode script, that can't be good
torv has quit [Quit: torv]
torv has joined #openwrt-devel
<cmonroe>
nbd: Ansuel: we have a device going thru certification right now which requires pre-cal data due to some off-channel noise.. I just wanted to confirm it is also as you described (e.g. one big blob). an offset in "regular" calibration data (0x62 for MT7915 I think) indicates whether pre-cal data will follow at the end of regular calibration data. happy to share samples if helpful.
<RoganDawes>
so it seems that the brcmfmac firmware that I require doesn't exist in the OpenWrt repos - brcm/brcmfmac4334-sdio.bin
<RoganDawes>
brcm/brcmfmac43340-sdio.bin exists, but not the version without the trailing zero :-(
<RoganDawes>
what is the correct way to add the ubi-tools to my filesystem? Update the busybox config to build them, or can I add a define in my Makefile to do that automatically?
<KanjiMonster>
RoganDawes: if you add nand to the FEATURES of the target, it should automatically be added
<RoganDawes>
KanjiMonster: that is what I thought, but it doesn't seem to work.