[SeaBIOS] EHCI boot problems

[Dave Frodin]

I'm seeing a problem booting from USB thumbdrives with commit ab9d771ce
ehci: Update usb command timeouts to use usb_xfer_time()

I'm not quite sure what the problem is other than it not liking the new
timeouts.
I couldn't see any problems with the ehci_control() calls to ehci_wait_td().
But the ehci_send_bulk() only allows the system to boot if I change
int ret = ehci_wait_td(pipe, td, end);
to
int ret = ehci_wait_td(pipe, td, timer_calc(5000));

One potential problem is that the end value is calculated once and reused
multiple times in the functions. Prior to the commit the timeout value was
passed
to the ehci_wait_td() function. Now the final end time is passed. So it
looks like
once the end timeout is reached in one of the loops that calls
ehci_wait_td() the
timer will always be expired for any other calls from that function.

One solution might be to get rid of the end variable and change the calls
from
ret = ehci_wait_td(pipe, td, end);
to
ret = ehci_wait_td(pipe, td, timer_calc(usb_xfer_time(p, datasize)));

Making the above change didn't have any impact on my booting problem until
I forced the ehci_send_bulk() timeouts to 5000.

Thanks in advance for any advice anyone can offer,
Dave
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] EHCI boot problems

[Dave Frodin]

Kevin,
With your patch I'm not seeing that timeout message get displayed.
I also forgot to mention that the USB thumbdrive will always get identified
by SeaBIOS and will be listed as a boot device but will hang as soon as it
is selected in the F12 boot menu. The activity LED on the thumbdrive only
flashes when Seabios is identifying it.

Thanks,
Dave


On Tue, Sep 9, 2014 at 2:46 PM, Kevin O'Connor ke...@koconnor.net wrote:

 On Tue, Sep 09, 2014 at 01:15:04PM -0600, Dave Frodin wrote:
  I'm seeing a problem booting from USB thumbdrives with commit ab9d771ce
  ehci: Update usb command timeouts to use usb_xfer_time()
 
  I'm not quite sure what the problem is other than it not liking the new
  timeouts.
  I couldn't see any problems with the ehci_control() calls to
 ehci_wait_td().
  But the ehci_send_bulk() only allows the system to boot if I change
  int ret = ehci_wait_td(pipe, td, end);
  to
  int ret = ehci_wait_td(pipe, td, timer_calc(5000));
 
  One potential problem is that the end value is calculated once and
 reused
  multiple times in the functions. Prior to the commit the timeout value
 was
  passed
  to the ehci_wait_td() function. Now the final end time is passed. So it
  looks like
  once the end timeout is reached in one of the loops that calls
  ehci_wait_td() the
  timer will always be expired for any other calls from that function.
 
  One solution might be to get rid of the end variable and change the
 calls
  from
  ret = ehci_wait_td(pipe, td, end);
  to
  ret = ehci_wait_td(pipe, td, timer_calc(usb_xfer_time(p, datasize)));
 
  Making the above change didn't have any impact on my booting problem
 until
  I forced the ehci_send_bulk() timeouts to 5000.

 Hi Dave,

 Stefan Burger reported a similar problem with that commit.  However,
 I'm puzzled what would be causing such a regression - five seconds
 should be more then enough time to complete a single usb transaction.

 Do you have serial debugging (or similar) available on the device you
 are working with?  If you could provide the output from the debugging
 patch below it may help diagnose the issue.

 I also got my Acer c720 back, and will run some tests on it.

 -Kevin


 --- a/src/hw/usb-ehci.c
 +++ b/src/hw/usb-ehci.c
 @@ -629,6 +629,7 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void
 *data, int datasize)
  , pipe-qh, dir, data, datasize);

  // Allocate 4 tds on stack (with required alignment)
 +u32 starttime = timer_calc(0);
  u32 end = timer_calc(usb_xfer_time(p, datasize));
  u8 tdsbuf[sizeof(struct ehci_qtd) * STACKQTDS + EHCI_QTD_ALIGN - 1];
  struct ehci_qtd *tds = (void*)ALIGN((u32)tdsbuf, EHCI_QTD_ALIGN);
 @@ -642,7 +643,7 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void
 *data, int datasize)
  struct ehci_qtd *td = tds[tdpos++ % STACKQTDS];
  int ret = ehci_wait_td(pipe, td, end);
  if (ret)
 -return -1;
 +goto fail;

  struct ehci_qtd *nexttd_fl = MAKE_FLATPTR(GET_SEG(SS)
   , tds[tdpos %
 STACKQTDS]);
 @@ -662,10 +663,15 @@ ehci_send_bulk(struct usb_pipe *p, int dir, void
 *data, int datasize)
  struct ehci_qtd *td = tds[tdpos++ % STACKQTDS];
  int ret = ehci_wait_td(pipe, td, end);
  if (ret)
 -return -1;
 +goto fail;
  }

  return 0;
 +fail:
 +dprintf(1, timeout: start=%x end=%x cur=%x time=%d devaddr=%x
 datasize=%d\n
 +, starttime, end, timer_calc(0)
 +, usb_xfer_time(p, datasize), p-devaddr, datasize);
 +return -1;
  }

  int

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

Re: [SeaBIOS] [PATCH] Add SD card support

[Dave Frodin]

Kevin,

Marc suggested that I reword what are intent was/is.
We view the SD patch as a starting point and that we would like to work
with the
community on getting it into seabios. I think that we could use help from
yourself
and David Woodhouse, who has expressed an interest in it, to improve and
further
develop the code.

Thanks,
Dave Frodin



On Wed, Jun 11, 2014 at 1:37 PM, Dave Frodin dave.fro...@se-eng.com wrote:

 Kevin,
 Our intent at this time was to just get it out for others to see/use.
 I'll try attaching the files.

 Thanks,
 Dave



 On Tue, Jun 10, 2014 at 6:19 PM, Kevin O'Connor ke...@koconnor.net
 wrote:

 On Thu, Jun 05, 2014 at 10:36:07AM -0600, Dave Frodin wrote:
  Paul,
 
  I'm resending the patch, supposedly as plain text.
  Let me know if you still see a problem.
 
  Thanks,
  Dave

 Thanks for posting this Dave.

 Is the intention to publish this, or to get this into SeaBIOS master?
 I think the patch will need a bit of work before it could be committed
 to upstream.

 [...]
  +//@NOTE:  This step appears to be unnecessary for booting from
  the sd card as the pchs info does not get used...

 BTW, the patch still got corrupted.  You might try gzipping it and
 then attaching the gzipped patch.

 -Kevin



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

Re: [SeaBIOS] [PATCH] Add SD card support

[Dave Frodin]

Kevin,
Our intent at this time was to just get it out for others to see/use.
I'll try attaching the files.

Thanks,
Dave



On Tue, Jun 10, 2014 at 6:19 PM, Kevin O'Connor ke...@koconnor.net wrote:

 On Thu, Jun 05, 2014 at 10:36:07AM -0600, Dave Frodin wrote:
  Paul,
 
  I'm resending the patch, supposedly as plain text.
  Let me know if you still see a problem.
 
  Thanks,
  Dave

 Thanks for posting this Dave.

 Is the intention to publish this, or to get this into SeaBIOS master?
 I think the patch will need a bit of work before it could be committed
 to upstream.

 [...]
  +//@NOTE:  This step appears to be unnecessary for booting from
  the sd card as the pchs info does not get used...

 BTW, the patch still got corrupted.  You might try gzipping it and
 then attaching the gzipped patch.

 -Kevin



0001-Add-SD-card-support.patch.tar.gz
Description: GNU Zip compressed data
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] MP Table corruption

[Dave Frodin]

Kevin,

Comments are inline.

