≡
[00:03:41] <GNUtoo> On upstream Linux, the micrel phy is supposed to work on the Lime2: https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[00:04:01] <GNUtoo> "A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07). "
[00:04:44] <GNUtoo> However it doesn't work for one of the Parabola users that has a lime2 with that PHY
[00:05:38] <GNUtoo> While the bugreport is complicated to understand for me, if I understood right the user used a linux-libre 5.8.13-1
[00:05:45] <GNUtoo> sorry
[00:05:48] <GNUtoo> linux-libre-lts 5.4.85-1
[00:06:14] <GNUtoo> And working around in u-boot to add delays worked for that person
[00:06:41] <GNUtoo> Since it's possibly fixed upstream and that the person cannot really test (as she's hosting a website on the device) would it be possible to get that tested somehow
[00:07:09] <GNUtoo> I personally have a Lime2 with a RTL8211E, so I can easily test on that one
[00:07:17] <GNUtoo> But I don't have any of the other versions
[00:07:33] <GNUtoo> And it'd be great if we could support all versions with only 1 kernel and bootloader
[00:09:14] <GNUtoo> The bugreport we got is here: https://labs.parabola.nu/issues/2945
[00:09:24] <jo0nas> GNUtoo: as I understand it (still haven't found a bulletproof setup myself yet - and I wrote those lines at the linux-sunxi wiki), what *might* be the one solution to cover all revisions is to change "rgmii" to "rgmii-id" in device-tree for both linux and u-boot
[00:09:48] <GNUtoo> I also asked a bit in u-boot but I didn't find a good solution yet
[00:10:00] <GNUtoo> My idea was to detect the PHY id in the uboot env
[00:10:06] <GNUtoo> and then patch the dts according to that
[00:10:16] <jo0nas> when did you ask in uboot? just now?
[00:10:22] <jo0nas> ACTION goes look at backlog
[00:10:29] <GNUtoo> and I'd add the delays properties like rxc-skew-ps/txc-skew-ps
[00:10:30] <GNUtoo> yes
[00:11:56] <jo0nas> what I would do first is switch ti rgmii-id and then test if that in itself (i.e. with other workarounds and hacks removed!) make all 3 board types work well
[00:12:43] <jo0nas> ...and only afterwards try if things *not* working in such setup is helped by messing with *-skew-ps
[00:13:44] <jo0nas> ...and only if such skew teeaks are indeed necessary, and necessary *differently* for different board revisions, look into ways to detect revision
[00:32:58] <GNUtoo> wow nice
[00:33:09] <GNUtoo> Will you send that upstream in Linux?
[00:33:31] <GNUtoo> Now I understood what was rgmii-id thanks to some dts documentation file
[00:33:46] <GNUtoo> one has "rgmii-id" (Internal Delay)
[00:40:34] <GNUtoo> jo0nas: did you test that with the stock u-boot configs as well?
[00:41:30] <GNUtoo> like keep A20-OLinuXino-Lime2_defconfig and A20-OLinuXino-Lime2-eMMC_defconfig as-is and change the phy-mode to rgmii-id
[00:43:40] <GNUtoo> ACTION can try stuff but only has the RTL8211E
[00:46:42] <GNUtoo> The issue is that if the CONFIG_GMAC_*_DELAY are not overwritten/ignore by the hardware once Linux has booted, we'd have to handle the migration somehow
[00:47:33] <GNUtoo> like and old u-boot with new Linux would break things and vice versa
[00:49:08] <GNUtoo> ACTION will go to sleep soon
[00:55:05] <jo0nas> no I have not pushed anything to mainline linux, because have nothing well tested across all three board types
[00:56:01] <jo0nas> yes, the trouble is that change must be done *both* in u-boot and kernel - otherwise each apply corrections at different places!
[00:57:50] <jo0nas> ok, so you have a 2nd generation board
[01:00:55] <jo0nas> as I try document in the sunxi wiki, there are many attempts at making it work, but possibly there really is only 1 or 2 issues: One issue is (probably) that calibration must be done at PHY (not at NIC), and the other possible issue is that 1st generation boards still need to force master mode because of an independent hardware bug specific to older RTL PHY used in those boards
[01:03:43] <jo0nas> (and then _historically_ the 3nd generation board failed when u-boot and/or linux was compiled without support for Micrel chip and then silently loaded an old crap fallback driver)
[01:04:53] <jo0nas> GNUtoo: if you have a 2nd generation board yourself but a customer/user has a 3rd generation board, then you cannot test which solution will work for your customer/user!
[01:07:16] <jo0nas> ...and when you talk about some "LTS kernel" then you *maybe* also need to watch out for legacy issues like the lack of Micrel driver and old voodoo applied which needs to get unapplied - in addition to whatever is the sane modern fix which must be applied to *both* u-boot and kernel
[01:14:08] <GNUtoo> oh I didn't know htat "calibration must be done at PHY"
[01:14:22] <GNUtoo> PHY do link training nowadays?
[01:15:21] <jo0nas> no
[01:15:25] <GNUtoo> which generation do you have?
[01:15:27] <GNUtoo> ok
[01:15:34] <jo0nas> calibration must be done at one place
[01:15:38] <jo0nas> or
[01:15:43] <jo0nas> calibration must be correct
[01:16:04] <GNUtoo> ACTION always though that calibration was only done at the MII controller level
[01:16:30] <GNUtoo> ACTION is learning new things
[01:16:37] <jo0nas> calibration is possible to do in the wire, or in the NIC, or in the PHY
[01:17:07] <GNUtoo> ok
[01:18:03] <GNUtoo> You have the third generation?
[01:18:12] <jo0nas> if Olimex did it in the wire, then whatever wrong double-work done in u-boot and/or linux and done at NIC and/or PHY should probably result in similar failure for all three generation boards
[01:19:30] <jo0nas> tests have shown that boards behave differently, with same u-boot and same linux - which leads me to the conclusion that calibration is *not* done in wiring, and it is *wrong* to do it in NIC because NIC does not change across these the generations, PHY *does* change
[01:19:56] <GNUtoo> ok
[01:19:56] <jo0nas> all this, in a single snetence, is "calibration must be done in PHY"
[01:20:08] <jo0nas> not "spec says that..." no no no
[01:20:47] <GNUtoo> I was assuming that the traces length were different somehow across all 3 PHYs
[01:21:12] <GNUtoo> but indeed it makes more sense the way you describe it
[01:21:26] <GNUtoo> Especially if the chip has the same formfactor
[01:21:30] <GNUtoo> (which I didn't verify)
[01:21:32] <jo0nas> linux cannot tweak at NIC side (as far as I am aware) for sunxi A64 chip - today tweaks are done in u-boot which then persist when handed over to linux
[01:21:36] <GNUtoo> s/formfactor/package/
[01:23:03] <jo0nas> linux can tweak at PHY side - and that is enabled by editing device-tree file from "rgmii" to "rgmii-id"
[01:24:46] <jo0nas> ...but if *only* doing that change, then hell breaks loose: u-boot tells A64 SoC to apply tweaks at NIC side, then hands over to linux, and linux applies tweaks at PHY side - that can only go horrbily wrong (or lead to wasted effort experimenting until finding the _negative_ tweaks to cancel out the NIC tweaking _and_ the actual tweak)
[01:25:38] <GNUtoo> indeed, after you told me about rgmii-id I added looking at what it does in the code in my TODO list
[01:25:53] <GNUtoo> I hoped it could somehow un-do what u-boot did when selected
[01:26:03] <jo0nas> shorter version: first unapply all tweaks, then move to rgmii-id for both u-boot and linux, and only *if* that alone is not enough look into tweaking further
[01:26:46] <jo0nas> ...and I say "further" because PHY drivers have different default corrections
[01:26:50] <GNUtoo> most importantly we need to find people to test, I assume you've the 3rd revision
[01:27:07] <jo0nas> I have all three generations - but lack time
[01:27:13] <GNUtoo> oh ok
[01:27:17] <jo0nas> :-)
[01:27:35] <jo0nas> or, I have all the time in the World, but also want to do all in the World
[01:27:39] <GNUtoo> ACTION needs to find boards or people with the time
[01:27:40] <GNUtoo> indeed
[01:27:52] <jo0nas> Debian has a freeze soon
[01:27:59] <jo0nas> I maintain 600 packages in Debian
[01:28:25] <jo0nas> ...and I want to try squeeze in some exciting new packages as well, last minute
[01:28:32] <GNUtoo> oh ok
[01:28:42] <GNUtoo> ACTION should check about that too
[01:28:47] <jo0nas> about what?
[01:28:53] <jo0nas> packages in Debian?
[01:29:13] <GNUtoo> yes, last oldstable has stuff for f-droid that went away in stable
[01:29:32] <hacktivista> jonas: IDK how specific is... but I know sometimes the process with a Pi is not the same as with other boards... and I would like to know if somebody has ever used olimex boards for flashing successfully so I can avoid the risk and the time :B
[01:29:53] <GNUtoo> "Pi?"
[01:30:02] <jo0nas> GNUtoo: huh? I haven't missed f-droid in Debian
[01:30:04] <GNUtoo> Raspberry PI?
[01:30:19] <hacktivista> there are reports of flashing libreboot with beagleboard for instance
[01:30:28] <hacktivista> yes, raspberry PI
[01:30:29] <GNUtoo> Ah for flashrom
[01:30:38] <GNUtoo> Beaglebone black work fine
[01:30:49] <GNUtoo> Personally I use microcontroller based flashers
[01:31:01] <GNUtoo> like Arduinos reconfigured to run at 3.3v
[01:31:06] <jo0nas> GNUtoo: you mean this?: https://tracker.debian.org/pkg/fdroidcl
[01:31:44] <GNUtoo> probably
[01:32:01] <jo0nas> as that page indicates, that package is in Debian stable
[01:32:05] <GNUtoo> Basically Debian had the Android SDK and enough to build f-droid packages
[01:32:19] <hacktivista> GNUtoo: yes... I think I'll go with Beaglebone black to be on the safe harbor
[01:32:44] <GNUtoo> The isuse with SBCs is that it's not simple anyway, you need to reconfigure pins and so on
[01:32:54] <GNUtoo> So I'm unsure stock OS works with the beagleboneblack either
[01:33:04] <GNUtoo> They use some image named screwdriver
[01:33:21] <GNUtoo> One day I'd like to package the software that the Raspberry PI uses to patch the dts at runtime
[01:33:31] <GNUtoo> this way you remove a big part of the setup
[01:34:10] <jo0nas> patching dts at runtime sounds like the trick Armbian does
[01:35:02] <GNUtoo> And if distros ship dtbo
[01:35:07] <GNUtoo> then it'd be very very simple
[01:35:11] <jo0nas> as I understand it, that is not a task of packaging some software, but a task of shifting further away from how mainline linux works
[01:35:43] <GNUtoo> If I understood well the functionality is upstream but I might understood it wrong
[01:35:58] <GNUtoo> Basically you already have stuff like cape manager
[01:36:13] <GNUtoo> but as I understand userspace can also supply a dtbo
[01:36:22] <jo0nas> important detail is defining "you" in that sentence
[01:37:04] <jo0nas> "you" can run off forking like hell as Armbian does it, or be more conservative like Debian does it - those are different "you"s
[01:37:08] <GNUtoo> AFAIK cape manager is upstream
[01:37:23] <jo0nas> ok
[01:37:28] <GNUtoo> Capes typically have a dtbo in an i2c memory
[01:37:47] <GNUtoo> And as I understand but I'm not 100% sure that is also available to userspace without that i2c chip
[01:38:03] <GNUtoo> But you probably need to package the software that the raspberry PI uses to do that
[01:38:11] <GNUtoo> like the userspace software
[01:40:33] <GNUtoo> "dtoverlay is a command line utility that loads and removes overlays while the system is running, as well as listing the available overlays and displaying their help information:"
[01:40:37] <GNUtoo> https://www.raspberrypi.org/documentation/configuration/device-tree.md
[01:44:24] <GNUtoo> I'll tr to find the rest of the drivers
[01:51:41] <GNUtoo> hmmm
[01:51:42] <GNUtoo> https://elinux.org/Capemgr#Implementation
[01:51:54] <GNUtoo> They talk about patches on top of 4.1 there
[01:54:31] <GNUtoo> ACTION assumed that it was upstream but it looks that it's ont
[01:54:33] <GNUtoo> *it's not
[01:56:44] <GNUtoo> ACTION need to check in more details
[02:15:17] <GNUtoo> Ah I found where my confusion came from
[02:15:38] <GNUtoo> In Parabola we had the functionality because it came from an archlinux patch
[02:15:50] <GNUtoo> It added /sys/devices/platform/bone_capemgr/
[02:17:01] <GNUtoo> I've looked for capemgr in Linux and there is nothing
[02:17:36] <GNUtoo> The person who worked on all that is Pantelis Antoniou and has patches inside Linux for dynamic devicetree but I'm unsure if it's in some way exported to userspace
[02:17:39] <GNUtoo> sorry for the confusion
[02:17:41] <GNUtoo> ACTION bbl
[02:19:21] <GNUtoo> ACTION should be more careful and check which patch the distro he has uses
[12:58:03] <Tsvetan> Happy New Year!
[15:51:40] <braunr> happy new year :)
[16:32:35] <jo0nas> GNUtoo, Tsvetan and others: I improved the wiki text at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks and hope it is more clear now what I think needs further testing and why I think my "idea 2" is more likely to be adoptable by mainline u-boot and linux
[16:33:20] <jo0nas> more likely than trying to carry over the board revision probing as currently done in the Olimex fork of u-boot, I mean
[18:20:45] <Tsvetan> jo0nas: thanks! much appreciated
[20:57:54] <GNUtoo> jo0nas: thanks a lot
IRC #olimex 2021-01-04
[00:02:50] <GNUtoo> hi,[00:03:41] <GNUtoo> On upstream Linux, the micrel phy is supposed to work on the Lime2: https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[00:04:01] <GNUtoo> "A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07). "
[00:04:44] <GNUtoo> However it doesn't work for one of the Parabola users that has a lime2 with that PHY
[00:05:38] <GNUtoo> While the bugreport is complicated to understand for me, if I understood right the user used a linux-libre 5.8.13-1
[00:05:45] <GNUtoo> sorry
[00:05:48] <GNUtoo> linux-libre-lts 5.4.85-1
[00:06:14] <GNUtoo> And working around in u-boot to add delays worked for that person
[00:06:41] <GNUtoo> Since it's possibly fixed upstream and that the person cannot really test (as she's hosting a website on the device) would it be possible to get that tested somehow
[00:07:09] <GNUtoo> I personally have a Lime2 with a RTL8211E, so I can easily test on that one
[00:07:17] <GNUtoo> But I don't have any of the other versions
[00:07:33] <GNUtoo> And it'd be great if we could support all versions with only 1 kernel and bootloader
[00:09:14] <GNUtoo> The bugreport we got is here: https://labs.parabola.nu/issues/2945
[00:09:24] <jo0nas> GNUtoo: as I understand it (still haven't found a bulletproof setup myself yet - and I wrote those lines at the linux-sunxi wiki), what *might* be the one solution to cover all revisions is to change "rgmii" to "rgmii-id" in device-tree for both linux and u-boot
[00:09:48] <GNUtoo> I also asked a bit in u-boot but I didn't find a good solution yet
[00:10:00] <GNUtoo> My idea was to detect the PHY id in the uboot env
[00:10:06] <GNUtoo> and then patch the dts according to that
[00:10:16] <jo0nas> when did you ask in uboot? just now?
[00:10:22] <jo0nas> ACTION goes look at backlog
[00:10:29] <GNUtoo> and I'd add the delays properties like rxc-skew-ps/txc-skew-ps
[00:10:30] <GNUtoo> yes
[00:11:56] <jo0nas> what I would do first is switch ti rgmii-id and then test if that in itself (i.e. with other workarounds and hacks removed!) make all 3 board types work well
[00:12:43] <jo0nas> ...and only afterwards try if things *not* working in such setup is helped by messing with *-skew-ps
[00:13:44] <jo0nas> ...and only if such skew teeaks are indeed necessary, and necessary *differently* for different board revisions, look into ways to detect revision
[00:32:58] <GNUtoo> wow nice
[00:33:09] <GNUtoo> Will you send that upstream in Linux?
[00:33:31] <GNUtoo> Now I understood what was rgmii-id thanks to some dts documentation file
[00:33:46] <GNUtoo> one has "rgmii-id" (Internal Delay)
[00:40:34] <GNUtoo> jo0nas: did you test that with the stock u-boot configs as well?
[00:41:30] <GNUtoo> like keep A20-OLinuXino-Lime2_defconfig and A20-OLinuXino-Lime2-eMMC_defconfig as-is and change the phy-mode to rgmii-id
[00:43:40] <GNUtoo> ACTION can try stuff but only has the RTL8211E
[00:46:42] <GNUtoo> The issue is that if the CONFIG_GMAC_*_DELAY are not overwritten/ignore by the hardware once Linux has booted, we'd have to handle the migration somehow
[00:47:33] <GNUtoo> like and old u-boot with new Linux would break things and vice versa
[00:49:08] <GNUtoo> ACTION will go to sleep soon
[00:55:05] <jo0nas> no I have not pushed anything to mainline linux, because have nothing well tested across all three board types
[00:56:01] <jo0nas> yes, the trouble is that change must be done *both* in u-boot and kernel - otherwise each apply corrections at different places!
[00:57:50] <jo0nas> ok, so you have a 2nd generation board
[01:00:55] <jo0nas> as I try document in the sunxi wiki, there are many attempts at making it work, but possibly there really is only 1 or 2 issues: One issue is (probably) that calibration must be done at PHY (not at NIC), and the other possible issue is that 1st generation boards still need to force master mode because of an independent hardware bug specific to older RTL PHY used in those boards
[01:03:43] <jo0nas> (and then _historically_ the 3nd generation board failed when u-boot and/or linux was compiled without support for Micrel chip and then silently loaded an old crap fallback driver)
[01:04:53] <jo0nas> GNUtoo: if you have a 2nd generation board yourself but a customer/user has a 3rd generation board, then you cannot test which solution will work for your customer/user!
[01:07:16] <jo0nas> ...and when you talk about some "LTS kernel" then you *maybe* also need to watch out for legacy issues like the lack of Micrel driver and old voodoo applied which needs to get unapplied - in addition to whatever is the sane modern fix which must be applied to *both* u-boot and kernel
[01:14:08] <GNUtoo> oh I didn't know htat "calibration must be done at PHY"
[01:14:22] <GNUtoo> PHY do link training nowadays?
[01:15:21] <jo0nas> no
[01:15:25] <GNUtoo> which generation do you have?
[01:15:27] <GNUtoo> ok
[01:15:34] <jo0nas> calibration must be done at one place
[01:15:38] <jo0nas> or
[01:15:43] <jo0nas> calibration must be correct
[01:16:04] <GNUtoo> ACTION always though that calibration was only done at the MII controller level
[01:16:30] <GNUtoo> ACTION is learning new things
[01:16:37] <jo0nas> calibration is possible to do in the wire, or in the NIC, or in the PHY
[01:17:07] <GNUtoo> ok
[01:18:03] <GNUtoo> You have the third generation?
[01:18:12] <jo0nas> if Olimex did it in the wire, then whatever wrong double-work done in u-boot and/or linux and done at NIC and/or PHY should probably result in similar failure for all three generation boards
[01:19:30] <jo0nas> tests have shown that boards behave differently, with same u-boot and same linux - which leads me to the conclusion that calibration is *not* done in wiring, and it is *wrong* to do it in NIC because NIC does not change across these the generations, PHY *does* change
[01:19:56] <GNUtoo> ok
[01:19:56] <jo0nas> all this, in a single snetence, is "calibration must be done in PHY"
[01:20:08] <jo0nas> not "spec says that..." no no no
[01:20:47] <GNUtoo> I was assuming that the traces length were different somehow across all 3 PHYs
[01:21:12] <GNUtoo> but indeed it makes more sense the way you describe it
[01:21:26] <GNUtoo> Especially if the chip has the same formfactor
[01:21:30] <GNUtoo> (which I didn't verify)
[01:21:32] <jo0nas> linux cannot tweak at NIC side (as far as I am aware) for sunxi A64 chip - today tweaks are done in u-boot which then persist when handed over to linux
[01:21:36] <GNUtoo> s/formfactor/package/
[01:23:03] <jo0nas> linux can tweak at PHY side - and that is enabled by editing device-tree file from "rgmii" to "rgmii-id"
[01:24:46] <jo0nas> ...but if *only* doing that change, then hell breaks loose: u-boot tells A64 SoC to apply tweaks at NIC side, then hands over to linux, and linux applies tweaks at PHY side - that can only go horrbily wrong (or lead to wasted effort experimenting until finding the _negative_ tweaks to cancel out the NIC tweaking _and_ the actual tweak)
[01:25:38] <GNUtoo> indeed, after you told me about rgmii-id I added looking at what it does in the code in my TODO list
[01:25:53] <GNUtoo> I hoped it could somehow un-do what u-boot did when selected
[01:26:03] <jo0nas> shorter version: first unapply all tweaks, then move to rgmii-id for both u-boot and linux, and only *if* that alone is not enough look into tweaking further
[01:26:46] <jo0nas> ...and I say "further" because PHY drivers have different default corrections
[01:26:50] <GNUtoo> most importantly we need to find people to test, I assume you've the 3rd revision
[01:27:07] <jo0nas> I have all three generations - but lack time
[01:27:13] <GNUtoo> oh ok
[01:27:17] <jo0nas> :-)
[01:27:35] <jo0nas> or, I have all the time in the World, but also want to do all in the World
[01:27:39] <GNUtoo> ACTION needs to find boards or people with the time
[01:27:40] <GNUtoo> indeed
[01:27:52] <jo0nas> Debian has a freeze soon
[01:27:59] <jo0nas> I maintain 600 packages in Debian
[01:28:25] <jo0nas> ...and I want to try squeeze in some exciting new packages as well, last minute
[01:28:32] <GNUtoo> oh ok
[01:28:42] <GNUtoo> ACTION should check about that too
[01:28:47] <jo0nas> about what?
[01:28:53] <jo0nas> packages in Debian?
[01:29:13] <GNUtoo> yes, last oldstable has stuff for f-droid that went away in stable
[01:29:32] <hacktivista> jonas: IDK how specific is... but I know sometimes the process with a Pi is not the same as with other boards... and I would like to know if somebody has ever used olimex boards for flashing successfully so I can avoid the risk and the time :B
[01:29:53] <GNUtoo> "Pi?"
[01:30:02] <jo0nas> GNUtoo: huh? I haven't missed f-droid in Debian
[01:30:04] <GNUtoo> Raspberry PI?
[01:30:19] <hacktivista> there are reports of flashing libreboot with beagleboard for instance
[01:30:28] <hacktivista> yes, raspberry PI
[01:30:29] <GNUtoo> Ah for flashrom
[01:30:38] <GNUtoo> Beaglebone black work fine
[01:30:49] <GNUtoo> Personally I use microcontroller based flashers
[01:31:01] <GNUtoo> like Arduinos reconfigured to run at 3.3v
[01:31:06] <jo0nas> GNUtoo: you mean this?: https://tracker.debian.org/pkg/fdroidcl
[01:31:44] <GNUtoo> probably
[01:32:01] <jo0nas> as that page indicates, that package is in Debian stable
[01:32:05] <GNUtoo> Basically Debian had the Android SDK and enough to build f-droid packages
[01:32:19] <hacktivista> GNUtoo: yes... I think I'll go with Beaglebone black to be on the safe harbor
[01:32:44] <GNUtoo> The isuse with SBCs is that it's not simple anyway, you need to reconfigure pins and so on
[01:32:54] <GNUtoo> So I'm unsure stock OS works with the beagleboneblack either
[01:33:04] <GNUtoo> They use some image named screwdriver
[01:33:21] <GNUtoo> One day I'd like to package the software that the Raspberry PI uses to patch the dts at runtime
[01:33:31] <GNUtoo> this way you remove a big part of the setup
[01:34:10] <jo0nas> patching dts at runtime sounds like the trick Armbian does
[01:35:02] <GNUtoo> And if distros ship dtbo
[01:35:07] <GNUtoo> then it'd be very very simple
[01:35:11] <jo0nas> as I understand it, that is not a task of packaging some software, but a task of shifting further away from how mainline linux works
[01:35:43] <GNUtoo> If I understood well the functionality is upstream but I might understood it wrong
[01:35:58] <GNUtoo> Basically you already have stuff like cape manager
[01:36:13] <GNUtoo> but as I understand userspace can also supply a dtbo
[01:36:22] <jo0nas> important detail is defining "you" in that sentence
[01:37:04] <jo0nas> "you" can run off forking like hell as Armbian does it, or be more conservative like Debian does it - those are different "you"s
[01:37:08] <GNUtoo> AFAIK cape manager is upstream
[01:37:23] <jo0nas> ok
[01:37:28] <GNUtoo> Capes typically have a dtbo in an i2c memory
[01:37:47] <GNUtoo> And as I understand but I'm not 100% sure that is also available to userspace without that i2c chip
[01:38:03] <GNUtoo> But you probably need to package the software that the raspberry PI uses to do that
[01:38:11] <GNUtoo> like the userspace software
[01:40:33] <GNUtoo> "dtoverlay is a command line utility that loads and removes overlays while the system is running, as well as listing the available overlays and displaying their help information:"
[01:40:37] <GNUtoo> https://www.raspberrypi.org/documentation/configuration/device-tree.md
[01:44:24] <GNUtoo> I'll tr to find the rest of the drivers
[01:51:41] <GNUtoo> hmmm
[01:51:42] <GNUtoo> https://elinux.org/Capemgr#Implementation
[01:51:54] <GNUtoo> They talk about patches on top of 4.1 there
[01:54:31] <GNUtoo> ACTION assumed that it was upstream but it looks that it's ont
[01:54:33] <GNUtoo> *it's not
[01:56:44] <GNUtoo> ACTION need to check in more details
[02:15:17] <GNUtoo> Ah I found where my confusion came from
[02:15:38] <GNUtoo> In Parabola we had the functionality because it came from an archlinux patch
[02:15:50] <GNUtoo> It added /sys/devices/platform/bone_capemgr/
[02:17:01] <GNUtoo> I've looked for capemgr in Linux and there is nothing
[02:17:36] <GNUtoo> The person who worked on all that is Pantelis Antoniou and has patches inside Linux for dynamic devicetree but I'm unsure if it's in some way exported to userspace
[02:17:39] <GNUtoo> sorry for the confusion
[02:17:41] <GNUtoo> ACTION bbl
[02:19:21] <GNUtoo> ACTION should be more careful and check which patch the distro he has uses
[12:58:03] <Tsvetan> Happy New Year!
[15:51:40] <braunr> happy new year :)
[16:32:35] <jo0nas> GNUtoo, Tsvetan and others: I improved the wiki text at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks and hope it is more clear now what I think needs further testing and why I think my "idea 2" is more likely to be adoptable by mainline u-boot and linux
[16:33:20] <jo0nas> more likely than trying to carry over the board revision probing as currently done in the Olimex fork of u-boot, I mean
[18:20:45] <Tsvetan> jo0nas: thanks! much appreciated
[20:57:54] <GNUtoo> jo0nas: thanks a lot
