14:52 <piglit_> Hello I have got a noob question, does U-Boot have got a config file which I can edit to change boot order? If so what is the name of the file and can anyone link me to a quick guide? I want to change the boot order on a Odroid N2+ it had a petitboot which points to a U-Boot for so far as I can understand

14:53 <piglit_> Or is the configfile only editable before a compile ?

14:59 <mps> piglit_: example `boot_targets=mmc1 usb0 nvme0 mmc0 dhcp`

15:00 <mps> and then `saveenv -a`

15:00 <mps> if the board have flash to save ENV

15:11 <piglit_> mps: thanx and the commands you typed, do I need to type them in console or will there be a config file somewhere on the sd-card or eMMC ?

15:12 <mps> piglit_: break u-boot when it start and type this from console

15:13 <mps> `printenv boot_targets` will show you current one

15:14 <mps> if there no saveenv, setenv, printenv then you can use `env` with subcomands

15:17 <piglit_> thanx, env shows a lot of data in the console, this is when the OS, Ubuntu is running, but this shows the environment of Ubuntu and not of U-Boot is thios assumption correct ?

15:18 <piglit_> how do I "break" U-boot ?

15:20 <mps> look when machine reboots is there something on console which shows you how to break u-boot

15:21 <mps> for example 'Hit any key to stop autoboot:'

15:22 <piglit_> I first get petitboot I can enter settings there. When I leave Petitboot the screen does not show text untul Ubuntu shows itself

15:24 <mps> I don't have experience with petitboot

15:30 <piglit_> well as far as I understand Petitboot is small engough to fit in a 8MB SPI flash the Petitboot can be set to start U-Boot from /boot which is on a SD-card or eMMC

15:30 <piglit_> I will have another search on www

15:30 <piglit_> thanx for the help so far

16:21 <CounterPillow> It sounds like you're using some omegacursed vendor image that goes u-boot->petitboot->u-boot->ubuntu. You're best off asking them for support.

16:25 <yang> I am trying to guess the correct lines for 'bootcmd' , the first long line from the example boots that device, the second lines I am trying to guess for Teres https://paste.debian.net/plainh/19779369

16:26 <yang> When trying the first line "load mmc 0:1 0x12000000 vmlinuz-6.1.0-17-arm64" I get a reply *** reading file would overwrite reserved memory *** failed to load "vmlinuz-6.1.0-17-arm64"

16:26 <yang> I use self-compiled 2024.01

17:03 <yang2> https://usercontent.irccloud-cdn.com/file/j3dSKhvG/1705251782472.jpg

17:22 <xypron> yang: Please, use the bdinfo command to display the avaialble memory. U-Boot relocates itself to the top. A good load address is in the lower half of the memory. printenv shows preallocated addresses. Look for kernel_addr_r, ramdisk_addr_r, fdt_addr_r.

17:22 <yang> ok

17:23 <yang> first thing I am recompiling U-boot for zboot support

18:38 <tlwoerner> is the networking code for rockchip known to work?

18:39 <tlwoerner> specifically: on the rock-pi-e the mdio code is not able to successfully probe and find the realtek phy

18:41 <tlwoerner> when drivers/net/phy/phy.c calls get_phy_id()

18:41 <tlwoerner> which is resolved by drivers/net/designware.c:dw_mdio_read()

18:42 <tlwoerner> the result is always 0xffff

18:42 <tlwoerner> linux has no problem probing the phy via mdio

19:17 <yang2> https://usercontent.irccloud-cdn.com/file/ggpXbJwp/1705259836634.jpg

19:22 <yang> xypron: ^

19:24 <yang2> https://usercontent.irccloud-cdn.com/file/yygKXvwc/1705260253354.jpg

19:27 <xypron> yang2: for arm64 you have to use the booti command.

19:27 <xypron> yang ^

19:27 <yang> ok thanks

19:31 <yang> just black screen, I cannot really debug well, because I don't have a serial console cable. I will buy one, and continue at some other time

19:39 <xypron> yang: You can add parameters to the kernel command line via environment variable bootargs. Once you have serial console access you can use parameter earlycon to get early console output.

19:40 <yang> like "setenv bootargs earlycon console=ttymxc3,115200 root=/dev/sda2 ro rootwait ${video}" ?

19:44 <marex> tlwoerner: I did use rk3588 recently, but that has a PCIe ethernet MAC I think

20:23 <yang> I will continue when I get serial console, I cannot see past the u-boot screen, it's just a black screen then

20:55 <CounterPillow> marex: rk3588 has two native GMACs

20:55 <CounterPillow> you're thinking of your specific board, the rock5b, which uses a pcie 2.5g mac

20:56 <CounterPillow> Kwiboo as of a few months ago sent in (and I think got merged?) a series to enable networking on RK356x at least, and I tested that and it worked

22:47 <marex> CounterPillow: it was some fruitboard, yes

22:55 <Tartarus> marex: Have you seen Sumit's series to move us to using the devicetree-rebasing tree for dts files?

22:57 <marex> Tartarus: not in detail, but for rcar that would be fine, why ?

23:07 <Tartarus> would sticking with just major release tags long term be an issue?

23:07 <Tartarus> Since you picked 6.6.3

23:08 <marex> Tartarus: by major release tags you mean 6.6(.0) and 6.7(.0) etc ?

23:08 <Tartarus> Yes

23:08 <marex> Tartarus: that wouldn't be great, because fixes which land after that

23:09 <marex> Tartarus: esp. for LTS, those keep trickling in

23:09 <Tartarus> But we'd be syncing up each next window we have

23:09 <Tartarus> Would that still be an issue?

23:10 <marex> Tartarus: in the meantime, it could be

23:10 <marex> Tartarus: e.g. in case a fix lands before the next release

23:10 <marex> Tartarus: why stick only to major version anyway ?

23:11 <Tartarus> Before whose next release? We could probably cherry-pick some critical fixes if needed I suppose

23:12 <Tartarus> And would you rather v2024.04 for example be using v6.7.0 or v6.6.x ?

23:12 <Tartarus> I'm not sure I want the potential instability of picking up v6.7.x between now'ish and April

23:13 <marex> Tartarus: this close to LTS release, I might pick the latest LTS exactly for that purpose -- stability

23:13 <Tartarus> With v2024.07 being on v6.8 or v6.9 tag tho?

23:14 <marex> hmmm, good question, there I would almost say this is board/maintainer specific then ?

23:14 <marex> because one board/arch/... might benefit from latest DTs, the other might be more conservative ?

23:15 <Tartarus> Nope, devicetree-rebasing and OF_UPSTREAM are the same for everyone

23:17 <marex> then maybe this needs to be more flexible with some per-config setting which version to use ?

23:19 <Tartarus> I can't see how that would work

23:19 <Tartarus> I think you need to find some time to read the current cover letter, think and reply please

23:20 <Tartarus> (to be clearer, I don't see how you could implement what you suggest of per config version settings)

23:23 <marex> Tartarus: if the DTs were in external git tree, git worktree would be the tool of choice for me

23:23 <marex> Tartarus: if synced in, hum, not great