Thanks,
Dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Tuesday, October 8, 2013 7:26:25 PM
 Subject: Re: [SeaBIOS] MP Table corruption
 
 On Tue, Oct 08, 2013 at 05:27:34PM -0500, Dave Frodin wrote:
  We have a customer that runs a RTOS that uses the MP Tables (rather
  than ACPI).  They are having an issue with the RTOS not being able
  to determine certain system interrupt settings from the MP
  tables. The sent me a MPDiag utility (this may be their own MPDiag
  utility, I believe I've seen others) that exposes the problem. Using
  it I was able to determine that the mptable that coreboot generates
  is getting corrupted somehow by seabios. When I bisected seabios I
  found that there are several commits that cause the mptable
  corruption. The first two problem commits are ...
  5DBF1732
  ECA5A947
 
 This is on coreboot, right?

Yes this is for a coreboot build.

 I don't see a commit ECA5A947 in seabios,

Oooops. I rebased and deleted 5DBF1732 after I bisected down to it.
The 2nd commit that breaks the MPtable is actually A2A86E29.
Sorry for the confusion.

 and I don't see how 5DBF1732 could impact mptable.  I guess it's
 possible that 5DBF1732 could impact the interrupts as we no longer run
 a sipi on all the processors, but I don't think SeaBIOS should have to
 issue a sipi - if that is doing something that impacts the OS then
 coreboot should do it as part of initializing the processors.
 
 -Kevin
 

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

[SeaBIOS] MP Table corruption

[Dave Frodin]

We have a customer that runs a RTOS that uses the MP Tables (rather than ACPI). 
They are having an issue with the RTOS not being able to determine certain 
system interrupt 
settings from the MP tables. The sent me a MPDiag utility (this may be their 
own MPDiag utility, I 
believe I've seen others) that exposes the problem. Using it I was able to 
determine that the mptable 
that coreboot generates is getting corrupted somehow by seabios. When I 
bisected seabios I found 
that there are several commits that cause the mptable corruption. The first two 
problem commits are ... 
5DBF1732 
ECA5A947 
I reverted both of those commits and still had issues, so for the short term 
solution I just used a 
seabios branch based off of 4EDDA08 (which is the commit that precedes 
5DBF1732) to allow 
the customers MPDiag to pass. 

Has anybody else seen an issue like this? 
Anybody have any suggestions on how to approach fixing this? 

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

Re: [SeaBIOS] Commit b98a4b1 prevents USB drives from being detected

[Dave Frodin]

Kevin,

Your patch does fix the problem with USB thumbdrives.
I tested on a Gizmo (Family14/SB800) board.

Thanks,
Dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Sunday, July 14, 2013 11:59:11 AM
 Subject: Re: [SeaBIOS] Commit b98a4b1 prevents USB drives from being detected
 
 On Fri, Jul 12, 2013 at 03:22:43PM -0500, Dave Frodin wrote:
 
  I'm using the current seabios (master or stable) as a payload for
  coreboot.  If I build the current seabios I've found that commit
  b98a4b1 Convert PCIDevices list to use standard list manipultion
  code.  prevents the system from finding USB thumbdrives. The USB
  keyboard and mouse still work.
 
 Thanks.  The PCI list changes broke the ordering of the PCIDevices
 list.  Can you confirm the patch below fixes it for you?
 
 -Kevin
 
 
 commit 2a9aeabdfb34374ecac25e7a8d21c9e368618cd4
 Author: Kevin O'Connor ke...@koconnor.net
 Date:   Sun Jul 14 13:55:52 2013 -0400
 
 Fix USB EHCI detection that was broken in hlist conversion of PCIDevices.
 
 Make sure the PCI device list is ordered in bus order.
 
 Don't iterate past the end of the list when detecting EHCI devices.
 
 Signed-off-by: Kevin O'Connor ke...@koconnor.net
 
 diff --git a/src/pci.c b/src/pci.c
 index 6163a29..dc62c5c 100644
 --- a/src/pci.c
 +++ b/src/pci.c
 @@ -122,6 +122,7 @@ pci_probe_devices(void)
  }
  memset(dev, 0, sizeof(*dev));
  hlist_add(dev-node, pprev);
 +pprev = dev-node.next;
  count++;
  
  // Find parent device.
 diff --git a/src/usb.c b/src/usb.c
 index ecccd75..42541ff 100644
 --- a/src/usb.c
 +++ b/src/usb.c
 @@ -444,7 +444,7 @@ usb_setup(void)
  }
  if (ehcipci-class == PCI_CLASS_SERIAL_USB)
  found++;
 -ehcipci = container_of(
 +ehcipci = container_of_or_null(
  ehcipci-node.next, struct pci_device, node);
  if (!ehcipci || (pci_bdf_to_busdev(ehcipci-bdf)
   != pci_bdf_to_busdev(pci-bdf)))
 

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

[SeaBIOS] Commit b98a4b1 prevents USB drives from being detected

[Dave Frodin]

I'm using the current seabios (master or stable) as a payload for coreboot. 
If I build the current seabios I've found that commit b98a4b1 Convert 
PCIDevices list to use standard list manipultion code. 
prevents the system from finding USB thumbdrives. The USB keyboard and mouse 
still work. 

This problem occurs for multiple mainboards (persimmon/parmer/gizmo). 

Let me know if there's something else I can try for anybody. 

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

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

Kevin,

I talked with Marc Jones about this and he sees value in the method I've 
proposed.
He also predicts that this will be an issue in the future on Intel motherboards.

The one major difference is that if you were building coreboot for a Family15 
mainboard
you would only need to add one file (vendev_map) rather than 20 alias mapping 
files to
CBFS. I agree that the parsing code is more than clunky (what I wouldn't give 
for a sscanf()),
perhaps my patch could use some changes rather than throwing it out.

I'll re-attach my patch in case anybody wants to review it.

Thanks again,
Dave


- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Tuesday, July 2, 2013 10:29:39 PM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 On Tue, Jul 02, 2013 at 07:40:17AM -0500, Dave Frodin wrote:
  Kevin,
  
  Did you ever get a chance to look over this patch?
 
 I don't see the gain in introducing a config file parser for this
 task.  What was wrong with the approach of creating alias files?
 
 -Kevin
 
From 907686ae6a41a0cb75d0ff2a565586b6f4e25615 Mon Sep 17 00:00:00 2001
From: Dave Frodin dave.fro...@se-eng.com
Date: Thu, 23 May 2013 16:07:17 -0600
Subject: [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

This feature was added to allow mapping multiple different PCI
vendor/device IDs to a single ID. It allows a coreboot/seabios ROM
image to be used on a mainboard whose graphics ID will vary depending
on which cpu is installed. The intent is to have the coreboot mainboard
define its VGA_BIOS_ID as the ID that is present in the actual VGA BIOS.
The PCI ID of all possible graphics IDs would then be mapped to that ID.
It may have use for other PCI devices where a single option ROM can be
used with PCI devices with varying IDs.

Signed-off-by: Dave Frodin dave.fro...@se-eng.com
---
 src/optionroms.c | 87 +++-
 1 file changed, 86 insertions(+), 1 deletion(-)

diff --git a/src/optionroms.c b/src/optionroms.c
index ac92613..3b86244 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -177,13 +177,98 @@ deploy_romfile(struct romfile_s *file)
 return rom;
 }
 
+/* Read up to 8 ascii chars plus one non-convertible character from a
+ * string and convert to binary.
+ */
+static u32
+text_to_binary( char **ptr )
+{
+u32 data = 0;
+u8 loop = 0;
+if (*ptr == NULL)
+return data;
+for ( ; ; (*ptr)++ ) {
+if ((**ptr = '0')  ( **ptr = '9'))
+data = (data * 0x10) + (**ptr - '0');
+else if ((**ptr = 'a')  (**ptr = 'f'))
+data = (data * 0x10) + (**ptr - 'a' + 0x0A);
+else if ((**ptr = 'A')  (**ptr = 'F'))
+data = (data * 0x10) + (**ptr - 'A' + 0x0A);
+else
+break;
+if (++loop = 9)
+break;
+}
+(*ptr)++; /* point to the char after the non-convertible char */
+return data;
+}
+
+/* Allow mapping of multiple different PCI IDs to a single ID. A single AMD
+ * VGA BIOS will quite often be used on hardware that reports different
+ * PCI graphics IDs. This allows a mainboard to have a single definition
+ * (which would match the ID in the option ROM) yet would support multiple
+ * CPU IDs.
+ * Example vendev-map format for AMD Family14 (ID=1002) vgabios.
+ *10029803-10029802
+ *10029804-10029802
+ *10029805-10029802
+ *10029806-10029802
+ *10029807-10029802
+ *10029808-10029802
+ *10029809-10029802
+ */
+#define MAP_FILE_STATUS_UNINITED 0
+#define MAP_FILE_STATUS_GOOD 1
+#define MAP_FILE_STATUS_NOEXIST  2
+#define MAP_FILE_STATUS_USED 3
+#define MAPPER_BYTES_PER_LINE18 /* U32 src, '-', U32 dst, 0x0A */
+
+static u32
+map_oprom_vendev(u32 vendev)
+{
+static char *filedata = NULL;
+static int filesize = 0, map_status = MAP_FILE_STATUS_UNINITED;
+u32 vendev_src = 0, vendev_dst = 0;
+char *tmp_ptr;
+int i;
+
+if ((map_status == MAP_FILE_STATUS_NOEXIST) ||
+(map_status == MAP_FILE_STATUS_USED))
+return vendev;
+
+if (map_status == MAP_FILE_STATUS_UNINITED) {
+filedata = romfile_loadfile(vendev-map, filesize);
+if (!filedata) {
+map_status = MAP_FILE_STATUS_NOEXIST;
+return vendev;
+}
+else
+map_status = MAP_FILE_STATUS_GOOD;
+}
+
+tmp_ptr = filedata;
+for (i=0; i  filesize/MAPPER_BYTES_PER_LINE; i++) {
+vendev_src = text_to_binary( tmp_ptr );
+vendev_dst = text_to_binary( tmp_ptr );
+dprintf(5, map %d: src=%x dst=%x\n, i, vendev_src, vendev_dst);
+if ( vendev_src == vendev) {
+dprintf(1, Mapping PCI device %8x to %8x\n,vendev, vendev_dst);
+map_status = MAP_FILE_STATUS_USED;
+free(filedata);
+return vendev_dst;
+}
+}
+return vendev

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

Kevin,

Did you ever get a chance to look over this patch?

Thanks,
Dave

- Original Message -
 From: Dave Frodin dave.fro...@se-eng.com
 To: Kevin O'Connor ke...@koconnor.net
 Cc: seabios seabios@seabios.org
 Sent: Wednesday, June 5, 2013 8:45:11 AM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 Kevin,
 
 Attached is the new option rom mapping patch.
 I was hunting around for an existing SeaBIOS ftn that would convert
 ascii strings to a binary value (i.e. sscanf) but couldn't find one.
 If there's already one in the code I can replace the text_to_binary()
 with it.
 
 I tested this on a AMD family14 platform. The vendev-map file I added
 to CBFS looks like this...
 
 10029803-10029802
 10029804-10029802
 10029805-10029802
 10029806-10029802
 10029807-10029802
 10029808-10029802
 10029809-10029802
 
 Each line ends with a NEWLINE character (0x0A).
 
 On my test platform the actual graphics ID of the part is 10029804.
 The vgabios gets added to CBFS with the name pci1002,9802.rom.
 
 Thanks,
 Dave
 ___
 SeaBIOS mailing list
 SeaBIOS@seabios.org
 http://www.seabios.org/mailman/listinfo/seabios
 

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

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

Kevin,

Attached is the new option rom mapping patch.
I was hunting around for an existing SeaBIOS ftn that would convert
ascii strings to a binary value (i.e. sscanf) but couldn't find one.
If there's already one in the code I can replace the text_to_binary()
with it.

I tested this on a AMD family14 platform. The vendev-map file I added
to CBFS looks like this...

10029803-10029802
10029804-10029802
10029805-10029802
10029806-10029802
10029807-10029802
10029808-10029802
10029809-10029802

Each line ends with a NEWLINE character (0x0A).

On my test platform the actual graphics ID of the part is 10029804.
The vgabios gets added to CBFS with the name pci1002,9802.rom.

Thanks,
DaveFrom 907686ae6a41a0cb75d0ff2a565586b6f4e25615 Mon Sep 17 00:00:00 2001
From: Dave Frodin dave.fro...@se-eng.com
Date: Thu, 23 May 2013 16:07:17 -0600
Subject: [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

This feature was added to allow mapping multiple different PCI
vendor/device IDs to a single ID. It allows a coreboot/seabios ROM
image to be used on a mainboard whose graphics ID will vary depending
on which cpu is installed. The intent is to have the coreboot mainboard
define its VGA_BIOS_ID as the ID that is present in the actual VGA BIOS.
The PCI ID of all possible graphics IDs would then be mapped to that ID.
It may have use for other PCI devices where a single option ROM can be
used with PCI devices with varying IDs.

Signed-off-by: Dave Frodin dave.fro...@se-eng.com
---
 src/optionroms.c | 87 +++-
 1 file changed, 86 insertions(+), 1 deletion(-)

diff --git a/src/optionroms.c b/src/optionroms.c
index ac92613..3b86244 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -177,13 +177,98 @@ deploy_romfile(struct romfile_s *file)
 return rom;
 }
 
+/* Read up to 8 ascii chars plus one non-convertible character from a
+ * string and convert to binary.
+ */
+static u32
+text_to_binary( char **ptr )
+{
+u32 data = 0;
+u8 loop = 0;
+if (*ptr == NULL)
+return data;
+for ( ; ; (*ptr)++ ) {
+if ((**ptr = '0')  ( **ptr = '9'))
+data = (data * 0x10) + (**ptr - '0');
+else if ((**ptr = 'a')  (**ptr = 'f'))
+data = (data * 0x10) + (**ptr - 'a' + 0x0A);
+else if ((**ptr = 'A')  (**ptr = 'F'))
+data = (data * 0x10) + (**ptr - 'A' + 0x0A);
+else
+break;
+if (++loop = 9)
+break;
+}
+(*ptr)++; /* point to the char after the non-convertible char */
+return data;
+}
+
+/* Allow mapping of multiple different PCI IDs to a single ID. A single AMD
+ * VGA BIOS will quite often be used on hardware that reports different
+ * PCI graphics IDs. This allows a mainboard to have a single definition
+ * (which would match the ID in the option ROM) yet would support multiple
+ * CPU IDs.
+ * Example vendev-map format for AMD Family14 (ID=1002) vgabios.
+ *10029803-10029802
+ *10029804-10029802
+ *10029805-10029802
+ *10029806-10029802
+ *10029807-10029802
+ *10029808-10029802
+ *10029809-10029802
+ */
+#define MAP_FILE_STATUS_UNINITED 0
+#define MAP_FILE_STATUS_GOOD 1
+#define MAP_FILE_STATUS_NOEXIST  2
+#define MAP_FILE_STATUS_USED 3
+#define MAPPER_BYTES_PER_LINE18 /* U32 src, '-', U32 dst, 0x0A */
+
+static u32
+map_oprom_vendev(u32 vendev)
+{
+static char *filedata = NULL;
+static int filesize = 0, map_status = MAP_FILE_STATUS_UNINITED;
+u32 vendev_src = 0, vendev_dst = 0;
+char *tmp_ptr;
+int i;
+
+if ((map_status == MAP_FILE_STATUS_NOEXIST) ||
+(map_status == MAP_FILE_STATUS_USED))
+return vendev;
+
+if (map_status == MAP_FILE_STATUS_UNINITED) {
+filedata = romfile_loadfile(vendev-map, filesize);
+if (!filedata) {
+map_status = MAP_FILE_STATUS_NOEXIST;
+return vendev;
+}
+else
+map_status = MAP_FILE_STATUS_GOOD;
+}
+
+tmp_ptr = filedata;
+for (i=0; i  filesize/MAPPER_BYTES_PER_LINE; i++) {
+vendev_src = text_to_binary( tmp_ptr );
+vendev_dst = text_to_binary( tmp_ptr );
+dprintf(5, map %d: src=%x dst=%x\n, i, vendev_src, vendev_dst);
+if ( vendev_src == vendev) {
+dprintf(1, Mapping PCI device %8x to %8x\n,vendev, vendev_dst);
+map_status = MAP_FILE_STATUS_USED;
+free(filedata);
+return vendev_dst;
+}
+}
+return vendev;
+}
+
 // Check if an option rom is at a hardcoded location or in CBFS.
 static struct rom_header *
 lookup_hardcode(struct pci_device *pci)
 {
 char fname[17];
+u32 vendev = map_oprom_vendev((pci-vendor  16) | pci-device);
 snprintf(fname, sizeof(fname), pci%04x,%04x.rom
- , pci-vendor, pci-device);
+ , vendev  16, vendev  0x);
 struct romfile_s *file = romfile_find(fname);
 if (file)
 return deploy_romfile(file

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Friday, May 31, 2013 9:18:21 PM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 On Fri, May 31, 2013 at 08:32:16AM -0500, Dave Frodin wrote:
  I see now, that's pretty slick. The problem I see with that approach is
  that coreboot would need to add all of these files for a family14
  mainboard.
 [...]
  And all of these files for a family15 mainboard
 [...]
  
  Since at build time we only know what cpu family the rom is being
  built for and not (necessarily) what the exact graphics ID is.
  
  The method I proposed would have one family specific vendev-map.bin file.
 
 Yes, but it would be quite difficult to inspect vendev-map.bin.  I
 think an ascii interface is preferable.
 
 One could go a level up and make a symbolic link type in cbfs (this
 is effectively what my patch did).  The advantage would be that
 cbfstool could display it in a nicer format.
 
 -Kevin

I agree with that, and marc made the same suggestion. I'll put together a
new patch next week.

Dave

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

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Thursday, May 30, 2013 7:45:13 PM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 On Thu, May 30, 2013 at 07:49:36AM -0500, Dave Frodin wrote:
   From: Kevin O'Connor ke...@koconnor.net
   --- a/src/optionroms.c
   +++ b/src/optionroms.c
   @@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
static struct rom_header *
lookup_hardcode(struct pci_device *pci)
{
   -char fname[17];
   -snprintf(fname, sizeof(fname), pci%04x,%04x.rom
   +struct romfile_s *file;
   +char fname[19];
   +snprintf(fname, sizeof(fname), alias%04x,%04x.rom
 , pci-vendor, pci-device);
   -struct romfile_s *file = romfile_find(fname);
   +char *alias = romfile_loadfile(fname, NULL);
   +if (alias) {
   +file = romfile_find(alias);
   +free(alias);
   +} else {
   +snprintf(fname, sizeof(fname), pci%04x,%04x.rom
   + , pci-vendor, pci-device);
   +file = romfile_find(fname);
   +}
if (file)
return deploy_romfile(file);
return NULL;
  
  
  In your sample code above, I don't see where any pci ID translation
  (mapping) occurs.
  As an example we could have a family14 mainboard with a coreboot
  .config that generates a vga option rom with the name
  pci1002,9802.rom. The actual mainboard could have a graphics chip
  with the id of 1002,9804 (which is 1 of 8 possible IDs). So there
  needs to be some sort of mapping function (in SeaBIOS) that maps the
  ID of 1002,9804 to 1002,9802.
 
 With the above patch (assuming it works) one should be able to create
 a CBFS file named alias1002,9804.rom that contains the text
 pci1002,9802.rom.
 
 -Kevin

I see now, that's pretty slick. The problem I see with that approach is
that coreboot would need to add all of these files for a family14 mainboard.
alias1002,9803.rom
alias1002,9804.rom
alias1002,9805.rom
alias1002,9806.rom
alias1002,9807.rom
alias1002,9808.rom
alias1002,9809.rom

And all of these files for a family15 mainboard
alias1002,9901.rom
alias1002,9903.rom
alias1002,9904.rom
alias1002,9906.rom
alias1002,9907.rom
alias1002,9908.rom
alias1002,990a.rom
alias1002,9910.rom
alias1002,9913.rom
alias1002,9917.rom
alias1002,9918.rom
alias1002,9919.rom
alias1002,9990.rom
alias1002,9991.rom
alias1002,9992.rom
alias1002,9993.rom
alias1002,9994.rom
alias1002,99a0.rom
alias1002,99a2.rom
alias1002,99a4.rom

Since at build time we only know what cpu family the rom is being
built for and not (necessarily) what the exact graphics ID is.

The method I proposed would have one family specific vendev-map.bin file.

Someone who's building a rom for a mainboard with a single known graphics
ID wouldn't need to add any files with either method.

Thanks, Dave

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

Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Saturday, May 25, 2013 10:47:42 AM
 Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option 
 ROMs to one
 
 On Fri, May 24, 2013 at 09:06:54AM -0500, Dave Frodin wrote:
  Kevin,
  
  Thanks.
  The new patch that I've attached no longer alters the pci device struct.
  I also no longer repeatedly read the file in from CBFS, but keep the
  pointer to it around for the next time the function is called.
  
  As far as the use case is concerned. We (or a client) will often have
  several of
  the same mainboard (e.g. persimmon), but the graphics ID will vary
  depending on
  which version of the cpu is installed. Previously, we would have to figure
  out
  what the PCI ID of the graphics devices was, adjust the ID in coreboot's
  config,
  build/flash the new rom image. This seabios change along with a change to
  coreboot to set the ID and stuff the correct vendev mapping file into CBFS
  will allow a single coreboot/seabios image to be used on any particular
  mainboard independent of what cpu was installed. This change won't be
  useful
  to someone who is using a single board who's graphics ID would never
  change.
  For that case they wouldn't need to do anything. If the vendev mapping file
  doesn't get added they would see no difference.
 
 Thanks.
 
 Why not just place the rom in vgaroms/ directory where it will
 always be run?

That is an option but I was hoping to reduce the number of configuration
differences between having coreboot vs seabios load/run the vga option rom.
Currently, coreboot has vendor/device ID mapping functions for the family14,
family15tn northbridges.

 Also, I think we could avoid the binary structure in CBFS.  Something
 like the below (totally untested).
 
 -Kevin
 
 
 --- a/src/optionroms.c
 +++ b/src/optionroms.c
 @@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
  static struct rom_header *
  lookup_hardcode(struct pci_device *pci)
  {
 -char fname[17];
 -snprintf(fname, sizeof(fname), pci%04x,%04x.rom
 +struct romfile_s *file;
 +char fname[19];
 +snprintf(fname, sizeof(fname), alias%04x,%04x.rom
   , pci-vendor, pci-device);
 -struct romfile_s *file = romfile_find(fname);
 +char *alias = romfile_loadfile(fname, NULL);
 +if (alias) {
 +file = romfile_find(alias);
 +free(alias);
 +} else {
 +snprintf(fname, sizeof(fname), pci%04x,%04x.rom
 + , pci-vendor, pci-device);
 +file = romfile_find(fname);
 +}
  if (file)
  return deploy_romfile(file);
  return NULL;


In your sample code above, I don't see where any pci ID translation (mapping) 
occurs.

As an example we could have a family14 mainboard with a coreboot .config that 
generates
a vga option rom with the name pci1002,9802.rom. The actual mainboard could 
have a
graphics chip with the id of 1002,9804 (which is 1 of 8 possible IDs). So there 
needs
to be some sort of mapping function (in SeaBIOS) that maps the ID of 1002,9804 
to 1002,9802.

Thanks again,
Dave

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

[SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one

[Dave Frodin]

All, 
This is a patch that reproduces the vendor ID mapping that is done in 
coreboot in the various AMD northbridge's. The coreboot mapping is only 
useful if coreboot is used to run the vga bios. If seabios is the payload 
then most coreboot configs leave the vga bios init for it. 



From 5b7f2ba9f43fbc67a81a2449d8bbd3d2f6e530aa Mon Sep 17 00:00:00 2001 
From: Dave Frodin dave.fro...@se-eng.com 
Date: Tue, 7 May 2013 13:51:56 -0600 
Subject: [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one 

This feature was added to allow mapping multiple different 
PCI graphics vendor/device IDs to a single ID. The intent is 
to have the coreboot mainboard define its VGA_BIOS_ID as the 
ID that is present in the actual VGA BIOS. The PCI ID of the 
graphics device would then be mapped to that ID. 

Change-Id: Id06a1c9730546070146932a4dc8ab8229c4a59b9 
Signed-off-by: Dave Frodin dave.fro...@se-eng.com 
--- 
src/optionroms.c | 69 +- 
1 files changed, 68 insertions(+), 1 deletions(-) 

diff --git a/src/optionroms.c b/src/optionroms.c 
index 00697b2..bf1e977 100644 
--- a/src/optionroms.c 
+++ b/src/optionroms.c 
@@ -154,7 +154,6 @@ getRomPriority(u64 *sources, struct rom_header *rom, int 
instance) 
return bootprio_find_named_rom(file-name, instance); 
} 

- 
/ 
* Roms in CBFS 
/ 
@@ -174,11 +173,79 @@ deploy_romfile(struct romfile_s *file) 
return rom; 
} 

+/* Allow mapping of multiple different PCI IDs to a single ID. A single AMD 
+ * VGA BIOS will quite often be used on hardware that reports different 
+ * PCI graphics IDs. This allows a mainboard to have a single definition 
+ * (which would match the ID in the VGA BIOS) yet would support multiple 
+ * CPU IDs. 
+ */ 
+static u32 
+map_oprom_vendev(u32 vendev) 
+{ 
+ u32 new_vendev = vendev; 
+ 
+ switch (vendev) { 
+ case 0x10029803: // Family14 
+ case 0x10029804: 
+ case 0x10029805: 
+ case 0x10029806: 
+ case 0x10029807: 
+ case 0x10029808: 
+ case 0x10029809: 
+ new_vendev = 0x10029802; 
+ break; 
+ case 0x10029901: // Family15tn 
+ case 0x10029903: 
+ case 0x10029904: 
+ case 0x10029906: 
+ case 0x10029907: 
+ case 0x10029908: 
+ case 0x1002990A: 
+ case 0x10029910: 
+ case 0x10029913: 
+ case 0x10029917: 
+ case 0x10029918: 
+ case 0x10029919: 
+ case 0x10029990: 
+ case 0x10029991: 
+ case 0x10029992: 
+ case 0x10029993: 
+ case 0x10029994: 
+ case 0x100299A0: 
+ case 0x100299A2: 
+ case 0x100299A4: 
+ new_vendev = 0x10029900; 
+ break; 
+ case 0x10029831: // Family16kb 
+ case 0x10029832: 
+ case 0x10029833: 
+ case 0x10029834: 
+ case 0x10029835: 
+ case 0x10029836: 
+ case 0x10029837: 
+ case 0x10029839: 
+ case 0x1002983D: 
+ new_vendev = 0x10029830; 
+ break; 
+ default: 
+ break; 
+ } 
+ if (vendev != new_vendev) 
+ dprintf(1, Mapping PCI device %8x to %8x\n,vendev, new_vendev); 
+ return new_vendev; 
+} 
+ 
// Check if an option rom is at a hardcoded location or in CBFS. 
static struct rom_header * 
lookup_hardcode(struct pci_device *pci) 
{ 
char fname[17]; 
+ u32 vendev_mapped; 
+ 
+ vendev_mapped = map_oprom_vendev((pci-vendor  16) | pci-device); 
+ pci-vendor = vendev_mapped  16; 
+ pci-device = vendev_mapped  0x; 
+ 
snprintf(fname, sizeof(fname), pci%04x,%04x.rom 
, pci-vendor, pci-device); 
struct romfile_s *file = romfile_find(fname); 
-- 
1.7.9 

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

Re: [SeaBIOS] Get rid of a compile time dprintf warning

[Dave Frodin]

Thanks for looking into this.

I'm using gcc version 4.6.3

  
  I'm building this in cygwin, and using our (Sage's) toolchain.
 
 What version of gcc is it?
 
 If I change the format to %ld I get:
 
   Compile checking out/post.o
 src/post.c: In function ‘reloc_init’:
 src/post.c:350:5: warning: format ‘%ld’ expects argument of type
 ‘long int’, but argument 4 has type ‘int’ [-Wformat]
 
 Which is what I'd expect.  Maybe there is something odd with your
 version of gcc?
 
 $ gcc --version
 gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
 
 and I get similar behavior with gcc v3.4.
 
 -Kevin
 

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

Re: [SeaBIOS] Get rid of a compile time dprintf warning

[Dave Frodin]

Here's a patch that's been lingering awhile. 
thanks, 
Dave 

- Original Message -

 From: Dave Frodin dave.fro...@se-eng.com
 To: seabios seabios@seabios.org
 Sent: Wednesday, October 17, 2012 9:30:01 AM
 Subject: Get rid of a compile time dprintf warning

 This patch gets rid of a compile time dprintf warning.
 A 'long int' was being passed to a '%d'.

 Signed-off-by: Dave Frodin dave.fro...@se-eng.com
 ---
 src/post.c | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/src/post.c b/src/post.c
 index 924b311..b84d19e 100644
 --- a/src/post.c
 +++ b/src/post.c
 @@ -345,7 +345,7 @@ reloc_init(void)
 panic(No space for init relocation.\n);

 // Copy code and update relocs (init absolute, init relative, and
 runtime)
 - dprintf(1, Relocating low data from %p to %p (size %d)\n
 + dprintf(1, Relocating low data from %p to %p (size %ld)\n
 , datalow_start, final_datalow_start, datalow_end - datalow_start);
 updateRelocs(code32flat_start, _reloc_datalow_start,
 _reloc_datalow_end
 , final_datalow_start - datalow_start);
 --
 1.7.9
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] Get rid of a compile time dprintf warning

[Dave Frodin]

Kevin,

Here are some of the lines from the output stream...

  Compile checking out/esp-scsi.o
  Compile checking out/megasas.o
  Compile checking out/post.o
src/post.c: In function 'reloc_init':
src/post.c:350:5: warning: format '%d' expects argument of type 'int', but 
argument 4 has type 'long int' [-Wformat]
  Compile checking out/shadow.o
  Compile checking out/memmap.o
  Compile checking out/coreboot.o

I'm building this in cygwin, and using our (Sage's) toolchain.

thanks,
Dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: seabios seabios@seabios.org
 Sent: Wednesday, January 9, 2013 4:54:28 PM
 Subject: Re: [SeaBIOS] Get rid of a compile time dprintf warning
 
 On Wed, Jan 09, 2013 at 08:34:18AM -0600, Dave Frodin wrote:
  Here's a patch that's been lingering awhile.
  thanks,
 
 Thanks.  I don't receive a warning for this - what is the exact
 warning you receive?  I don't see why gcc would convert (datalow_end
 -
 datalow_start) to a long.
 
 -Kevin
 

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

Re: [SeaBIOS] I2C console16/32 segment problems

[Dave Frodin]

I found a solution to my problem. My I2C code relies on using several static 
int variables. 
In order to get the code to build I had to change them to global and add the 
VAR16VISIBLE definition. 

int i2c_inited VAR16VISIBLE = 0; 

My static i2c_inited variable doesn't need global visibility. Is there a 
better way to do this in SeaBIOS so 
that they are static local variables rather than global and still satisfy the 
16/32 segment stuff? 

thanks in advance, 
Dave 
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] I2C console16/32 segment problems

[Dave Frodin]

All, 

I've added code to output.c to implement a I2C console interface. 
Everything was working great on my AMD/Persimmon until I added additional code 
to determine what south bridge I was on. I'm evidently not correctly handling 
the 16/32 bit code segments correctly. It's evident when I run the debugger 
and watch the disassembly. Not only is the disassembly wrong but it isn't 
even consistent between runs. 

The new code is below, along with the modified putc_debug(). 

Any suggestions would be appreciated. 

Thanks, 
Dave 


#if MODE16 
#define FIXUP_CODE_SEG_LOCATION VAR16 
#elif MODESEGMENT 
#define FIXUP_CODE_SEG_LOCATION VAR32SEG 
#else 
#define FIXUP_CODE_SEG_LOCATION 
#endif 

struct amd_i2c_list{ 
u16 sb_ven; 
u16 sb_dev; 
u8 sb_ver; 
u8 base_access; 
}; 

/* send a debug character to the i2c port */ 
static void debug_i2c(char data) 
{ 
static int FIXUP_CODE_SEG_LOCATION i2c_amd_iobase = 0; 
static int FIXUP_CODE_SEG_LOCATION i2c_inited = 0; 

static const FIXUP_CODE_SEG_LOCATION struct amd_i2c_list amd_smbus_table[] = { 
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x39, 2 }, /* ATI/AMD SB700 
base in pci space */ 
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x42, 1 }, /* ATI/AMD SB800 
base in pmreg */ 
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SB900_SM, 0x14, 1 }, /* ATI/AMD SB900 
base in pmreg */ 
}; 

volatile u16 rd_vendor, rd_device; 
volatile u8 rd_ver, base_access; 
int i; 
u32 x; 

if (!CONFIG_DEBUG_I2C) 
return; 

/* check to see if we already tried init and it failed */ 
if (i2c_inited  !i2c_amd_iobase) 
return; 

/* check to see if the base address has been initialized */ 
if (!i2c_inited) { 
i2c_inited=1; 
/* check for the AMD/ATI southbridges */ 
rd_vendor = pci_config_readw(0xA0, 0x00); 
rd_device = pci_config_readw(0xA0, 0x02); 
rd_ver = pci_config_readb(0xA0, 0x08); 
base_access=0; 
for (i=0;i  sizeof(amd_smbus_table)/sizeof(amd_smbus_table[0]);++i) { 
if ((amd_smbus_table[i].sb_ven==rd_vendor) 
 (amd_smbus_table[i].sb_dev==rd_device) 
 (amd_smbus_table[i].sb_ver==rd_ver)) { 
base_access = amd_smbus_table[i].base_access; 
break; 
} 
} 

switch (base_access) { 
case 1: 
/* check the PM regs for the SM bus base address */ 
outb (0x2D, 0xCD6); 
i2c_amd_iobase = inb(0xCD7)8; 
outb (0x2C, 0xCD6); 
i2c_amd_iobase |= inb(0xCD7); 
if ((i2c_amd_iobase!=0)  ((i2c_amd_iobase0x01)==0x01)) { 
/* Found a SBx00 base address in PM reg space */ 
i2c_amd_iobase = 0xffe0; 
} 
else { 
/* can not find a valid base address */ 
i2c_amd_iobase = 0; 
} 
break; 
case 2: 
/* check PCI config space for SM bus base address */ 
x = pci_config_readl(0xA0, 0x90); 
if ((x!=0)  ((x0x01)==0x01)) { 
/* Found a SBx00 base address in PCI cfg space */ 
i2c_amd_iobase = (int)(x  0xffe0); 
} 
else { 
/* can not find a valid base address */ 
i2c_amd_iobase = 0; 
} 
break; 
default: 
i2c_amd_iobase = 0; 
break; 
} 
/* add checks for other vendors SMBUS controllers here */ 
} 

if (i2c_amd_iobase) { 
/* this sequence will send out addr/data on the AMD SBx00 smbus */ 
int timeout=DEBUG_TIMEOUT; 
/* check to see if the h/w is idle */ 
do { 
if (!timeout--) 
return; // Ran out of time. 
} 
while ((inb(i2c_amd_iobase)  0x01)!=0x00); 
outb (0xFF, i2c_amd_iobase + 0); // clear error status 
outb (0x1F, i2c_amd_iobase + 1); // clear error status 
outb (data, i2c_amd_iobase + 3); // tx index 
outb (CONFIG_DEBUG_I2C_DEVICE_ADDR, i2c_amd_iobase + 4); // slave address and 
write bit 
outb (0x44, i2c_amd_iobase + 2); // command it to go 
/* check to see if the h/w is done */ 
do { 
if (!timeout--) 
return; // Ran out of time. 
} 
while ((inb(i2c_amd_iobase)  0x01)!=0x00); 
} 
} 

