date:20151223

Re: [SeaBIOS] [PATCH] xhci: Wait for port enable even for USB3 devices

2015-12-23 Thread Kevin O'Connor

On Sun, Dec 20, 2015 at 03:10:48PM -0500, Kevin O'Connor wrote:
> Some USB3 controllers (and/or devices) need additional time after the
> device is detected to place the port in an enabled state.  Wait for
> the controller to report enabled before proceeding.  This fixes
> several reports of devices that showed a "stall" error (cc 4) during
> set address.

FYI, I committed this change.

Wim, Zheng, Idwer - this commit appears to fix several USB3 issues.
If you are still having problems with USB3 devices, can you retry with
the latest SeaBIOS from git?

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 09:27:25PM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > SeaBIOS is careful to always disable IRQs while running C code to
> > prevent this issue, but disabling normal IRQs does not disable NMIs.
> > So, I believe this issue is specific to the nature of NMIs.
> 
> Would a dedicated NMI handler stack be a good solution?

I don't think it's possible to prevent the NMI from using the current
stack when in 16bit mode.  (There are no task gates or things like
that for 16bit interrupts, so the return address is always put on the
current stack.)

We could switch onto a dedicated stack, but the current nmi handler
doesn't really do anything so I think using the current stack is okay.
(My analysis using scripts/checkstack.py indicates entry_02 would use
34 bytes of stack space.)

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 2/2] block: Report drive->sectors using "%u" instead of "%d"

2015-12-23 Thread Kevin O'Connor

The sector count is a 64bit number that is often reported as a 32bit
number (due to limitations in dprintf).  Consistently use "%u"
reporting to avoid confusing negative numbers.

Reported-by: Tobias Diedrich 
Signed-off-by: Kevin O'Connor 
---
 src/block.c   | 2 +-
 src/hw/blockcmd.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/block.c b/src/block.c
index 1762e2a..b4530fc 100644
--- a/src/block.c
+++ b/src/block.c
@@ -162,7 +162,7 @@ setup_translation(struct drive_s *drive)
 // clip to 1024 cylinders in lchs
 if (cylinders > 1024)
 cylinders = 1024;
-dprintf(1, "drive %p: PCHS=%u/%d/%d translation=%s LCHS=%d/%d/%d s=%d\n"
+dprintf(1, "drive %p: PCHS=%u/%d/%d translation=%s LCHS=%d/%d/%d s=%u\n"
 , drive
 , drive->pchs.cylinder, drive->pchs.head, drive->pchs.sector
 , desc
diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c
index 0725b46..093c5d7 100644
--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -232,7 +232,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int 
prio)
 return -1;
 }
 drive->sectors = (u64)be32_to_cpu(capdata.sectors) + 1;
-dprintf(1, "%s blksize=%d sectors=%d\n"
+dprintf(1, "%s blksize=%d sectors=%u\n"
 , s, drive->blksize, (unsigned)drive->sectors);
 
 // We do not recover from USB stalls, so try to be safe and avoid
-- 
2.5.0


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 09:14:44PM +0100, Tobias Diedrich wrote:
> Final diff attached (without the src/stacks.c change, with %d->%u change
> for sector counts).
> Bootlog with debug_level 1 attached.

Great!  Patches sent - if no further comments I'll commit in a few
days.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH 1/2] scsi: Do not call printf() from scsi_is_ready()

2015-12-23 Thread Kevin O'Connor

The scsi_is_ready() function may be called from a thread, and it is
not valid to call printf() from a thread.  Convert printf() to
dprintf() to avoid this possibility.

This does mean that cdrom detection (from cdrom_boot() ) may not give
notification of slow cdrom drives to a user.  However, the extra
medium detection time is unlikely to be large anyway.

Reported-by: Tobias Diedrich 
Signed-off-by: Kevin O'Connor 
---
 src/hw/blockcmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c
index e20e3fc..0725b46 100644
--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
 
 if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
 /* IN PROGRESS OF BECOMING READY */
-printf("Waiting for device to detect medium... ");
+dprintf(1, "Waiting for device to detect medium... ");
 /* Allow 30 seconds more */
 end = timer_calc(3);
 in_progress = 1;
-- 
2.5.0


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] [PATCH] nmi: Don't try to switch onto extra stack in NMI handler

2015-12-23 Thread Kevin O'Connor

The NMI could occur when already on the extra stack, which would
corrupt it.  Always use the current stack on an NMI to avoid this.

Signed-off-by: Kevin O'Connor 
---
 src/romlayout.S | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/romlayout.S b/src/romlayout.S
index fedadfe..53cc0f5 100644
--- a/src/romlayout.S
+++ b/src/romlayout.S
@@ -548,7 +548,10 @@ entry_post:
 ENTRY_INTO32 _cfunc32flat_handle_post   // Normal entry point
 
 ORG 0xe2c3
-IRQ_ENTRY 02
+.global entry_02
+entry_02:
+ENTRY handle_02  // NMI handler does not switch onto extra stack
+iretw
 
 ORG 0xe3fe
 .global entry_13_official
-- 
2.5.0


___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

2015-12-23 Thread Peter Stuge

Kevin O'Connor wrote:
> SeaBIOS is careful to always disable IRQs while running C code to
> prevent this issue, but disabling normal IRQs does not disable NMIs.
> So, I believe this issue is specific to the nature of NMIs.

Would a dedicated NMI handler stack be a good solution?


//Peter

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

Final diff attached (without the src/stacks.c change, with %d->%u change
for sector counts).
Bootlog with debug_level 1 attached.


On Wed, Dec 23, 2015 at 8:56 PM, Tobias Diedrich 
wrote:

