On Mon, Nov 05, 2018 at 01:27:10PM +0100, Krystian Hebel wrote:
> SeaBIOS modifies its internal e820 structure, but does not propagate
> these changes back to coreboot tables. This resulted in multiple errors
> in MemTest86 when run on 2 GB platforms, probably because of some
> memory-mapped
I don't think SeaBIOS should be altering coreboot information. (Doing
so leads to all sorts of painful debugging problems, for example.)
Well, currently it is marking at least first couple of kilobytes of
memory (4 if I recall correctly) as free to use RAM. There coreboot
tables are
On Fri, Nov 02, 2018 at 01:07:20AM +0300, Mike Banon wrote:
> All the floppy images available at CBFS will be found and listed in a
> boot menu, instead of the first found. Could be highly valuable if you
> are participating in a hobby OS development - would like to test
> multiple versions of
On Thu, Nov 01, 2018 at 05:14:42PM +0200, Shmuel Eiderman wrote:
> The max number of targets per PVSCSI controller is 64, not 7.
> This can easily be seen in QEMU PVSCSI emulation code
> (hw/scsi/vmw_pvscsi.c) as PVSCSI_MAX_DEVS, which defines the
> number of targets, have value of 64.
Thanks. I
Signed-off-by: Kevin O'Connor
---
src/fw/shadow.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/fw/shadow.c b/src/fw/shadow.c
index 987eaf4..4c627a8 100644
--- a/src/fw/shadow.c
+++ b/src/fw/shadow.c
@@ -173,9 +173,9 @@ qemu_reboot(void)
return;
> However I'm concerned that this would reserve memory for all
> of the floppy images in the e820 map (and thus the final OS
> would not be able to use that memory).
sorry Kevin I'm not fully understanding the consequences. Would
reserving e820 memory for all the floppies - result in a slightly