// Write a character to debug port(s). 
static void 
putc_debug(struct putcinfo *action, char c) 
{ 
if (! CONFIG_DEBUG_LEVEL) 
return; 
if (CONFIG_DEBUG_IO) 
// Send character to debug port. 
outb(c, GET_GLOBAL(DebugOutputPort)); 
if (CONFIG_DEBUG_I2C) 
debug_i2c(c); 
if (c == '\n') 
debug_serial('\r'); 
debug_serial(c); 
} 

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

Re: [SeaBIOS] [PATCH] Use cpu_to_be32() (and related) instead of htonl (and related).

[Dave Frodin]

Is there anything preventing this from being added to seabios?

thanks,
dave

- Original Message -
 From: Dave Frodin dave.fro...@se-eng.com
 To: Kevin O'Connor ke...@koconnor.net
 Cc: seabios@seabios.org
 Sent: Wednesday, August 15, 2012 11:18:09 AM
 Subject: Re: [SeaBIOS] [PATCH] Use cpu_to_be32() (and related) instead of 
 htonl (and related).
 
 Kevin,
 
 This patch works for me.
 
 I also inappropriately ack'd the other patch use ntohll instead of
 ntohl which
 actually becomes obsolete with this patch.
 
 thanks,
 Dave
 
 - Original Message -
  From: Kevin O'Connor ke...@koconnor.net
  To: seabios@seabios.org
  Cc: Dave Frodin dave.fro...@se-eng.com
  Sent: Tuesday, August 14, 2012 7:20:10 PM
  Subject: [PATCH] Use cpu_to_be32() (and related) instead of htonl
  (and related).
  
  Unify the syntax for byte swab calls.
  
  This also fixes a bug in coreboot due to the lack of a
  be64_to_cpu()
  call.
  
  Signed-off-by: Kevin O'Connor ke...@koconnor.net
  ---
   src/ata.c   |  3 ++-
   src/blockcmd.c  | 17 +++---
   src/byteorder.h | 69
   +
   src/coreboot.c  | 31 +-
   src/paravirt.c  |  9 
   src/util.h  | 30 -
   vgasrc/vgafb.c  |  3 ++-
   7 files changed, 103 insertions(+), 59 deletions(-)
   create mode 100644 src/byteorder.h
  
  diff --git a/src/ata.c b/src/ata.c
  index 7ff5f86..f604b37 100644
  --- a/src/ata.c
  +++ b/src/ata.c
  @@ -8,6 +8,7 @@
   #include types.h // u8
   #include ioport.h // inb
   #include util.h // dprintf
  +#include byteorder.h // be16_to_cpu
   #include cmos.h // inb_cmos
   #include pic.h // enable_hwirq
   #include biosvar.h // GET_GLOBAL
  @@ -696,7 +697,7 @@ ata_extract_model(char *model, u32 size, u16
  *buffer)
   // Read model name
   int i;
   for (i=0; isize/2; i++)
  -*(u16*)model[i*2] = ntohs(buffer[27+i]);
  +*(u16*)model[i*2] = be16_to_cpu(buffer[27+i]);
   model[size] = 0x00;
   nullTrailingSpace(model);
   return model;
  diff --git a/src/blockcmd.c b/src/blockcmd.c
  index 97c72a6..77c690f 100644
  --- a/src/blockcmd.c
  +++ b/src/blockcmd.c
  @@ -6,7 +6,8 @@
   // This file may be distributed under the terms of the GNU LGPLv3
   license.
   
   #include biosvar.h // GET_GLOBAL
  -#include util.h // htonl
  +#include util.h // dprintf
  +#include byteorder.h // be32_to_cpu
   #include disk.h // struct disk_op_s
   #include blockcmd.h // struct cdb_request_sense
   #include ata.h // atapi_cmd_data
  @@ -144,12 +145,12 @@ scsi_init_drive(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 = ntohl(capdata.blksize);
  +drive-blksize = be32_to_cpu(capdata.blksize);
   if (drive-blksize != DISK_SECTOR_SIZE) {
   dprintf(1, %s: unsupported block size %d\n, s,
   drive-blksize);
   return -1;
   }
  -drive-sectors = (u64)ntohl(capdata.sectors) + 1;
  +drive-sectors = (u64)be32_to_cpu(capdata.sectors) + 1;
   dprintf(1, %s blksize=%d sectors=%d\n
   , s, drive-blksize, (unsigned)drive-sectors);
   
  @@ -243,7 +244,7 @@ cdb_mode_sense_geom(struct disk_op_s *op,
  struct
  cdbres_mode_sense_geom *data)
   cmd.command = CDB_CMD_MODE_SENSE;
   cmd.flags = 8; /* DBD */
   cmd.page = MODE_PAGE_HD_GEOMETRY;
  -cmd.count = htons(sizeof(*data));
  +cmd.count = cpu_to_be16(sizeof(*data));
   op-count = 1;
   op-buf_fl = data;
   return cdb_cmd_data(op, cmd, sizeof(*data));
  @@ -256,8 +257,8 @@ cdb_read(struct disk_op_s *op)
   struct cdb_rwdata_10 cmd;
   memset(cmd, 0, sizeof(cmd));
   cmd.command = CDB_CMD_READ_10;
  -cmd.lba = htonl(op-lba);
  -cmd.count = htons(op-count);
  +cmd.lba = cpu_to_be32(op-lba);
  +cmd.count = cpu_to_be16(op-count);
   return cdb_cmd_data(op, cmd,
   GET_GLOBAL(op-drive_g-blksize));
   }
   
  @@ -268,7 +269,7 @@ cdb_write(struct disk_op_s *op)
   struct cdb_rwdata_10 cmd;
   memset(cmd, 0, sizeof(cmd));
   cmd.command = CDB_CMD_WRITE_10;
  -cmd.lba = htonl(op-lba);
  -cmd.count = htons(op-count);
  +cmd.lba = cpu_to_be32(op-lba);
  +cmd.count = cpu_to_be16(op-count);
   return cdb_cmd_data(op, cmd,
   GET_GLOBAL(op-drive_g-blksize));
   }
  diff --git a/src/byteorder.h b/src/byteorder.h
  new file mode 100644
  index 000..94e3a3b
  --- /dev/null
  +++ b/src/byteorder.h
  @@ -0,0 +1,69 @@
  +#ifndef __BYTEORDER_H
  +#define __BYTEORDER_H
  +
  +static inline u16 __swab16_constant(u16 val) {
  +return (val8) | (val8);
  +}
  +static inline u32 __swab32_constant(u32 val) {
  +return (val24) | ((val0xff00)8) | ((val0xff)8) |
  (val24);
  +}
  +static inline u64

