<tlwoerner>
in essence it was the 3 lines in the gmac2io section
<tlwoerner>
which, interestingly enough, are pretty much repeated again in the mdio section
<tlwoerner>
removing them from the mdio section (and leaving them in the gmac2io section) also works
prabhakarlad has quit [Ping timeout: 250 seconds]
<tlwoerner>
but they are in the mdio section in the kernel's dt, so i left them
<tlwoerner>
thanks qschulz and marex for the help!
<tlwoerner>
and CounterPillow too
<qschulz>
tlwoerner: mmmm so this was only a missing reset GPIO then?
<qschulz>
tlwoerner: I don't see a compatible for ethernet-phy node, is it just the generic compatible then?
<qschulz>
and it properly detects the PHY based on its ID?
<tlwoerner>
yes, and specifying that it's active-low, and its delays (leaving those out won't work, i tried)
<qschulz>
I would recommend to test this patch in the Linux kernel, without having it in U-Boot as well
<qschulz>
then send this to the Linux kernel if it works
<tlwoerner>
yes, the realtek driver checks the id and goes from there
<qschulz>
becasuse DTSes in U-Boot are supposed to be simply imported from the Linux kernel git repo
<qschulz>
and the U-boot specific thingies are in -u-boot.dtsi
<tlwoerner>
this patch, without any modifications to linux, allows both boards the work under linux as well
<tlwoerner>
but i understand that these things must go through linux first
<tlwoerner>
my next step is to test these changes in linux alone and see what happens
<qschulz>
it's also that Linux shouldn't depend on any bootloader to work
<qschulz>
(well, it needs a bootloader to boot, but not depend on what it does before it starts jumping into the kernel)
<tlwoerner>
eventually the linux folks will realize that the kernel shouldn't be in the device tree business at all, but maybe not in our lifetimes
<qschulz>
it's handled quite differently already, I see them as just being in the same git repo
<qschulz>
tlwoerner: mmmmmm
<qschulz>
the reset you have used, it's already in the ethernet-phy node
<tlwoerner>
yes, that's what i said above
<tlwoerner>
i can remove it from the ethernet-phy node and it still works
<tlwoerner>
but i left it in the ethernet-phy node because that's what the linux kernel already has
<tlwoerner>
both the reset and the delays are duplicated in the ethernet-phy node
<qschulz>
yeah but they won't want this :)
<tlwoerner>
exactly
<tlwoerner>
i tested it both ways, just for my own edification, but left it anyway
<qschulz>
also, you need to move ð_phy_reset_pin to the gmac now
<tlwoerner>
under pinctrl?
<qschulz>
add something to pinctrl-0 node yes
<qschulz>
without overriding the existing ones
<tlwoerner>
should there be a bindings doc for the gmac2io node? or is that covered under something more generic?
<qschulz>
Documentation/devicetree/bindings/net/snps,dwmac.yaml or Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
<qschulz>
don't know why it's in two different places
<qschulz>
tlwoerner: so you need to add ð_phy_reset_pin after &rgmiim1_pins in pinctrl-0 of gmac2io
<tlwoerner>
like it is in the ethernet-phy node?
<tlwoerner>
oops! the one in ethernet-phy has the eth_phy_int_pin, not the rgmiim1_pins
<tlwoerner>
okay, i can add that
<qschulz>
there are different schools when it comes to how to put things into pinctrl-0
<qschulz>
you could do either
<qschulz>
pinctrl-0 = <&rgmiim1_pins ð_phy_reset_pin>; or pinctrl-0 = <&rgmiim1_pins>, <ð_phy_reset_pin>;
<qschulz>
i tend to use the first one but there are occurences of both in the kernel... so :)
mmu_man has quit [Ping timeout: 256 seconds]
<tlwoerner>
i'll use the second since this specific file only has examples of the second
<tlwoerner>
out of curiosity, it works without this, so what does this do?
<qschulz>
in SoCs, you have a limited number of pins exposed
<qschulz>
the more you have exposed, the bigger the silicon, the more expensive it is
<qschulz>
but you have a big amount of IPs inside an SoC, and very likely users of that SoC only want a subset of those
manchaw has joined #u-boot
<qschulz>
this is where the compromise come (during the SoC design)
<tlwoerner>
right, each pin has like 6 functions
<qschulz>
yup
<qschulz>
so you need to configure this pin to be in a specific function
<qschulz>
this is called pinctrl
<qschulz>
you need the device that controls a pin to mux it in its proper function
<tlwoerner>
so a pinctrl-0 item in a node specifies which function?
<qschulz>
and you cannot have two devices request the same pin (through the pinctrl subsystem), even if it's the same function
<qschulz>
the default on Rockchip for most if not all pins is the GPIO function
<tlwoerner>
which is nice :-)
<qschulz>
furthermore, if U-Boot takes care of the pinctrl from the eth-phy (which is probable but not guaranteed)
<qschulz>
then U-Boot will mux it into GPIO function
<qschulz>
and since the kernel does nothing if it's not asked to, it'll not set another function for that pin
<qschulz>
which is bad (but everybody does assume that the bootloader doesn't change a pin into anything but a GPIO function if we need a GPIO function)
<qschulz>
so pinctrl-0 is the first array of pinctrl associated with the entry at index 0 in pinctrl-names
<qschulz>
which is usually "default"
<qschulz>
which is automatically handled by the pinctrl subsystem in the Linux kernel, you don't have to do anything special in any driver for those pinctrl to be proper before you probe the device
<qschulz>
how you define in which function to mux the pin is in the node pointed at by what you have inside pinctrl-0
<qschulz>
so here inside eth_phy_reset_pin we have
<qschulz>
remove eth_phy_reset_pin from pinctrl-0 of the ethernet-phy
<qschulz>
and also the reset pings
<qschulz>
pins*
<qschulz>
also, it states it's submitted but without a link :) And I cannot find it on https://lore.kernel.org/u-boot :)
<tlwoerner>
"will be submitted"? ;-)
<tlwoerner>
my plan was to submit to u-boot, who will bounce it and tell me in need to submit to the kernel, who will take a year or more to apply/release it
mripard has quit [Remote host closed the connection]
<qschulz>
tlwoerner: for something that trivial, it should go smoothly, but you may have missed the merge window for v6.8, so maybe for v6.9 indeed
<qschulz>
but you don't have to wait for it to be merged in v6.9 for backporting it into U-Boot
<qschulz>
if it's part of a next-2024 tag for example, that's acceptable
<qschulz>
also, for U-Boot, you can modify arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi and do the changes there
mmu_man has joined #u-boot
<qschulz>
mmmm.... maybe won't work actually
<qschulz>
I don't remember if -u-boot.dtsi is included at the top or end of the dts it is named after
prabhakarlad has joined #u-boot
<qschulz>
you may have to play with /delete-property/ and overwrite stuff from arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi to make this work
rvalue has quit [Ping timeout: 252 seconds]
jmasson has quit [Remote host closed the connection]
rvalue has joined #u-boot
goliath has joined #u-boot
mckoan is now known as mckoan|away
ladis has joined #u-boot
joeskb7 has joined #u-boot
<tlwoerner>
qschulz: i don't get the 2nd change, isn't eth_phy_reset_pin the reset pin? so how do i remove the reset pins from pinctrl-0 of ethernet-phy
<tlwoerner>
if i've already done step 1
<qschulz>
tlwoerner: it is the reset pin, but it is handled by the gmac2io now
<qschulz>
eth_phy_reset_pin configures gpio1c2 into gpio function
<qschulz>
but it's the gmac2io that actually controls the gpio now
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
ikarso has joined #u-boot
<dormito>
I am trying to setup secureboot on a lx2162a (specifically a solidrun clearfog carrier board), I want to override the environment, but when secureboot is enable it lookes like the env can only be built in (which seems sane). However when ever I set CONFIG_USE_DEFAULT_ENV_FILE (or CONFIG_ENV_SOURCE_FILE... though the diff isn't entirely clear to me) u-boot's board_init_f() end's up calling hang()
<dormito>
without printing anything out. Is there a different/correct way to override the builtin env?
monstr has quit [Remote host closed the connection]
<marex>
include/configs/<yourboard>.h has some EXTRA_ENV maybe ?
<marex>
CFG_EXTRA_ENV_SETTINGS
<dormito>
it does set CONFIG_EXTRA_ENV_SETTINGS
<dormito>
is overriding the builting env only possible via a change to that define?
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
alan_o has quit [Remote host closed the connection]
slobodan has quit [Read error: Connection reset by peer]
alan_o has joined #u-boot
slobodan has joined #u-boot
jfsimon has quit [Remote host closed the connection]
vagrantc has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
<marex>
dormito: depends on a board, but often that's where extra built in env is defined
<marex>
except for special vars
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
Clamor has quit [Ping timeout: 268 seconds]
Clamor has joined #u-boot
ladis has quit [Quit: Leaving]
stefanct has quit [Ping timeout: 245 seconds]
stefanct has joined #u-boot
goliath has quit [Quit: SIGSEGV]
frieder has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 264 seconds]
sakman has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
haritz has quit [Ping timeout: 260 seconds]
haritz has joined #u-boot
haritz has quit [Changing host]
haritz has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
<KREYREN>
ok so for context i am the community distro maintainer of OLIMEX Teres-I and i am trying to make a compatibility patches for alpine and postmarketos for the device.. For that i am trying to package u-boot with scp and BL31 but using the same packaging instructions (make teres_i_defconfig && make with SCP and BL31 exported as variables to same things) i get no display once booted in comparison using these same packaging instructions on any other mainstream
<KREYREN>
linux distro the u-boot works without any issue.. i am out of ideas, sunxi-linux is out of ideas, olimex is out of ideas, alpine and postmarket devs have no idea so i came here.. does anyone know what might be causing that? This is the u-boot for reference https://upload.disroot.org/r/toKvztLB#TDxvFpUlvD/L+wBt8w8FRds4UJhgv/HBseo0xZKues8=
<Tartarus>
KREYREN: What things have you ruled out already, ie using the same bl31/scp binaries in all cases? Which kernels do/don't give video?
<KREYREN>
i excluded the whole kernel by just having an sdcard with u-boot on it and the alpine package was crosscompiled in docker using nixos kernel
<marex>
Tartarus: are you sure they are asking about video in Linux and not video in U-Boot ?
<Tartarus>
marex: Good question, yes
<KREYREN>
the difference seem to be that alpine's at-f is using 'SUNXI_SETUP_REGULATORS=0 SUNXI_AMEND_DTB=1' but removing that changes nothing, they use busybox sh and musl but musl seems to work fine otherwise
<Tartarus>
KREYREN: Do you mean video once Linux is up, or video within Linux?
<KREYREN>
didn't try to use the same binaries for BL31 and SCP as that's impractical solution if it's a solution at all
<KREYREN>
Tartarus, video of the u-boot only it's made to not boot an OS for testing purposes
<Tartarus>
KREYREN: Right, but using the same BL31/SCP would rule out problems with those parts
<Tartarus>
Or point to the problem being with BL31/SCP
<Tartarus>
and not U-Boot
<KREYREN>
true, i try to do that bcs it's kinda hassle to package that within apkbuild
<KREYREN>
* i try to do that later
<Tartarus>
Yes, I would start by ruling out the problem being a difference in tf-a between those two and other distros
<marex>
you dont have to package anything, just assemble the combined stuff from multiple binaries
<Tartarus>
Like just drop in the BL31 and SCP that're used by something that does work
<KREYREN>
does it matter that it would be GCC-compiled on a non-busybox?
<KREYREN>
bcs i could take these from armbian in that case
<Tartarus>
It doesn't matter where you take the blobs from, so long as they're from an example where things are working
<marex>
no
<Tartarus>
Since the goal is to have one variable that changes, not 3
* KREYREN
is trying to figure out how to get them to alpine then
<marex>
KREYREN: you dont have to involve the distro or its packaging at all
<marex>
just assmeble the bootloader image from those components by hand
<KREYREN>
i can use SCP=/dev/null to avoid needing the SCP as it works fine without it
<KREYREN>
so just BL31.bin
<marex>
"fine" means including the graphics part ?
<KREYREN>
marex, yes the SCP just handles power management
<KREYREN>
some distros doesn't even provide it e.g. nixos
<marex>
ok
<KREYREN>
like there is a specific power UP sequence for the display for teres (and afaik other AllWinner A64 devices) https://i.imgur.com/j3QzbXT.png
<KREYREN>
but scp is not known to affect it
<KREYREN>
afaik it's low-end stuff for kernel in userland
<KREYREN>
i got BL31.bin and i guess you want me to try manual compilation right
<KREYREN>
cloning..
<KREYREN>
compiling..
ikarso has quit [Quit: Connection closed for inactivity]
<KREYREN>
BL31.bin grabbed from NixOS
<KREYREN>
without ccache it takes a really long time
<KREYREN>
~30 min on average
slobodan has quit [Ping timeout: 252 seconds]
<KREYREN>
same issue with manually compiled u-boot
<KREYREN>
and BL31.bin from nixos
sakman has joined #u-boot
<KREYREN>
loaded 2024.01 from armbian and everything works without issues
<KREYREN>
i guess it might be bcs of the musl then