<iocampomx>
Any idea on how can I fix the "Bad Magic Number,03000000" error message?
<Mangix>
alright. it turns out mdnsresponder needs to go
<Mangix>
extremely broken package
<raenye>
iocampomx: sorry, no idea
<raenye>
dwfreed: rmilecki: git bisect shows a4792d79e899b28cefdb6d is responsible for EA9200 non-working LAN ports, must be something with the switch
<raenye>
but this commit introduces multiple patches
<iocampomx>
I'm seeing someting strange on the Kernel image binary. There are 96 bits in the uImage header that somehow may be causing an issue.
raenye has quit [Ping timeout: 480 seconds]
<iocampomx>
So, I made a copy of the /dev/mtd4 device, which has the current "Kernel" on the router. I then listed its content and the content for the stock firmware, and found a difference on the "uImage header"
<iocampomx>
The stock .bin file, has 96 bits of additional information, that somehow gets stripped when it's actually flashed on the device, because, that is actually the content that get stored on /dev/mtd4
<iocampomx>
It worked. I removed the first 69 bytes from the stock image and I was able to boot it from the TFTP.
<aparcar>
colo: if you have an idea on how to improve that situation. please let me know
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
<colo>
aparcar: ah, cool! :)
<colo>
aparcar: since the basic mechanism seems to already exist, what would be (afaict/imho) required is to fan out the work of generating the data that makes it tick correctly to those who are best able to do it (i.e., package maintainers)...
<colo>
maybe have a convention for a "magic paragraph" in a commit message that can be used to parse out the required info?
<colo>
that would give maintainers who care about the feature an opt-in choice to implement it, for some additional effort spent
<colo>
(and missing data from packages where maintainers choose not to spend the additional time/effort could still be backfilled as it were)
<colo>
(oh, and to add a disclaimer: I'm mostly talking out of my ass here and have ~0 familiarity with established OpenWrt dev processes :))
bluew has quit [Ping timeout: 480 seconds]
tomn has joined #openwrt-devel
SpectreDev_01 has joined #openwrt-devel
cmonroe has quit [Ping timeout: 480 seconds]
hitech95 has joined #openwrt-devel
<hitech95>
does anyone know how the uboot board files (.c) in included from the configuration? I want to add some custom logic for a specific board but I cannot figure out how and when a board file is selected.
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
xback has quit [Ping timeout: 480 seconds]
tidalf has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tidalf has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
SpectreDev_01 has quit [Quit: Connection closed for inactivity]
_lore_ has joined #openwrt-devel
iocampomx has joined #openwrt-devel
tidalf has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tidalf has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
tidalf has quit [Read error: Connection reset by peer]
tidalf has joined #openwrt-devel
tidalf has quit [Read error: Connection reset by peer]
tidalf has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
goliath has joined #openwrt-devel
tidalf has quit [Ping timeout: 480 seconds]
<hitech95>
Ok I'm feeling quite dumb, you can specify that in the config the chip name is also the board target. ooook.
goliath has quit [Quit: SIGSEGV]
zer0def has joined #openwrt-devel
rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
rmilecki has quit []
rmilecki has joined #openwrt-devel
CodingMarco has joined #openwrt-devel
<hitech95>
Is there a way to generate the diffconfig from .config of uboot to be put in a .patch file?
<CodingMarco>
Hi, I'm currently porting OpenWrt to an AP which uses a Broadcom BCM54612E PHY. However, the vendor u-boot suspends the PHY when the AP is booted from flash. Since the `phy_driver` struct of the BCM54612E doesn't have the `resume` function pointer defined, it isn't woken up on boot. What would be the preferred way to enable the PHY for OpenWrt? A kernel patch (which would effect all devices)? Or is it possible to enable the PHY with a
<CodingMarco>
In general I'm wondering why some PHYs have the `resume` function pointer defined and some don't. Also some use `genphy_resume` and some use `bcm54xx_resume`. This all seems a bit inconsistent.
cmonroe has joined #openwrt-devel
<rmilecki>
CodingMarco: i believe .resume() callback is for resuming from sleep
<rmilecki>
CodingMarco: powering PHY on and init should happen just fine without .resume()
<rmilecki>
CodingMarco: for PHY_ID_BCM54612E there is:
<rmilecki>
.probe= bcm54xx_phy_probe,
<rmilecki>
CodingMarco: please verify it gets called
<rmilecki>
you can add dev_info(&phydev->mdio.dev, "%s called\n", __func__);
<rmilecki>
CodingMarco: how resuming/initializing that PHY should happen?
goliath has joined #openwrt-devel
philipp64 has joined #openwrt-devel
<philipp64>
Ansuel: I think you're right that ipcalc.sh might be due for a rewrite into another language.
tidalf has joined #openwrt-devel
<CodingMarco>
rmilecki: Maybe I got the wording a bit wrong. It's the BMCR_PDOWN bit in the MII_BMCR register. This bit is set to 1 by u-boot. genphy_resume (which in turn is called by bcm54xx_resume) clears this bit.
<rmilecki>
CodingMarco: ah, you mean generic PHY reg
<CodingMarco>
rmilecki: yes.
<rmilecki>
CodingMarco: ok, i can see that phy_attach_direct() calls phy_resume() which calls .resume() callback
<rmilecki>
so .resume() is also used during init
<rmilecki>
CodingMarco: can you
<rmilecki>
1. open drivers/net/phy/broadcom.c
<rmilecki>
2. find PHY_ID_BCM54612E entry
<rmilecki>
3. add .resume= genphy_resume,
<rmilecki>
and see if that helps?
CodingMarco has quit [Remote host closed the connection]
<hurricos>
russell--: ACK RE: realtek-poe; are there issues with the current userspace implementation?
<hurricos>
I've turned all my spare time to reverse-engineering early-00s ECUs :|
<hurricos>
(now that I have what I need working at home / at the Lab)
<philipp64>
anyone: i'm running on a 32GB SSD, but for whatever reason my writable root (using squashfs) is tiny... I have `CONFIG_TARGET_ROOTFS_PARTSIZE=2027`. How do I grow my root partition? I can grow the partition size, but after that... I can't just do a `resize2fs` because the squashfs is on there with the root ext4 filesystem as well...
CodingMarco has joined #openwrt-devel
<dwfreed>
you resize2fs the loop device that the ext4 filesystem is actually mounted from
<CodingMarco>
rmilecki: Yes, I already tried that. This fixes it. This is why I asked in the first place - a kernel patch would fix it but I'm not sure if this is the correct way to proceed.
<rmilecki>
CodingMarco: sounds OK to me
<rmilecki>
CodingMarco: i suggest sending a patch, see what reviews its going to get
<CodingMarco>
Also, I'm asking myself why some PHY models have a resume function defined and some have not. Potentially there could be more strange bootloaders out there doing the same thing. So I'm wondering if a resume function should be added to all (Broadcom) PHYs.
<CodingMarco>
However the scope would of course be very large without me being able to test it with all PHYs.
<CodingMarco>
rmilecki: What do you think, would the PHY patch be more appropriate as part of my "adding device support" PR/patch or as a separate one?
<rmilecki>
CodingMarco: please send upstream patch for that
<rmilecki>
there are ppl looking after broadcom PHY driver
<hurricos>
I did see that waaay back when the bindings were initially being set up
<hurricos>
I didn't want to get messy with kernel development at that time, but I do (when I find time) want to review and make sure the bindings we've been playing with make sense RE: upcoming kernel standards
<hurricos>
userspace has always worked fine for PoE -- it's hardware, yes, but it's independently driven power control hardware, being spoken to over serial ... it's a whole thing.
<hurricos>
We don't even have a firmware extract for any of these microcontrollers so we can do the whoel linux-firmware thing of uploading it to the chip on boot :p
<CodingMarco>
rmilecki: Ok, I will do that. Funny - it means that my journey continues (until 4 weeks ago I was only a high-level C#/python developer 1 year after my bachelor's degree).
<hurricos>
granted they don't *need* that, but ... yeah.
<rmilecki>
CodingMarco: congratz :)
<KanjiMonster>
I've written a serial driver for kernel, it's not that complicated
<hurricos>
it's a mess though.
<KanjiMonster>
in what way?
<hurricos>
I remember repeatedly grepping through kernel and openwrt device trees for examples, pretty much only that caviumx puzzle board is the only thing I remember finding that talks to a microcontroller over serial as defined by a device tree
<hurricos>
it's not common
<KanjiMonster>
I've written a kernel driver for poe-mcu (pre-6.1) before, it isn't really that complicated
<robimarko>
Puzzle M801 and M901/2 use a UART driven MCU
<hurricos>
that's the one.
<hurricos>
I'm aware that it's not terribly complicated; to be clear, my goal was not to figure out what the standards were there
<hurricos>
or rather
<hurricos>
create standards for something that was unstandardized up to that point
<hurricos>
I also did not do most of the realtek-poe development -- it was all -- oh where is he -- mrnuke.
<KanjiMonster>
are you talking about the poe side? on that part I agree
<hurricos>
Yes.
<hurricos>
Mostly.
<KanjiMonster>
for the serial part there's the serdev stuff
<robimarko>
To be clear, I also find using UART as the communication method weird
<hurricos>
I figured, I'd wait for the needs to turn into more commonly accepted bindings, and then implement <whatever> correctly against bindings
<robimarko>
Well, I doubt we are going to see bindings before a more concrete PoE subsystem
<hurricos>
baby steps ;p
<KanjiMonster>
I would rewrite my poe-pse driver for the pse-pd thingy, but unfortunately the system(s) where it's used don't have a switchdev/dsa driver (so no eth with phy to assign to), or don't even use devicetree (x86)
<hurricos>
but that kind of work fills a hole when folks like myself have no idea how these things actually work
<KanjiMonster>
though amazo^Wdent is likely pushing for a new(?) poe binding/interface for the kernel, because the current one is NIH or so. bootlin is doing the implementation, so might be good anyway
<robimarko>
I can confirm that we are working with Bootlin to actually add PoE PSE support to the kernel
<robimarko>
Cause what exists is just barebones PoE-DL and not the usual 802.3at/af and the rest
<robimarko>
And this situation where everybody has their userspace tool isnt feasible if you have more than a single vendor
<KanjiMonster>
yeah. I mean as a base it isn't bad, you have a way to assign pse mcu channels to ethernet macs (well phys lol) in the device tree, and a generic ethtool interface to enable/disable PD
<robimarko>
Yes, that is all part of the work
<robimarko>
Its meant to be a new subsystem
<robimarko>
Still early in development currently
floof58 has quit [Ping timeout: 480 seconds]
robimarko has quit [Remote host closed the connection]
<philipp64>
and if I don't want to throw the dice on reizefs.f2fs?
<KanjiMonster>
¯\_(ツ)_/¯
<dwfreed>
can always reformat the loop device to ext4 manually
<philipp64>
seems arbitrary.
<dwfreed>
but iirc that config setting you mentioned would do it too
<philipp64>
would that still be squashfs+ext4? Or would it be a purely ext4 root?
<philipp64>
looking at config/Config.in it's not obvious
<philipp64>
* Config-images.in
tidalf has quit [Ping timeout: 480 seconds]
tidalf has joined #openwrt-devel
<philipp64>
well, nothing stops me from enabling both...
CodingMarco has quit [Remote host closed the connection]
tidalf has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
<russell-->
hurricos: the newer engenius and zyxel gs1900-10hp appear to use the higher baud rate. i provided mrnuke some logic analyzer decodes in august 2022, and he gave me a patch that "kind of worked" (turned on PoE, but didn't provide status or a function control plane on power to individual ports)
<russell-->
(and fwiw it is still nuts to me that the vendors didn't hide the pse differences behind the stm32 microcontroller's firmware and presented a consistent interface to the SoC, but my boggling isn't particularly influential on the parties involved)
raenye has joined #openwrt-devel
hitech95 has quit [Read error: Connection reset by peer]
<iocampomx>
It's about booting OpenWRT on SDRAM via TFTP, but somehow the bootloader is expecting an uBoot + Kernel image that I don't know how to build (yet)