Re: [SeaBIOS] What do I pass to cbfs_run_payload() after finding the payload with romfile_find() ?

[Dave Frodin]

 Subject: Re: [SeaBIOS] What do I pass to cbfs_run_payload() after finding the 
 payload with romfile_find() ?
 
 On Wed, Aug 29, 2012 at 02:06:03PM -0500, Dave Frodin wrote:
 [...]
  This is where I'm at after the change ...
  
  // Output the LCD splash image to the Explorer board
  struct romfile_s *file;
  dprintf(1,Looking for Explorer LCD splash payload ... );
  file = romfile_find(img/explorer-splash);
  if(file)
  {
  dprintf(1, found file [%s]. Loading it...\n ,file-name); ===
  everything works up to here
  // cbfs_run_payload();
  }
  else dprintf(1,could NOT find it!\n);
  
  The cbfs_run_payload is expecting (cbfs_file *). How do I extract
  what cbfs_run_payload() wants from what
  I got back from romfile_find() ?
 
 cbfs_run_payload((void*)file-id);
 
 -Kevin
 

Kevin,
Well that was easy enough.

Thanks, again
Dave

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

[SeaBIOS] Bootorder file question regarding USB hubs/devices

[Dave Frodin]

Previously (before fetching the latest seabios/master) our bootorder file 
looked like this 

