Re: [SeaBIOS] USB flash device not recognized on cold boot, but on reboot
Am Sonntag, den 18.05.2014, 16:06 -0400 schrieb Kevin O'Connor: On Sat, May 17, 2014 at 10:25:58PM +0200, Paul Menzel wrote: on LinuxTag 2014 the OpenMandriva project [1] gave away USB flash storage devices with OpenMandriva installed for live booting. Testing it out on the ASRock E350M1 with coreboot and SeaBIOS payload it was not detected by SeaBIOS, meaning pressing F12 it was not listed in the boot options. Rebooting the system by pressing Ctrl + Alt + Del the USB device was recognized by SeaBIOS and listed in the boot menu. I am still able to reproduce this with SeaBIOS build from master. Please find the coreboot and SeaBIOS logs attached. Thanks. At first glance this looks like it could be a quirk of the particular flash drive. That might be. As a side note, enabling serial console in coreboot and SeaBIOS causes the devices to always be detected. With serial console the boot takes longer, as the messages need to be transmitted, so it could be a timing issue. Can you apply the patch below, set the SeaBIOS debug level to 3, and report the results of both the working/not-working cases? I forgot to lower the debug level to 3, so it is still at 8. Sorry. I hope that is still fine. If not, I’ll redo the tests. Thanks, Paul coreboot_console.7z Description: application/7z-compressed signature.asc Description: This is a digitally signed message part ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update
On Tue, 2014-05-20 at 14:22 +0100, David Woodhouse wrote: However, this doesn't work if I have both CONFIG_MALLOC_UPPERMEMORY *and* CONFIG_EXTRA_STACK enabled. Hm, this appears to be because rom_get_max() is returning 0xef000, causing us to ask UEFI to leave only the range 0xef000-0xf writeable. And that doesn't work quite so nicely when we use the extra stack which in my case is at 0xef520. Is rom_get_max() not what I should be using for this? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update
On Wed, May 21, 2014 at 11:15:44AM +0100, David Woodhouse wrote: On Tue, 2014-05-20 at 14:22 +0100, David Woodhouse wrote: However, this doesn't work if I have both CONFIG_MALLOC_UPPERMEMORY *and* CONFIG_EXTRA_STACK enabled. Did you mean CONFIG_ENTRY_EXTRASTACK? I don't see how CONFIG_ENTRY_EXTRASTACK would have an impact, as we allocate and use the same extra stack regardless of that config setting. Hm, this appears to be because rom_get_max() is returning 0xef000, causing us to ask UEFI to leave only the range 0xef000-0xf writeable. And that doesn't work quite so nicely when we use the extra stack which in my case is at 0xef520. Why is it wrong to declare memory at 0xef000-0xf and have a stack at 0xef520-0xefd20? Is rom_get_max() not what I should be using for this? That is the right function (when CONFIG_MALLOC_UPPERMEMORY). It's what fw/shadow.c:make_bios_readonly_intel() uses. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update
On Wed, 2014-05-21 at 09:52 -0400, Kevin O'Connor wrote: Why is it wrong to declare memory at 0xef000-0xf and have a stack at 0xef520-0xefd20? Er, it's not. I'm stupid. But still it didn't work and it was almost certainly because it's trying to write to read-only memory, given the symptoms and the fact that it doesn't fail when KVM is enabled. I'll run it in qemu with insane levels of tracing, and see if I can work out precisely where it goes wrong. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] Update EFI_COMPATIBILITY16_TABLE to match 0.98 spec update
On Wed, 2014-05-21 at 09:52 -0400, Kevin O'Connor wrote: Why is it wrong to declare memory at 0xef000-0xf and have a stack at 0xef520-0xefd20? I found the problem and it was on the UEFI side, not with the SeaBIOS patch. UEFI was only unlocking the requested 0xef000-0xf region when it actually issued a Legacy16Boot request. Prior to that, the entire 0xc-0x10 region was remaining locked. I'll fix my EDK2 patch accordingly. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
