redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
jaganteki has quit [Quit: Client closed]
thopiekar has quit [Ping timeout: 265 seconds]
thopiekar has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
naoki has joined #u-boot
<sjg1_>
Tartarus: I notice some PowerPC boards still have not been converted to DM_SERIAL. The deadline is looming...do you know what is happening there?
\dev\ice has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
prabhakarlad has quit [Quit: Client closed]
Leopold_ is now known as Leopold
\dev\ice has joined #u-boot
srk- has joined #u-boot
srk has quit [Read error: Connection reset by peer]
<sakman>
sjg1_: for me (mpc837x) as ns16550 already converted, enabling dm_serial and a small change in <board>.h compiles cleanly with no dm_serial warning but I will be at the office where the board is only next week and I will then be able to test.
ikarso has joined #u-boot
jaganteki has joined #u-boot
Leopold_ has joined #u-boot
Leopold has quit [Ping timeout: 255 seconds]
vfazio_ has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
vfazio has quit [Remote host closed the connection]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
jybz has joined #u-boot
gsz has joined #u-boot
<xypron>
sjg1_: EFI_TCG2_PROTOCOL_GUID - 607f766c-7455-42be-930b-e4d76db2720f, these seem to be proprietary GUIDs of firmware vendors like Phoenix. E.g. EDK of 2010 used EFI_CONSOLE_CONTROL_PROTOCOL_GUID - f42f7782-012e-4c12-9956-49f94304f721. This GUID does not exist in current EDK II.
<Tartarus>
sjg1_: I guess the next step for me is making a list of the boards, again, and emailing, and being a bit more proactive about the "hunh, now there's no maintainer that doesn't bounce" ones too
<sakman>
Tartarus: FWIW, except me (a non-nxp), for all fsl p/t/mpc boards I believe it is total of four maintainers, so it should be easy to find out if they are still around
goliath has quit [Quit: SIGSEGV]
mckoan is now known as mckoan|away
d-s-e has quit [Quit: Konversation terminated!]
rockworld has quit [Ping timeout: 276 seconds]
<Tartarus>
sakman: Yeah, I suspect this will heavily reduce the number of powerpc board we still have in tree
<Tartarus>
Of course, it really should just be a matter of setting the config option, which is hopefully what you'll confirm when you get to next week
<rfs613>
I guess it's fair to assume everyone is busy with the approaching release? Patches for the next version are probably being ignored until the release is out?
<sakman>
Tartarus: yes hopefully this is all and won't need dm-/bootph- etc. I just compiled p2020rdb and p2041rdb with dm_serial enable and they compiled without a warning too, I have those boards so if mine is just config mod I will test them too
<Tartarus>
rfs613: Got a particular request? I think it's more people being busy in general / u-boot being a low priority :(
<Tartarus>
yeah, marex is probably just busy in general
<rfs613>
yup. Just would be good to know if its generally okay looking... if major changes are requested, i'd like to start on them... to hopefully get this merged one of these releases ;-)
goliath has joined #u-boot
<Tartarus>
sjg1_: Andrew Pinski's suggestion on linker lists seems to be fixing it
<sjg1_>
Tartarus: Ah OK, that is good. I am amazed we still find corner cases in C after all of these years. The 'optimisation people' are really looking into corners
mmu_man has joined #u-boot
<sjg1_>
xypron: With the Ubuntu ISO I get 'error: file `/boot/' not found'. Then later it says: 'Unable to find a medium containing a live file system'
<sjg1_>
xypron: I wonder if they are related?
<xypron>
sjg1_: do you have a repo with mttr fixes?
<sjg1_>
xypron: Yes I suppose it must be, but it appears while boot services are still active. I am wondering if it causing the later problem
<sjg1_>
xypron: For linux I used console=uart8250,io,0x3f8,115200n8 to see the output. Still seeing an ACPI error. I found that 'bootefi' writes out a whole new set of ACPI tables
<sjg1_>
xypron: But I can't see why that would cause problems. Linux happily prints out the ACPI tables, then decides it doesn't like them
<xypron>
sjg1_: We don't have a message "file `%s' not found" but GRUB uses thise in different places.
<sjg1_>
xypron: Sounds right...the question is whether this is causing 'Unable to find a medium containing a live file system' or not
<sjg1_>
xypron: I'm not sure how to get a useful error from the installer
<xypron>
sjg1_: obviously the SATA CD-ROM is not found
<xypron>
sjg1_: We need something with a recovery console.
<sjg1_>
xypron: Would that rely on ACPI tables? I would assume that QEMU would put it in the DSDT. But perhaps there is another way to connect a CDROM?
<xypron>
sjg1_: Use EDK II with the same QEMU command for booting and dump the ACPI tables. You want to produce the same in U-Boot.
<sjg1_>
xypron: But U-Boot is not producing the tables...they are just coming from QEMU. Or do you mean that there is some finessing that might be different in EDK2?
<xypron>
sjg1_: How do you pass on ACPI tables from QEMU? Do you install them as an UEFI configuration table in U-Boot?
<sjg1_>
xypron: Yes, see the call to write_acpi_tables() in drivers/misc/qfw.c
<sjg1_>
xypron: You can use 'acpi list' in U-Boot to see them...but then 'bootefi' calls the function again to set up some new ones (which is odd, but should be OK)
<sjg1_>
xypron: Basically the tables come from a QEMU file
goliath has quit [Quit: SIGSEGV]
gsz has quit [Ping timeout: 255 seconds]
<sjg1_>
xypron: I tried replacing the CDROM with virtio
<xypron>
sjg1_: you can also save the table in a binary format in separate files. tar them and scp them to your server for analysis
goliath has joined #u-boot
<sjg1_>
xypron: OK... BGRT is not present with U-Boot
<sjg1_>
Otherwise they seem the same. I will see if I can stop bootefi from creating a new set of tables
<xypron>
sjg1_: that is only the 'Lenovo' or whatever logo.
<sjg1_>
xypron: OK, so we can ignore that
<xypron>
sjg1_: later we can copy the U-Boot logo to the table
<sjg1_>
xypron: OK. Did you see the SMBIOS line? [ 0.000000] efi: SMBIOS=0x7f9ab000 ACPI=0x7fb7e000 ACPI 2.0=0x7fb7e014 MEMATTR=0x7ea2f198 MOKvar=0x7f9a7000
<kettenis>
hmm, why does it have both ACPI and ACPI 2.0?
<sjg1_>
xypron: With U-Boot I get [ 0.000000] efi: RTPROP=0x7dce2040 ACPI 2.0=0x7dccf000 SMBIOS=0x7dcce000 MOKvar=0x7dbe9000
<xypron>
sjg1_: So you copied the ACPI2.0 but not the ACPI table?
<sjg1_>
xypron: They seem to be the same thing, since acpi2 is 0x14 bytes offset?
<sjg1_>
xypron: U-Boot is apparently missing MEMATTR but perhaps that doesn't matter?
<xypron>
sjg1_: I don't think that has to do with device discovery
<xypron>
sjg1_: On my laptop: [ +0.000000] efi: ACPI=0x2cffd000 ACPI 2.0=0x2cffd014 TPMFinalLog=0x2cf2f000 SMBIOS=0x286ca000 SMBIOS 3.0=0x286c7000 MEMATTR=0x244a1018 MOKvar=0x2861c000 RNG=0x2cfc1018 TPMEventLog=0x215a8018. We should try to understand what these 0x14 bytes are.
<sjg1_>
xypron: Oh...when I stop 'bootefi' creating its own tables, it seems to boot!
<sjg1_>
xypron: OK will look at the 0x14 bytes. I suspect the original ACPI had a different (smaller) header. The new ACPI is 0x24 bytes I think
<xypron>
sjg1_: Other way round: ACPI < ACPI 2.0 addresswise
<sjg1_>
xypron: Oh OK. Will take a look
<xypron>
sjg1_: But ACPI 2.0 should be good enough to boot.
<xypron>
We are at ACPI 6.0 now
<sjg1_>
xypron: Yes, I wonder if having two copies of the ACPI tables confused it somehow?
<xypron>
sjg1_: per GUID we only have one configuration table
<sjg1_>
xypron: Thank you for your help!
<sjg1_>
xypron: Yes, but perhaps it gets confused anyway?
<xypron>
sjg1_: Does qemu-system-aarch64 also pass ACPI tables to U-Boot?
<sjg1_>
xypron: Hope note!
<sjg1_>
not!
<xypron>
sjg1_: I know for riscv64 ACPI has been worked on. ARM servers want ACPI not dtb
<xypron>
sjg1_: I guess we need to have configurations for ACPI besides dtb
<xypron>
sjg1_: When writing a patch for efi_acpi_register() I guess we should check for any QEMU.
<xypron>
sjg1_: x86 uses symbols CONFIG_QEMU. Arm64 and riscv64 use CONFIG_ARCH_QEMU. Can we use the same symbol for all QEMU targets?
<xypron>
sjg1_: riscv64's symbol is CONFIG_TARGET_QEMU_VIRT=y
<xypron>
sjg1_: We can have an arch specific symbol but that should select a common one.
<sjg1_>
xypron: sorry, afk for an hour. Does efi_acpi_register() really need to reinstall the tables?
<xypron>
sjg1_: What we pass to GRUB and further to the kernel is the system table. This table has a pointer to the list of configuration tables. In this list must be the pointer to the ACPI 2.0 table
<xypron>
sjg1_: So yes we need to add that pointer.
<xypron>
sjg1_: And we must ensure that in the EFI memory map that table is in acpi_reclaim_memory.
<xypron>
sjg1_: EFI spec 2.10: CPI Tables loaded at boot time can be contained in memory of type EfiACPIReclaimMemory (recommended)
<xypron>
or EfiACPIMemoryNVS . ACPI FACS must be contained in memory of type EfiACPIMemoryNVS
<xypron>
sjg1_: If we do not want to copy the ACPI tables from QEMU we have to call efi_add_memory_map_pg().
<xypron>
to set the memory type of the pages
<xypron>
sjg1_: The best place to set to do the efi_add_memory_map_pg() would be when you set up the qfw pointer. We should also map all other tables that QEMU provides and are passed to Linux unaltered.
<xypron>
sjg1_: QEMU's hw/arm/virt-acpi-build.c has the code to build ACPI tables on ARM platform virt. Function virt_acpi_setup() and virt_build_smbios() are called unconditionally.
<xypron>
sjg1: So we should enable to boot QEMU on arm64 with ACPI tables instead of a device-tree.
ikarso has quit [Quit: Connection closed for inactivity]
<sjg1_>
xypron: It's a shame about ARM servers. It is ridiculous that one of the reasons for using UEFI was that U-Boot could not handle a large SoC!
<sjg1_>
xypron: Yes QEMU should use the same symbol. Care to write a patch?
<sjg1_>
xypron: Well the tables can be installed anywhere. At present qfw allocates memory to write them to
<sjg1_>
xypron: So it seems to me that EFI could pick up the tables and make sure that they are in the memory map. After all, that happens on x86 today, when not booting with EFI
<sjg1_>
xypron: Calling efi_add_memory_map_pg() should be easy enough, with your pointers
<sjg1_>
xypron: We need QEMU to work with DT on ARM...I suppose we could have an option to boot with ACPI, but it should not be the default. Hardly any upstream boards (in U-Boot or Linux) boot with ACPI on ARM, last time I looked
<sjg1_>
xypron: After all, ACPI is basically pretty awful :-)