/pci@i0cf8/usb@12,2/*@4 
/pci@i0cf8/usb@12,2/*@5 
/pci@i0cf8/usb@12,2/*@3 
/pci@i0cf8/usb@12,2/*@2 
/pci@i0cf8/usb@12,2/*@1 
/pci@i0cf8/usb@12,2/*@0 

Now it looks like this. This also includes devices plugged into hubs on two of 
the ports. 
(Thank you to whoever got hubs working) 

/pci@i0cf8/usb@12,2/storage@5/*@0/*@0,0 
/pci@i0cf8/usb@12,2/storage@4/*@0/*@0,0 
/pci@i0cf8/usb@12,2/storage@3/*@0/*@0,0 
/pci@i0cf8/usb@12,2/storage@2/*@0/*@0,0 
/pci@i0cf8/usb@12,2/storage@1/*@0/*@0,0 
/pci@i0cf8/usb@12,2/storage@0/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@4/storage@1/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@4/storage@2/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@4/storage@3/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@4/storage@4/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@1/storage@1/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@1/storage@2/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@1/storage@3/*@0/*@0,0 
/pci@i0cf8/usb@12,2/hub@1/storage@4/*@0/*@0,0 

Is there an easier/generic way to condense this down? 
Is there any kind of wildcard support when it comes to adding any USB device? 

Thanks in advance, 
Dave 
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

[SeaBIOS] What do I pass to cbfs_run_payload() after finding the payload with romfile_find() ?

[Dave Frodin]

I'm having a problem finding/loading/executing a payload from seabios which is 
now using the romfile 
functions for cbfs (commit 59d6ca52a7eba5). 
I do have the cpu_to_be32() patch to get the correct payload destination 
address. 

Here's what I had previously that worked before the change... 

// Output the LCD splash image to the Explorer board 
struct cbfs_file *file; 
dprintf(1,Looking for Explorer LCD splash payload ... ); 
file = cbfs_finddatafile(img/explorer-splash); 
if(file) 
{ 
dprintf(1, found file [%s]. Loading it...\n ,file-filename); 
cbfs_run_payload(file); 
} 
else dprintf(1,could NOT find it!\n); 

This is where I'm at after the change ... 

// Output the LCD splash image to the Explorer board 
struct romfile_s *file; 
dprintf(1,Looking for Explorer LCD splash payload ... ); 
file = romfile_find(img/explorer-splash); 
if(file) 
{ 
dprintf(1, found file [%s]. Loading it...\n ,file-name); === everything 
works up to here 
// cbfs_run_payload(); 
} 
else dprintf(1,could NOT find it!\n); 

The cbfs_run_payload is expecting (cbfs_file *). How do I extract what 
cbfs_run_payload() wants from what 
I got back from romfile_find() ? 

Thanks in advance, 
Dave 
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios

Re: [SeaBIOS] The cbfs header for a payloads dest addr is a u64, use ntohll instead of ntohl

[Dave Frodin]

Kevin,

Thanks, your patch works for me.

Dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: Dave Frodin dave.fro...@se-eng.com
 Cc: Peter Stuge pe...@stuge.se, seabios@seabios.org
 Sent: Tuesday, August 14, 2012 7:20:01 PM
 Subject: Re: [SeaBIOS] The cbfs header for a payloads dest addr is a u64, use 
 ntohll instead of ntohl
 
 On Wed, Aug 08, 2012 at 12:07:50PM -0600, Dave Frodin wrote:
  Peter,
  
  You're right, that u64 cast wasn't needed, but I needed to cast the
  result to u32.
  The (void*) is evidently expecting a u32. Is that correct? Would
  SeaBIOS always be
  expecting a u32 for an address to execute from?
  
  I also cleaned up the macro to use the existing ntohl.
  The new patch is below. I also tested it.
 
 Thanks for catching this.  I think it would be worthwhile to clean up
 the byteorder calls - see a patch I've sent in a separate email.
 
 -Kevin
 

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

Re: [SeaBIOS] [PATCH] Use cpu_to_be32() (and related) instead of htonl (and related).

[Dave Frodin]

Kevin,

This patch works for me.

I also inappropriately ack'd the other patch use ntohll instead of ntohl which
actually becomes obsolete with this patch.

thanks,
Dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: seabios@seabios.org
 Cc: Dave Frodin dave.fro...@se-eng.com
 Sent: Tuesday, August 14, 2012 7:20:10 PM
 Subject: [PATCH] Use cpu_to_be32() (and related) instead of htonl (and 
 related).
 
 Unify the syntax for byte swab calls.
 
 This also fixes a bug in coreboot due to the lack of a be64_to_cpu()
 call.
 
 Signed-off-by: Kevin O'Connor ke...@koconnor.net
 ---
  src/ata.c   |  3 ++-
  src/blockcmd.c  | 17 +++---
  src/byteorder.h | 69
  +
  src/coreboot.c  | 31 +-
  src/paravirt.c  |  9 
  src/util.h  | 30 -
  vgasrc/vgafb.c  |  3 ++-
  7 files changed, 103 insertions(+), 59 deletions(-)
  create mode 100644 src/byteorder.h
 
 diff --git a/src/ata.c b/src/ata.c
 index 7ff5f86..f604b37 100644
 --- a/src/ata.c
 +++ b/src/ata.c
 @@ -8,6 +8,7 @@
  #include types.h // u8
  #include ioport.h // inb
  #include util.h // dprintf
 +#include byteorder.h // be16_to_cpu
  #include cmos.h // inb_cmos
  #include pic.h // enable_hwirq
  #include biosvar.h // GET_GLOBAL
 @@ -696,7 +697,7 @@ ata_extract_model(char *model, u32 size, u16
 *buffer)
  // Read model name
  int i;
  for (i=0; isize/2; i++)
 -*(u16*)model[i*2] = ntohs(buffer[27+i]);
 +*(u16*)model[i*2] = be16_to_cpu(buffer[27+i]);
  model[size] = 0x00;
  nullTrailingSpace(model);
  return model;
 diff --git a/src/blockcmd.c b/src/blockcmd.c
 index 97c72a6..77c690f 100644
 --- a/src/blockcmd.c
 +++ b/src/blockcmd.c
 @@ -6,7 +6,8 @@
  // This file may be distributed under the terms of the GNU LGPLv3
  license.
  
  #include biosvar.h // GET_GLOBAL
 -#include util.h // htonl
 +#include util.h // dprintf
 +#include byteorder.h // be32_to_cpu
  #include disk.h // struct disk_op_s
  #include blockcmd.h // struct cdb_request_sense
  #include ata.h // atapi_cmd_data
 @@ -144,12 +145,12 @@ scsi_init_drive(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 = ntohl(capdata.blksize);
 +drive-blksize = be32_to_cpu(capdata.blksize);
  if (drive-blksize != DISK_SECTOR_SIZE) {
  dprintf(1, %s: unsupported block size %d\n, s,
  drive-blksize);
  return -1;
  }
 -drive-sectors = (u64)ntohl(capdata.sectors) + 1;
 +drive-sectors = (u64)be32_to_cpu(capdata.sectors) + 1;
  dprintf(1, %s blksize=%d sectors=%d\n
  , s, drive-blksize, (unsigned)drive-sectors);
  
 @@ -243,7 +244,7 @@ cdb_mode_sense_geom(struct disk_op_s *op, struct
 cdbres_mode_sense_geom *data)
  cmd.command = CDB_CMD_MODE_SENSE;
  cmd.flags = 8; /* DBD */
  cmd.page = MODE_PAGE_HD_GEOMETRY;
 -cmd.count = htons(sizeof(*data));
 +cmd.count = cpu_to_be16(sizeof(*data));
  op-count = 1;
  op-buf_fl = data;
  return cdb_cmd_data(op, cmd, sizeof(*data));
 @@ -256,8 +257,8 @@ cdb_read(struct disk_op_s *op)
  struct cdb_rwdata_10 cmd;
  memset(cmd, 0, sizeof(cmd));
  cmd.command = CDB_CMD_READ_10;
 -cmd.lba = htonl(op-lba);
 -cmd.count = htons(op-count);
 +cmd.lba = cpu_to_be32(op-lba);
 +cmd.count = cpu_to_be16(op-count);
  return cdb_cmd_data(op, cmd, GET_GLOBAL(op-drive_g-blksize));
  }
  
 @@ -268,7 +269,7 @@ cdb_write(struct disk_op_s *op)
  struct cdb_rwdata_10 cmd;
  memset(cmd, 0, sizeof(cmd));
  cmd.command = CDB_CMD_WRITE_10;
 -cmd.lba = htonl(op-lba);
 -cmd.count = htons(op-count);
 +cmd.lba = cpu_to_be32(op-lba);
 +cmd.count = cpu_to_be16(op-count);
  return cdb_cmd_data(op, cmd, GET_GLOBAL(op-drive_g-blksize));
  }
 diff --git a/src/byteorder.h b/src/byteorder.h
 new file mode 100644
 index 000..94e3a3b
 --- /dev/null
 +++ b/src/byteorder.h
 @@ -0,0 +1,69 @@
 +#ifndef __BYTEORDER_H
 +#define __BYTEORDER_H
 +
 +static inline u16 __swab16_constant(u16 val) {
 +return (val8) | (val8);
 +}
 +static inline u32 __swab32_constant(u32 val) {
 +return (val24) | ((val0xff00)8) | ((val0xff)8) |
 (val24);
 +}
 +static inline u64 __swab64_constant(u64 val) {
 +return ((u64)__swab32_constant(val)  32) |
 __swab32_constant(val32);
 +}
 +static inline u32 __swab32(u32 val) {
 +asm(bswapl %0 : +r(val));
 +return val;
 +}
 +static inline u64 __swab64(u64 val) {
 +union u64_u32_u i, o;
 +i.val = val;
 +o.hi = __swab32(i.lo);
 +o.lo = __swab32(i.hi);
 +return o.val;
 +}
 +
 +#define swab16(x) __swab16_constant(x)
 +#define swab32(x) (__builtin_constant_p((u32)(x)) \
 +   ? __swab32_constant(x) : __swab32(x))
 +#define

Re: [SeaBIOS] The cbfs header for a payloads dest addr is a u64, use ntohll instead of ntohl

[Dave Frodin]

Peter,
Have you had a chance to review my last patch (below)?

thanks,
dave

