01:05 <ac_slater> hey all. Is there a general place to learn how u-boot deals with devicetree at build time? I use a zynq device (zedboard) and see default ps7_init files and devicetrees for the boards. I can trace the zynq files to see how it loads it but I was curious if there was a doc for this

01:05 <ac_slater> thanks

09:22 <Duality> hey all

09:23 <Duality> is it possible to print all i2c transactions for debugging

09:24 <Duality> I am running an am335x board and it looks like UBoot doesn't setup my PMIC correctly on a power cycle the defaults for the PMIC are used but when a reboot is applied it keeps the value that linux had set it too.

09:24 <Duality> So I want to verify what uboot is actually sending to my PMIC

09:24 <Duality> and if it is actually like setting anything

09:32 <crb> what does PMIC stand for?

10:20 <frieder> crb: https://en.wikipedia.org/wiki/Power_management_integrated_circuit

10:21 <crb> frieder, thanks that's what I thought

10:22 <Duality> tried enabling some debug options but now uboot is complaining that the spl won't fit in region .sram and is overflowing but I don't specifically want to compile the spl right now only the main uboot program

10:23 <Duality> ah yea nvm i disabled compiling the spl in my defconfig :)

10:24 <marex> Duality: add printf() into the i2c driver ?

10:26 <Duality> yep the PMIC does the power management for the board it's controlled through i2c and the issue I seem to be having is that at a power on boot it is using the defaults and works but a reboot of linux puts some low voltage setting in the PMIC and uboot doesn't seem to over rule these though if I read the code it should set it to a perticular value but isn't.

10:27 <Duality> marex: I thought maybe there was a debug config that enabled that but if i have to do it by hand i'll do that

10:27 <marex> maybe there is, but then rolling your own print also takes like a minute

10:28 <marex> if there is one, it is in the omap i2c driver too ;-)

10:31 <Duality> maybe it takes more time to setup this time (since it's the first time I am doing it) but the next time I'll know how to and it'll be quicker Plus I might learn a thing or two along the way :)

10:31 <Duality> but sometimes doing the simple thing is the best solution

10:33 <marex> It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away. -- Antoine de Saint Exupéry

10:41 <milkylainen> old mbr partition question. Does the extended mbr partition occupy any physical sectors? I have a creation tool that has created a disk image with a partition table. But the next partition in the extended one is sector + 1. I didn't think the extended partition physically occupied any space?

12:47 <Duality> i seem to have found the trouble

12:48 <Duality> the pmic function "scale_vcores" is never called that function eventually sets my PMIC up. but not sure how to fix

13:09 <marex> isnt it called from board/ti/am335x/board.c ?

14:00 <hthiery> hi .. has anyone an idea whythe mii command shows: PHY 0x00: OUI = 0x1374, Model = 0x07, Rev = 0x04, 1000baseX, FDX, although it is a copper connection? it is an atheros phy

14:01 <marex> is the OUI (PHY register 0x2 or 0x3, see datasheet) even correct ?

14:02 <marex> if not, maybe your MDIO does not work

14:05 <hthiery> yes that is not the problem

14:09 <mwalle> hthiery: https://elixir.bootlin.com/linux/v5.17-rc5/source/drivers/net/phy/at803x.c#L836

14:09 <mwalle> marex: ^

14:20 <hthiery> mwalle: does that mean in u-boot this will be displayed wrongly? we would also have to clear this flag to make sure it is diplayes correctly?

22:12 <mwalle> marex: there is at least code in the phy uclass to handle the gpio-reset property, do you have the CONFIG_DM_ETH_PHY enabled?

22:42 <marex> mwalle: what ? where ?

23:44 <sjg1> kettenis: Yes it seems a patch was lost, or something? In any case the upstream version is slightly different, so it needs to be redone