On Sun, Jun 22, 2014 at 05:54:17PM +0200, Idwer Vollering wrote:
> > So, this looks different from Matt's report. What appears to be
> > happening in the above is that the device shows up originally as a
> > high speed device (see "[High]" above). However, when the set_address
> > command is sent to it, it appears that the device effectively
> > disconnects and then reconnects as a super speed device (see "change
> > port #2" and "change port #4" above - port 2==port 4 - see ("offset 1"
> > / "offset 3" above)).
> >
> > You can try increasing the xchi_event_wait timeout which fixes Matt's
> > issue, but I think we tried this on your hardware before with no luck.
>
> Indeed, changing 1000 to 5000 or USB_TIME_COMMAND in
> src/hw/usb-xhci.c:501 didn't matter.
Can you retry with the patch series I just posted? It's also at:
https://github.com/KevinOConnor/seabios/tree/testing
It may help with this device.
-Kevin
This series reworks the internal 16bit <-> 32bit trampolining that the
SeaBIOS code uses during runtime, and it adds support for using System
Management Mode (SMM) for performing a more correct switch to 32bit
mode during runtime. Currently, QEMU v2.1 in TCG mode is needed in
order for the SMM handler to be utilized.
This series was inspired by the desire to move more hardware
processing to 32bit mode. This change, however, does not move any
additional code to 32bit. The series may still be useful though when
running some existing 32bit drivers (eg, ahci and xhci).
The series is also available at:
https://github.com/KevinOConnor/seabios/tree/testing
With the completion of this series, the full 32bit hardware branch is
down to only three patches. For reference, that branch is at:
https://github.com/KevinOConnor/seabios/tree/testing-32bit-drivers
-Kevin
Kevin O'Connor (12):
Move stack hop code below call32/call16 code in stacks.c
Add need_hop_back() call that determines if stack_hop_back is needed
Update invoke_mouse_handler() to use need_hop_back()
Update stack_hop_back() to jump to 16bit mode if called in 32bit mode.
Track when entering via call32() and use the same mode for
stack_hop_back()
Simplify farcall16 code
Update reset() to use call16_back()
build: Support declaring 32bit C functions that must reside in the
f-segment
Move call16() functions from romlayout.S to inline assembler in
stacks.c
Break up call32() into call32() and call32_sloppy()
Fully restore 16bit state during call16_sloppy()
Implement call32 mechanism using SMIs.
scripts/layoutrom.py | 16 +-
src/Kconfig | 4 +
src/fw/smm.c | 46 ++++-
src/mouse.c | 15 +-
src/romlayout.S | 42 -----
src/stacks.c | 510 ++++++++++++++++++++++++++++++++++++++-------------
src/stacks.h | 23 ++-
src/types.h | 4 +
8 files changed, 477 insertions(+), 183 deletions(-)
--
1.9.3
On Tue, Sep 30, 2014 at 12:40:26PM -0600, Marc Jones wrote:
> On Tue, Sep 30, 2014 at 7:06 AM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > You don't see any output from SeaBIOS (no version banner and no boot
> > menu prompt)?
> >
> > Is the framebuffer really at 0xc0000000 (as the log reports) or at
> > 0xb8000 (as your question states)? In my tests grub uses int10
> > instead of 0xb8000, but if it detects a vbe adapter it will setup a
> > graphical framebuffer and then write to that. Do you see seavgabios
> > debug messages showing grub probing for vbe later in the log? Is the
> > grub output you do see in graphics mode or text mode?
>
> I don't get any output from SeaBIOS. The framebuffer is at 0xc0000000.
> I asked about b8000 since that is the legacy area and I wasn't certain
> how grub does things. I didn't capture any additional ouptut while
> grub was loading. I assume that it is doing the vbe setup as you said.
> I can do some additional debug and instrument the int10s.
If the framebuffer is at 0xc0000000 then I'm surprised that you're not
getting output - the cbvga code is pretty simple once the framebuffer
is found. I'd try increasing the debug level to 8 and recompile
seavgabios.
Also, you might want to make sure that the framebuffer wasn't turned
off by something, and that some other vga option rom didn't get run
after cbvga.
Another random thing to check would be if cbvga is writing black on
black for some reason. Also, make sure you have a recent version of
SeaBIOS - as I think f6b44b81e is needed.
-Kevin
On Mon, Sep 29, 2014 at 11:27:33PM -0600, Marc Jones wrote:
> I'm trying to use the cbvga after a coreboot has initialized graphics.
> It looks like everything is fine, but I don't get any seabios text on
> the screen. It seems that int10 isn't working. Grub is able to display
> fine. Does anyone know if Grub uses int10 or direct b8000 accress?
>
> Scan for VGA option rom
> Running option rom at c000:0003
> Start SeaVGABIOS (version ?-20140929_231635-megaman)
> enter vga_post:
> a=00000000 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000
> si=00000000 di=000087b0 bp=00000000 sp=00006e62 cs=f000 ip=d413 f=0000
> coreboot vga init
> Found FB @ c0000000 1024x768 with 16 bpp (2048 stride)
> set VGA mode 140
> Attempting to allocate VGA stack via pmm call to f000:d46a
> pmm call arg1=0
> VGA stack allocated at ef590
> Turning on vga text mode console
> set VGA mode 3
> SeaBIOS (version ?-20140929_231635-megaman)
You don't see any output from SeaBIOS (no version banner and no boot
menu prompt)?
Is the framebuffer really at 0xc0000000 (as the log reports) or at
0xb8000 (as your question states)? In my tests grub uses int10
instead of 0xb8000, but if it detects a vbe adapter it will setup a
graphical framebuffer and then write to that. Do you see seavgabios
debug messages showing grub probing for vbe later in the log? Is the
grub output you do see in graphics mode or text mode?
-Kevin
If the pmm entry point was called with a non-zero stack segment, the
pointer to the arguments on the stack would not be valid once the
code transitioned to 32bit mode. Fix by adding the stack segment
offset into the args pointer.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/romlayout.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/romlayout.S b/src/romlayout.S
index a3ba965..028d1e8 100644
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -321,10 +321,11 @@ entry_pmm:
pushl %edx
pushw %es
pushw %ds
- movw %ss, %cx // Move %ss to %ds
+ movl %ss, %ecx // Move %ss to %ds
movw %cx, %ds
+ shll $4, %ecx
movl $_cfunc32flat_handle_pmm, %eax // Setup: call32(handle_pmm, args, -1)
- leal 28(%esp), %edx // %edx points to start of args
+ leal 28(%esp, %ecx), %edx // %edx points to start of args
movl $-1, %ecx
calll call32
movw %ax, 12(%esp) // Modify %ax:%dx to return %eax
--
1.9.3
I'm trying to use the cbvga after a coreboot has initialized graphics.
It looks like everything is fine, but I don't get any seabios text on
the screen. It seems that int10 isn't working. Grub is able to display
fine. Does anyone know if Grub uses int10 or direct b8000 accress?
Scan for VGA option rom
Running option rom at c000:0003
Start SeaVGABIOS (version ?-20140929_231635-megaman)
enter vga_post:
a=00000000 b=0000ffff c=00000000 d=0000ffff ds=0000 es=f000 ss=0000
si=00000000 di=000087b0 bp=00000000 sp=00006e62 cs=f000 ip=d413 f=0000
coreboot vga init
Found FB @ c0000000 1024x768 with 16 bpp (2048 stride)
set VGA mode 140
Attempting to allocate VGA stack via pmm call to f000:d46a
pmm call arg1=0
VGA stack allocated at ef590
Turning on vga text mode console
set VGA mode 3
SeaBIOS (version ?-20140929_231635-megaman)
Marc
--
http://se-eng.com
The usbdev->port field is zero indexed, while the USB spec expects the
port values to start at one.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
This problem was causing intermittent detection failures with low
speed devices on my c720. It seems that most hubs don't care about
this field, as the code has never been correct but it hasn't shown up
as a problem prior to now. (And even on the c720, it would still work
much of the time.)
This patch is also available for testing at:
https://github.com/KevinOConnor/seabios/tree/testing
---
src/hw/usb-ehci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/hw/usb-ehci.c b/src/hw/usb-ehci.c
index 20e387b..f5ee5bf 100644
--- a/src/hw/usb-ehci.c
+++ b/src/hw/usb-ehci.c
@@ -366,7 +366,7 @@ ehci_desc2pipe(struct ehci_pipe *pipe, struct usbdevice_s *usbdev
struct ehci_pipe *hpipe = container_of(
hubdev->defpipe, struct ehci_pipe, pipe);
if (hpipe->pipe.speed == USB_HIGHSPEED)
- pipe->qh.info2 |= ((usbdev->port << QH_HUBPORT_SHIFT)
+ pipe->qh.info2 |= (((usbdev->port+1) << QH_HUBPORT_SHIFT)
| (hpipe->pipe.devaddr << QH_HUBADDR_SHIFT));
else
pipe->qh.info2 = hpipe->qh.info2;
--
1.9.3
On Sat, Sep 13, 2014 at 06:12:24PM -0400, Leonardo Passos wrote:
> Dear all,
>
> I am using Seabios for a personal project and I need to try different
> versions of it.
> After cloning the project code, I see many releases when issuing git tag,
> but which ones are stable? Clearly, 1.7.5-rc1 isn't, but what about the
> others?
>
> Stated otherwise, what is the rationale of release numbering in Seabios?
The history of major seabios releases is documented at:
http://seabios.org/Releases
All of the tags in git (with the exception of the -rcX "release
candidate" tags) were considered stable at the time they were tagged.
The tags/releases with 4 digits (eg, rel-1.7.2.2) were incremental
stable branch releases. That is, they were bug fix only releases. As
far as I know, this is the same release numbering scheme that qemu and
the Linux kernel currently use.
If you're looking for the most recent stable release, it's rel-1.7.5
(as documented on the wiki above). The code being developed for the
next major release is on the master branch.
I'm not sure what info you are looking for, but I hope that helps.
-Kevin