- Original Message -
 From: Dave Frodin dave.fro...@se-eng.com
 To: Peter Stuge pe...@stuge.se
 Cc: seabios@seabios.org
 Sent: Wednesday, August 8, 2012 12:07:50 PM
 Subject: Re: [SeaBIOS] The cbfs header for a payloads dest addr is a u64, 
 use ntohll instead of ntohl
 
 Peter,
 
 You're right, that u64 cast wasn't needed, but I needed to cast the
 result to u32.
 The (void*) is evidently expecting a u32. Is that correct? Would
 SeaBIOS always be
 expecting a u32 for an address to execute from?
 
 I also cleaned up the macro to use the existing ntohl.
 The new patch is below. I also tested it.
 
 dave
 
 commit 66c82fdbf283340067a8531ef6e3afae82102396
 Author: Dave Frodin dave.fro...@se-eng.com
 Date:   Tue Aug 7 17:01:08 2012 -0600
 
 Seabios: This fixes reading of CBFS 64 bit destination addresses
 from payload headers.
 This allows img/payloads to run.
 
 diff --git a/src/coreboot.c b/src/coreboot.c
 index e116a14..b989517 100644
 --- a/src/coreboot.c
 +++ b/src/coreboot.c
 @@ -470,6 +470,8 @@ struct cbfs_payload {
  struct cbfs_payload_segment segments[1];
  };
 
 +#define ntohll(in) (((u64) ntohl( (in)  0x)  32) | ((u64)
 ntohl( (in)  32)))
 +
  void
  cbfs_run_payload(struct cbfs_file *file)
  {
 @@ -480,7 +482,7 @@ cbfs_run_payload(struct cbfs_file *file)
  struct cbfs_payload_segment *seg = pay-segments;
  for (;;) {
  void *src = (void*)pay + ntohl(seg-offset);
 -void *dest = (void*)ntohl((u32)seg-load_addr);
 +void *dest = (void*)(u32)ntohll(seg-load_addr);
  u32 src_len = ntohl(seg-len);
  u32 dest_len = ntohl(seg-mem_len);
  switch (seg-type) {
 
 
 
 
 - Original Message -
  From: Peter Stuge pe...@stuge.se
  To: seabios@seabios.org
  Sent: Wednesday, August 8, 2012 5:29:57 AM
  Subject: Re: [SeaBIOS] The cbfs header for a payloads dest addr is
  a u64,  use ntohll instead of ntohl
  
  Dave Frodin wrote:
   @@ -480,7 +491,7 @@ cbfs_run_payload(struct cbfs_file *file)
struct cbfs_payload_segment *seg = pay-segments;
for (;;) {
void *src = (void*)pay + ntohl(seg-offset);
   -void *dest = (void*)ntohl((u32)seg-load_addr);
   +void *dest = (void*)ntohll((u64)seg-load_addr);
  
  Is the (u64) cast still needed? The less casts the better.
  
  
  //Peter
  
  ___
  SeaBIOS mailing list
  SeaBIOS@seabios.org
  http://www.seabios.org/mailman/listinfo/seabios
  
 
 ___
 SeaBIOS mailing list
 SeaBIOS@seabios.org
 http://www.seabios.org/mailman/listinfo/seabios
 

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

Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?

[Dave Frodin]

I tested this (the combined patches) with several of the different USB
thumbdrives that I have and didn't have any problems.
In fact it actually increased the pass rate of my failing Ubuntu booting
problem from ~0% to ~50%, but I'll address that in that email stream.

dave

- Original Message -
 From: Paolo Bonzini pbonz...@redhat.com
 To: Kevin O'Connor ke...@koconnor.net
 Cc: seabios@seabios.org
 Sent: Friday, March 16, 2012 11:54:46 AM
 Subject: Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY needs USB_DIR_OUT?
 
 Il 15/03/2012 02:31, Kevin O'Connor ha scritto:
  On Wed, Mar 14, 2012 at 01:02:39PM -0600, Steve Goodrich wrote:
  I've been working with coreboot and SeaBIOS lately to try to get a
  platform
  working, including having boot capability using an SD-to-USB
  adapter.  I got
  stuck on this last part: the USB/SD adapter would start
  enumeration, but
  would fail out during TEST_UNIT_READY because the device came back
  with a
  STALL (this via a LeCroy/CACT USB analyzer).  I compared the
  transactions to
  those done during USB enumeration/configuration in Linux, and I
  noticed that
  the Direction bit in bmCBWFlags is *cleared* for the
  TEST_UNIT_READY command
  in Linux, but *set* in coreboot.
  
  If Linux always clears the direction bit for zero length transfers,
  then I think it should be safe to do that in SeaBIOS also.  How
  about
  the patch below?
  
  -Kevin
  
  
  From 1fd9a89082b807a4bb4ab6ce1285df474cb75746 Mon Sep 17 00:00:00
  2001
  From: Kevin O'Connor ke...@koconnor.net
  Date: Wed, 14 Mar 2012 21:27:45 -0400
  Subject: [PATCH] Use OUT mode for all zero byte scsi transfers.
  
  Some devices can get confused if asked to read data during a zero
  byte transfer, so consider these transfers as writes.  (Reported
  by
  Steve Goodrich.)
  
  Also, extract out the code to determine the transfer direction into
  cdb_is_read().
  
  Signed-off-by: Kevin O'Connor ke...@koconnor.net
  ---
   src/blockcmd.c|7 +++
   src/blockcmd.h|1 +
   src/usb-msc.c |4 ++--
   src/virtio-scsi.c |7 ---
   4 files changed, 14 insertions(+), 5 deletions(-)
  
  diff --git a/src/blockcmd.c b/src/blockcmd.c
  index 8d881a5..2dda04d 100644
  --- a/src/blockcmd.c
  +++ b/src/blockcmd.c
  @@ -35,6 +35,13 @@ cdb_cmd_data(struct disk_op_s *op, void *cdbcmd,
  u16 blocksize)
   }
   }
   
  +// Determine if the command is a request to pull data from the
  device
  +int
  +cdb_is_read(u8 *cdbcmd, u16 blocksize)
  +{
  +return blocksize  cdbcmd[0] != CDB_CMD_WRITE_10;
  +}
  +
   int
   scsi_is_ready(struct disk_op_s *op)
   {
  diff --git a/src/blockcmd.h b/src/blockcmd.h
  index ccfeeaf..8459d3e 100644
  --- a/src/blockcmd.h
  +++ b/src/blockcmd.h
  @@ -100,6 +100,7 @@ struct cdbres_mode_sense_geom {
   } PACKED;
   
   // blockcmd.c
  +int cdb_is_read(u8 *cdbcmd, u16 blocksize);
   int cdb_get_inquiry(struct disk_op_s *op, struct cdbres_inquiry
   *data);
   int cdb_get_sense(struct disk_op_s *op, struct
   cdbres_request_sense *data);
   int cdb_test_unit_ready(struct disk_op_s *op);
  diff --git a/src/usb-msc.c b/src/usb-msc.c
  index dadb9ca..c53a1f5 100644
  --- a/src/usb-msc.c
  +++ b/src/usb-msc.c
  @@ -77,13 +77,13 @@ usb_cmd_data(struct disk_op_s *op, void
  *cdbcmd, u16 blocksize)
   cbw.dCBWSignature = CBW_SIGNATURE;
   cbw.dCBWTag = 999; // XXX
   cbw.dCBWDataTransferLength = bytes;
  -cbw.bmCBWFlags = (cbw.CBWCB[0] == CDB_CMD_WRITE_10) ?
  USB_DIR_OUT : USB_DIR_IN;
  +cbw.bmCBWFlags = cdb_is_read(cdbcmd, blocksize) ? USB_DIR_IN :
  USB_DIR_OUT;
   cbw.bCBWLUN = 0; // XXX
   cbw.bCBWCBLength = USB_CDB_SIZE;
   
   // Transfer cbw to device.
   int ret = usb_msc_send(udrive_g, USB_DIR_OUT
  -, MAKE_FLATPTR(GET_SEG(SS), cbw),
  sizeof(cbw));
  +   , MAKE_FLATPTR(GET_SEG(SS), cbw),
  sizeof(cbw));
   if (ret)
   goto fail;
   
  diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
  index 3c59438..50339d7 100644
  --- a/src/virtio-scsi.c
  +++ b/src/virtio-scsi.c
  @@ -31,7 +31,7 @@ struct virtio_lun_s {
   
   static int
   virtio_scsi_cmd(u16 ioaddr, struct vring_virtqueue *vq, struct
   disk_op_s *op,
  -void *cdbcmd, u16 target, u16 lun, u32 len)
  +void *cdbcmd, u16 target, u16 lun, u16 blocksize)
   {
   struct virtio_scsi_req_cmd req;
   struct virtio_scsi_resp_cmd resp;
  @@ -44,7 +44,8 @@ virtio_scsi_cmd(u16 ioaddr, struct
  vring_virtqueue *vq, struct disk_op_s *op,
   req.lun[3] = (lun  0xff);
   memcpy(req.cdb, cdbcmd, 16);
   
  -int datain = (req.cdb[0] != CDB_CMD_WRITE_10);
  +u32 len = op-count * blocksize;
  +int datain = cdb_is_read(cdbcmd, blocksize);
 
 The patch changes the way TEST_UNIT_READY is composed in the
 buffers and breaks virtio-scsi.  Now I remember why I did it
 this way. :)
 
 You can squash this in:
 
 diff --git a/src/virtio-scsi.c b/src/virtio-scsi.c
 index 

Re: [SeaBIOS] USB OHCI issues when keyboard activity occurs prior to booting from thumbdrive

[Dave Frodin]

Kevin,
I mentioned in a response to the Re: [SeaBIOS] usb-msc.c: TEST_UNIT_READY 
needs USB_DIR_OUT?
email thread that when I applied the patches related to that thread the Ubuntu 
booting
issue that I see in this thread actually increases the passing rate from ~0% to 
~50%.
Perhaps setting the DIR bit twice will solve my problem :)

I also was wondering if you could point me to the code that you referred to 
when you
wrote ... I did see what appears to be a race with USB interrupt pipe 
reading ?

thanks in advance,
Dave

  
  The failure occurs when the system boots up to the GRUB menu. If I
  let the menu timeout it will boot the default option which is
  Ubuntu. If I hit the Enter key the system will lock-up with no
  output on the debug COM port. If at the GRUB menu and I down
  arrow
  to the memtest86 option, it will sometimes work and sometimes
  lockup.
 
 In the processes of looking through the OHCI code, I did see what
 appears to be a race with USB interrupt pipe reading.  The code is
 assuming the TD is complete when the ED acknowledges the change, but
 the spec is pretty clear that the TD can be modified after the ED is
 updated.  However, I'd be quite surprised that such a small race
 would
 lead to reproducible failures.  I also don't see how it would relate
 to EHCI thumbdrive usage.
 
 -Kevin
 

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

Re: [SeaBIOS] [PATCH 08/19] usb: Push 'struct usbdevice_s' usage through to pipe allocation.

[Dave Frodin]

I had to do some whitespace cleanup in order for patch 08/19 to apply cleanly. 
I don't have
much experience in applying patches so there might be something I'm missing.

Here are the changes I had to do...

Subject: [PATCH] Whitespace cleanup, replace two tabs with spaces

---
 src/usb-msc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/usb-msc.c b/src/usb-msc.c
index e143401..62152d8 100644
--- a/src/usb-msc.c
+++ b/src/usb-msc.c
@@ -132,8 +132,8 @@ usb_msc_init(struct usb_pipe *pipe
 
 // Verify right kind of device
 if ((iface-bInterfaceSubClass != US_SC_SCSI 
-iface-bInterfaceSubClass != US_SC_ATAPI_8070 
-iface-bInterfaceSubClass != US_SC_ATAPI_8020)
+iface-bInterfaceSubClass != US_SC_ATAPI_8070 
+iface-bInterfaceSubClass != US_SC_ATAPI_8020)
 || iface-bInterfaceProtocol != US_PR_BULK) {
 dprintf(1, Unsupported MSC USB device (subclass=%02x proto=%02x)\n
 , iface-bInterfaceSubClass, iface-bInterfaceProtocol);
-- 
1.7.9

dave

- Original Message -
 From: Kevin O'Connor ke...@koconnor.net
 To: seabios@seabios.org
 Sent: Saturday, March 10, 2012 7:44:46 PM
 Subject: [SeaBIOS] [PATCH 08/19] usb: Push 'struct usbdevice_s' usage through 
 to pipe allocation.
 
 Pass the usbdevice_s info to device configuration and allocation
 code.
 
 Signed-off-by: Kevin O'Connor ke...@koconnor.net
 ---
  src/usb-hid.c |   28 +++-
  src/usb-hid.h |6 ++
  src/usb-hub.c |8 
  src/usb-hub.h |4 ++--
  src/usb-msc.c |   15 ---
  src/usb-msc.h |6 ++
  src/usb.c |   35 +++
  src/usb.h |   13 +++--
  8 files changed, 59 insertions(+), 56 deletions(-)
 
 diff --git a/src/usb-hid.c b/src/usb-hid.c
 index 168b7fa..21363c3 100644
 --- a/src/usb-hid.c
 +++ b/src/usb-hid.c
 @@ -49,7 +49,8 @@ set_idle(struct usb_pipe *pipe, int ms)
  #define KEYREPEATMS 33
  
  static int
 -usb_kbd_init(struct usb_pipe *pipe, struct usb_endpoint_descriptor
 *epdesc)
 +usb_kbd_init(struct usbdevice_s *usbdev
 + , struct usb_endpoint_descriptor *epdesc)
  {
  if (! CONFIG_USB_KEYBOARD)
  return -1;
 @@ -61,15 +62,15 @@ usb_kbd_init(struct usb_pipe *pipe, struct
 usb_endpoint_descriptor *epdesc)
  return -1;
  
  // Enable boot protocol.
 -int ret = set_protocol(pipe, 0);
 +int ret = set_protocol(usbdev-defpipe, 0);
  if (ret)
  return -1;
  // Periodically send reports to enable key repeat.
 -ret = set_idle(pipe, KEYREPEATMS);
 +ret = set_idle(usbdev-defpipe, KEYREPEATMS);
  if (ret)
  return -1;
  
 -keyboard_pipe = alloc_intr_pipe(pipe, epdesc);
 +keyboard_pipe = alloc_intr_pipe(usbdev, epdesc);
  if (!keyboard_pipe)
  return -1;
  
 @@ -78,7 +79,8 @@ usb_kbd_init(struct usb_pipe *pipe, struct
 usb_endpoint_descriptor *epdesc)
  }
  
  static int
 -usb_mouse_init(struct usb_pipe *pipe, struct usb_endpoint_descriptor
 *epdesc)
 +usb_mouse_init(struct usbdevice_s *usbdev
 +   , struct usb_endpoint_descriptor *epdesc)
  {
  if (! CONFIG_USB_MOUSE)
  return -1;
 @@ -90,11 +92,11 @@ usb_mouse_init(struct usb_pipe *pipe, struct
 usb_endpoint_descriptor *epdesc)
  return -1;
  
  // Enable boot protocol.
 -int ret = set_protocol(pipe, 0);
 +int ret = set_protocol(usbdev-defpipe, 0);
  if (ret)
  return -1;
  
 -mouse_pipe = alloc_intr_pipe(pipe, epdesc);
 +mouse_pipe = alloc_intr_pipe(usbdev, epdesc);
  if (!mouse_pipe)
  return -1;
  
 @@ -104,29 +106,29 @@ usb_mouse_init(struct usb_pipe *pipe, struct
 usb_endpoint_descriptor *epdesc)
  
  // Initialize a found USB HID device (if applicable).
  int
 -usb_hid_init(struct usb_pipe *pipe
 - , struct usb_interface_descriptor *iface, int imax)
 +usb_hid_init(struct usbdevice_s *usbdev)
  {
  if (! CONFIG_USB_KEYBOARD || ! CONFIG_USB_MOUSE)
  return -1;
 -dprintf(2, usb_hid_init %p\n, pipe);
 +dprintf(2, usb_hid_init %p\n, usbdev-defpipe);
  
 +struct usb_interface_descriptor *iface = usbdev-iface;
  if (iface-bInterfaceSubClass != USB_INTERFACE_SUBCLASS_BOOT)
  // Doesn't support boot protocol.
  return -1;
  
  // Find intr in endpoint.
  struct usb_endpoint_descriptor *epdesc = findEndPointDesc(
 -iface, imax, USB_ENDPOINT_XFER_INT, USB_DIR_IN);
 +usbdev, USB_ENDPOINT_XFER_INT, USB_DIR_IN);
  if (!epdesc) {
  dprintf(1, No usb hid intr in?\n);
  return -1;
  }
  
  if (iface-bInterfaceProtocol ==
  USB_INTERFACE_PROTOCOL_KEYBOARD)
 -return usb_kbd_init(pipe, epdesc);
 +return usb_kbd_init(usbdev, epdesc);
  if (iface-bInterfaceProtocol == USB_INTERFACE_PROTOCOL_MOUSE)
 -return usb_mouse_init(pipe, epdesc);
 +return usb_mouse_init(usbdev, epdesc);
  return -1;
  }
 

Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

- Original Message -
 From: Paolo Bonzini pbonz...@redhat.com
 To: Kevin O'Connor ke...@koconnor.net
 Cc: Dave Frodin d...@camp.se-eng.com, seabios@seabios.org
 Sent: Monday, March 5, 2012 1:17:08 AM
 Subject: Re: Booting from USB thumbdrives, older drives boot, newer drives 
 don't.
 
 Il 04/03/2012 19:49, Kevin O'Connor ha scritto:
   The sg_modes command has a -a option to dump out all of the
   supported page codes
  - it reports that none of the thumbdrives (tested 9) support
  page code = 4
  - it reports that most of the thumbdrives (tested 9) support
  page code = 5
  - it commented that page code 5 is obsolete
  Thanks Dave.  I appreciate your detailed analysis.
  
  The call to cdb_mode_sense_geom() was only recently added.  I'm
  inclined to just remove the call.  Paolo, is there a use case where
  having the physical chs info is important?  SeaBIOS should
  generate
  good virtual chs info regardless, and the underlying physical
  info
  is only exported in a couple of places.
 
 MS-DOS doesn't boot if you do not export the physical chs.  I can
 remove
 it, but it was the best testcase I had for SCSI support.
 
 The simplest solution seems to be to look for page 4 support in page
 0x3f.

Except that none of the 12 devices I've tested support page 4.
There's also a good chance that some of the devices could generate the
stall on the page 3f request. That's what led us to thinking we should
leave the page 4 query in and just add support to clear the stall. 

 
 Paolo
 
 

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

Re: [SeaBIOS] [PATCH] scsi: do not send MODE SENSE except to QEMU disks

[Dave Frodin]

Paolo,
I tested your patch.
It works with all 14 USB thumbdrives and with a USB-to-SATA
adapter we dug up.

Dave

- Original Message -
 From: Paolo Bonzini pbonz...@redhat.com
 To: seabios@seabios.org
 Cc: Dave Frodin d...@camp.se-eng.com
 Sent: Monday, March 5, 2012 4:29:12 AM
 Subject: [PATCH] scsi: do not send MODE SENSE except to QEMU disks
 
 This is the simplest way to avoid breaking boot on USB sticks that
 stall when asked for the MODE SENSE page 4.  Some old sticks do
 not support the MODE SENSE command at all and just return a
 medium may have changed unit attention condition when SeaBIOS
 sends it!
 
 Reported-by: Dave Frodin d...@camp.se-eng.com
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  src/blockcmd.c |   36 +++-
  1 files changed, 23 insertions(+), 13 deletions(-)
 
 diff --git a/src/blockcmd.c b/src/blockcmd.c
 index 2769573..b4a1e37 100644
 --- a/src/blockcmd.c
 +++ b/src/blockcmd.c
 @@ -139,19 +139,29 @@ scsi_init_drive(struct drive_s *drive, const
 char *s, int prio)
  dprintf(1, %s blksize=%d sectors=%d\n
  , s, drive-blksize, (unsigned)drive-sectors);
  
 -struct cdbres_mode_sense_geom geomdata;
 -ret = cdb_mode_sense_geom(dop, geomdata);
 -if (ret == 0) {
 -u32 cylinders;
 -cylinders = geomdata.cyl[0]  16;
 -cylinders |= geomdata.cyl[1]  8;
 -cylinders |= geomdata.cyl[2];
 -if (cylinders  geomdata.heads 
 -drive-sectors = 0xULL 
 -((u32)drive-sectors % (geomdata.heads * cylinders) ==
 0)) {
 -drive-pchs.cylinders = cylinders;
 -drive-pchs.heads = geomdata.heads;
 -drive-pchs.spt = (u32)drive-sectors / (geomdata.heads
 * cylinders);
 +// We do not recover from USB stalls, so try to be safe and
 avoid
 +// sending the command if the (obsolete, but still provided by
 QEMU)
 +// fixed disk geometry page may not be supported.
 +//
 +// We could also send the command only to small disks (e.g.
 504MiB)
 +// but some old USB keys only support a very small subset of
 SCSI which
 +// does not even include the MODE SENSE command!
 +//
 +if (! CONFIG_COREBOOT  memcmp(vendor, QEMU, 8) == 0) {
 +struct cdbres_mode_sense_geom geomdata;
 +ret = cdb_mode_sense_geom(dop, geomdata);
 +if (ret == 0) {
 +u32 cylinders;
 +cylinders = geomdata.cyl[0]  16;
 +cylinders |= geomdata.cyl[1]  8;
 +cylinders |= geomdata.cyl[2];
 +if (cylinders  geomdata.heads 
 +drive-sectors = 0xULL 
 +((u32)drive-sectors % (geomdata.heads * cylinders)
 == 0)) {
 +drive-pchs.cylinders = cylinders;
 +drive-pchs.heads = geomdata.heads;
 +drive-pchs.spt = (u32)drive-sectors /
 (geomdata.heads * cylinders);
 +}
  }
  }
  
 --
 1.7.7.6
 
 

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

Re: [SeaBIOS] [PATCH] scsi: do not send MODE SENSE except to QEMU disks

[Dave Frodin]

Signed-off-by: Dave Frodin d...@camp.se-eng.com

Paolo,
Marc wanted me to request that this patch be included in the next stable
SeaBIOS release.

Thanks again for your help on this.
Dave

- Original Message -
 From: Paolo Bonzini pbonz...@redhat.com
 To: seabios@seabios.org
 Cc: Dave Frodin d...@camp.se-eng.com
 Sent: Monday, March 5, 2012 4:29:12 AM
 Subject: [PATCH] scsi: do not send MODE SENSE except to QEMU disks
 
 This is the simplest way to avoid breaking boot on USB sticks that
 stall when asked for the MODE SENSE page 4.  Some old sticks do
 not support the MODE SENSE command at all and just return a
 medium may have changed unit attention condition when SeaBIOS
 sends it!
 
 Reported-by: Dave Frodin d...@camp.se-eng.com
 Signed-off-by: Paolo Bonzini pbonz...@redhat.com
 ---
  src/blockcmd.c |   36 +++-
  1 files changed, 23 insertions(+), 13 deletions(-)
 
 diff --git a/src/blockcmd.c b/src/blockcmd.c
 index 2769573..b4a1e37 100644
 --- a/src/blockcmd.c
 +++ b/src/blockcmd.c
 @@ -139,19 +139,29 @@ scsi_init_drive(struct drive_s *drive, const
 char *s, int prio)
  dprintf(1, %s blksize=%d sectors=%d\n
  , s, drive-blksize, (unsigned)drive-sectors);
  
 -struct cdbres_mode_sense_geom geomdata;
 -ret = cdb_mode_sense_geom(dop, geomdata);
 -if (ret == 0) {
 -u32 cylinders;
 -cylinders = geomdata.cyl[0]  16;
 -cylinders |= geomdata.cyl[1]  8;
 -cylinders |= geomdata.cyl[2];
 -if (cylinders  geomdata.heads 
 -drive-sectors = 0xULL 
 -((u32)drive-sectors % (geomdata.heads * cylinders) ==
 0)) {
 -drive-pchs.cylinders = cylinders;
 -drive-pchs.heads = geomdata.heads;
 -drive-pchs.spt = (u32)drive-sectors / (geomdata.heads
 * cylinders);
 +// We do not recover from USB stalls, so try to be safe and
 avoid
 +// sending the command if the (obsolete, but still provided by
 QEMU)
 +// fixed disk geometry page may not be supported.
 +//
 +// We could also send the command only to small disks (e.g.
 504MiB)
 +// but some old USB keys only support a very small subset of
 SCSI which
 +// does not even include the MODE SENSE command!
 +//
 +if (! CONFIG_COREBOOT  memcmp(vendor, QEMU, 8) == 0) {
 +struct cdbres_mode_sense_geom geomdata;
 +ret = cdb_mode_sense_geom(dop, geomdata);
 +if (ret == 0) {
 +u32 cylinders;
 +cylinders = geomdata.cyl[0]  16;
 +cylinders |= geomdata.cyl[1]  8;
 +cylinders |= geomdata.cyl[2];
 +if (cylinders  geomdata.heads 
 +drive-sectors = 0xULL 
 +((u32)drive-sectors % (geomdata.heads * cylinders)
 == 0)) {
 +drive-pchs.cylinders = cylinders;
 +drive-pchs.heads = geomdata.heads;
 +drive-pchs.spt = (u32)drive-sectors /
 (geomdata.heads * cylinders);
 +}
  }
  }
  
 --
 1.7.7.6
 
 

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

Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

Paolo,
Thanks for the reply.
I ran the sg_modes for pages 4 and 5 on 4 USB thumbdrives.
sandisk_old is a 4GB Sandisk Cruzer (yes, the old is ver=8.02)
sandisk_new is a 4GB Sandisk Cruzer
transcend   is a 2GB drive
verbatimis a 2GB drive

If I use the unmodified master SeaBIOS ...
sandisk_old   boots
sandisk_new   stalls at mode sense
transcend stalls at mode sense
verbatim  boots

If I change the mode page from 4 to 5 ...
sandisk_old   boots
sandisk_new   boots
transcend stalls at mode sense
verbatim  boots

The mode page change from 4 to 5 allowed four of my none booting
drives to boot. Hopefully these logs will be helpful.

Thanks again,
dave

starting sandisk_old tests
   sudo sg_modes -HHp 4 /dev/sdb
SanDisk   Cruzer8.02   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 46 00 00 00 00 00 00 
Mode data length=72, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0
 page_code=0x0, page_control=0
00 00 00 
Unexpectedly received extra mode page responses, ignore

   sudo sg_modes -HHp 5 /dev/sdb
SanDisk   Cruzer8.02   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 26 00 00 00 00 00 00 
Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0
 page_code=0x5, page_control=0
00 05 1e 80 00 04 20 02 00  ef c0 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 
starting sandisk_new tests
   sudo sg_modes -HHp 4 /dev/sdb
SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
invalid field in cdb (perhaps page 0x4 not supported)

   sudo sg_modes -HHp 5 /dev/sdb
SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 26 00 00 00 00 00 00 
Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0
 page_code=0x5, page_control=0
00 05 1e 00 00 10 3f 02 00  1e 4f 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
 
starting transcend
   sudo sg_modes -HHp 4 /dev/sdb
JetFlash  Transcend 2GB 8.07   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 06 00 00 00 00 00 00 
Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0

   sudo sg_modes -HHp 5 /dev/sdb
JetFlash  Transcend 2GB 8.07   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 06 00 00 00 00 00 00 
Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0


starting verbatim
   sudo sg_modes -HHp 4 /dev/sdb
Verbatim  STORE N GO5.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 06 00 00 00 00 00 00 
Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0

   sudo sg_modes -HHp 5 /dev/sdb
Verbatim  STORE N GO5.00   peripheral_type: disk [0x0]
Mode parameter header from MODE SENSE(10):
00 00 26 00 00 00 00 00 00 
Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
Block descriptor length=0
 page_code=0x5, page_control=0
00 05 1e f0 00 ff 20 02 00  01 df 00 00 00 00 00 00
10 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00


- Original Message -
 From: Paolo Bonzini pbonz...@redhat.com
 To: seabios@seabios.org, d...@camp.se-eng.com
 Sent: Friday, March 2, 2012 7:20:28 AM
 Subject: Re: Booting from USB thumbdrives, older drives boot, newer drives 
 don't.
 
 Il 02/03/2012 01:34, Dave Frodin ha scritto:
  On a related topic, I have a copy of the Indispensable PC
  Hardware book
  that lists the return values for the mode page 4 request. It list
  the cyc/head
  data as follows...
   offset   value
  ==
 2 cyl(msb)
 3 cyl
 4 cyl(lsb)
 5 heads
  
  the struct in the blockcmd.h file shows...
struct cdbres_mode_sense_geom {
  u8 unused_00[3];
  u8 read_only;
  u32 unused_04;
  u8 page;
  u8 length;
  u8 cyl[3];
  u8 heads;
  u8 precomp[3];
  u8 reduced[3];
  u16 step_rate;
  u8 landing[3];
  u16 rpm;
} PACKED;
  which would put cyl[3] at offset 10 thru 12 and heads at offset

Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

Here are my latest results.
The sg_modes command has a -a option to dump out all of the supported page 
codes
   - it reports that none of the thumbdrives (tested 9) support page code = 4 
   - it reports that most of the thumbdrives (tested 9) support page code = 5
   - it commented that page code 5 is obsolete

the page_code=4 and 5 cyc/head info must be garbage
these are the types of values I get back. I haven't
found a spec yet for the page_code 5 geometry struct
so it could be bogus because of that.

cyc[0]/cyc[1]/cyc[2]  head
---  
page_code 4   page_code 5

old_sandisk   00/00/00  0 80/00/04  20
new_sandisk  stall00/00/10  3F
verbatim  66/b5/02  f f0/00/ff  20
wintec00/00/80  0 13/88/10  3F

I think the booting drives boot because ...
  A) using page_code=5 got rid of the stall (even though the data is bogus)
  B) the MBR is at sector 0, and 0 is 0 no matter what the geometry
  C) perhaps there is code later in seabios that understands it's booting
 from a USB drive and knows better than us what to do and uses something
 like linear sectors.