> I replaced the printf(...) with dprintf(1, ...)  (since a dprintf earlier
> in the function was working fine).
>
> This appears to have fixed the issue (though PCHS seems to be wrong, maybe
> because sector count is negative when parsed as a signed int). Full log
> attached.
>
> |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
> removable=0
> \dfc04000/ End thread
> |dfbfd000| USB MSC vendor='Multiple' product='Card  Reader' rev='1.00'
> type=0 removable=1
> |dfbfd000| Device reports MEDIUM NOT PRESENT
> |dfbfd000| scsi_is_ready returned -1
> |dfbfd000| Unable to configure USB MSC drive.
> |dfbfd000| Unable to configure USB MSC device.
> \dfbfd000/ End thread
> |dfc02000| Waiting for device to detect medium... \dfc03000/ End thread
> |dfc02000| USB MSC blksize=512 sectors=-388003840
> |dfc02000| Registering bootable: USB MSC Drive WD Elements 10B8 1012
> (type:2 prio:103 data:f6110)
> \dfc02000/ End thread
> \dfc08000/ End thread
> All threads complete.
> Scan for option roms
>
> Press ESC for boot menu.
>
>
> On Wed, Dec 23, 2015 at 7:58 PM, Kevin O'Connor 
> wrote:
>
>> On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote:
>> > On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor 
>> wrote:
>> >
>> > > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
>> > > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
>> > > esp=dfbf3e50
>> > > >
>> > > > .text._farcall16 0x9563 : { *(.text._farcall16) }
>> > > >
>> > >
>> > > Can you include the full log?  It looks like the code tried to call a
>> > > 16bit function while in a "thread", and I need to figure out which
>> > > thread did that.
>> >
>> >
>> > From the esp address it looks like it'sin the USB probe for the MSC
>> device
>> > (full log attached):
>> > /dfc02000\ Start thread func=dfc135f1
>> > |dfc02000| set_address 0xdfc0a200
>> > |dfc02000| config_usb: 0xdfc0a0d0
>> > |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
>> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5
>> /*@0/*@0,0
>> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
>> > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
>> > removable=0
>> > Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0
>> esp=dfc02e54
>> > ret=0x000f0604
>>
>> What happens if you apply the patch below?  (If it looks like it is
>> hanging, give it at least a minute before stopping it.)
>>
>> -Kevin
>>
>>
>> --- a/src/hw/blockcmd.c
>> +++ b/src/hw/blockcmd.c
>> @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
>>
>>  if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
>>  /* IN PROGRESS OF BECOMING READY */
>> -printf("Waiting for device to detect medium... ");
>> +//printf("Waiting for device to detect medium... ");
>>  /* Allow 30 seconds more */
>>  end = timer_calc(3);
>>  in_progress = 1;
>>
>
>
diff --git a/src/block.c b/src/block.c
index 1762e2a..b4530fc 100644
--- a/src/block.c
+++ b/src/block.c
@@ -162,7 +162,7 @@ setup_translation(struct drive_s *drive)
 // clip to 1024 cylinders in lchs
 if (cylinders > 1024)
 cylinders = 1024;
-dprintf(1, "drive %p: PCHS=%u/%d/%d translation=%s LCHS=%d/%d/%d s=%d\n"
+dprintf(1, "drive %p: PCHS=%u/%d/%d translation=%s LCHS=%d/%d/%d s=%u\n"
 , drive
 , drive->pchs.cylinder, drive->pchs.head, drive->pchs.sector
 , desc
diff --git a/src/hw/blockcmd.c b/src/hw/blockcmd.c
index e20e3fc..6a2e179 100644
--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
 
 if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
 /* IN PROGRESS OF BECOMING READY */
-printf("Waiting for device to detect medium... ");
+dprintf(1, "Waiting for device to detect medium...\n");
 /* Allow 30 seconds more */
 end = timer_calc(3);
 in_progress = 1;
@@ -232,7 +232,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int 
prio)
 return -1;
 }
 drive->sectors = (u64)be32_to_cpu(capdata.sectors) + 1;
