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
On Sat Mar 18 02:04:38 CET 2017, Kevin O'Connor wrote:
>> Assume the GPU is VGA compatible when running in text-mode.
>> Advertise VGA modes using SeaVGABios' stdvga driver.
>> running in text mode, even when not advertised.
>>
>> Allows Windows 7 to boot in 640x480 and 16 colors mode using the
>> VgaSave driver.
>> Allows Windows 7 to show the loading bar splash screen.
>>
>> Known issues:
>> The palette seems wrong, as colors are swapped ( blue is red, ... ).
>
>What graphics hardware did you test this on?
>
>If stdvga_set_mode() works on the hardware, why not use stdvga
>seavgabios and get the rest of the vgabios functionality? (That is,
>why use cbvga seavgabios at all?)
I'm on Lenovo T500 (Intel Graphics Media Accelerator 4500MHD).
I'm going to do some tests using stdvga instead of cbvga.
Regards,
Patrick
A number of SCSI drivers currently only see luns #0 in their targets.
This may be a problem when drives have to be assigned bigger lun
numbers, e.g. because the storage controllers don't provide enough
target numbers to accomodate all drives.
(In particular, I'm about to submit a driver for Hyper-V VMBus SCSI
controller which is limited to 2 targets only).
This series adds generic SCSI lun enumeration (either via REPORT LUNS
command or sequentially trying every lun), and makes the respective
drivers use it.
Note that the series has only been minimally tested against a recent QEMU.
Roman Kagan (9):
blockcmd: accept only disks and CD-ROMs
blockcmd: generic SCSI luns enumeration
virtio-scsi: enumerate luns with REPORT LUNS
esp-scsi: enumerate luns with REPORT LUNS
usb-uas: enumerate luns with REPORT LUNS
pvscsi: fix the comment about lun enumeration
mpt-scsi: try to enumerate luns with REPORT LUNS
lsi-scsi: reset in case of a serious problem
lsi-scsi: try to enumerate luns with REPORT LUNS
Signed-off-by: Roman Kagan <rkagan(a)virtuozzo.com>
---
v1 -> v2:
- use malloc_tmp instead of malloc_high
- format the retry logic as a regular while{} loop
- I left the interface as in v1 as the alternatives looked heavier
- patches 1,3-9 are unchanged
src/hw/blockcmd.h | 4 +++
src/hw/blockcmd.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/hw/esp-scsi.c | 35 +++++++++++++------
src/hw/lsi-scsi.c | 39 +++++++++++++++------
src/hw/mpt-scsi.c | 40 ++++++++++++++--------
src/hw/pvscsi.c | 2 +-
src/hw/usb-uas.c | 45 +++++++++++++++---------
src/hw/virtio-scsi.c | 38 +++++++++++++-------
8 files changed, 236 insertions(+), 64 deletions(-)
--
2.9.3
[For the GRUB folks, this is about coreboot commit d67c6876 (Turn CBMEM
console into a ring buffer that can persist across reboots) [1].
Julius’ message can be find in the coreboot list archive [2].]
Dear Julius,
Am Montag, den 10.04.2017, 15:50 -0700 schrieb Julius Werner:
[…]
> The change may also cause some hiccups if you're using a newer version of
> coreboot with an older version of cbmem (or SeaBIOS or whatever else reads
> the console): it will not crash and it will still print the whole log, but
> if the log has rolled over (into "ring buffer mode") it will print lines
> out of order. This is unfortunately the best I can do with the way current
> readers are implemented. I'm of course also updating the code for cbmem so
> as soon as you deploy the new version it will be able to display buffers
> from both old and new coreboot versions correctly. (I'll send patches to
> align SeaBIOS and the Linux memconsole driver in the same manner as soon as
> the coreboot patch is approved.)
Could you please also check, if GRUB’s CBMEM console driver, and the
the command cbmemc to display it need any updates?
Thanks,
Paul
PS: Where can I get your S/MIME certificate, used to sign your email?
[1] https://review.coreboot.org/18301
[2] https://mail.coreboot.org/pipermail/coreboot/2017-April/083950.html
Hello.
I tried seabios on an emulator (not qemu) and
faced the PCI memory regions overlap.
After some debugging I came to the conclusion
that seabios simply forgets to align the base
addresses, and as the result, when the device
aligns the address down by clearing the "dont
care" bits, it can overlap the previous region.
I fixed the problem with the attached simple patch.
Still it is hard to believe such a bug can exist, so
I wonder if I am missing something. Any suggestions
to where should I dig to narrow the problem further?
Or can it be that seabios actually has the bug like
that and no one have noticed? :)
Please change line 485 of src/boot.c and increase the BootDevice
description length 'char desc' value from [60] to [80]. Right now it's
cutting off text for some devices. 80 would most likely fix the issue and
provide enough space for very lengthy descriptions. Example shown here:
https://github.com/coreboot/seabios/pull/1
Thanks.
--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
Hi,
I did a very simple test :
1, modify qemu/hw/block/virtio-blk.c, let virtio-blk use 256 queue:
*s->vq = virtio_add_queue(vdev, 128, virtio_blk_handle_output);*
--> *s->vq = virtio_add_queue(vdev, 256 , virtio_blk_handle_output);*
**
2, compile qemu and run a VM which boots from virtio-blk disk.
The VM can NOT boot because seabios use macro MAX_QUEUE_NUM as 128.
So, does virtio-pci support more queues?
Looking forward your reply!
--
Rather than love ,than money ,than faith,than fame,than fairness,give me truth.
Hi,
> Right, sorry, I confused something while writing the explanation
> there. Nevertheless, the SeaBIOS code will require a small adjustment
> (same as the libpayload driver in the patch I linked) to continue
> appending correctly after the log has rolled over, and I'll provide
> that patch.
Is it possible to figure whenever the cbmem buffer supports rollover or
not, so a updated seabios version can work correctly with both old and
new coreboot?
cheers,
Gerd