Hi Ard, everyone,
On 03. 07. 24 19:35, Jan Čermák wrote:
Sure, below is output from the board I have available. I'll ask the
community members who reported the issues to get me output from their
systems.
in the attachments I'm sending all complete dmidecode outputs I was able
to
On 03. 07. 24 16:47, Ard Biesheuvel wrote:
If GRUB no longer works correctly on these systems due to the move to
the generic EFI loader, and we can straight-forwardly identify them
using SMBIOS metadata, I don't anticipate any objections from the GRUB
maintainers.
Cool, that sounds great!
I
Hi Ard
On 28. 06. 24 19:28, Ard Biesheuvel wrote:
Given that you carry your own GRUB build, I would recommend reverting
to non-EFI stub boot for affected Atom systems, identified by DMI
data, which should be easy to access on such systems.
Look for 'goto fallback' in the existing loader logic i
Hi Ard,
sorry, I feel a little ashamed for replying after such a long time but I
wanted to do some due diligence first and didn't have time (or the Atom
board around) until now.
Does your Kconfig have EFI_DISABLE_PCI_DMA enabled by any chance? That
could definitely produce the issues you are
Hi Ard, everyone,
On 23. 05. 23 17:31, Ard Biesheuvel wrote:
> Switch the x86 based EFI platform builds to the generic EFI loader,
> ...
We use GRUB as the loader for the Home Assistant Operating System (based
on Buildroot, using mostly unpatched GRUB 2 build [1]) and after
updating to the lat