-dprintf(1, "%s blksize=%d sectors=%d\n"
+dprintf(1, "%s blksize=%d sectors=%u\n"
 , s, drive->blksize, (unsigned)drive->sectors);
 
 // We do not recover from USB stalls, so try to be safe and avoid
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_210554-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_210554-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
Found coreboot cbmem

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

I replaced the printf(...) with dprintf(1, ...)  (since a dprintf earlier
in the function was working fine).

This appears to have fixed the issue (though PCHS seems to be wrong, maybe
because sector count is negative when parsed as a signed int). Full log
attached.

|dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
removable=0
\dfc04000/ End thread
|dfbfd000| USB MSC vendor='Multiple' product='Card  Reader' rev='1.00'
type=0 removable=1
|dfbfd000| Device reports MEDIUM NOT PRESENT
|dfbfd000| scsi_is_ready returned -1
|dfbfd000| Unable to configure USB MSC drive.
|dfbfd000| Unable to configure USB MSC device.
\dfbfd000/ End thread
|dfc02000| Waiting for device to detect medium... \dfc03000/ End thread
|dfc02000| USB MSC blksize=512 sectors=-388003840
|dfc02000| Registering bootable: USB MSC Drive WD Elements 10B8 1012
(type:2 prio:103 data:f6110)
\dfc02000/ End thread
\dfc08000/ End thread
All threads complete.
Scan for option roms

Press ESC for boot menu.


On Wed, Dec 23, 2015 at 7:58 PM, Kevin O'Connor  wrote:

> On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote:
> > On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor 
> wrote:
> >
> > > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> > > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
> > > esp=dfbf3e50
> > > >
> > > > .text._farcall16 0x9563 : { *(.text._farcall16) }
> > > >
> > >
> > > Can you include the full log?  It looks like the code tried to call a
> > > 16bit function while in a "thread", and I need to figure out which
> > > thread did that.
> >
> >
> > From the esp address it looks like it'sin the USB probe for the MSC
> device
> > (full log attached):
> > /dfc02000\ Start thread func=dfc135f1
> > |dfc02000| set_address 0xdfc0a200
> > |dfc02000| config_usb: 0xdfc0a0d0
> > |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5
> /*@0/*@0,0
> > |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
> > |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
> > removable=0
> > Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0
> esp=dfc02e54
> > ret=0x000f0604
>
> What happens if you apply the patch below?  (If it looks like it is
> hanging, give it at least a minute before stopping it.)
>
> -Kevin
>
>
> --- a/src/hw/blockcmd.c
> +++ b/src/hw/blockcmd.c
> @@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
>
>  if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
>  /* IN PROGRESS OF BECOMING READY */
> -printf("Waiting for device to detect medium... ");
> +//printf("Waiting for device to detect medium... ");
>  /* Allow 30 seconds more */
>  end = timer_calc(3);
>  in_progress = 1;
>
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_204524-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
Attempting to find coreboot table
Found coreboot table forwarder.
Now attempting to find coreboot memory map
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_204524-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
Found coreboot cbmem console @ dffde000
Found mainboard PC Engines APU1
malloc preinit
Relocating init from 0x000e4800 to 0xdfc0b9e0 (size 46464)
malloc init
Found CBFS header at 0xffe00138
Add romfile: cbfs master header (size=32)
Add romfile: fallback/romstage (size=168724)
Add romfile: fallback/ramstage (size=126226)
Add romfile: fallback/payload (size=60769)
Add romfile: config (size=282)
Add romfile: revision (size=569)
Add romfile: cmos.default (size=256)
Add romfile: cmos_layout.bin (size=796)
Add romfile: fallback/dsdt.aml (size=9847)
Add romfile: spd.bin (size=256)
Add romfile: payload_config (size=1585)
Add romfile: payload_revision (size=265)
Add romfile: etc/ps2-keyboard-spinup (size=8)
Add romfile:  (size=1660504)
Add romfile: s3nv (size=32768)
Add romfile:  (size=31576)
Add romfile: bootblock (size=1088)
multiboot: eax=0, ebx=0
init ivt
init bda
init bios32
init PMM
init PNPBIOS table
init keyboard
init mouse
init pic
math cp init
PCI probe
Found 27 PCI devices (max PCI bus is 05)
Relocating coreboot bios tables
Copying SMBIOS entry point from 0xdfc5f000 to 0x000f6440
Copying ACPI RSDP from 0xdfc7 to 0x000f6410
Copying MPTABLE from 0xdfc94000/dfc94010 to 0x000f6230
Copying PIR from 0xdfc95000 to 0x000f6200
Using pmtimer, ioport 0x808
init timer
Scan for VGA option rom
/dfc09000\ Start thread func=dfc0f9ed
|dfc09000| init usb
|dfc09000| EHCI init on dev 00:12.2 (regs=0xf7f04020)
/dfc08000\ Start thread func=dfc0f07e
init ps2port
/dfc07000\ Start thread func=dfc0e567
|dfc07000| WARNING - Timeout at i8042_flush:71!
\dfc07000/ End thread
|dfc09000| EHCI init on dev 00:13.2 (regs=0xf7f05020)
/dfc07000\ Start thread func=dfc0f07e
/dfc05000\ Start threa

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 07:39:56PM +0100, Tobias Diedrich wrote:
> On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor  wrote:
> 
> > On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> > > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
> > esp=dfbf3e50
> > >
> > > .text._farcall16 0x9563 : { *(.text._farcall16) }
> > >
> >
> > Can you include the full log?  It looks like the code tried to call a
> > 16bit function while in a "thread", and I need to figure out which
> > thread did that.
> 
> 
> From the esp address it looks like it'sin the USB probe for the MSC device
> (full log attached):
> /dfc02000\ Start thread func=dfc135f1
> |dfc02000| set_address 0xdfc0a200
> |dfc02000| config_usb: 0xdfc0a0d0
> |dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
> |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0
> |dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
> |dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
> removable=0
> Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0 esp=dfc02e54
> ret=0x000f0604

What happens if you apply the patch below?  (If it looks like it is
hanging, give it at least a minute before stopping it.)

-Kevin


--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -168,7 +168,7 @@ scsi_is_ready(struct disk_op_s *op)
 
 if (sense.asc == 0x04 && sense.ascq == 0x01 && !in_progress) {
 /* IN PROGRESS OF BECOMING READY */
-printf("Waiting for device to detect medium... ");
+//printf("Waiting for device to detect medium... ");
 /* Allow 30 seconds more */
 end = timer_calc(3);
 in_progress = 1;

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

On Wed, Dec 23, 2015 at 7:10 PM, Kevin O'Connor  wrote:

> On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> > Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563
> esp=dfbf3e50
> >
> > .text._farcall16 0x9563 : { *(.text._farcall16) }
> >
>
> Can you include the full log?  It looks like the code tried to call a
> 16bit function while in a "thread", and I need to figure out which
> thread did that.


>From the esp address it looks like it'sin the USB probe for the MSC device
(full log attached):
/dfc02000\ Start thread func=dfc135f1
|dfc02000| set_address 0xdfc0a200
|dfc02000| config_usb: 0xdfc0a0d0
|dfc02000| device rev=0210 cls=00 sub=00 proto=00 size=64
|dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0
|dfc02000| Searching bootorder for: /pci@i0cf8/usb@12,2/usb-*@5
|dfc02000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
removable=0
Wcall16 with invalid stack: eax=dfc02e66 edx=0 func=0x000f91f0 esp=dfc02e54
ret=0x000f0604
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_191828-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
Attempting to find coreboot table
Found coreboot table forwarder.
Now attempting to find coreboot memory map
SeaBIOS (version rel-1.9.0-43-g76327b9-dirty-20151223_191828-navi)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU 
Binutils) 2.25
Found coreboot cbmem console @ dffde000
Found mainboard PC Engines APU1
malloc preinit
Relocating init from 0x000e4800 to 0xdfc0b9e0 (size 46464)
malloc init
Found CBFS header at 0xffe00138
Add romfile: cbfs master header (size=32)
Add romfile: fallback/romstage (size=168724)
Add romfile: fallback/ramstage (size=126226)
Add romfile: fallback/payload (size=60767)
Add romfile: config (size=282)
Add romfile: revision (size=569)
Add romfile: cmos.default (size=256)
Add romfile: cmos_layout.bin (size=796)
Add romfile: fallback/dsdt.aml (size=9847)
Add romfile: spd.bin (size=256)
Add romfile: payload_config (size=1585)
Add romfile: payload_revision (size=265)
Add romfile: etc/ps2-keyboard-spinup (size=8)
Add romfile:  (size=1660504)
Add romfile: s3nv (size=32768)
Add romfile:  (size=31576)
Add romfile: bootblock (size=1088)
multiboot: eax=0, ebx=0
init ivt
init bda
init bios32
init PMM
init PNPBIOS table
init keyboard
init mouse
init pic
math cp init
PCI probe
Found 27 PCI devices (max PCI bus is 05)
Relocating coreboot bios tables
Copying SMBIOS entry point from 0xdfc5f000 to 0x000f6440
Copying ACPI RSDP from 0xdfc7 to 0x000f6410
Copying MPTABLE from 0xdfc94000/dfc94010 to 0x000f6230
Copying PIR from 0xdfc95000 to 0x000f6200
Using pmtimer, ioport 0x808
init timer
Scan for VGA option rom
/dfc09000\ Start thread func=dfc0f9ed
|dfc09000| init usb
|dfc09000| EHCI init on dev 00:12.2 (regs=0xf7f04020)
/dfc08000\ Start thread func=dfc0f07e
init ps2port
/dfc07000\ Start thread func=dfc0e567
|dfc07000| WARNING - Timeout at i8042_flush:71!
\dfc07000/ End thread
|dfc09000| EHCI init on dev 00:13.2 (regs=0xf7f05020)
/dfc07000\ Start thread func=dfc0f07e
/dfc05000\ Start thread func=dfc135f1
init lpt
Found 1 lpt ports
init serial
Found 2 serial ports
init floppy drives
init hard drives
init ahci
ebda moved from 9f000 to 9e800
AHCI controller at 11.0, iobase f7f03000, irq 11
AHCI: cap 0xf332ff05, ports_impl 0x3f
/dfc04000\ Start thread func=dfc11e79
|dfc04000| AHCI/0: probing
|dfc04000| AHCI/0: link up
|dfc09000| EHCI init on dev 00:16.2 (regs=0xf7f06020)
/dfc03000\ Start thread func=dfc0f07e
/dfc02000\ Start thread func=dfc135f1
/dfc01000\ Start thread func=dfc135f1
/dfbff000\ Start thread func=dfc11e79
|dfbff000| AHCI/1: probing
|dfbff000| AHCI/1: link up
|dfc04000| AHCI/0: ... finished, status 0x51, ERROR 0x4
|dfc09000| OHCI init on dev 00:12.0 (regs=0xf7f0)
/dfbfe000\ Start thread func=dfc0f784
/dfbfd000\ Start thread func=dfc135f1
/dfbfc000\ Start thread func=dfc135f1
/dfbfb000\ Start thread func=dfc135f1
/dfbfa000\ Start thread func=dfc11e79
|dfbfa000| AHCI/2: probing
|dfc04000| Searching bootorder for: /pci@i0cf8/*@11/drive@0/disk@0
|dfc09000| OHCI init on dev 00:13.0 (regs=0xf7f01000)
/dfbf9000\ Start thread func=dfc0f784
/dfbf8000\ Start thread func=dfc135f1
/dfbf7000\ Start thread func=dfc135f1
/dfbf6000\ Start thread func=dfc135f1
\dfbf6000/ End thread
\dfbfb000/ End thread
\dfc01000/ End thread
\dfc05000/ End thread
/dfc01000\ Start thread func=dfc11e79
|dfc01000| AHCI/3: probing
|dfbfa000| AHCI/2: link down
|dfbff000| AHCI/1: ... finished, status 0x51, ERROR 0x4
|dfc04000| AHCI/0: registering: "AHCI/0: SB mSATA SSD ATA-10 Hard-Disk (14318 
MiBytes)"
|dfc04000| Registering bootable: AHCI/0: SB mSATA SSD ATA-10 Hard-Disk (14318 
MiBytes) (type:2 prio:103 data:f6190)
\dfc04000/ End thread
|dfc09000| OHCI init on dev 00:16.0 (regs=0xf7f02000)
/dfc04000\ Start thread func=dfc0f784
/dfbfb000\ Start thread func=dfc135f1
/dfbf6000\ Start thread func=dfc135f1
\dfbf6000/ End thread
\dfbf7000/ End

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 07:13:27PM +0100, Tobias Diedrich wrote:
> Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50
> ret=0x000f2304
> 
> │.text:000F22C8 sub_F22C8   proc near   ; CODE XREF:
> sub_F2309+2Cvp
>  ▒
> │.text:000F22C8 ; sub_F2309+35vj
> 

FYI, to line up "ret" with the code, one can look in
out/romlayout32flat.lds .  I prefer to run the following though:

  objdump -m i386 -M suffix -d out/rom.o | less

and then look for the function containing the desired address.

The thread associated with esp=dfbf3e50 is key though, which is why
the full log is useful.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50
ret=0x000f2304

│.text:000F22C8 sub_F22C8   proc near   ; CODE XREF:
sub_F2309+2Cvp
 ▒
│.text:000F22C8 ; sub_F2309+35vj

  ▒
│.text:000F22C8

 ▒
│.text:000F22C8 var_2A  = byte ptr -2Ah

 ▒
│.text:000F22C8 var_1A  = byte ptr -1Ah

 ▒
│.text:000F22C8 var_E   = byte ptr -0Eh

 ▒
│.text:000F22C8 var_D   = byte ptr -0Dh

 ▒
│.text:000F22C8 var_6   = word ptr -6

 ▒
│.text:000F22C8

 ▒
│.text:000F22C8 pushebx

 ▒
│.text:000F22C9 sub esp, 28h

  ▒
│.text:000F22CC mov ebx, eax

  ▒
│.text:000F22CE mov ecx, 26h

  ▒
│.text:000F22D3 xor edx, edx

  ▒
│.text:000F22D5 lea eax, [esp+2Ch+var_2A]

 ▒
│.text:000F22D9 callsub_F1BA0

 ▒
│.text:000F22DE mov [esp+2Ch+var_6], 200h

 ▒
│.text:000F22E5 mov [esp+2Ch+var_D], 0Eh

  ▒
│.text:000F22EA mov [esp+2Ch+var_E], bl

 ·
│.text:000F22EE mov [esp+2Ch+var_1A], 7

 ▒
│.text:000F22F3 mov edx, offset word_FD2EA

  ▒
│.text:000F22F8 movzx   edx, dx

 ▒
│.text:000F22FB lea eax, [esp+2Ch+var_2A]

 ▒
│.text:000F22FF callsub_F22A6

 ▒
│.text:000F2304 add esp, 28h

  ▒
│.text:000F2307 pop ebx

 ▒
│.text:000F2308 retn

  ▒
│.text:000F2308 sub_F22C8   endp

  ▒

1ba0 R_386_PC32.text.pci_probe_devices
.text.asm.irq_trampoline_0x10 0xd2ea : { *(.text.asm.irq_trampoline_0x10) }


On Wed, Dec 23, 2015 at 6:55 PM, Kevin O'Connor  wrote:

> On Wed, Dec 23, 2015 at 12:51:30PM -0500, Kevin O'Connor wrote:
> > On Wed, Dec 23, 2015 at 04:27:55PM +0100, Tobias Diedrich wrote:
> > > And with verbose logging (level 8).
> > >
> > > [...]
> > > Wcall16 with invalid stack
> >
> > Strange.  Can you report the output with the patch below?
>
> Using the patch below would be even better.
>
> -Kevin
>
>
> --- a/src/stacks.c
> +++ b/src/stacks.c
> @@ -274,7 +274,8 @@ call16(u32 eax, u32 edx, void *func)
>  {
>  ASSERT32FLAT();
>  if (getesp() > MAIN_STACK_MAX)
> -panic("call16 with invalid stack\n");
> +panic("call16 with invalid stack eax=%x edx=%x func=%p esp=%x
> ret=%p\n"
> +  , eax, edx, func, getesp(), __builtin_return_address(0));
>  if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM)
>  return call16_smm(eax, edx, func);
>
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 07:02:37PM +0100, Tobias Diedrich wrote:
> Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50
> 
> .text._farcall16 0x9563 : { *(.text._farcall16) }
> 

Can you include the full log?  It looks like the code tried to call a
16bit function while in a "thread", and I need to figure out which
thread did that.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 06:40:12AM +, Gonglei (Arei) wrote:
> > From: Kevin O'Connor [mailto:ke...@koconnor.net]
> > On Tue, Dec 22, 2015 at 02:14:12AM +, Gonglei (Arei) wrote:
> > > Sorry, it doesn't work. What's worse is we cannot stop SeaBIOS stuck by
> > > Setting "CONFIG_ENTRY_EXTRASTACK=n" after applying this patch.
> > 
> > Oops, can you try with the patch below instead?
> > 
> 
> It works now. Thanks!
> 
> But do we need to check other possible situations
> that maybe cause *extra stack* broken or overridden?

I believe the issue is that an NMI could occur while SeaBIOS is
already using its extra stack.  The code is not prepared to switch
into the extra stack while already on the extra stack.  SeaBIOS is
careful to always disable IRQs while running C code to prevent this
issue, but disabling normal IRQs does not disable NMIs.  So, I believe
this issue is specific to the nature of NMIs.

-Kevin

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

Wcall16 with invalid stack: eax=dfbf3e62 edx=0 func=0x000f9563 esp=dfbf3e50

.text._farcall16 0x9563 : { *(.text._farcall16) }

On Wed, Dec 23, 2015 at 6:51 PM, Kevin O'Connor  wrote:

> On Wed, Dec 23, 2015 at 04:27:55PM +0100, Tobias Diedrich wrote:
> > And with verbose logging (level 8).
> >
> > [...]
> > Wcall16 with invalid stack
>
> Strange.  Can you report the output with the patch below?
>
> -Kevin
>
>
> --- a/src/stacks.c
> +++ b/src/stacks.c
> @@ -274,7 +274,8 @@ call16(u32 eax, u32 edx, void *func)
>  {
>  ASSERT32FLAT();
>  if (getesp() > MAIN_STACK_MAX)
> -panic("call16 with invalid stack\n");
> +panic("call16 with invalid stack eax=%x edx=%x func=%p esp=%x\n"
> +  , eax, edx, func, getesp());
>  if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM)
>  return call16_smm(eax, edx, func);
>
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 12:51:30PM -0500, Kevin O'Connor wrote:
> On Wed, Dec 23, 2015 at 04:27:55PM +0100, Tobias Diedrich wrote:
> > And with verbose logging (level 8).
> > 
> > [...]
> > Wcall16 with invalid stack
> 
> Strange.  Can you report the output with the patch below?

Using the patch below would be even better.

-Kevin


--- a/src/stacks.c
+++ b/src/stacks.c
@@ -274,7 +274,8 @@ call16(u32 eax, u32 edx, void *func)
 {
 ASSERT32FLAT();
 if (getesp() > MAIN_STACK_MAX)
-panic("call16 with invalid stack\n");
+panic("call16 with invalid stack eax=%x edx=%x func=%p esp=%x ret=%p\n"
+  , eax, edx, func, getesp(), __builtin_return_address(0));
 if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM)
 return call16_smm(eax, edx, func);
 

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Kevin O'Connor

On Wed, Dec 23, 2015 at 04:27:55PM +0100, Tobias Diedrich wrote:
> And with verbose logging (level 8).
> 
> [...]
> Wcall16 with invalid stack

Strange.  Can you report the output with the patch below?

-Kevin


--- a/src/stacks.c
+++ b/src/stacks.c
@@ -274,7 +274,8 @@ call16(u32 eax, u32 edx, void *func)
 {
 ASSERT32FLAT();
 if (getesp() > MAIN_STACK_MAX)
-panic("call16 with invalid stack\n");
+panic("call16 with invalid stack eax=%x edx=%x func=%p esp=%x\n"
+  , eax, edx, func, getesp());
 if (CONFIG_CALL32_SMM && Call16Data.method == C16_SMM)
 return call16_smm(eax, edx, func);
 

___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

Hi,

I've attached a WD Elements 2TB drive to my pcengines APU1 as external
storage and just found that with the disk attached SeaBIOS crashes on boot.
:/
The controller is USB2, not USB3.

Both the stock rom "Build 4/5/2014 (current production)" and a
self-compiled coreboot rom with SeaBIOS master from git
(rel-1.9.0-43-g76327b9) exhibit the same issue.

I'm not sure if
http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the
same issue since it doesn't have log messages and doesn't seem to complain
about it not booting at all.

Cheers,
Tobias
coreboot-4.2-616-gc890996 Tue Dec 22 22:07:20 UTC 2015 romstage starting...
BSP Family_Model: 00500f20
cpu_init_detectedx = 
agesawrapper_amdinitreset() returned AGESA_SUCCESS
agesawrapper_amdinitearly() returned AGESA_SUCCESS
read SPD
CBFS: 'Master Header Locator' located CBFS at [0:1fffc0)
CBFS: Locating 'spd.bin'
CBFS: Found @ offset 5a5c0 size 100
agesawrapper_amdinitpost() returned AGESA_WARNING

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.
agesawrapper_amdinitenv() returned AGESA_SUCCESS
CBFS: 'Master Header Locator' located CBFS at [0:1fffc0)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 29500 size 1ed12


coreboot-4.2-616-gc890996 Tue Dec 22 22:07:20 UTC 2015 ramstage starting...
BS: BS_PRE_DEVICE times (us): entry 0 run 2 exit 0
SB800 - Smbus.c - alink_ab_indx - Start.
SB800 - Smbus.c - alink_ab_indx - End.
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 7163 exit 0
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
DOMAIN: : enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 0
PCI: 00:04.0: enabled 1
PCI: 00:05.0: enabled 1
PCI: 00:06.0: enabled 1
PCI: 00:07.0: enabled 1
PCI: 00:08.0: enabled 1
PCI: 00:11.0: enabled 1
PCI: 00:12.0: enabled 1
PCI: 00:12.2: enabled 1
PCI: 00:13.0: enabled 1
PCI: 00:13.2: enabled 1
PCI: 00:14.0: enabled 1
PCI: 00:14.1: enabled 0
PCI: 00:14.2: enabled 0
PCI: 00:14.3: enabled 1
PNP: 002e.0: enabled 0
PNP: 002e.2: enabled 1
PNP: 002e.3: enabled 1
PNP: 002e.10: enabled 0
PNP: 002e.11: enabled 0
PNP: 002e.8: enabled 0
PNP: 002e.f: enabled 0
PNP: 002e.7: enabled 0
PNP: 002e.107: enabled 0
PNP: 002e.607: enabled 0
PNP: 002e.e: enabled 0
PCI: 00:14.4: enabled 1
PCI: 00:14.5: enabled 0
PCI: 00:15.0: enabled 1
PCI: 00:15.1: enabled 0
PCI: 00:15.2: enabled 0
PCI: 00:15.3: enabled 0
PCI: 00:16.0: enabled 1
PCI: 00:16.2: enabled 1
PCI: 00:18.0: enabled 1
PCI: 00:18.1: enabled 1
PCI: 00:18.2: enabled 1
PCI: 00:18.3: enabled 1
PCI: 00:18.4: enabled 1
PCI: 00:18.5: enabled 1
PCI: 00:18.6: enabled 1
PCI: 00:18.7: enabled 1
Compare with tree...
Root Device: enabled 1
 CPU_CLUSTER: 0: enabled 1
  APIC: 00: enabled 1
 DOMAIN: : enabled 1
  PCI: 00:00.0: enabled 1
  PCI: 00:01.0: enabled 0
  PCI: 00:04.0: enabled 1
  PCI: 00:05.0: enabled 1
  PCI: 00:06.0: enabled 1
  PCI: 00:07.0: enabled 1
  PCI: 00:08.0: enabled 1
  PCI: 00:11.0: enabled 1
  PCI: 00:12.0: enabled 1
  PCI: 00:12.2: enabled 1
  PCI: 00:13.0: enabled 1
  PCI: 00:13.2: enabled 1
  PCI: 00:14.0: enabled 1
  PCI: 00:14.1: enabled 0
  PCI: 00:14.2: enabled 0
  PCI: 00:14.3: enabled 1
   PNP: 002e.0: enabled 0
   PNP: 002e.2: enabled 1
   PNP: 002e.3: enabled 1
   PNP: 002e.10: enabled 0
   PNP: 002e.11: enabled 0
   PNP: 002e.8: enabled 0
   PNP: 002e.f: enabled 0
   PNP

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

2015-12-23 Thread Tobias Diedrich

And with verbose logging (level 8).

[...]
|dfbf9000| USB MSC vendor='WD' product='Elements 10B8' rev='1012' type=0
removable=0
|dfbf9000| scsi_is_ready (drive=0x000f5c40)
|dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31
|dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfeed2 size=18
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13
|dfbfe000| ehci_send_pipe qh=0x0009ef00 dir=128 data=0xdfbfee38 size=13
|dfbf9000| ehci_send_pipe qh=0x0009ed80 dir=0 data=0xdfbf9e45 size=31
|dfbfe000| Device reports MEDIUM NOT PRESENT
|dfbfe000| scsi_is_ready returned -1
|dfbfe000| Unable to configure USB MSC drive.
|dfbfe000| phys_free f5c70 (detail=0xdfc08fe0)
|dfbfe000| Unable to configure USB MSC device.
|dfbfe000| phys_free dfc090f0 (detail=0xdfc090c0)
|dfbfe000| phys_free dfc05400 (detail=0xdfc04e40)
\dfbfe000/ End thread
phys_free dfbfe000 (detail=0xdfc04e10)
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9ed2 size=18
|dfc02000| ehci_free_pipes 0xdfc057b0
|dfbf9000| ehci_send_pipe qh=0x0009ee00 dir=128 data=0xdfbf9e38 size=13
|dfc02000| phys_free dfc08f00 (detail=0xdfc08f70)
|dfc02000| phys_free 9ee80 (detail=0xdfc09060)
|dfc02000| phys_free 9ef00 (detail=0xdfc09090)
Wcall16 with invalid stack
[hangs here]


On Wed, Dec 23, 2015 at 4:05 PM, Tobias Diedrich 
wrote:

> Hi,
>
> I've attached a WD Elements 2TB drive to my pcengines APU1 as external
> storage and just found that with the disk attached SeaBIOS crashes on boot.
> :/
> The controller is USB2, not USB3.
>
> Both the stock rom "Build 4/5/2014 (current production)" and a
> self-compiled coreboot rom with SeaBIOS master from git
> (rel-1.9.0-43-g76327b9) exhibit the same issue.
>
> I'm not sure if
> http://www.seabios.org/pipermail/seabios/2015-November/009910.html is the
> same issue since it doesn't have log messages and doesn't seem to complain
> about it not booting at all.
>
> Cheers,
> Tobias
>
SeaBIOS (version rel-1.9.0-43-g76327b9)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU Binutils) 2.25
Attempting to find coreboot table
Found coreboot table forwarder.
Now attempting to find coreboot memory map
Add to e820 map:  1000 2
Add to e820 map: 1000 0009f000 1
Add to e820 map: 000c dfb97000 1
Add to e820 map: dfc57000 003a9000 2
Add to e820 map: f800 0400 2
Add to e820 map: 1 1f00 1
Add to e820 map:  4000 1
SeaBIOS (version rel-1.9.0-43-g76327b9)
BUILD: gcc: (coreboot toolchain v1.33 November 25th, 2015) 5.2.0 binutils: (GNU Binutils) 2.25
Found coreboot cbmem console @ dffde000
Found mainboard PC Engines APU1
malloc preinit
Add to e820 map: 000a 0005 -1
Add to e820 map: 000f 0001 2
Add to e820 map: dfc17000 0004 2
phys_alloc zone=0x000ed720 size=50560 align=20 ret=dfc0a9e0 (detail=0xdfc0a9b0)
Relocating init from 0x000e1220 to 0xdfc0a9e0 (size 50560)
malloc init
Found CBFS header at 0xffe00138
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a8b0 (detail=0xdfc0a880)
Add romfile: cbfs master header (size=32)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a7e0 (detail=0xdfc0a7b0)
Add romfile: fallback/romstage (size=168724)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a710 (detail=0xdfc0a6e0)
Add romfile: fallback/ramstage (size=126226)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a640 (detail=0xdfc0a610)
Add romfile: fallback/payload (size=67551)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a570 (detail=0xdfc0a540)
Add romfile: config (size=282)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a4a0 (detail=0xdfc0a470)
Add romfile: revision (size=569)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a3d0 (detail=0xdfc0a3a0)
Add romfile: cmos.default (size=256)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a300 (detail=0xdfc0a2d0)
Add romfile: cmos_layout.bin (size=796)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a230 (detail=0xdfc0a200)
Add romfile: fallback/dsdt.aml (size=9847)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a160 (detail=0xdfc0a130)
Add romfile: spd.bin (size=256)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc0a090 (detail=0xdfc0a060)
Add romfile: payload_config (size=1574)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09fc0 (detail=0xdfc09f90)
Add romfile: payload_revision (size=238)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09ef0 (detail=0xdfc09ec0)
Add romfile: etc/ps2-keyboard-spinup (size=8)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09e20 (detail=0xdfc09df0)
Add romfile:  (size=1653784)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09d50 (detail=0xdfc09d20)
Add romfile: s3nv (size=32768)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09c80 (detail=0xdfc09c50)
Add romfile:  (size=31576)
phys_alloc zone=0xdfc16ee0 size=156 align=10 ret=dfc09bb0 (detail=0xdfc09b80)
Add romfile: bootblock (size=1088)
multiboot: eax=0, ebx=0
init ivt
init bda
Add to e820 map: 0009f000 1

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33

2015-12-23 Thread Wim Vervoorn

Hello Kevin,

Understood.

Thanks.


Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED 
RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF 
YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER 
BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS 
MESSAGE AND ALL COPIES."




From: Stefan Berger [mailto:stef...@us.ibm.com]
Sent: Tuesday, December 22, 2015 3:30 PM
To: Wim Vervoorn 
Cc: Kevin O'Connor ; seabios@seabios.org
Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33

Wim Vervoorn mailto:wvervo...@eltan.com>> wrote on 
12/22/2015 09:15:55 AM:

>
> Hello Stefan,
>
> I think it will work perfectly for the higher level functions like :
> tpm_smbios_measure(void) etc. Here you can easily implement tpm 1.2
> and 2.0 handling. For the functions like tpm_add_measurement_to_log()
> I don’t think it is that easy or useful. For those it’s probably
> better to have a tpm 1.2 and a tpm 2.0 variant each with their own
> API but not with a wrapper.

If TPM 2 is not operated in sha1 mode, then we may need different *internal* 
functions, yes (tpm2_bar()).
Otherwise it's mostly byte streams being passed into the TPM parts to which 
sha1 is applied if needed; the
exception is the BIOS API which seems to return SHA1 hashes in some structures.

For the BIOS API functions where applications expect structures with embedded 
sha1 hashes, we will
need to restrict those APIs to sha1 mode, return failure otherwise. If the 
standard defines structures (for BIOS)
for sha256 etc.,  and possibly new API functions, then we can implement those 
for TPM 2 and they would result
in an error if invoked by TPM 1.2 (which only supports sha1).


   Stefan

>
> Please note I did not look into all details so I might be seeing
> problems that aren’t there (or can be solved easily).
>
>
> Best Regards,
> Wim Vervoorn
>
> Eltan B.V.
> Ambachtstraat 23
> 5481 SM Schijndel
> The Netherlands
>
> T : +31-(0)73-594 46 64
> E : wvervo...@eltan.com
> W : http://www.eltan.com
> "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
>
>
>
>
>
>
> From: Stefan Berger [mailto:stef...@us.ibm.com]
> Sent: Tuesday, December 22, 2015 2:56 PM
> To: Wim Vervoorn mailto:wvervo...@eltan.com>>
> Cc: Kevin O'Connor mailto:ke...@koconnor.net>>; 
> seabios@seabios.org
> Subject: RE: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
>
> Wim Vervoorn mailto:wvervo...@eltan.com>> wrote on 
> 12/22/2015 08:43:54 AM:
>
> >
> > Hello Stefan,
> >
> > I have my doubts. This will work fine as long as the toplevel
> > function tpm_foo() in your example can be implemented to have a
> > single API independent of the required support. If the API differs
> > between the tpm 1.2 and tpm 2.0 case I think it will only be
> confusing things.
> >
> > Given the differences between tpm 1.2 and 2.0 do you think you will
> > be able to maintain this single API?
>
> The top level function tpm_foo() will be called by other SeaBIOS
> code for doing TPM initialization,
> measurements, the menu, S3 resume, and for the BIOS API. For the API
> we would support the same API
> for TPM 1.2 and for TPM 2. The difference between the tpm12_foo and
> tpm2_foo functions are mainly
> that different TPM commands are created and sent to the TIS. So far,
> this works fine.
>
> Do you have concrete concerns regarding this? How else would you do it ?
>
> Regards,
>Stefan
>
> >
> >
> > Best Regards,
> > Wim Vervoorn
> >
> > Eltan B.V.
> > Ambachtstraat 23
> > 5481 SM Schijndel
> > The Netherlands
> >
> > T : +31-(0)73-594 46 64
> > E : wvervo...@eltan.com
> > W : http://www.eltan.com
> > "THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE
> > INTENDED RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS
> > STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS MESSAGE IN ERROR,
> > PLEASE IMMEDIATELY NOTIFY THE SENDER BY TELEPHONE +31-(0)73-5944664
> > OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."
> >
> >
> >
> >
> > From: Stefan Berger [mailto:stef...@us.ibm.com]
> > Sent: Monday, December 21, 2015 5:50 PM
> > To: Kevin O'Connor mailto:ke...@koconnor.net>>
> > Cc: seabios@seabios.org; Wim Vervoorn 
> > mailto:wvervo...@eltan.com>>
> > Subject: Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33
> >
> > "Kevin O'Connor" mailto:ke...@koconnor.net>> wrote on 
> > 12/17/2015 05:22:56 PM:
>

Re: [SeaBIOS] [PATCH] xhci: Wait for port enable even for USB3 devices

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

[SeaBIOS] [PATCH 2/2] block: Report drive->sectors using "%u" instead of "%d"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

[SeaBIOS] [PATCH 1/2] scsi: Do not call printf() from scsi_is_ready()

[SeaBIOS] [PATCH] nmi: Don't try to switch onto extra stack in NMI handler

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

[SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] WD Elements hang SeaBIOS at boot with "call16 with invalid stack"

Re: [SeaBIOS] SeaBIOS Digest, Vol 72, Issue 33

21 matches

Site Navigation

Mail list logo

Footer information