10:48 <ziga_> Which U-boot setting sets the name of the DTB that is sent to the kernel? I set up my own DTS i.e "fotovolt.dts" in the u-boot-s folder "arch/arm/boot/dtb" and bitbake/yocto compiles it successfully to the DTB i.e. "fotovolt.dtb". But on boot U-boot keeps on looking for "am335x-boneblack.dtb" and it fails to boot unless I manually rename "fotovolt.dtb" to "am335x-boneblack.dtb"...

12:06 <agraf> ziga_: in your case, probably the findfdt function in your environment?

12:08 <agraf> ziga_: if you have an EEPROM on your BBB cape, you should be able to provide your own board name which you can then use to identify your own dtb file generically

12:09 <agraf> ziga_: Otherwise, just change your .config to set fdtfile manually as part of CONFIG_BOOTCOMMAND instead of calling findfdt

12:10 <ziga_> @agraf Hmmmmm I really don-t understand the first two replies, but the last one is interesting. I will try the last one.

12:11 <ziga_> Probablz I should configure this in my "fotovolt_defconfig" file?

12:11 <agraf> I would expect you already have a CONFIG_BOOTCOMMAND in there?

12:11 <agraf> I guess you copied the beaglebone one, no?

12:14 <ziga_> Yes. It is currently like this: "CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd""

12:15 <agraf> Ok, the "run findfdt" part in there is what sets the "fdtfile" environment variable to am335x-boneblack.dtb

12:15 <ziga_> Okay. I see it. So how do I change it to "fotovolt.dtb"?

12:16 <agraf> you replace "run findfdt" there with "setenv fdtfile fotovolt.fdt"

12:17 <ziga_> Ah okay! Thanks! So I actually switch from autosearch to manually setting it! Perfect solution!

12:17 <agraf> You're building a custom image anyway, no? :)

12:18 <agraf> If you want to keep it generic, you'd need to provide an EEPROM as part of your cape

12:18 <agraf> But you didn't sound like you care

12:18 <agraf> :)

12:18 <ziga_> Yes. It is custom for our racier board which we connect to the Beaglebone Black.

12:20 <ziga_> I actually did not understand the EEPROM thing.

12:20 <ziga_> :)

12:20 <agraf> ziga_: https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md :)

12:21 <ziga_> I will take a look thanks.

12:22 <agraf> ziga_: if you connect an EEPROM to I2C on your racier board, you can put a "device tree patch" into it and have it automatically customize the BBB dtb on boot

12:22 <agraf> ziga_: That can be super useful if you want to sell the customer board as stand alone item and your customers will use different variants of BB products, like BBW, BBB, BBBlue, etc.

12:23 <agraf> ziga_: If you bundle everything as a single appliance, I don't think the additional complexity is worth it :). Just override the dtb in CONFIG_BOOTCOMMAND and call it a day

12:25 <ziga_> Okay. I am just reading the link that you sent me and I partially understand. Thanks.

12:47 <ziga_> @agraf Replacing "run findfdt" with "setenv fdtfile fotovolt.dtb". Should I use "setenv fdtfile fotovolt.fdt"???

12:47 <agraf> ziga_: compiled device trees are usually called dtb

12:47 <ziga_> @agraf Ignore previous message - it is incomplete. Replacing "run findfdt" with "setenv fdtfile fotovolt.dtb" didnt resolve mz problem. Should I use "setenv fdtfile fotovolt.fdt"???

12:48 <agraf> ziga_: abort the boot process, run "printenv" on the u-boot shell

12:48 <agraf> ziga_: and look at where the name comes from :)

12:48 <ziga_> How can I modify the defconfig so that it will not autoboot but it will remain in the u-boot?

12:50 <agraf> it will usually give you a countdown of N seconds where you can press a key to drop into the shell. N is defined in CONFIG_BOOTDELAY. If you set N to -1, it will always drop into the shell

13:12 <ziga_> Okay

13:24 <coldspark29> Hi, does anyone have an idea why I am experiencing memory errors since upgrading from kernel 5.4 to 5.10? https://pastebin.com/h3cCdAqc

13:24 <coldspark29> It seems to me that the kernel numerates the storage devices differntly

13:32 <milkylainen> coldspark29: #u-boot?

13:47 <coldspark29> milkylainen: Sure it is U-Boot

13:48 <coldspark29> I am building the linux-fslc-imx Kernel, which is the NXP kernel with patches as far as I understand

13:48 <coldspark29> Before we were using linux-im 5.4 and everything was alright

16:05 <marex> rfried: hey, there is one thing I keep wondering about -- why do we have 'mii' and 'mdio' commands when they seem to be doing the same thing, just with different syntax ?

18:06 <rfried> marex: see 7d9701db40895ff5271220ae852d3631b4500219

18:07 <rfried> I also wondered this before, but there's a subtle difference.

18:48 <redbrain> is CONFIG_SYS_BOOTM_LEN some where globaly definded for arm64 boards?

18:51 <redbrain> for mx6_common.h mx7_common.h there are but can't find a mx8_common.h

18:54 <redbrain> for imx8/arm64 boards

19:06 <Forty-Bot> so mdio==c45 access?

21:34 <marex> rfried: hum, both of those could've been implemented in one command though

21:55 <rfried> Marex: indeed

21:57 <marex> rfried: how very much do we care about command ABI in this case /

21:57 <marex> ?

23:36 <rfried> marex: I don't care, ask Tartarus

23:36 <marex> rfried: arent you the network guru here ? :)

23:37 <rfried> marex: it's not a matter of networking, it's a legacy :)

23:37 <marex> maybe we need a switch "config DISABLE_LEGACY_CRAP_IT_IS_2022_ALREADY"