Hi,
Next round of serial console patches, Still not ready to merge.
Headline feature of this version is split mode (i.e. output on both vga
and serial). Have a initial working implementation now, logic is
simliar to the vgabios timer hook (as suggested by Kevin).
Also changed the output logic, down to a one-cell buffer (char+attr) for
output. Cursor updates are simply written to BDA now, with the actual
move being done lazily when printing the next character or checking for
keyboard input. That is especially useful for splitmode as we can
simply skip the cursor position updates and let the vgabios do them
instead.
TODO list:
* compile time (CONFIG_*) option.
* input handling cleanups.
* implement missing int10h functions.
* more testing.
cheers,
Gerd
Gerd Hoffmann (5):
std: add cp437 to unicode map
kbd: make enqueue_key public, add ascii_to_keycode
paravirt: read QEMU_CFG_NOGRAPHIC, store in etc/sercon-enable romfile
add serial console support
[wip] sercon: initial split-output implementation
Makefile | 7 +-
src/clock.c | 1 +
src/fw/paravirt.c | 2 +
src/kbd.c | 17 +-
src/misc.c | 2 +
src/optionroms.c | 9 +-
src/romlayout.S | 39 ++++
src/sercon.c | 621 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/std/cp437.c | 275 ++++++++++++++++++++++++
src/std/cp437.h | 1 +
src/util.h | 5 +
11 files changed, 974 insertions(+), 5 deletions(-)
create mode 100644 src/sercon.c
create mode 100644 src/std/cp437.c
create mode 100644 src/std/cp437.h
--
1.8.3.1
This series of patches extends the TPM2 code to extend the BIOS related
PCRs 0-7 in all available banks. This prevents that these PCRs remain
untouched and filled with bogus values by applications. For example, the
SHA1 hash is extended into the SHA256 bank. The value that is extended
into this bank is essentially a SHA1 with zero bytes used for filling it to
the size of a sha256 hash. This is done for all PCR banks of the TPM2
where these PCRs are available.
In v2 of this series I also extended the log functions for logging the
additional hashes. So there are more patches now.
Regards,
Stefan
Stefan Berger (6):
tpm: Retrieve the PCR Bank configuration
tpm: Restructure tpm20_extend to use buffer and take hash as parameter
tpm: Extend tpm20_extend to support extending to multiple PCR banks
tpm: Move tpm_log_init to a later point
tpm: Adjust the TPM2 log header to show all hashes
tpm: Append to TPM2 log the hashes used for PCR extension
src/std/tcg.h | 78 +++++++++++--
src/tcgbios.c | 348 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 371 insertions(+), 55 deletions(-)
--
2.5.5
On Tue, Jul 26, 2016 at 03:02:02PM +0800, Li Wang wrote:
> Hi all,
> I am reading seaBios code, and I have a question about the shadow memory
> copy part. In fw/shadow.c:make_bios_writable_intel() reads pam0 to see if
> shadow memory is already readable (if pam0's fourth bit is set), if pam0
> shows shadow memory is not readable running __make_bios_writable_intel from
> high-memory flash location (statements marked green below).
> But in my understanding the entry point of bios is 0xffff:fff0, then it
> jumps to 0xf000:e05b, which points to memory space in shadowing, but before
> __make_bios_writable_intel copying bios from high-memory flash to shadow
> memory, shadow memory is disabled, so these codes are forwarded to
> high-memory flash, including code to read pam0 before invoking
> __make_bios_writable_intel (statement marked red below). Why these codes
> are not relocate to high-memory flash, but only the invocation of
> __make_bios_writable_intel is need to be relocated?
> If shadow ram is present and readable, how cpu execute bios codes in
> 0xf000:xxxx before copying them to shadow ram?
This code only runs on QEMU and is very specific to the quirky way
that QEMU implements the pam registers. When emulation starts, QEMU
places a read-only copy of the code in 0xe0000-0x100000. When SeaBIOS
requests that 0xc0000-0x100000 be read/writable ram by writing to the
pam registers in __make_bios_writable_intel(), then qemu converts the
region to uninitialized memory. This is why
__make_bios_writable_intel() needs to run from the copy of the code in
the "flash" location at the end of the first 4Gig of ram. The
make_bios_writable_intel() code can run in 0xe0000-0x100000 because
prior to __make_bios_writable_intel() QEMU places a read-only copy of
the code there and after __make_bios_writable_intel() SeaBIOS has
restored the code by copying the code back to that ram.
-Kevin
Hi all,
I am reading seaBios code, and I have a question about the shadow memory
copy part. In fw/shadow.c:make_bios_writable_intel() reads pam0 to see if
shadow memory is already readable (if pam0's fourth bit is set), if pam0
shows shadow memory is not readable running __make_bios_writable_intel from
high-memory flash location (statements marked green below).
But in my understanding the entry point of bios is 0xffff:fff0, then it
jumps to 0xf000:e05b, which points to memory space in shadowing, but before
__make_bios_writable_intel copying bios from high-memory flash to shadow
memory, shadow memory is disabled, so these codes are forwarded to
high-memory flash, including code to read pam0 before invoking
__make_bios_writable_intel (statement marked red below). Why these codes
are not relocate to high-memory flash, but only the invocation of
__make_bios_writable_intel is need to be relocated?
If shadow ram is present and readable, how cpu execute bios codes in
0xf000:xxxx before copying them to shadow ram?
60 static void
61 make_bios_writable_intel(u16 bdf, u32 pam0)
62 {
63 int reg = pci_config_readb(bdf, pam0);
64 if (!(reg & 0x10)) {
65 // QEMU doesn't fully implement the piix shadow capabilities -
66 // if ram isn't backing the bios segment when shadowing is
67 // disabled, the code itself won't be in memory. So, run the
68 // code from the high-memory flash location.
69 u32 pos = (u32)__make_bios_writable_intel + BIOS_SRC_OFFSET;
70 void (*func)(u16 bdf, u32 pam0) = (void*)pos;
71 func(bdf, pam0);
72 return;
73 }
74 // Ram already present - just enable writes
75 __make_bios_writable_intel(bdf, pam0);
76 }
Thanks
This series of patches extends the TPM2 code to extend the BIOS related
PCRs 0-7 in all available banks. This prevents that these PCRs remain
untouched and filled with bogus values by applications. For example, the
SHA1 hash is extended into the SHA256 bank. The value that is extended
into this bank is essentially a SHA1 with zero bytes used for filling it to
the size of a sha256 hash. This is done for all PCR banks of the TPM2
where these PCRs are available.
Regards,
Stefan
Stefan Berger (3):
tpm: Retrieve the PCR Bank configuration
tpm: Restructure tpm20_extend to use buffer and take hash as parameter
tpm: Extend tpm20_extend to support extending to multiple PCR banks
src/std/tcg.h | 45 +++++++++++++--
src/tcgbios.c | 175 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 201 insertions(+), 19 deletions(-)
--
2.5.5
Currently the MTRRs and MSR_IA32_FEATURE_CONTROL are not restored on S3
resume. Because these have to be applied to all processors, SMP setup
has to be added to S3 resume.
There are two differences between the boot and resume paths. First,
romfile_* is not usable in the resume paths so we move the call out
of smp_setup and into a new function smp_boot_setup. Second,
smp_msr has to be walked on the BSP as well, so we extract that
out of handle_smp and into a new function smp_write_msrs. Then,
resume can call smp_write_msrs on the BSP followed by smp_setup to
initialize the APs.
Reported-by: Laszlo Ersek <lersek(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
src/fw/paravirt.c | 1 +
src/fw/smp.c | 28 +++++++++++++++++++++++-----
src/resume.c | 1 +
src/util.h | 2 ++
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index e8e419e..9189672 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -160,6 +160,7 @@ qemu_platform_setup(void)
// Initialize mtrr, msr_feature_control and smp
mtrr_setup();
msr_feature_control_setup();
+ smp_boot_setup();
smp_setup();
// Create bios tables
diff --git a/src/fw/smp.c b/src/fw/smp.c
index 6e706e4..64e76b6 100644
--- a/src/fw/smp.c
+++ b/src/fw/smp.c
@@ -46,6 +46,15 @@ int apic_id_is_present(u8 apic_id)
return !!(FoundAPICIDs[apic_id/32] & (1ul << (apic_id % 32)));
}
+static void
+smp_write_msrs(void)
+{
+ // MTRR and MSR_IA32_FEATURE_CONTROL setup
+ int i;
+ for (i=0; i<smp_msr_count; i++)
+ wrmsr(smp_msr[i].index, smp_msr[i].val);
+}
+
void VISIBLE32FLAT
handle_smp(void)
{
@@ -58,10 +67,7 @@ handle_smp(void)
u8 apic_id = ebx>>24;
dprintf(DEBUG_HDL_smp, "handle_smp: apic_id=%d\n", apic_id);
- // MTRR and MSR_IA32_FEATURE_CONTROL setup
- int i;
- for (i=0; i<smp_msr_count; i++)
- wrmsr(smp_msr[i].index, smp_msr[i].val);
+ smp_write_msrs();
// Set bit on FoundAPICIDs
FoundAPICIDs[apic_id/32] |= (1 << (apic_id % 32));
@@ -73,6 +79,12 @@ handle_smp(void)
u32 SMPLock __VISIBLE;
u32 SMPStack __VISIBLE;
+void
+smp_boot_setup(void)
+{
+ MaxCountCPUs = romfile_loadint("etc/max-cpus", 0);
+}
+
// find and initialize the CPUs by launching a SIPI to them
void
smp_setup(void)
@@ -141,10 +153,16 @@ smp_setup(void)
// Restore memory.
*(u64*)BUILD_AP_BOOT_ADDR = old;
- MaxCountCPUs = romfile_loadint("etc/max-cpus", 0);
if (!MaxCountCPUs || MaxCountCPUs < CountCPUs)
MaxCountCPUs = CountCPUs;
dprintf(1, "Found %d cpu(s) max supported %d cpu(s)\n", CountCPUs,
MaxCountCPUs);
}
+
+void
+smp_resume(void)
+{
+ smp_write_msrs();
+ smp_setup();
+}
diff --git a/src/resume.c b/src/resume.c
index a5465d8..3a26f84 100644
--- a/src/resume.c
+++ b/src/resume.c
@@ -97,6 +97,7 @@ s3_resume(void)
pic_setup();
smm_setup();
+ smp_resume();
pci_resume();
diff --git a/src/util.h b/src/util.h
index cba3359..510da73 100644
--- a/src/util.h
+++ b/src/util.h
@@ -131,7 +131,9 @@ void smm_setup(void);
// fw/smp.c
extern u32 MaxCountCPUs;
void wrmsr_smp(u32 index, u64 val);
+void smp_boot_setup(void);
void smp_setup(void);
+void smp_resume(void);
int apic_id_is_present(u8 apic_id);
// hw/dma.c
--
1.8.3.1
On Mon, Jul 11, 2016 at 08:25:14PM +0300, Andrey Korolyov wrote:
> Awesome suggestion, turns out that the PCI_COMMAND_IO is not set.
> Removing the check entirely would lead to an incomplete PCI
> initialization but placing VGA ROM to vgaroms/seavgabios.rom could do
> the trick.
So, out of curiosity, does Geode SeaVGABIOS work on this board if one
of the above is done? I haven't seen a recent confirmation that Geode
SeaVGABIOS still works.
-Kevin
On Mon, Jul 11, 2016 at 02:23:12AM +0300, Andrey Korolyov wrote:
> Hi,
>
> as per Kevin`s suggestion, I am posting initialization log (mixed one)
> from initialization of the GeodeLX board. As it could be clearly seen
> from the log, VGA option ROM was never called and executed during the
> initialization sequence, therefore issue with a lack of video output
> during SeaBIOS stage on this board looks somehow logical. [1] suggests
> that the problem existed long before, as most users of these boards
> are Alix owners who do not care about existence of the video output :)
Best guess is this check:
u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
if (!(cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY))
return 0;
in optionroms.c:is_pci_vga() is being triggered. You could see if
coreboot is not enabling these PCI flags, temporarily disable the
check in seabios, or use "vgaroms/seavgabios.rom" instead of
"pci1022,2081.rom" for the seavgabios rom.
-Kevin