Marc suggested that I leave the page_code set to 4 in order to preserve 
functionality for
drives that actually report valid CHS geometry, and to add code that would 
clear the stall
from the USB controller and thumbdrive.

Questions:
  1) Any recommendations on my direction?
  2) Is there any way to differentiate between a USB thumbdrive and
 a USB-to-SATA adapter?

dave

- Original Message -
 From: Dave Frodin d...@camp.se-eng.com
 To: seabios@seabios.org
 Sent: Friday, March 2, 2012 8:53:54 AM
 Subject: Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot,   
 newer drives don't.
 
 Paolo,
 Thanks for the reply.
 I ran the sg_modes for pages 4 and 5 on 4 USB thumbdrives.
 sandisk_old is a 4GB Sandisk Cruzer (yes, the old is ver=8.02)
 sandisk_new is a 4GB Sandisk Cruzer
 transcend   is a 2GB drive
 verbatimis a 2GB drive
 
 If I use the unmodified master SeaBIOS ...
   sandisk_old   boots
   sandisk_new   stalls at mode sense
   transcend stalls at mode sense
   verbatim  boots
 
 If I change the mode page from 4 to 5 ...
   sandisk_old   boots
   sandisk_new   boots
   transcend stalls at mode sense
   verbatim  boots
 
 The mode page change from 4 to 5 allowed four of my none booting
 drives to boot. Hopefully these logs will be helpful.
 
 Thanks again,
 dave
 
 starting sandisk_old tests
