15:11 <zear> hey guys

15:13 <zear> whom should I add as e-mail recipient to a patch that adds a new board/*/ subdirectory? get_maintainer.py fails to list anybody

15:13 <silurian_invader> email the arch/soc maintainers

15:13 <zear> alright, thanks

15:25 <marex> zear: which board is this ? and soc ?

15:28 <zear> I'm officially adding support for Conclusive Engineering's KSTR-SAMA5D27 SBC: https://conclusive.pl/products/kstr-sama5d27-sbc/

15:28 <zear> This is Microchip ATSAMA5D27 based, so I believe Eugen Hristev should be attached, as the maintainer of at91

15:30 <zear> since we have some other boards (based on different SoCs) that were are thinking of upstreaming as well, our intention is to have `board/conclusive` subdirectory

15:33 <zear> marex, does that sound fine? I'm about to press enter on git send-email for this series ;)

15:34 <marex> zear: atmel , that was uh ...

15:35 <marex> zear: try Eugen Hristev

15:35 <zear> yep

15:35 <zear> thanks

20:06 <deathmist> mps: about VF2 fdtfile selection, maybe it could select it if not already specified somehow via e.g. CONFIG_DEFAULT_DEVICE_TREE/CONFIG_DEFAULT_FDT_FILE (and drop those from starfive_visionfive2_defconfig)? would help with keeping downstream kernel boot compat without enforcing mainline stuff by always overriding fdtfile, unless with the RFC version you can already do that somehow

20:07 <mps> deathmist: these was posted today https://github.com/Headcrabed/u-boot/tree/ddr_fix_v2

20:08 <mps> and this https://patchwork.ozlabs.org/project/uboot/patch/20230907112128.342315-1-heinrich.schuchardt@canonical.com/

20:09 <deathmist> ah cool, I'm fine with someone else taking over that patch stuff, less need for me to deal with email patches :)

20:10 <mps> I tested these patches and that works fine

20:11 <deathmist> if it can be made to work with downstream kernel boot as well that would be perfect, though maybe not mandatory(?) since they have downstream U-Boot anyway which already works with that and is flashed on SPI by default

20:14 <mps> yes, but they are trying to upstream patches for u-boot and also for kernel

20:14 <mps> which is good for distro maintainers

20:15 <deathmist> as was I, I bring up downstream kernel boot because I saw on https://github.com/MichaIng/DietPi/issues/6212 they're struggling with constant breakages being done even for other distros using downstream kernel and not wanting to use the very much hardcoded partition setup StarFive looks to want to enforce

20:17 <deathmist> along with the uEnv.txt stuff and whatnot, it's exactly what I wanted to avoid as well and just go with a "normal" U-Boot, thus mainline

20:18 <mps> iirc VF2 can boot without uENV.txt

20:43 <xypron> I am just booting VF2 the EFI way using upstream U-Boot. The vendor EDK II is a good alternative.

21:44 <Eschik> I am working on adding support for the Graphics Management Bus interface on x86 SOCs, and would like to open a call for collaboration from anyone who may be more knowledgeable than I. After reading the docs I dont see a standardized way to request this assistance from the U-Boot community. Anyone have any advice? I have a WIP commit, which at the moment is basically just a skeleton code placeholder, but I will be actively developing this for anyone

21:44 <Eschik> interested.

21:52 <marex> Eschik: send a patch to the ML, CC whoever might be interested

22:12 <Eschik> marex: Thanks, email has been sent, awaiting moderator approval

22:14 <marex> Eschik: register with the ML and you wont have to go through that moderator stuff

22:15 <marex> (you can disable mail delivery so you wont get all the firehose of email)