Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.01 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2024.04 is scheduled for 02 April 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
rvalue has quit [Ping timeout: 268 seconds]
experemental has joined #u-boot
rvalue has joined #u-boot
experemental has quit [Read error: error:0A000119:SSL routines::decryption failed or bad record mac]
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 246 seconds]
f_ has quit [Read error: Connection reset by peer]
f_ has joined #u-boot
qqq has quit [Remote host closed the connection]
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #u-boot
justache- is now known as justache
Clamor has joined #u-boot
Clamor has quit [Read error: Connection reset by peer]
Clamor has joined #u-boot
monstr has joined #u-boot
goliath has joined #u-boot
mckoan|away is now known as mckoan
frieder has joined #u-boot
Clamor has quit [Ping timeout: 246 seconds]
Clamor has joined #u-boot
mripard has quit [Quit: mripard]
mripard has joined #u-boot
ladis_ has quit [Quit: Leaving]
jmasson has joined #u-boot
sszy has joined #u-boot
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
xroumegue has quit [Ping timeout: 276 seconds]
xroumegue has joined #u-boot
ezulian has joined #u-boot
ikarso has joined #u-boot
experemental has joined #u-boot
<qschulz> i'm trying to debug some boopth-pre-ram vs bootph-all and I'm hitting a very odd bug
<qschulz> I want to print something in ofnode_pre_reloc only when it's checking for a specific DT path
<qschulz> but U-Boot just stalls whenever I access of_node.np->full_name
<qschulz> I checked that node.np is not NULL, and I do a check on full_name before printing it, but the check itself seems to break U-Boot
<qschulz> After TF-A goes back to U-Boot proper but before the U-Boot proper banner starts printing
<qschulz> (on RK3588 if that matters in any way, so external TPL + U-Boot SPL + downstream TF-A)
Hypfer0 has joined #u-boot
Hypfer has quit [Ping timeout: 260 seconds]
Hypfer0 is now known as Hypfer
experemental has quit [Remote host closed the connection]
sakman has joined #u-boot
Stat_headcrabed has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
dsimic has quit [Ping timeout: 256 seconds]
dsimic has joined #u-boot
Clamor has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
Clamor has joined #u-boot
pgreco_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
pgreco has joined #u-boot
Peng_Fan has quit [Quit: Connection closed for inactivity]
monstr has quit [Ping timeout: 252 seconds]
ezulian has quit [Quit: ezulian]
ezulian has joined #u-boot
ezulian has quit [Remote host closed the connection]
ezulian has joined #u-boot
monstr has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
slobodan has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
rfs613 has quit [Ping timeout: 252 seconds]
Stat_headcrabed has joined #u-boot
rfs613 has joined #u-boot
sakman has quit [Quit: sakman]
sakman has joined #u-boot
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #u-boot
<tlwoerner> qschulz: i don't know if this will help you, but this patch is what i needed to get networking running on the rock-pi-e
<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 &eth_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 &eth_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 &eth_phy_reset_pin>; or pinctrl-0 = <&rgmiim1_pins>, <&eth_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> rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
<qschulz> which configures gpio1_c2 as GPIO (with a pull-down)
<qschulz> RK_FUNC_GPIO is 0 as far as I remember
<qschulz> so if you want to mux this pin in something else, you need to use a different number
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<qschulz> and the number is the register value in the SoC documentation
<qschulz> which is never the same between two pins of the same SoC, hence why there's no constant for it
<qschulz> (aside from the gpio function which is almost always function 0)
<tlwoerner> in one of my projects i connect an spi-based adc to my board and enable it like this:
<tlwoerner> it works, but is it correct or would it also need a pinctrl-0 entry?
<qschulz> tlwoerner: mmmm really for rk3328? I don't see any spi2 controller on rk3328, only spi0
<qschulz> tlwoerner: but sometimes, and actually often on Rockchip SoCs, controllers are provided a default mux in the SoC DTSI
<tlwoerner> hahha!! i was just coming to that same issue myself lol
<tlwoerner> sorry, that patch is broken, it's for the rk3308 (rock-pi-s)
<qschulz> so if you use the exact same pins, then should be fine :)
<tlwoerner> rk3308.dtsi
ezulian has quit [Remote host closed the connection]
<tlwoerner> i see. in rk3308.dtsi, in the spi2 node, it specifies the pinctrl-0 already
<qschulz> so if you use the same pins in the same functions, then you're good
<qschulz> sometimes you may have to remove or add some though
<qschulz> when you want to add some, you need not forget to copy the current ones from the SoC DTSI over and "extend" pinctrl-0
<tlwoerner> wow, so wonderful. thanks for spending the time
<tlwoerner> i really appreciate it
goliath has quit [Quit: SIGSEGV]
<qschulz> tlwoerner: almost there
<qschulz> two changes:
<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
<qschulz> c.f. snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
<tlwoerner> right, my v2 patch to yocto added it to gmac2io
<tlwoerner> then you pointed out in 1/2 that i need to remove it from ethernet-phy
<tlwoerner> done
<tlwoerner> but i don't understand your 2/2 "and also the reset pins"
<qschulz> can you paste the current diff somewhere?
<qschulz> about to go soon, it'll help to see a diff :)
<qschulz> ah yes sorry
<qschulz> the reset *properties*
<tlwoerner> awesome, thanks!!
<qschulz> the ones in ethernet-phy
<qschulz> you already have them in gmac2io
<qschulz> well, named differently but for the same purpose
<tlwoerner> right. i mentioned that before that i did a test where i removed them from ethernet-phy, and that works just fine
<tlwoerner> but i left them in because that's where they were originally in the dts from the linux kernel
<tlwoerner> but i'll remove them from there and test it all in the kernel and u-boot
<tlwoerner> okay, sounds good thanks!
<qschulz> yup, the kernel will want them gone i'm pretty sure
<tlwoerner> perfect, thank you so much
<tlwoerner> got it
<qschulz> tlwoerner: pleasure, looking forward seeing those patches on the Linux ML :)
<tlwoerner> yea, lately i've been getting 1 or 2 in the last couple releases :-D
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
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]
slobodan has joined #u-boot
KREYREN has joined #u-boot
<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
<KREYREN> marex, Tartarus ^