00:36 <hanetzer> I don't suppose anyone here knows if there's a register one can query in the gic to see if it supports virtualization extensions?

15:48 <emz229> Hello everyone! would someone be willing / available to answer a few questions about automatic SOM detection?

16:33 <marex> emz229: just ask the questions

16:43 <emz229> I have 2 different SOM modules, each have a different list of I2C devices (thus providing a way to differentiate them) I would like to know the best way to implement a way to setup things like early UART and secondary DIMM address.

16:44 <marex> i2c is not a discoverable bus (i2c probe can confuse the i2c devices, dont do it)

16:44 <marex> so , do you have some e.g. GPIO straps to differentiate the SoMs ?

16:45 <emz229> unfortunately not, they are by two separate vendors with no available GPIO to my knowledge

16:47 <emz229> we currently probe i2c address 0x27 to detect what carrier board the SOM is on.. and then load the appropriate image

16:58 <rfs613> emz229: as marex said, there is no safe way to "probe" for i2c devices. It carries a risk of issuing the wrong command (eg. a read could become a write). So you while this might work in your particular situation, it is not a general purpose solution.

16:59 <rfs613> You said there was no gpio, so maybe there is somethign that is shared? Perhaps an i2c eeprom that is always present, into which you could store the information of which carrier it is?

17:00 <emz229> rfs613: what is considered general best practice instead of probing I2C devices?

17:01 <emz229> The carrier board will always have the SPI flash mounted on it that u-boot is running from.

17:03 <rfs613> emz229: the same u-boot binary regardless of SoM?

17:04 <emz229> yes the goal is to have a single u-boot binary that can use either SoM

17:06 <emz229> These are baytrail based Intel Atom modules, the only difference is one uses the internal legacy UART, and has 2nd DIMM addr 0xA4. The other (original) has an embedded controller that outputs UART, and 2nd DIMM addr 0xA2

17:08 <cambrian_invader> well, if you know there is only a choice between X and Y it may be discoverable

17:08 <cambrian_invader> since you can examine the registers of the devices and determine what is safe to access

17:08 <rfs613> yes, thats what I mean by "it might work in your particular situation"

17:10 <cambrian_invader> but this is no different than having a device-tree which specifies what is at each address

17:10 <cambrian_invader> so IMO it's safe as long as you are smart about it

17:10 <rfs613> https://www.microforum.cc/blogs/entry/42-the-problems-of-i2c-common-problems-and-errors-with-using-i2c

17:19 <emz229> so currently the function `setup_internal_uart()` is called from `board_early_init_f` but from my testing I have very limited functionality at this point

17:22 <rfs613> yes, this is really quite early in the boot, the real serial console comes a bit later

17:28 <emz229> rfs613: yes, it is very early.. however I have tried as a test to call that function from a later stage `board_late_init` and it has no effect at that point

17:35 <emz229> also I find it rather challenging to interface with I2C devices from within the code instead of using the commands like I would within CONFIG_STD_DEVICES_SETTINGS for example

17:58 <lovesegfault[m]1> Hi folks, would anyone be able to direct me on debugging NVME booting on a RaspberryPi CM4 with u-boot?

17:59 <lovesegfault[m]1> I have the RPi's bootloader loading u-boot on the NVME, but then u-boot doesn't seem to discover the NVME and hangs

17:59 <lovesegfault[m]1> if I do `pci`, I can see the PCIe device for the NVME drive listed, but `nvme scan`/`nvme info` don't show it

18:00 <lovesegfault[m]1> Any ideas?

18:37 <emz229> cambrian_invader: Do you have any suggestions?

18:39 <cambrian_invader> define board_fit_config_name_match in your board file

18:39 <cambrian_invader> and in it try probing the appropriate i2c driver at the address above

18:40 <cambrian_invader> depending on what you get, yield a different compatible

18:40 <cambrian_invader> that is, if you are using SPL

18:41 <cambrian_invader> I think U-Boot proper uses that function too?

18:41 <marex> or you can use minimal DT with RESELECT

18:41 <marex> or enable both UARTs and use both at the same time

18:41 <cambrian_invader> neat, I didn't know about reselect

18:42 <cambrian_invader> AFAIK you can't have multiple active serial consoles

18:43 <emz229> marex: can you provide any documentation I can review?

18:44 <marex> emz229: git grep DTB_RESELECT for examples

18:51 <emz229> marex: thankyou I see several examples

18:51 <emz229> cambrain_invader: I am using U-Boot proper, the first thing that gets printed out is: U-Boot 2018.09 (Apr 26 2022 - 16:48:27 +0000)

18:52 <marex> upgrade

18:54 <emz229> I agree an upgrade is required.. convincing the team of that is another story.. what are your reasons for the upgrade suggestion? maybe it will help convince them

18:58 <cambrian_invader> if you are doing secure boot there are some CVEs which would otherwise need backporting

19:05 <cambrian_invader> the easiest way is to do `git log --grep=Fixes` on your arch's directory

19:17 <emz229> we are using secure boot, including several TPM setup / test steps, I have backported numerous CVEs most recent looks like CVE-2019-14195

19:28 <emz229> I can change the second DIMM address to match the current SOM using `fsp,mrc-init-spd-addr2 = <0xa2>;` in the device tree, however what do you suggest for setting up early UART? im not sure how to change that, that early in the boot process (unless I save a env variable and read it back at that early boot stage)

19:30 <emz229> for reference the dts I am working with is `x86/dts/baytrail_som-db5800-som-6867.dts`

19:37 <emz229> i guess the question becomes, can I read environment variables such as `bootcmd` within `board_early_init_f` and if so, what function can I use to do so?

19:40 <cambrian_invader> emz229: CVE-2021-27097

19:40 <cambrian_invader> you can use env_get to read variables

19:40 <cambrian_invader> but you shouldn't need to read bootcmd

19:41 <cambrian_invader> also CVE-2020-10648