<sjg1>
Tartarus: Yes... also Takahiro's UEFI clean-up series uses it, as well as the tag stuff (which is just inline in his series)
<Tartarus>
sjg1: OK, I'll pick that up for next soon then
<Tartarus>
I'm already at 0/1 in "lets merge 2 series and push them through CI to see that nothing breaks"
<sjg1>
Tartarus: OK ta. I hope the UEFI stuff can come in soon
<sjg1>
Tartarus: If you like I can rebase and check it to save you the hassle. Something may have changed
<Tartarus>
sjg1: Please and thanks!
<sjg1>
Tartarus: OK I'll let you know
monstr has quit [Remote host closed the connection]
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #u-boot
<sjg1>
Tartarus: sadly there is one new misc_init_f() function to convert, so I'll send a v2
<Tartarus>
OK, thanks!
kveremitz has quit [Ping timeout: 250 seconds]
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #u-boot
Dhruvag2000[m] has quit [Quit: You have been kicked for being idle]
tnovotny has quit [Quit: Leaving]
zibolo has quit [Ping timeout: 240 seconds]
tre has quit [Remote host closed the connection]
milkylainen_ has joined #u-boot
<MWelchUK>
I'm currently working on a system which has a SoM mounted to a main board. Due to supplier shortages there's a desire to use both the existing SoM or a second one from a different supplier, but boot from the same firmware Binary.
<MWelchUK>
Both of the SoMs are i.MX6 based. I have a build where this basically works booting with a shared SPL and main U-Boot image, however both SoMs use SPI-NOR to store U-Boot, but on different buses. This is a little bit problematic with CONFIG_ENV_SPI_BUS/CONFIG_SF_DEFAULT_BUS.
sobkas has joined #u-boot
<MWelchUK>
I have what seems to me to be a very hacky solution where I replace the usage of these defines with a weakly defined function returning the define value. I then provide this function as part of the board support with a function that determines the correct bus for the SoM in use.
<MWelchUK>
Ideally we'd be upstreaming support for this device at some point in the not too distant future.
<MWelchUK>
(It's a sister product for the already upstreamed bx50v3 devices)
<MWelchUK>
Would such a solution potentially be acceptable upstream? Can anyone suggest a better option?
vagrantc has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
<marex>
MWelchUK: doesnt DM_SPI permit you to select bus in DT ?
<marex>
MWelchUK: which SoMs are these btw ?
<MWelchUK>
marex: Unless I'm missing something, the default bus is hardcoded in `spl_spi_load_image()` (common/spl/spl_spi.c), `do_spi_flash_probe()` (cmd/sf.c), `splash_sf_read_raw()` (common/splash_source.c), `fsl_spi_spl_load_image()` and `fsl_spi_boot()` (drivers/mtd/spi/fsl_espi_spl.c), and `setup_flash_device()` and `setup_flash_device()` (env/sf.c).
milkylainen has quit [Quit: Ping timeout (120 seconds)]
<MWelchUK>
marex: The SoMs are the Congatec QMX6 and MSC Q7-imx
<MWelchUK>
marex: I don't currently have DM support in the SPL, which I guess is where the bulk of the issue lies...
<MWelchUK>
I'm not using all the functions listed above, but I clearly need to find a solution that continues to work for others too if I'm going to be upstreaming this...
kveremitz has joined #u-boot
<apritzel>
MWelchUK: if you don't have DM_SPL, and this problem is SPL only, then I'd hope those kind of "hacks" are somewhat tolerated
<apritzel>
MWelchUK: we use similar tricks in sunxi to support booting board variants, where we select one of multiple DTs, in SPL code
<MWelchUK>
apritzel: Looking at `setup_flash_device()` in `env/sf.h`, the default bus is hardcoded regardless of whether DM_SPL is being used or not.
<apritzel>
MWelchUK: smells like some legacy, since nobody had this case so far
<apritzel>
but replacing a fixed CONFIG_ with a weak function sounds familiar, I think I did this in the past as well ;-)
<MWelchUK>
apritzel: Yes, I'm assuming what we're trying to do isn't something that many people have tried before (I assume we wouldn't if chip supply wasn't fairly screwed up at the moment.
<apritzel>
I don't know about that, but I would assume that the boot SPI flash is mostly at one fixed bus on a platform, so there was little need for runtime checks so far
<apritzel>
for instance the Allwinner BootROM only supports SPI booting from SPI0 on the PortC pins, so this indeed nicely modeled with a CONFIG_ variable
<MWelchUK>
That would seem like a very sane assumption to make. :-)
<apritzel>
MWelchUK: and I think just selecting a different bus is not enough, since you would probably need differentiation between the board variants in U-Boot proper as well
<apritzel>
for Allwinner we put multiple DTs in the U-Boot FIT image, and select the right one from the SPL: check board_fit_config_name_match() in board/sunxi/board.c
<MWelchUK>
apritzel: Yep, that's what I'm doing in this instance. Though there's a few bits that are hard coded with are a little problematic. Other than the SPI bus, the console UART seems to be hardcoded too. Thankfully I have access to a UART that both SoMs use.
<apritzel>
I don't think there is much opposition to go from hardcoded to runtime determined, given that this doesn't ignore the DT (which is not the case if this is in the SPL with DM_SPL)
<apritzel>
s/with/without/
matthias_bgg has quit [Ping timeout: 245 seconds]
<MWelchUK>
apritzel: Oh, OK. I'll assume that my hacky solution may be closer to something upstreamable than I'd expected then :-)
frieder has quit [Remote host closed the connection]
<apritzel>
if that allows a single image, simplifying the user experience, and prevents worse hacks ...
<sjg1>
Tartarus: yuk that is pretty horrible. I suspect it can be fixed by adding: self.patch = '' to the __init__() function in class Commit (see commit.py)