Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.07 is OUT / Merge Window is OPEN until 26 July 2021 / Release v2021.10 is scheduled for 04 October 2021 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
hanetzer has joined #u-boot
hanetzer has joined #u-boot
hanetzer has quit [Changing host]
hanetzer has quit [Quit: WeeChat 3.2]
qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
hanetzer has joined #u-boot
hanetzer has joined #u-boot
hanetzer has quit [Changing host]
mmu_man has quit [Ping timeout: 272 seconds]
Peng_Fan has joined #u-boot
jwillikers has quit [Remote host closed the connection]
torez has quit [Quit: torez]
macromorgan has quit [Read error: Connection reset by peer]
agust has joined #u-boot
drewfustini has quit []
drewfustini has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
fdanis_away is now known as fdanis
frieder has joined #u-boot
sbach has joined #u-boot
frieder_ has joined #u-boot
tre has joined #u-boot
alpernebbi has joined #u-boot
<milkylainen> Nobody knows if an SDHCI can be enumerated via ACPI for x86 in U-boot?
frieder_ has quit [Quit: Leaving]
<marex> milkylainen: isnt sdhci usually sitting on pcie on those intel acpi machines ?
<milkylainen> marex: This is an AMD R1000 (Embedded Ryzen). I think the controllers are pcie in all cases. But enumeration are quite often ACPI enumeration.
<milkylainen> I don't know why they decided to muck up the enumeration. But this effectively makes u-boot x86 emmc a dud in a lot of modern cases.
<marex> milkylainen: well, colaborative project and all, fix it, send patch, you know the drill :)
sszy has joined #u-boot
<milkylainen> marex: I wish I knew what was needed. PCIe enumeration I know a little bit about. Enough to fix existing things a bit. ACPI enumeration? Nada.
<marex> isnt acpi about some table parsing , kinda like DT ?
<milkylainen> There are ACPI tables, sure. Don't know what tables there is and how they are used though.
<marex> milkylainen: it is actually all there, and it looks like a weird DT for the most part
<milkylainen> Does x86 need an SPL?
<milkylainen> It's forcibly enabled if I have RUN_64BIT enabled (EFI)... Which seems ... odd.
monstr has joined #u-boot
<__ad> hi, using CONFIG_OF_SEPARATE on 2017.01, and fdt_subnode_offset() fails to find a node that i know is there
<__ad> debugging, if any hint, welcome
<milkylainen> Ah. a 32-bit U-boot is built as a SPL for a 64bit... yuck.
<milkylainen> And EFI stub must be the same as the runtime, otherwise you can't define the EFI_LOADER library... sigh.
mmu_man has joined #u-boot
<marex> __ad: try mainline, maybe the problem was fixed in the last almost five years
<milkylainen> This commit disables efi_loader and efi_disk. I can't have efi block io unless U-boot runtime bitness matches with EFI stub bitness.
<milkylainen> That's just weird.
<milkylainen> I don't intend to boot an efi application. But I do need access to EFI protocols to be able to use initialized devices.
<milkylainen> marex: I hope that I can use the UEFI initilized emmc through the EFI provided IO block protocol.
<marex> milkylainen: talk to xypron , efi is his doing
<milkylainen> xypron: -^
<milkylainen> How do I get a hold of efi block devices?
jwillikers has joined #u-boot
alpernebbi has quit [Quit: alpernebbi]
<milkylainen> sjg1: mtrr cmd does not seem to work on hw. Only getting "Invalid CPU (err=-2)". Don't think I'm abusing the arg list.
eiffel has joined #u-boot
eiffel has quit [Remote host closed the connection]
<sjg1> milkylainen: My guess is that there is no /cpus {} node in the devicetree. This is needed at present, by cpu_x86_get_count()
<milkylainen> hmm. Default devicetree? Should atleast contain one cpu then?
<milkylainen> I don't have SMP support built.
<sjg1> milkylainen: Yes, although that could be fixed I suppose
<sjg1> milkylainen: See cpu_get_count() in get_bsp(). If cpu_get_count() returns -ENOENT, then we could just return 0 from get_bsp(), on the basis that the BSP is the current one
<milkylainen> -ENOSYS?
<milkylainen> Sorry.
<milkylainen> sjg1: Ok. I see.
macromorgan has joined #u-boot
torez has joined #u-boot
<milkylainen> sjg1: Think the problem is mp.h for non mp builds.
<sjg1> milkylainen: Ah OK
tre has quit [Remote host closed the connection]
sszy has quit [Ping timeout: 268 seconds]
fdanis is now known as fdanis_away
frieder has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
Amit_T has joined #u-boot
Amit_T has quit [Client Quit]
redbrain has joined #u-boot
<milkylainen_> I'd really appreciate if someone could explain how the UEFI block IO protocol driver in U-boot is supposed to work.
override has joined #u-boot
mmu_man has quit [Ping timeout: 272 seconds]
milkylainen_ has quit [Quit: Connection closed]
redbrain has quit [Ping timeout: 268 seconds]
milkylainen_ has joined #u-boot
redbrain has joined #u-boot
pgreco_ is now known as pgreco
redbrain has quit [Ping timeout: 245 seconds]
<sjg1> milkylainen: Which driver are you referring to?
srk has quit [Ping timeout: 268 seconds]
srk has joined #u-boot
srk_ has joined #u-boot
mmu_man has joined #u-boot
srk has quit [Ping timeout: 268 seconds]
srk_ is now known as srk
agust has quit [Quit: Leaving.]
jwillikers has quit [Remote host closed the connection]