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,
…
[View More]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
[View Less]
With the first two patches applied, I am able to install and boot
FreeDOS on an Intel SSD DC P3700, an NVMe 1.0 device, in QEMU
using PCI device assignment.
The rest of the patches are minor issues found through inspection.
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 $…
[View More]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
[View Less]
On Tue, Feb 21, 2017 at 08:10:57AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Gerd - are you planning to backport this series to the stable branch?
>
> Yes. Unless we'll have a 1.11 release next week, which I doubt ;)
No short term plans for a major release.
You may want to consider the following additional patches for the next
stable release:
106543de - ahci: Set upper 32-bit registers to zero
970af16e - vgasrc: Increase debug level
dbf9dd27 - ps2port: Disable keyboard/…
[View More]mouse prior to resetting ps2 controller
-Kevin
[View Less]
I liked to try out seabios instead of grub as payload and after flashing a coreboot image with seabios as only payload i got the message that i cant find any bootable device. Seems like seabios cant boot a basic debian installation where you encrypt the hdd and write grub into the MBR - the most default configuration.
I have search trough the last months seabios mailing list archives but cant find a talk about that.
Are there any plans of adding support for this?
From: Ben Warren <ben(a)skyportsystems.com>
This patch set adds the capability to write to QEMU across the fw_cfg DMA
link. It adds a higher-level command to write the BIOS-allocated address of
one fw_cfg file into an arbitrary point within another, writeable fw_cfg file
across the above-mentioned link.
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.
The …
[View More]final corresponding QEMU patch can be found here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg430490.html
v6->v7: - minor refactoring of qemu_cfg_write_file* functions
v5->v6: - Rebased to top-of-tree
- Minor refactoring and conditional execution based on code review
v4->v5: - Minor changes to range checking and data validation
- Added code for replaying COMMAND_WRITE_POINTER commands on S3 resume
v3->v4: - Added a 'src_offset' field in the message so the pointer need not
point to the beginning of the file.
- Changed the command struct definitions from anonymous to named.
v2->v3: - fixed up the qemu_cfg_write* functions to allow writing to an
arbitrary offset within the destination file.
- Changed function name to COMMAND_WRITE_POINTER and its functionality
to not patch memory at all, but write back to a specified offset.
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 (5):
QEMU DMA: Add DMA write capability
romfile-loader: Switch to using named structs
QEMU fw_cfg: Add command to write back address of file
QEMU fw_cfg: Add functions for accessing files by key
QEMU fw_cfg: Write fw_cfg back on S3 resume
src/fw/paravirt.c | 68 +++++++++++++++++++++++++++++
src/fw/paravirt.h | 5 +++
src/fw/romfile_loader.c | 112 ++++++++++++++++++++++++++++++++++++++++--------
src/fw/romfile_loader.h | 65 ++++++++++++++++++----------
src/resume.c | 4 ++
5 files changed, 214 insertions(+), 40 deletions(-)
--
2.7.4
[View Less]