10:50 <littlebobeep> Hi all, I am curious about having a menu TUI screen that allows me to choose between physical boot media such as USB Flash drive, internatl eMMC, a microSDXC card, and an NVMe SSD, I would like to store U-Boot in NOR SPI Flash and have a menu detecting these other devices, but I wanted to confirm that U-Boot might not provide this at present.

10:50 <littlebobeep> Should I use Tow-Boot?

10:52 <mps> littlebobeep: I'm trying to use grub with u-boot efi on my arm boxes for this reason

10:53 <mps> managed to get this on some of them already

11:08 <littlebobeep> I think GRUB does not have display or keyboard support on my platform yet, but I can't check because I do not have the hardware. what arm boxes do you have where GRUB works?

11:08 <littlebobeep> mps: ^

11:11 <j`ey> littlebobeep: GRUb uses EFI protocools provided by uboot

11:11 <j`ey> for keyboard/display

11:13 <littlebobeep> Oh interesting I did not know uboot had anything to do with EFI

11:14 <mps> littlebobeep: I have it on rk3399 gru-kevin, apple m1 macbook and olimex teres-i notebook

11:15 <mps> also will try on exynos5000 peach pi chromebook in next days, if I find some free time

11:17 <littlebobeep> mps: What bootloader does M1 macbook ship with?

11:17 <j`ey> littlebobeep: iBoot

11:18 <j`ey> its proprietary, but it can be used to load u-boot

11:19 <littlebobeep> I see you cannot delete it

11:19 <j`ey> no

11:21 <mps> littlebobeep: you can look here about it https://github.com/asahilinux/docs/wiki

11:42 <hanetzer> littlebobeep: try petitboot :P

11:44 <hanetzer> mps: oh, you have a gru-kevin too? :)

11:45 <mps> hanetzer: yes, but in last half year my daughter uses it

11:51 <littlebobeep> hanetzer: Okay tow-boot does not provide this? I will look for petitboot

12:12 <hanetzer> littlebobeep: pettiboot is linux-as-a-bootloader. boots, starts a discovery service, and finds various sorts of bootloader config files. can kexec linux and bsd.

19:05 <cambrian_invader> if I refactor something like `obj-$(CONFIG_FOO) += foo.o` into `obj-$(CONFIG_$(SPL_TPL_)FOO) += foo.o`

19:05 <cambrian_invader> should the new CONFIG_SPL_FOO symbols default to y for backwards compatibility or n for reduced size?

19:06 <Tartarus> kettenis: if you have any ideas on adding openbsd host tool builds to CI I'd be quite happy to hear them and try it out

19:06 <cambrian_invader> perhaps there is a BSD docker image?

19:07 <Tartarus> cambrian_invader: There's no easy default for SPL_FOO vs FOO, it depends on what it is, and how many boards do/don't set it

19:08 <cambrian_invader> the FOO in this case is MISC

19:08 <cambrian_invader> which I want for regular U-Boot but which is missing a DM dependency for SPL

19:08 <Tartarus> SPL_MISC is already a symbol

19:08 <Tartarus> Ah

19:08 <Tartarus> That's harder since SPL_DM isn't required

19:08 <cambrian_invader> huh, so it is

19:09 <cambrian_invader> I guess the makefile is just incorrect then

19:09 <Tartarus> So, yeah, you end up needing CONFIG_IS_ENABLED(MISC) && CONFIG_IS_ENABLED(DM)

19:09 <Tartarus> is it? hm

19:09 <Tartarus> No, I guess misc is one of the cases where there's not a no-DM option

19:10 <Tartarus> MISC/SPL_MISC depend on DM/SPL_DM

19:10 <Tartarus> So Makefile cleanup should be straight forward

19:10 <Tartarus> (And TPL_MISC depends on TPL_DM)

19:21 <hanetzer> I'm under the assumption that spl (or tpl) needs to be smaller than the sram of a given chip?

19:22 <cambrian_invader> generally, yes

19:22 <cambrian_invader> unless you have xip

19:24 <hanetzer> cambrian_invader: I'm masochisticly working on a soc with a shit old u-boot-2010.06/linux-3.10 BSP so I'm not quite sure 'what I have' :P

19:25 <hanetzer> I *do* have a serial based recovery mechanism which I can use from linux now :)

19:26 <cambrian_invader> sorry, I'm not an expert in this area, I just know the xip option exists

19:26 <cambrian_invader> if you're already using SPL you probably don't have it

19:26 <hanetzer> well, their setup uses something akin to spl. its just stupid :P

19:27 <kettenis> Tartarus: unfortunately all of the "free" CI providers only support Linux and Windows (and sometimes macOS)

19:28 <hanetzer> 0x40 bytes of vectors, then 4096 bytes of 'reg_info.bin' which is basically a binary csv containing addresses, bytes to write to those addresses, and flags. its generated from an excel workbook with visual basic(?)

19:28 <hanetzer> so, first loop, it reads that data and applies it, then second loop it skips it.

19:35 <Tartarus> kettenis: Figured :( There are apparently options to host your own agents and so forth, both for Azure and GitLab.

19:36 <Tartarus> Maybe a something could get hand-waved and weaved together, for testing, not 100% sure on the hows, since we try (but don't succeed with gitlab) to have the yml file Just Work for anyone

20:17 <machinehum> How can I begin to start fixing this: https://pastebin.com/raw/V3Bwa54n ?

20:21 <Tartarus> machinehum: What did you add?

20:21 <Tartarus> Or, if nothing, what toolchain are you using?

20:24 <machinehum> Well I'm trying to upstream something that isn't upstreamed yet. Hacked a bunch of stuff together trying to get the allwinner V5 to boot. I guess a more specific question I should have asked is, where are the memory regions defined and are there any optimisation flags or something to get it to fit?

20:25 <machinehum> Sorry if these questions are not entirely appropriate, it's been a long few weeks

20:38 <cambrian_invader> machinehum: look in the linker script for your arch; should be called u-boot-spl.lds

20:38 <cambrian_invader> machinehum: you can also try enabling CONFIG_LTO

20:43 <machinehum> cambrian_invader: LTO=[y] made it fit

20:43 <machinehum> Thanks

21:00 <Tartarus> Yeah, the memory regions are generally defined right, so that error is the build time "stop now because it will fail silently at run time"

21:01 <Tartarus> And if you aren't using the gcc-11.0 toolchains, or possibly newer general ones, you may also get binaries that are too large

21:01 <machinehum> I'm using 11.2

21:11 <machinehum> If I get this board to boot I'm going to lose my shit

23:49 <hanetzer> anyone know of a trick for defining registers and their bitfields in headers in such a way they're usable in assembly files?

23:50 <hanetzer> something like https://github.com/qemu/qemu/blob/master/include/hw/registerfields.h#L21 's FIELD and REG32 macros?

23:52 <marex> hanetzer: #define REG 0x1c , #define REG_BIT (1 << 20) ?

23:52 <hanetzer> marex: very manual, trying to avoid that.

23:55 <marex> how ? you have to somehow get the initial data

23:55 <hanetzer> well, I have for each REG n amount of bitfields, and I have y amount of REGs for z amount of peripherals.

23:56 <hanetzer> it'll pile up lmao

23:56 <hanetzer> actually...