sudo sg_modes -HHp 4 /dev/sdb
   SanDisk   Cruzer8.02   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 46 00 00 00 00 00 00
   Mode data length=72, medium type=0x00, WP=0, DpoFua=0, longlba=0
   Block descriptor length=0
page_code=0x0, page_control=0
   00 00 00
   Unexpectedly received extra mode page responses, ignore
 
sudo sg_modes -HHp 5 /dev/sdb
   SanDisk   Cruzer8.02   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 26 00 00 00 00 00 00
   Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
   Block descriptor length=0
page_code=0x5, page_control=0
   00 05 1e 80 00 04 20 02 00  ef c0 00 00 00 00 00 00
   10 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  
 starting sandisk_new tests
sudo sg_modes -HHp 4 /dev/sdb
   SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
   invalid field in cdb (perhaps page 0x4 not supported)
 
sudo sg_modes -HHp 5 /dev/sdb
   SanDisk  Cruzer   1.26   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 26 00 00 00 00 00 00
   Mode data length=40, medium type=0x00, WP=0, DpoFua=0, longlba=0
   Block descriptor length=0
page_code=0x5, page_control=0
   00 05 1e 00 00 10 3f 02 00  1e 4f 00 00 00 00 00 00
   10 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
  
 starting transcend
sudo sg_modes -HHp 4 /dev/sdb
   JetFlash  Transcend 2GB 8.07   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 06 00 00 00 00 00 00
   Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
   Block descriptor length=0
 
sudo sg_modes -HHp 5 /dev/sdb
   JetFlash  Transcend 2GB 8.07   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 06 00 00 00 00 00 00
   Mode data length=8, medium type=0x00, WP=0, DpoFua=0, longlba=0
   Block descriptor length=0
 
 
 starting verbatim
sudo sg_modes -HHp 4 /dev/sdb
   Verbatim  STORE N GO5.00   peripheral_type: disk [0x0]
   Mode parameter header from MODE SENSE(10):
   00 00 06 00 00 00 00 00 00

[SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

I'm a new subscriber to seabios.org so feel free to straighten me out if needed.

I've been debugging an problem we've been seeing with not being able to boot 
(Ubuntu specifically) off
of a variety of newer USB thumb drives. I've been specifically looking at an 
older/newer pair of
Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down the 
problem to the blockcmd.c file.
The function scsi_init_drive() queries the USB device to determine stuff like 
vendor/device/size/etc.
Near the end of the function is a call to cdb_mode_sense_geom(dop, geomdata) 
to retrieve the info
related to cyl/head type stuff. On the older/working thumbdrive it returns 
zeroes for all of the values
that get used by the code. The newer/failing drive generates a stall on the 
USB bus, which it never
recovers from. The cdb_mode_sense_geom() function is sending a SCSI CDB Mode 
Sense (CMD=0x5A) to the device.

As a hack of a test, I removed the call to cdb_mode_sense_geom() and filled the 
buffer it should have returned
with zeroes and the failing thumbdrive now boots.

I have some searching I need to do to find out...
1) Is there a SCSI command to determine what protocols are supported?
2) Is there another SCSI command that might return similar required data?

Has anyone out there experienced similar booting difficulties?
Or does anyone have any recommendations on what approach I should take?

thanks,
Dave

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

Re: [SeaBIOS] Booting from USB thumbdrives, older drives boot, newer drives don't.

[Dave Frodin]

I have some addition results and questions.

I changed the page mode value that is in the struct sent in the 
MODE SENSE command from the existing value of 04h (rigid disk) to
05h (flexible disk). This change increased the number of passing
USB thumbdrives from 6 to 10. I'm testing with a total of 12 different
vendor/size drives.

The two failing drives still send a USB stall but the failure mode is
different. With the page mode type set to 4 the failure sequence was ...
   1) send MODE SENSE command to drive = device accepts data and ACKs
   2) device stalls the USB bus
With the page mode set to 5 the failure sequence is ...
   1) send MODE SENSE command to drive = device accepts data and ACKs
   2) device sends response = host accepts data and ACKs
   3) device stalls the USB bus
Also, the device only sends 6 bytes instead of the requested 27 bytes.

I'm planning on seeing if there isn't something missing prior to the mode
sense command tomorrow.

On a related topic, I have a copy of the Indispensable PC Hardware book
that lists the return values for the mode page 4 request. It list the cyc/head
data as follows...
 offset   value
==
   2 cyl(msb)
   3 cyl
   4 cyl(lsb)
   5 heads

the struct in the blockcmd.h file shows...
  struct cdbres_mode_sense_geom {
u8 unused_00[3];
u8 read_only;
u32 unused_04;
u8 page;
u8 length;
u8 cyl[3]; 
u8 heads;
u8 precomp[3];
u8 reduced[3];
u16 step_rate;
u8 landing[3];
u16 rpm;
  } PACKED;
which would put cyl[3] at offset 10 thru 12 and heads at offset 13.
Am I missing something here?

USB thumbdrives that don't stall on the mode sense return values like
cyl = 10h 3Fh 02h
heads = 00h
???

The values for that drive have 00h at offsets 2 thru 5.

I'm looking forward to any insight into this from anyone knowledgeable on the 
subject.

Dave

- Original Message -
 From: Dave Frodin d...@camp.se-eng.com
 To: seabios@seabios.org
 Sent: Wednesday, February 29, 2012 4:38:21 PM
 Subject: [SeaBIOS] Booting from USB thumbdrives, older drives boot,   newer 
 drives don't.
 
 I'm a new subscriber to seabios.org so feel free to straighten me out
 if needed.
 
 I've been debugging an problem we've been seeing with not being able
 to boot (Ubuntu specifically) off
 of a variety of newer USB thumb drives. I've been specifically
 looking at an older/newer pair of
 Sandisk Cruzer 4GB drives. I've been adding dprintf's to narrow down
 the problem to the blockcmd.c file.
 The function scsi_init_drive() queries the USB device to determine
 stuff like vendor/device/size/etc.
 Near the end of the function is a call to cdb_mode_sense_geom(dop,
 geomdata) to retrieve the info
 related to cyl/head type stuff. On the older/working thumbdrive it
 returns zeroes for all of the values
 that get used by the code. The newer/failing drive generates a
 stall on the USB bus, which it never
 recovers from. The cdb_mode_sense_geom() function is sending a SCSI
 CDB Mode Sense (CMD=0x5A) to the device.
 
 As a hack of a test, I removed the call to cdb_mode_sense_geom() and
 filled the buffer it should have returned
 with zeroes and the failing thumbdrive now boots.
 
 I have some searching I need to do to find out...
 1) Is there a SCSI command to determine what protocols are supported?
 2) Is there another SCSI command that might return similar required
 data?
 
 Has anyone out there experienced similar booting difficulties?
 Or does anyone have any recommendations on what approach I should
 take?
 
 thanks,
 Dave
 
 ___
 SeaBIOS mailing list
 SeaBIOS@seabios.org
 http://www.seabios.org/mailman/listinfo/seabios
 

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