WD elements problem

[Wim Vervoorn]

Hello Kevin,

I hooked up an external USB 3.0 WD hard drive and found that this wasn't supported by SeaBIOS as this used 4K blocks.

Do you have plans to support this in the future in some way? Or will this simply be incompatible without plans for support. (This isn't a problem but it's good to know what the plans are).

I haven't seen any devices like that - I was under the impression the 4K drives emulated 512 byte blocks.  It should be possible to support them though.  Can you send an email to the mailing list (and include a debug log)?

BR, Wim

[Kevin O'Connor]

On Mon, Nov 09, 2015 at 02:38:39PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I hooked up an external USB 3.0 WD hard drive and found that this
>  wasn't supported by SeaBIOS as this used 4K blocks.

As an unrelated issue, I noticed the build is not able to extract the
gcc version.  What does "gcc --version" report for you?

-Kevin

[Wim Vervoorn]

Hello Kevin,

I am using 4.9.3 please note that I am building from Cygwin.

Best Regards,

Wim Vervoorn

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

T : [phone]
E : [e-mail]
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 [phone] OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Monday, November 9, 2015 5:33 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] WD elements problem

On Mon, Nov 09, 2015 at 02:38:39PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I hooked up an external USB 3.0 WD hard drive and found that this  
> wasn't supported by SeaBIOS as this used 4K blocks.

As an unrelated issue, I noticed the build is not able to extract the gcc version.  What does "gcc --version" report for you?

-Kevin

[Kevin O'Connor]

On Tue, Nov 10, 2015 at 01:10:19PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I am using 4.9.3 please note that I am building from Cygwin.

Thanks.  Can you cut-and-paste the output from "gcc --version" ?  I'd
like to figure out why the build can't extract the version
automatically.

-Kevin

[Wim Vervoorn]

wiv@wim-ws /cygdrive/C/GIT/APU2
$ gcc --version
gcc (GCC) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Tuesday, November 10, 2015 2:25 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] WD elements problem

On Tue, Nov 10, 2015 at 01:10:19PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I am using 4.9.3 please note that I am building from Cygwin.

Thanks.  Can you cut-and-paste the output from "gcc --version" ?  I'd like to figure out why the build can't extract the version automatically.

-Kevin

[Kevin O'Connor]

On Tue, Nov 10, 2015 at 01:26:56PM +0000, Wim Vervoorn wrote:
> wiv@wim-ws /cygdrive/C/GIT/APU2
> $ gcc --version
> gcc (GCC) 4.9.3
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks.  Could you grab the repo from:

git clone https://github.com/KevinOConnor/seabios.git -b testing

and cut-and-paste the build output?  That repo has some debugging
enabled in the build version extraction code.

-Kevin

[Kevin O'Connor]

On Mon, Nov 09, 2015 at 02:38:39PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I hooked up an external USB 3.0 WD hard drive and found that this wasn't supported by SeaBIOS as this used 4K blocks.

If you don't care about the data on that drive, you could try the
patches below.  (If there is any important data on the drive,
definitely don't try these patches as they could definitely cause
corruption.)

The first patch ignores the block size and continues on assuming a
block size of 512.  The second patch should only be applied after
reverting the first patch - it removes the requirement for 512 byte
blocks.

Neither of these patches is correct, but they could provide additional
information.

Thanks,
-Kevin

Patch 1:

--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -226,7 +226,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int prio)
     // READ CAPACITY returns the address of the last block.
     // We do not bother with READ CAPACITY(16) because BIOS does not support
     // 64-bit LBA anyway.
-    drive->blksize = be32_to_cpu(capdata.blksize);
+    drive->blksize = DISK_SECTOR_SIZE;
     if (drive->blksize != DISK_SECTOR_SIZE) {
         dprintf(1, "%s: unsupported block size %d\n", s, drive->blksize);
         return -1;

Patch 2:

--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -227,7 +227,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int prio)
     // We do not bother with READ CAPACITY(16) because BIOS does not support
     // 64-bit LBA anyway.
     drive->blksize = be32_to_cpu(capdata.blksize);
-    if (drive->blksize != DISK_SECTOR_SIZE) {
+    if (0) {
         dprintf(1, "%s: unsupported block size %d\n", s, drive->blksize);
         return -1;
     }

[Wim Vervoorn]

Hello Kevin,

I attached a log of both patches.

The disk was recognized in both cases but couldn't be mounted for various reasons. I booted from linux and included a dmesg to show you the Linux failure.

There was another item worth noticing as well. I started the test with the msleep left out. If I do this the disk is recognized in the bottom slot but to get it working in the top slot I needed to add the msleep unfortunately.

Best Regards,

Wim Vervoorn

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

T : [phone]
E : [e-mail]
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 [phone] OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS MESSAGE AND ALL COPIES."

-----Original Message-----
From: Kevin O'Connor [mailto:[e-mail]] 
Sent: Monday, November 9, 2015 5:50 PM
To: Wim Vervoorn 
Cc: [e-mail]
Subject: Re: [SeaBIOS] WD elements problem

On Mon, Nov 09, 2015 at 02:38:39PM +0000, Wim Vervoorn wrote:
> Hello Kevin,
>
> I hooked up an external USB 3.0 WD hard drive and found that this wasn't supported by SeaBIOS as this used 4K blocks.

If you don't care about the data on that drive, you could try the patches below.  (If there is any important data on the drive, definitely don't try these patches as they could definitely cause
corruption.)

The first patch ignores the block size and continues on assuming a block size of 512.  The second patch should only be applied after reverting the first patch - it removes the requirement for 512 byte blocks.

Neither of these patches is correct, but they could provide additional information.

Thanks,
-Kevin

Patch 1:

--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -226,7 +226,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int prio)
     // READ CAPACITY returns the address of the last block.
     // We do not bother with READ CAPACITY(16) because BIOS does not support
     // 64-bit LBA anyway.
-    drive->blksize = be32_to_cpu(capdata.blksize);
+    drive->blksize = DISK_SECTOR_SIZE;
     if (drive->blksize != DISK_SECTOR_SIZE) {
         dprintf(1, "%s: unsupported block size %d\n", s, drive->blksize);
         return -1;

Patch 2:

--- a/src/hw/blockcmd.c
+++ b/src/hw/blockcmd.c
@@ -227,7 +227,7 @@ scsi_drive_setup(struct drive_s *drive, const char *s, int prio)
     // We do not bother with READ CAPACITY(16) because BIOS does not support
     // 64-bit LBA anyway.
     drive->blksize = be32_to_cpu(capdata.blksize);
-    if (drive->blksize != DISK_SECTOR_SIZE) {
+    if (0) {
         dprintf(1, "%s: unsupported block size %d\n", s, drive->blksize);
         return -1;
     }