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?
Otherwise, checksum_far is getting called with zero as the length
parameter, and the ROM checksum in the header end up beeing zero
after vga_post() is called.
Signed-off-by: Julian Pidancet <julian.pidancet(a)gmail.com>
vgasrc/vgabios.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/vgasrc/vgabios.c b/vgasrc/vgabios.c
index 58e467d..c1b10c1 100644
@@ -1255,6 +1255,7 @@ vga_post(struct bregs *regs)
// Fixup checksum
extern u8 _rom_header_size, _rom_header_checksum;
- u8 sum = -checksum_far(get_global_seg(), 0, _rom_header_size * 512);
+ u8 sum = -checksum_far(get_global_seg(), 0,
+ GET_GLOBAL(_rom_header_size) * 512);
On Thu, Mar 01, 2012 at 05:39:25PM +0900, Daniel Castro wrote:
> Hello all,
> The xen pv drivers are almost done.
> When I start the booting process from hda seabios tries to read lba at
> 0 (sector 0) buffer (buf_fl) to 7c00 count 0 operation 0 (read)
> command 1 (unlisted)
> I do not understand count 0 and command 1.
> Should it be count 1, for the first sector on the drive and a command
> such as listed in drive.h?
> Is this normal? Am I missing something?
I don't understand what you are reporting/asking.
The code at boot.c:boot_disk() issues a legacy bios read (int 13 ah=2)
of the first sector (count=1).
On Sun, Mar 04, 2012 at 10:13:56PM +0100, Christian Gmeiner wrote:
> Am 4. März 2012 19:54 schrieb Kevin O'Connor <kevin(a)koconnor.net>:
> > On Fri, Mar 02, 2012 at 09:32:38AM +0100, Christian Gmeiner wrote:
> >> What is the cause of this error message?
> > It means an application (eg, a bootloader) called a BIOS function with
> > an invalid parameter. It's not a SeaBIOS error condition. (Indeed,
> > it's quite common to see the bootloader probe for drives - which
> > appears to be what is occuring in your log.)
> So you are saying that this is a grub mistake? Or should I disable cdrom/floppy
> support from seabios?
It's an information message. It does not indicate a problem at all.
On Fri, Mar 02, 2012 at 09:32:38AM +0100, Christian Gmeiner wrote:
> What is the cause of this error message?
It means an application (eg, a bootloader) called a BIOS function with
an invalid parameter. It's not a SeaBIOS error condition. (Indeed,
it's quite common to see the bootloader probe for drives - which
appears to be what is occuring in your log.)
>I am tying to boot via CFC.
I'm not sure what a CFC is.
On Sun, Mar 04, 2012 at 08:08:12PM +0000, Julian Pidancet wrote:
> On Sun, Mar 4, 2012 at 7:54 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > The only thing I can think of would be to post-process the assembler
> > and replace "retl" instructions with "retw $2" instructions. I'm not
> > sure if it would work and it would be real ugly.
> As I mentionned, ret is not the only instruction causing problems.
> I've identified issues with leave, enter, iret, and even some forms of
> the call instruction, and the list is probaly not complete yet. So it
> could be even more complicated that we think.
> It looks like x86emu was never tested with gcc produced code before.
> And it looks like handling of the 0x66 instruction prefix has been
> neglected in a lot of different places in the code.
The coreboot project has an improved x86emu - it may have many of
these issues fixed.
On Sun, Mar 04, 2012 at 07:26:58PM +0000, Julian Pidancet wrote:
> On Sun, Mar 4, 2012 at 7:04 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > So, I guess the question is, how important is support for
> > current/legacy x86emu versions?
> I've tried to replace .code16gcc with .code16 in src/code16gcc.s to
> see if gcc would be able to generate code which doesn't use 32bit
> version of the call/ret instructions. The result was quite
> disappointing, it generates functions like this:
That definitely wont work. Gcc assumes the return address is 32bits -
it will be totally confused if it's not. (Function parameters passed
on the stack wont be in the right spot.) Likely other things will
break as well.
> I am going to propose a patch to xorg-devel in the next few days, but
> in the meantime, it would be nice to find a solution in SeaBIOS so the
> code can work with older versions of Xorg.
The only thing I can think of would be to post-process the assembler
and replace "retl" instructions with "retw $2" instructions. I'm not
sure if it would work and it would be real ugly.
On Sun, Mar 04, 2012 at 03:48:17PM +0100, Christian Gmeiner wrote:
> As my last mail is still waiting for approval, I will resend it.
> Hi all,
> I am trying to boot Linux via Grub
> from an USB stick. I have tried the USB stick on my devel i5 machine
> and it worked.
> Log can be found here: http://nopaste.info/2b119334eb.html
I don't see anything that looks obviously wrong from your log. A more
detailed description of what's failing may help.
Also, you could try copying the image to a machine and run it under
qemu (both as an ATA image and as a USB ehci image). Testing under
qemu will verify that it's not a logic error.