SourceForge has been redesigned. Learn more.
Close

bios boots from usb but gujin can't see usb

law man
2008-05-01
2013-10-08
  • law man

    law man - 2008-05-01

    OK, I've got a lot of stuff working with Gujin and it's great.

    I have numerous ISO cd files that I have used 'cat' to put into partitions on my usb hdd.  this is great and I can usually boot from my usb hdd and then from the gujin menu select my usb partitions to boot from el-torito style.

    however...

    on a few computers, i've switched the bios to boot from the usb device.  it then boots ok into gujin, but gujin does not find the usb device (even though it is on it itself), so gujin only shows the internal hdd partitions.

    this is really strange.  how can i make gujin show the usb hdd partitions on these types of computers?

    i've tried 3 dell computers, and it's been the same on all 3 of them.

     
    • Etienne LORRAIN

      Etienne LORRAIN - 2008-05-01

      I am not sure, but maybe...
      Do you see the message " (CDROM emulation on BIOS 0x%X stopped)" after "Detecting disks:"
      when Gujin boots in verbose mode, on the Dell computers?
      The only way for Gujin to know if it has booted from CDROM is to ask the BIOS using
      the CDROM BIOS extensions, and this CDROM BIOS may also be used for USB (a virtual disk
      is simulated by BIOS approximately the same way).
      In this case, try to install Gujin with instboot --stop_emulation=0 to check if that is
      the problem (or modify in the menu the field "set stop CDROM FD/HD emulation" to 0).

      If not, can you tell me which BIOS disks Gujin displays when in "verbose" mode, on the
      startup "text" screen - for those Dell?

      Cheers,
      Etienne.

       
    • law man

      law man - 2008-09-16

      hi,

      i modified the 'set stop cdrom/ fd/hod emulation' to 0, and nothing happened.  tried rebooting with the new setting, but it doesn't seem to save the setting.

      not sure how to display 'verbose' mode in bootup (or do u mean installation?), but when the screen boots up and i press pause, i have the following info:

      detecting disks (booted from BIOS0 0x80):
      Have found 2 disks:
      0: ATAPI/lba master@0x1F0,0xF6, no media detected.
      1. IDE/lba48 master"0xFE00,0xFE12 (HP), size 74 Gb, 2 partitions.
      Analyse filesystems: found 0 ways to boot and 0 initial RAM disks.

      does that help?

       
    • Etienne LORRAIN

      Etienne LORRAIN - 2008-09-17

      Hi,

      > i modified the 'set stop cdrom/ fd/hod emulation' to 0, and nothing happened.
      > tried rebooting with the new setting, but it doesn't seem to save the setting.

      That may be another problem: Did you enable the tick box "write enable" ?
      If not, nothing is written to disk and you re-test the same configuration.
      Also, some BIOSes emulate a read-only BIOS disk from a USB Thumb drive.
      The "verbose" mode is also enabled by a tick box, but you have it enabled
      if you see "detecting disks (booted from BIOS 0x80):".

      If for any reason you cannot check tickboxes and save them to disks,
      you can use options from instboot to set those switches at installation time.

      The 'set stop cdrom/fd/hd emulation' is quite special because it does not
      influence the probing (you can re-proble with CTRL-R) but calls the BIOS
      to say "I have finished with the [CDROM] disk simulation, please stop it", which
      is needed in some cases - either before probing disks or after probing them,
      or not at all. So you cannot change 'set stop cdrom/fd/hd emulation' value
      and then just reprobe by CTRL-R, you have to reboot.

      Etienne.

       
    • law man

      law man - 2008-09-17

      ok, i made it write enabled and changed that setting for emulation.  i rebooted the system and saw that all the settings had been saved.

      still cannot see partitions on the usb hdd.

      also, when tried to boot windows ntfs partition through usb gujin, (with write enabled) i get:

      "error 0x4 while partition hiding/unhiding (disk content unchanged)"

      ps. manage visible partition is ticked.
      pps. see 'general protection fault' posting for addition similar problems on this same machine.

       
    • Etienne LORRAIN

      Etienne LORRAIN - 2008-09-18

      So there is a problem on the partition table of the USB HDD and Gujin prefer not
      to continue with this disk.
      Can you please do, using linux, an "/sbin/fdisk -l /dev/sd?" and post the result.

      But I may know what is happening on those DELLs: the BIOS simulate a disk which
      covers only the first partition, i.e. the first sector of the emulated disk is
      the first sector of the partition and not the first sector of the disk.
      There is no partition table in the first sector of the partition - so Gujin cannot
      display other partition.

      Do you use instboot option "--usb_hdd"? I assume it else Gujin would not have booted
      on those DELLs. You may be able to play dirty tricks by putting a false partition
      table (offseted by the start of the first partition) in the first sector of the
      first partition - assuming that DELL BIOS offset sector number but do not check
      the end of first partition to end the disk, but you are entering very dirty hacking.

      The system to hide or un-hide partitions is made for Windows98, because the booted
      partition has to appear as the first un-hidden partition on disk, i.e. C:.
      If you do not need it (i.e. booting Windows NT), it is better not to enable the
      tickbox. The problem there is that Gujin did not find the partition table on
      the USB, so it has to be a "floppy - like" disk and that kind of disk will always
      take the letter "C:", and window98 cannot boot anyway because the main Window
      directory will always be on D: when the USB disk is inserted.

      p.s. can you tell the size and filesystem type of your first partition of this
      USB disk? And do you have the tickbox "probe BIOS disks" active - because
      your USB drive is only a BIOS disk.

      p.s. I like to see 'general protection fault' messages (with the exact version number
      and the GCC version if Gujin has been rebuilt) - even a photo of the screen to my E-mail
      is sufficient.

      Etienne.

       
  • Malo

    Malo - 2009-11-22

    HI.. I've notice the same error on my 16gb usb pen. Still can't able to see the device on Gujin menu. Only partition from my local hd.. I've tried changing BIOS, EBIOS, -usb_hdd option, making only one fat16 partition, making only one primary partition with gujin inside and other logical partition with isos "catted" inside.
    Still not working
    :(

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2009-11-22

    Hi malo87,

    Your message is not really precise. Process in order:

    - if you do, with gujin-2.7, the dd to erase the beginning of USB disk and then "./gujin /dev/sdg -mbr", does that USB boot the system and the disk is displayed in verbose mode?
    - Then, if you do an "fdisk /dev/sdg", delete the only partition and create two or more primary partition, and re-install Gujin like "./gujin /dev/sdg1 -mbr-device=/dev/sdg", does that USB still boot the system and do you see the partitions count in the initial (text) screen?
    - Then, if you cat some ISO into the partitions where Gujin is not installed, do you see them in the menu?

    There can be a lot of possible failure mode, bad partition table, no filesystem in the partition, it is difficult to tell what is happening in your case.

    Etienne.

     
  • Aleksey Midenkov

    Hello Etienne!

    I have similar problem. My USB stick with many partions works fine on one laptop. But it doesn't work on Asus P5QL with latest BIOS. When I run it successfully on laptops it shows 'Detecting EBIOS 0x80'. But on Asus it shows 'BIOS 0x80'. What is the difference between 'BIOS' and 'EBIOS'? Also I have all tickboxes set (otherwise it wouldn't work on laptop): 'probe BIOS hard disks'.

    The output of fdisk -l:

    Disk /dev/sdb: 32.0 GB, 32006733824 bytes
    255 heads, 63 sectors/track, 3891 cylinders, total 62513152 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0002361b

       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1   *          63      192779       96358+   e  W95 FAT16 (LBA)
    /dev/sdb2          192780     7807589     3807405   83  Linux
    /dev/sdb4         7807590    62508914    27350662+   f  W95 Ext'd (LBA)
    /dev/sdb5         7807653     9253439      722893+  83  Linux
    /dev/sdb6         9253503    10699289      722893+  83  Linux
    /dev/sdb7        10699353    12145139      722893+  83  Linux
    /dev/sdb8        12145203    13590989      722893+  83  Linux
    /dev/sdb9        13591053    15036839      722893+  83  Linux
    /dev/sdb10       15036903    16482689      722893+  83  Linux
    /dev/sdb11       16482753    17928539      722893+  83  Linux

    But it should be fine because it works on laptop, isn't it? Also in Asus BIOS there are boot USB option as hard disk, floppy, DVD. I tried every option. In 'hard disk' mode it at least starts Gujin which succesfully enters menu. So, I suppose, it found succesfully second stage boot-loader which is on first partition (100Mb FAT). Can we debug the problem together?

     
  • Aleksey Midenkov

    I also tried it on third computer. It worked fine! So, there is something wrong with some kind of BIOS.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-07-28

    Hello Midenok,

    > What is the difference between 'BIOS' and 'EBIOS'?

    The difference is that BIOS interface is older (made when disks were small in size) and can read sectors up to the limit (Heads*Cylinder*Sectorpertrack), that is why Gujin displays those three numbers Heads, Cylinder, Sectorpertrack when detecting a BIOS only hard disk.
    The EBIOS (Extended BIOS) interface has no such limit and can read any sectors.
    So, at best, Gujin will only propose you to boot the partitions below the limit (see fdisk -u) if it does not find an EBIOS interface.
    It is possible that the BIOS on your Asus P5QL do not implement the "Extended BIOS", then there is no other solution than having a full USB driver in Gujin and considering the number of chipsets existing, that would be a lot of code to write.
    It is also possible that you Asus P5QL implement a buggy "Extended BIOS", and Gujin may be able not to trigger the bug, there is already some "dirty patchs" there to work with some ASUS problem.
    You can find why Gujin did not find/choose not to use the EBIOS interface by booting DOS on your ASUS and executing dbgdisk.exe (type Control D to exit Gujin) and then reading the DBG file produced (on another PC).
    If you wonder how to boot DOS, take a similar USB disk and format it with a software called HPBOOT (HP Drive Key Boot Utility), then copy dbgdisk.exe (I think it is in standard.tar.gz) on that key and boot that key.
    This DBG file may tell you exactly what is the problem, if you do not understand I may help but I need to read this file too.

    Cheers, Etienne.

     
  • Aleksey Midenkov

    Hello Etienne,

    I have added output from dbgdisk.exe of good and bad BIOSes. I suppose, that problem is with this message:

    BIOS only or unknown ideIOadr/ideIOctrladr

    Aleksey.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-07-31

    Hello Aleksey,
    I have read good.dbg and bad.dbg and have a problem: nothing seems really wrong.
    The only bad thing for "bad.dbg" is that only one "hard disk" is found, number 0x80, which would mean that when booting from USB the real internal hard disk is not accessible (I assume there is one internal hard disk on the ASUS).
    The message "BIOS only or unknown ideIOadr/ideIOctrladr" at the end is to send an ATA command to all IDE hard disk, and only to them, so it is normal that the message appear for USB disks.
    So to repeat, the USB disk in bad.dbg is accessed using EBIOS by the ASUS, and Gujin should be able to see all its partitions.
    There are two possible causes:
    1) there is a bit in the USB description that the BIOS is reading which tells if the disk is removable or not. This bit is not accessible to Gujin, some BIOS will only implement Extended BIOS disk access when this bit is set, because they assume a removable disk is like a floppy and do not have a large capacity. That would explain why the USB disk used for the test in BAD.DBG can have access to EBIOS while your "production" 32 Mbytes USB cannot (two different USB disks with different USB descriptions).
    2) The BIOS of your ASUS is reading the MBR (first sector) of your 32 Mbytes USB disk and do not like what it is reading, and decides to only implement BIOS and no EBIOS for whatever reason. The MBR read is the Gujin MBR, so it may be possible to do something (When you boot HP DOS disk the first sector is HP MBR).
    I would say, to test that case, there are two solutions (shown from simple to complex):
    - Reinstall Gujin the way you do it usually, but add the option to the installer "-sig0x29=0x28" - that changes a signature from 0x29 (the most used value) to 0x28 (another value declared as valid in the documentation) and test if that solves your problem. If not you could use any other value than 0x29 or 0x28 and re-test.
    - Reset the MBR of your 32 Mbytes USB disk (for instance with the one of the HP disk) and then re-install Gujin in the first partition, taking care not to overwrite the MBR. That would be done with such Linux commands:
       $ sudo -s
       # dd if=/dev/sdb of=/save_sdb_mbr bs=512 count=1   # just saving for safety reasons, /dev/sdb has to be your 32 Mb USB
       # dd if=/dev/sdc of=/HPMBR bs=410 count=1 # the HP MBR WITHOUT its partition table, /dev/sdc has to be the HP key
       # dd if=/HPMBR of=/dev/sdb bs=410 count=1 # use the HP MBR on your 32 Mb USB, no partition overwrite
       The part in between bytes 410 and 512 is the partition table, you do not want to replace the 32 Mb partition table by the HP partition table, that is why the "bs=" parameter is different in previous commands…
       Then you have to use fdisk on /dev/sdb to activate (command A) the first FAT partition, and only that partition.
       Then you have to reinstall Gujin in your first partition (installing Gujin that way is not the simplest way), I assume you used
        # gujin /dev/sdb1  # will erase everything on sdb1 so backup before / restore after
    The second solution is more complex, so really take care of what you are typing…

    Can you tell me success/failure after these tests?

     
  • Aleksey Midenkov

    Etienne,

    I have forgotten to attach 32gb multiboot pen that was the cause of trouble. Now here are the results of dbgdisk with that pen attached:

    good2.dbg
    bad2.dbg

    So on working laptop here are 3 disks:
    0x80: 32mb USB pen with DOS and DBGDISK.EXE
    0x81: 32gb USB multiboot pan with many ISO images
    0x82: Internal HDD

    On ASUS there are 2 disks:
    0x80: 32mb USB pen with DOS and DBGDISK.EXE
    0x81: 32gb USB multiboot pan with many ISO images
    (no internal HDD attached, as you rightly supposed)

    Diff between bad.dbg and bad2.dbg apart from some number differences shows that:

    - done probe_bios base_disk 0x80
    +
    +Hard disk 0x81: BIOSDISK_gettype: write protect
    +   done probe_bios base_disk 0x80

    Maybe this is the cause of problem: BIOSDISK_gettype() tells Gujin 'write protect' and Gujin decides to not use that disk.

    Also, I've noticed strange number difference:

    -Probing BIOS Hard drives (total = 1):
    -Hard disk 0x80: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0x8181 i.e. 33,153
    +Probing BIOS Hard drives (total = 2):
    +Hard disk 0x80: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0x8182 i.e. 33,154
    EBIOS detected: version 0x3000, features(0x5): extended_fct enhanced

    That is what Gujin found for 32mb pen drive I suppose. The total number of sectors differs by 1 with and without second USB pen attached. Is that normal?

     
  • Aleksey Midenkov

    I have tried -sig0x29=0x28 option and that didn't helped.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-01

    Hello Aleksey,
    You correctly spotted the problem:
    Hard disk 0x81: BIOSDISK_gettype: write protect   done probe_bios base_disk 0x80
    What happens is that Gujin want to detect if hard disk 0x81 is present in function  BIOSDISK_gettype() of file disk.c, Gujin calls _BIOSDISK_gettype() of file bios.h which returns carry set, then Gujin ask what the error was to the BIOS by calling BIOSDISK_error() of disk.c and _BIOSDISK_getstatus() of bios.h and reads AH=3 which means "disk write-protected".
    For more info on those BIOS calls you can look at:
    http://www.ctyme.com/intr/rb-0639.htm
    http://www.ctyme.com/intr/rb-0606.htm
    http://en.wikipedia.org/wiki/INT_13H
    But there is a bug in _BIOSDISK_gettype() of file bios.h, in that this function only saves the carry flag after having modified it by the "shll" assembly instruction.
    If you can recompile Gujin after modifying the function in bios.h from:
    extern inline unsigned char
    _BIOSDISK_gettype (unsigned char disk, unsigned *nbsect,
       unsigned char *status)
      {
      unsigned char carry;
      unsigned dummy;

      asm ASMREAD (
    " xor %%dh,%%dh \n"
    " xor %%cx,%%cx \n"
    " int $0x13 # _BIOSDISK_gettype \n"
    " shll $16,%%ecx \n"
    " movw %%dx,%%cx \n"
    " movb %%ah,%1 \n"
    " setc %0 \n"
    : "=qm" (carry), "=qm" (*status), "=c" (*nbsect), "=d" (dummy)
    : "a"((unsigned short)0x1500), "d" (disk) /* disk = 0x80..0x8F else buggy Compaq */
    );

      return carry;
      }
    to:
    extern inline unsigned char
    _BIOSDISK_gettype (unsigned char disk, unsigned *nbsect,
       unsigned char *status)
      {
      struct { unsigned char carry, status; } ax;

      asm ASMREAD (
    " xor %%dh,%%dh \n"
    " xor %%cx,%%cx \n"
    " int $0x13 # _BIOSDISK_gettype \n"
    " setc %%al \n"
    " shll $16,%%ecx \n"
    " movw %%dx,%%cx \n"
    : "=a" (ax), "=c" (*nbsect), "+d" (disk) /* disk = 0x80..0x8F else buggy Compaq */
    : "a"((unsigned short)0x1500)
    );
      *status = ax.status;
      return ax.carry;
      }
    Your problem may disappear. Note that I did not test that patch at all, I am at work and should really do something else right now…
    Cheers,
    Etienne.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-01

    > The total number of sectors differs by 1 with and without second USB pen attached. Is that normal?

    Well, that is a very usual bug, that is why it is writen as "probably nb sector".
    This number is not used if Extended BIOS is present because you have another way to get the number of sectors.
    Determining the number of sector of a disk is quite complex, Gujin has quite some "dirty patch" there, mostly when you begin to talk about SCSI disks (CDROMs/DVDs attached over ATAPI are more SCSI than ATA).

     
  • Aleksey Midenkov

    Hi Etienne,

    yes, that fix has perfectly worked!

    Also, I have tested byte order in ax structure. It works good: al gets to carry, ah gets to status.

    Thank you!

     
  • Aleksey Midenkov

    Etienne,

    I was premature with my 'perfectly' adverb. :) Yes, it shows menu items on Asus now. But it can't correctly start any of them (on laptop it still starts with no problems). Seems like execution goes to wrong address. This leads to senseless boot errors or just halts with garbled screen.

    I will supply dbgdisk output later.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-03

    At least there is improvement, it would be nice to have this dbgdisk to see if the disk has been detected correctly.
    If selecting the item do not work, it may be a problem with another subsystem, so maybe it is not dbgdisk.exe but dbgfs.exe or dbgload.exe which would give the right information.
    If you have a "General Protection", it may be the compiler you are using - it then would be nice to see the message (taking a photo of the screen may be the easiest) and I would need you to generate and send me the boot.asm you get by typing "make boot.asm" with that compiler.
    I will try to generate the installer "gujin" on a known good debian 32bits today and attach it to the tracker, I am sorry I am a bit busy at work and at home these days…

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-03

    Aleksey,
    The tracker is limited to 256 Kb files, so you can download a temporary patched version here:
    http://sourceforge.net/projects/gujin/files/temporary_patches/gujin/download
    It will identify as version 2.8.* in the bottom of the screen.
    You may have to make this file executable after downloading it, use this installer as usual.
    It has been checked working on one of my PC.

     
  • Aleksey Midenkov

    Hi Etienne,

    I have compiled standard.tar.gz myself. I don't think that this causes some additional troubles.

    GOOD3.DBG
    BAD3.DBG

    Diff between bad2.dbg and BAD3.DBG:

    -Hard disk 0x81: BIOSDISK_gettype: write protect
    -   done probe_bios base_disk 0x80
    +Hard disk 0x81: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0xB9000181 i.e. -1,191,181,951

    No doubt, that there is an error with number of sectors detection (right value should be close to 0x3B9E000).

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-06

    Hi Aleksey,

    As I said, a lot of BIOSes are buggy there and Gujin only trust that value if it does not have anything else more safe.
    In your case, after the line:
    Hard disk 0x81: BIOSDISK_gettype: returns 0x3, i.e. hard disk, probably nb sector = 0xB9000181 i.e. -1,191,181,951
    you have:
    EBIOS (buffersize before 0x4A after 0x42) reports: nbhead: 255, nbsectorpertrack: 63, nbcylinder: 3891, bytepersector: 512, nbtotalsector: 62,513,152 …
    So gujin has found a better value and use it from now on:
    fully trusting disk content, adjusting bytepersector 512, nbtotalsector 62513152
    Basically there is three size reported: the one with BIOS (unreliable), the one with ExtendedBIOS (more reliable) and the one recognised by Linux and written into the MBR (only there if Gujin has been installed on that device).
    The last two are identical in your case and that is the ones that Gujin is using.
    So I know there was a bug in Gujin, triggered by your BIOS, and I need to generate a new version.
    The thing I am bothered with, is that you said there was a General Protection Exception or something like that when you try to load a kernel of your USB disk; that would be another problem, possibly unrelated.
    That is why I would like to know if you can use my gujin installer I have put on the WEB server to fully load your USB kernels, and I would still be interested to know (if my version works) which compiler you used to create that other problem.
    I would also like to know which exact problem is triggered, so would like the first few line of what Gujin displays (you can usually pause the screen with the "Pause" key), or take a photo of the screen.

    Cheers,
    Etienne.

     
  • Aleksey Midenkov

    Hi, Etienne!

    Yes, I\'ve tried your installer. No difference. As I said before, execution (of booted OS) goes to wrong address. As a consequence, the errors are senseless (and random per particular OS image). You can examine some photoshots here.

    Lyosha.

     
  • Aleksey Midenkov

    Correction: constant per particular OS image and random between different OS images.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-09

    OK, this way of booting a CDROM involves Gujin terminating but leaving a small TSR (Terminate and Stay Resident) to simulate the El-Torito boot disk, and it seems you have problems with it on your ASUS PC.
    The aim of this small TSR is to get BIOS requests from isolinux (or any other real mode application) and convert them to reads to the right partition to give the right data back to isolinux.
    It seems it is not the right data given back, either because the conversion was wrong, or the data read was wrong, or the Gujin request reported an error.
    That part of Gujin is not the easyest to debug, you can not even use any DOS debug executable because you cannot simulate an El-Torito boot from DOS (it would overwrite parts of memory used by DOS).
    What I do in that case is to either "make dbgload_screen" and use the file boot.bin to install (./instboot boot.bin /dev/sdb1) or simply replace line 3032 of main.c from "#if 0" to "#if 1" (which gives less information on the screen but that is the most important information) and just type "make" to get the ./gujin installer.
    Comparing the results in between a working and a non working PC may give a clue of the problem.
    If nothing is conclusive here, it is possible to uncomment line 2823 of main.c "//#define FLOPPYDBG" to get a string displayed on the screen each times a request is done by isolinux and see the reply given by Gujin TSR, but it is in a cryptic string (space here is at a premium).
    I can help you interpret the result, that will probably involve more photos…
    Cheers, Etienne.

     
  • Aleksey Midenkov

    Hello, Etienne!

    Trying to run boot.bin from "make dbgload_screen" gives 'checksum error'.

    The output from line 3032: laptop   asus

    To sum up, there are only 2 differences:

    CS_nb_disk:      laptop:2  asus:1
    target_max_head: laptop:255 asus:254

    Will try to supply more debug later.

     
  • Aleksey Midenkov

    FLOPPYDBG output on Asus here.

    It hadn't work on laptop. It started ISO without any debug output.

     
  • Aleksey Midenkov

    Also, I don't know if this can be related to a problem: video in Gujin on Asus works really slow. I see how screen is updated with lines of characters from top to bottom. On laptop Gujin's video is normal.

    Now I've just noticed some error in further FLOPPYDBG output: file.

     
  • Aleksey Midenkov

    Another error in reading sector 171736 and same string 'Unknown keyword in configuration file: ME'.
    … and another error reading sector 171738…

    …and after a couple of dozens of screens another error: at sector 181930. Just before showing boot menu: file.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-14

    The format of FLOPPYDBG logs is the following: each times the application (ISOLINUX) calls INT 0x13, the letter a, b, c, d, e are displayed followed by their value (of registers ax, bx, cx, dx, es).
    The most significant byte of ax is the command of INT 0x13, in this case 0x42 which means "read sector with EBIOS".
    For command 0x42, the parameter of the read command are in the low byte of dx (disk 0xE0, i.e. CDROM) and in the memory pointed by ds:si. following the "#" caracter is the number of sector to read, following "@" is the address where to store the content of the sectors, and following the "l" is the LBA requested (parameters read from the memory on what should be a CDROM with 2048 bytes per sectors) (see line 3485 of main.c).
    I am looking at you last screen shot before ISOLINUX displays "EDD: Error 0x8000 reading sector 181930).
    So we can see the "l" showing the 48 bits number 0000 000B 1AA8, 0xB1AA8=727720/(2048/512)=181930
    The LBA displayed is already modified for the sector size change, see "loop_rotate" and line 3636 of main.c
    Then the log display the maximum request size at this LBA considering the size of the CDROM image after the "m" which is 0x0000000AF4F3, i.e. 718067. We are just requesting one sector so it is fine (1 < 718067).
    Then follows the "N" letter (line 3676 of main.c) saying that we are requesting 4 512 bytes sectors (adjusted from 1 2048 sector).
    At line 3681 of main.c we display + followed by the number of sector read up-to-know, which is 0x824. That value should not matter because the file is not fragmented (it is a partition).
    Then there is "S" 0x7B46 which prints the stack pointer value line 3725 in case we overflow.
    The "I" and "Z" show the segment request and the size requested. Because that is a contiguous file the "nb sectors this time" following the "s" is equal to "Z", the "o" (line 3908) indicate the calculated start of the request 0x823D4D (including the starting partition offset that we see on IMG_0172-laptop.jpg of 7807653) (that is 0xB1AA8 i.e. 727720/4 = 181930).
    Then we display E 0080 (target disk 0x80 using EBIOS) e 2000 (for register es)  b 0000 (for bx, memory placed in es:bx) s 0004 (for nb of sectors), seems to be the initial parameters (line 3926).
    Then  there is "|" to say how many sectors have been read (the whole lot because that is not a fragmented file), we have the whole lot in memory.
    Then we try to set back the registers as they should be if there was a real CDROM, 1 sector requested…
    So the old ax value, new ax dx was 4200, new 8000 0a13 *THOSE SEEM VERY STRANGE*
    The status of last HD is printed after the 'H', registers ax, bx, cx, dx, es are then printed.
    And there is capital R printed because the interrupt returns with carry set indicating an error.

    My first guess is that your EBIOS is modifying either dx or ax when calling INT 0x13/0x42, it is not allowed to do so…
    I would try to modify the block at line 3946 of main.c from:
    //" int $0x13 \n"
    " pushfw \n"
    " pushw %cs \n"
    " callw pushIPjumpOLDINT13 \n"
    " popw %ds \n"

    to:
    " pushw %dx \n"
    " pushw %ax \n"
    //" int $0x13 \n"
    " pushfw \n"
    " pushw %cs \n"
    " callw pushIPjumpOLDINT13 \n"
    " popw %ax \n"
    " popw %dx \n"
    " popw %ds \n"

    It may work, it may crash, I did not test it… It would be nice to know if the problem is the ax or the dx register.

    Cheers, Etienne.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-23

    I re-read those screen shots, and basically the error is even simpler: after the "|" character there should be a "Y" if carry was not set on the return of INT 0x13, as you can see here:
    https://sourceforge.net/tracker/download.php?group_id=15465&atid=115465&file_id=451127&aid=3552449
    The Gujin TSR decides it no more needs to read any more because carry was set - the EBIOS returns an error, you can see the error code in the two digits just after the "f" marker: 0x0A (meaning "bad disk sector flag" considering BIOS documentation).
    So the Gujin TSR can only report to ISOLINUX that there was an error reading that sector, and ISOLINUX retries to read the same sector, and the Gujin TSR report the same error…
    You could try to insert a "clc" assembly instruction by replacing line 3948 of main.c:
    " callw pushIPjumpOLDINT13 \n"
    with:
    " callw pushIPjumpOLDINT13  ; clc \n"
    to see if ignoring the error returned by EBIOS would help, note that the carry flag was clear at entry of the EBIOS by "orb $0x40,%ah".
    I think the only answer possible is that Gujin cannot fix the BIOS…

     
  • Aleksey Midenkov

    Hi, Etienne!

    Sorry for long delay. Also, I am sorry to say, that Asus output results have been changed. I don't know what have happened to input conditions, but there are no more reading sector errors! Though, final behaviour is still the same.

    Good news! I managed to get FLOPPYDBG output from working BIOS. Here are comparable screenshots. I also made patched version of Gujin which preserves AX and DX.

    The first difference between Working and Asus is 'f 0246' vs 'f 0296' (I have marked it with red marker). There are also differences between patched and not-patched versions of Asus. F.ex. 'r 0000' vs 'r 4200', though working sample says 'r 0000'.

    I have not tried yet 'clear carry fix'. Will try now…

     
  • Aleksey Midenkov

    Asus (not patched):

    Page 1
    Page 2

     
  • Aleksey Midenkov

    Working (not patched):

    Page 1   Page 2   Page 3

     
  • Aleksey Midenkov

    Asus (patched):

    Page 1   Page 2

     
  • Aleksey Midenkov

    Nope, CLC have not helped…

     
  • Aleksey Midenkov

    Asus stops reading at LBA 0x1BA8, but Working continues by reading 0x7B48.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-24

    You do no more have carry (i.e. errors) when exiting the EBIOS on these screen-shot, the clc will not help, and saving/restoring dx is not needed (because the value restored is anyway not used).
    The saving and restoring of ax was also a quick test, it does not work so shall be removed.
    In short please undo every modifications, start from a fresh copy.
    Because everything seems to work (only "r 0000" and no "R 0000") but isolinux displays "vesamenu.c32: not a COM32R image", it probably means that reads were successful but did not contain the right data.
    That means either one of two things:
    - either parameters translated by Gujin TSR are wrong
    - or EBIOS did not give the right content
    I would need more time to know, but if Gujin did not translate correctly I do not know how the same USB stick would work on another PC…

     
  • Aleksey Midenkov

    So, there is no help in different DX value?

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-24

    Preserving DX will not help, its value is overwritten few assembly lines later.
    There may be another problem in Gujin TSR which would create what you are seeing later on, but I do not know what it could be.
    The "f" marker which is different displays the flags register, I do not think it is a problem.
    My time is very limited these days….

    Cheers,
    Etienne.

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-26

    Basically the thing to know about your ASUS is if the BIOS really works (when using a USB disk).
    You can test that without Gujin involved, and it is quite simple.
    What you need is another USB stick of approximately the same size as the one you were using - but even a smaller USB key may indicate failure.
    You need to format it with the HP bootable disk utility, so that this USB disk is one single FAT partition and can boot to DOS.
    Then you copy few identical ISO images (or any big file) on this USB drive with Linux or Windows, and check they really are identical (but their name) using diff.
    Then you copy fc.exe, scandisk.exe and chkdsk.com from any old DOS partition onto that USB disk.
    Then you reboot the PC using the USB, so DOS is running (DOS only use the BIOS or EBIOS to access disks).
    Then you do a chkdsk and scandisk to do a full surface scan to see if any sector reads generate a BIOS error.
    Then you use fc.exe (file compare) to compare two of the identical files to see if the right sectors are read by BIOS.
    If DOS cannot read successfully the right sectors, then Gujin will not be able neither.
    You would not be the first to get those simple tests failing, I did and got BIOS failures myself… without even involving Gujin.

    Cheers, Etienne.

     
  • Aleksey Midenkov

    And how about dumping data checksum in your FLOPPYDBG output?

     
  • Etienne LORRAIN

    Etienne LORRAIN - 2012-08-27

    It is possible to calculate and display the checksum in FLOPPYDBG, but the TSR do not know when the upper layer (ISOLINUX) loads the next segment of a file or a new file. Anyway we already know the checksum will be wrong because the wrong content is loaded - ISOLINUX do not get what it did request…

     
  • Aleksey Midenkov

    Hi! I want to continue my quest with Gujin and Asus mobos. I have another Asus machine with modern UEFI BIOS (Maximus Gene VI). The problem is absolutely identical!

    I'll try to recollect how everything works. Please, correct me if I'm wrong.

    1. BIOS loads USB disk in 'Hard-drive mode'. BIOS boot code have passed control to MBR and its mission have been finished there;
    2. Gujin shows menu, user selects disk in 'El-Torito mode';
    3. Gujin starts specially patched TSR, that knows the address of El-Torito image;
    4. TSR is emulator of BIOS services, it patches INT table, so that ISOLINUX calls TSR instead of real BIOS.
    5. ISOLINUX thinks it boots from CDROM, when it needs another chunk of data, it calls appropriate BIOS function which is routed to TSR who supplies data from El-Torito image.
    6. One end of TSR is connected to ISOLINUX, another end of TSR is connected to real BIOS USB services. When ISOLINUX calls CDROM drive IO, TSR translates these calls into USB IO and passes them to real BIOS and back it translates returned result from USB IO into CDROM IO and returns it to ISOLINUX.

    I'm I right about 4., 5., 6.?

     
    Last edit: Aleksey Midenkov 2013-10-07
  • Etienne LORRAIN

    Etienne LORRAIN - 2013-10-08

    Hi Aleksey,

    Just to be sure of the "identical problem", it is "vesamenu.c32: not a COM32R image" when booting a Gujin USB disk containing a partition which is an image of a Linux distribution which itself start isolinux? And you can check that the Linux distribution works fine when written on a CDROM/DVD, and the same USB disk works on another PC, isn't it?

    For your points:
    1. yes, in your case your want "hard drive mode" because you have partitions on the USB, Gujin's first sector is loaded and executed by the BIOS and Gujin loads the rest of it's code/data using BIOS/EBIOS.
    2. Yes
    3. Yes, address of El-Torito is already known as start of partition + offset
    4. Yes
    5. Yes, Gujin TSR translate the request made by ISOLINUX into coordinate on the USB disk and call directly the old BIOS vector to provide the data. The translation may involve multiple calls to the initial BIOS (for a single ISOLINUX request).
    6. Yes.

    I did not look more into that problem myself, but will try to help - I am in holidays far away outside of any GSM/internet coverage from Monday october 14th to Monday 21st.

     

Log in to post a comment.