Hi Gerd,
I was curious to see what the "sercon" stuff would look like in
SeaVGABIOS instead of in SeaBIOS. So, I put together a quick
prototype. The code is also at:
https://github.com/KevinOConnor/seabios/tree/testing
This is just a proof-of-concept thing - I didn't implement any of the
useful features you have in your series. Specifically, it doesn't
unclutter the serial output, doesn't implement cp437 translations, and
doesn't handle multi-byte input. It does does have basic input,
output, and split-output handling though.
I'm not sure if this is better than a SeaBIOS implementation. I
suspect it will be easier to handle vga quirks this way. However,
handling exotic serial outputs (eg, mmio and usb based) would be
better suited in SeaBIOS.
Thoughts?
-Kevin
Kevin O'Connor (3):
sercon: Initial support for VGA emulation over serial port
sercon: Add basic keyboard input support
sercon: Support "split output" mode
Makefile | 2 +-
vgasrc/Kconfig | 6 +
vgasrc/sercon.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
vgasrc/vgabios.c | 15 ++-
vgasrc/vgabios.h | 5 +
vgasrc/vgaentry.S | 7 ++
vgasrc/vgahw.h | 72 ++++++++++-
vgasrc/vgainit.c | 12 +-
vgasrc/vgautil.h | 24 ++++
9 files changed, 482 insertions(+), 17 deletions(-)
create mode 100644 vgasrc/sercon.c
--
2.5.5
Hi,
I turned the debug level up to 4 on our smaller (128k) ROM downstream
build and seem to have hit a case where it's been layed out so that the
'ExtraStack' is at the same location as some code (display_uuid) which
was causing some very random behaviour;
from an objdump disassemble of the rom.o that was produced:
ef79d: f3 ab rep stos %eax,%es:(%edi)
ef79f: 8d 43 08 lea 0x8(%ebx),%eax
ef7a2: b1 10 mov $0x10,%cl
ef7a4: 8d 54 24 74 lea 0x74(%esp),%edx
ef7a8: e8 50 46 ff ff call e3dfd <memcmp>
ef7ad: 85 c0 test %eax,%eax
ef7af: 0f 84 33 01 00 00 je ef8e8 <ExtraStack+0x110>
ef7b5: 8b 15 0c 23 0f 00 mov 0xf230c,%edx
ef7bb: 80 7a 06 02 cmpb $0x2,0x6(%edx)
ef7bf: 0f b6 43 17 movzbl 0x17(%ebx),%eax
ef7c3: 77 0c ja ef7d1 <StackPos+0x1>
ef7c5: 0f 85 80 00 00 00 jne ef84b <ExtraStack+0x73>
ef7cb: 80 7a 07 05 cmpb $0x5,0x7(%edx)
ef7cf: 76 7a jbe ef84b <ExtraStack+0x73>
Note the 'ExtraStack+...' where as a few lines before it's maininit
for other jumps, then looking at a sorted output of the rom.o.objdump:
000eddf2 l F .text 000000e0 virtio_scsi_add_lun.constprop.113
000eded2 l F .text 0000080d device_hardware_setup
000ee6df l F .text 00001a17 maininit <-------------
000ef790 g *ABS* 00000000 final_varlow_start
000ef790 g O *ABS* 00000004 BootSequence
000ef794 g O *ABS* 00000001 FloppyDOR
000ef798 g O *ABS* 00000008 LastUSBkey
000ef7a0 g O *ABS* 00000001 Ps2ctr
000ef7a4 g O *ABS* 00000004 RTCusers
000ef7a8 g O *ABS* 00000004 TimerLast
000ef7ac g O *ABS* 00000001 HaveAttemptedReboot
000ef7ad g O *ABS* 00000001 Century
000ef7b0 g O *ABS* 00000010 CDRom_locks
000ef7c0 g O *ABS* 00000010 DefaultDPTE
000ef7d0 g O *ABS* 00000004 StackPos
000ef7d8 g O *ABS* 00000801 ExtraStack <-------------
000effdc g O *ABS* 00000018 Call16Data
000f0000 g *ABS* 00000000 final_readonly_start
000f0000 g *ABS* 00000000 zonefseg_start
000f00f6 g F .text 0000038b dopost
000f0481 g F .text 000001c2 handle_pmm
000f0644 l O .text 00000014 CSWTCH.1353
000f0658 l O .text 00000014 __func__.14607
000f066c l O .text 00000011 __func__.14624
000f0680 l O .text 00000010 __func__.14549
000f0690 l O .text 0000000b __func__.14497
What's supposed to stop that happening?
I'd chosen a debug level of 4 since that was the largest it would go
without the build complaining it wouldn't fit, so I thought I was
safe since something did complain if it got way too big.
(This is based off 1.9.1)
Dave
--
Dr. David Alan Gilbert / dgilbert(a)redhat.com / Manchester, UK
Dear SeaBIOS folks,
coreboots board status repository has some SeaBIOS warnings, and I
believe the keyboard doesn’t work in that case.
```
$ git grep 'Timeout at i8042_flush' origin/master --
origin/master:amd/lamar/4.0-9540-gae5ab60/2015-04-30T02:12:19Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:amd/olivehill/4.0-7005-gb9a0809/2014-10-08T13:44:17Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:amd/olivehillplus/4.0-6942-g4177db5/2014-09-19T19:38:48Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:amd/thatcher/4.3-102-g380e167/2016-02-04T18_30_40Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:aopen/dxplplusu/4.5-485-g52896c6/2016-12-04T02_03_58Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:gizmosphere/gizmo/4.0-9564-g58649b0/2015-05-03T07:14:33Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:google/panther/4.0-9491-g64c7791/2015-04-23T21:31:14Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:google/panther/4.1-340-gb38b0f2/2015-08-25T18:38:10Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:google/panther/4.3-777-g4774bb9/2016-04-18T13_11_58Z/coreboot_console.txt:|7f6bc000| WARNING - Timeout at i8042_flush:71!
origin/master:hp/2760p/4.5-906-g3fb6e6e-dirty/2017-01-27T03_04_14Z/coreboot_console.txt:|7feca000| WARNING - Timeout at i8042_flush:71!
origin/master:hp/2760p/4.5-911-g9510156/2017-01-28T14_47_33Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:hp/2760p/4.5-913-g0f70fbd/2017-01-29T02_16_08Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:intel/bayleybay_fsp/4.0-6293-g0b4b230/2014-06-25T23:32:28Z/coreboot_console.txt:|7ba9a000| WARNING - Timeout at i8042_flush:71!
origin/master:intel/minnowmax/4.2-429-g4013469/2015-11-30T20_21_41Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:intel/minnowmax/4.2-429-g4013469/2015-11-30T20_21_41Z/tests/cbmem-console.log:WARNING - Timeout at i8042_flush:71!
origin/master:intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:intel/minnowmax/4.5-306-g00ad7ff/2016-11-17T17_00_43Z/tests/cbmem-console.log:WARNING - Timeout at i8042_flush:71!
origin/master:pcengines/alix2d/4.0-6723-ga0a3727-dirty/2014-08-15T23:01:34Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:pcengines/alix2d/4.0-6723-ga0a3727/2014-08-15T01:44:46Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:pcengines/apu1/4.4-422-g9aba60e/2016-06-05T08_06_37Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:pcengines/apu2/4.5-801-gfeb4ef6/2017-01-11T16_15_42Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
origin/master:siemens/mc_tcu3/4.4-108-g0d4e124/2016-05-09T06_14_45Z/coreboot_console.txt:WARNING - Timeout at i8042_flush:71!
```
I also experience this sometimes on a Lenovo X60, when I load the
SeaBIOS ELF file from GRUB with the commands below.
```
> chainloader (cbfsdisk)/img/seabios
> boot
```
Every time, the keyboard doesn’t work – on the Lenovo X60 it’s
connected over the PS/2 port – the error message `Timeout at
i8042_flush:71!` can be seen.
Note, that it’s unlikely to be a timing issue, as the keyboard works in
the GRUB payload *before*.
Any idea, what causes the problem, and is there a way to fix it?
Thanks,
Paul
Dear SeaBIOS folks,
On the ASRock E350M1 with coreboot and SeaBIOS, setting the runtime
config option `threads` to 2, I am unable to press the boot menu key
(ESC). [1]
> By default, SeaBIOS will parallelize hardware initialization during bootup to reduce boot time. Multiple hardware devices can be initialized in parallel between vga initialization and option rom initialization. One can set this file to a value of zero to force hardware initialization to run serially. Alternatively, one can set this file to 2 to enable early hardware initialization that runs in parallel with vga, option rom initialization, and the boot menu.
My rotating hard drive is pretty slow, and SeaBIOS is waiting for that.
Not adding `etc/threads` to CBFS, pressing the key works, and the boot
menu is displayed.
Is that the expected behavior?
Kind regards,
Paul
[1] https://www.seabios.org/Runtime_config
When running Linux on an Intel machine with a commodity BIOS, CPUs are
numbered starting from 0 and the first half refers to the first logical
CPU on each core while the second half refers to the second logical CPU
on each core.
As an example, on machine with 2 sockets, 4 cores per socket, and 2
logical CPUs per core, CPUs would be numbered:
* 0 1 2 3 - first logical CPU on each core of socket 0
* 4 5 6 7 - first logical CPU on each core of socket 1
* 8 9 10 11 - second logical CPU on each core of socket 0
* 12 13 14 15 - second logical CPU on each core of socket 1
With seabios (prior to this patch), CPU 0 would be the first logical CPU
on core 0 of socket 0, CPU 1 would be the second logical CPU on core 0
of socket 0, and so on.
This is due to the fact that processor_id and local_apic_id are assigned
with the same value when building MADT.
Exhaust the most-significant 7 bits of the 8-bit APIC ID and then come
back to the least-significant bit when assigning local_apic_id, since
the least-significant bit identifies the second logical CPU on a core.
If HTT isn't available, keep the previous behavior.
Signed-off-by: Filippo Sironi <sironi(a)amazon.de>
---
src/fw/acpi.c | 42 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/src/fw/acpi.c b/src/fw/acpi.c
index 8bc2ca6..864c247 100644
--- a/src/fw/acpi.c
+++ b/src/fw/acpi.c
@@ -158,13 +158,53 @@ build_madt(void)
memset(madt, 0, madt_size);
madt->local_apic_address = cpu_to_le32(BUILD_APIC_ADDR);
madt->flags = cpu_to_le32(1);
+ u32 eax, ebx, ecx, edx;
+ cpuid(1, &eax, &ebx, &ecx, &edx);
+ int htt = 0;
+ if (!eax) {
+ dprintf(1, "No cpuid\n");
+ } else {
+ htt = !!(edx & (1 << 28));
+ /* assuming at most 2 logical CPUs per core */
+ if (htt)
+ dprintf(4, "Found HTT feature\n");
+ }
struct madt_processor_apic *apic = (void*)&madt[1];
int i;
for (i=0; i<MaxCountCPUs; i++) {
apic->type = APIC_PROCESSOR;
apic->length = sizeof(*apic);
apic->processor_id = i;
- apic->local_apic_id = i;
+ if (htt) {
+ /*
+ * In a system with 2 packages, 4 cores per package, and 2 CPUs per
+ * core we want to achieve the following coupling:
+ * CPU# APIC ID
+ * 0 0 [first socket, first logical CPUs]
+ * 1 2
+ * 2 4
+ * 3 6
+ * 4 8 [second socket, first logical CPUs]
+ * 5 10
+ * 6 12
+ * 7 14
+ * 8 1 [first socket, second logical CPUs]
+ * 9 3
+ * 10 5
+ * 11 7
+ * 12 9 [second socket, second logical CPUs]
+ * 13 11
+ * 14 13
+ * 15 15
+ * where the least-significant bit of the APIC ID identifies the
+ * first (0) or second (1) logical CPU in a core.
+ */
+ apic->local_apic_id = i * 2;
+ if (apic->local_apic_id >= MaxCountCPUs)
+ apic->local_apic_id -= MaxCountCPUs - 1;
+ } else {
+ apic->local_apic_id = i;
+ }
if (apic_id_is_present(apic->local_apic_id))
apic->flags = cpu_to_le32(1);
else
--
2.7.4
Dear SeaBIOS folks,
coreboot allows to prefix images to add different romstage, ramstage,
and payloads, and depending on the behavior during boot, choose a
certain one.
Commonly *normal* and *fallback* are used as prefixes, while the
bootblock code loads the *normal* image first, but if there is a
failure, commonly after three tries, boots the fallback image.
SeaBIOS takes runtime configuration values always from `etc/`. That way,
only one configuration can be used for different coreboot builds.
What could be a solution for that problem? Also allow `fallback/etc/`,
and `normal/etc`?
Kind regards,
Paul
Date: Fri, 20 Jan 2017 16:52:44 +0100
You only want this information for debugging. As it also slows down the
boot considerably, as, for example, for every character of the GRUB
menu, something is sent over the serial console.
Therefore, increase the debugging level to 9.
Signed-off-by: Paul Menzel <pmenzel(a)molgen.mpg.de>
---
vgasrc/vgabios.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vgasrc/vgabios.h b/vgasrc/vgabios.h
index 3d5bbfe..e2edec0 100644
--- a/vgasrc/vgabios.h
+++ b/vgasrc/vgabios.h
@@ -73,7 +73,7 @@ static inline int vga_emulate_text(void) {
// Debug settings
#define DEBUG_VGA_POST 1
-#define DEBUG_VGA_10 3
+#define DEBUG_VGA_10 9
// vgabios.c
int vga_bpp(struct vgamode_s *vmode_g);
--
2.7.4
From: Ben Warren <ben(a)skyportsystems.com>
This patch set adds the capability to write to QEMU across the DMA link and
adds a higher-level command to allocate a fw_cfg file and write its address
back to another, writeable fw_cfg file.
The initial use case is for Windows VM
Generation ID, where QEMU needs to change the contents of fw_cfg
data at runtime, while still having BIOS allocate and manage the memory.
v1->v2: separated patch into two functional units
changed so writes only occur over the DMA interface
fixed coding style
removed change to romfile struct definition (removed new write_back method)
Ben Warren (2):
QEMU DMA: Add DMA write capability
QEMU fw_cfg: Add command to write back address of file
src/fw/paravirt.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
src/fw/paravirt.h | 3 +++
src/fw/romfile_loader.c | 38 ++++++++++++++++++++++++++++++++++++++
src/fw/romfile_loader.h | 23 ++++++++++++++++++++---
4 files changed, 110 insertions(+), 3 deletions(-)
--
2.7.4