search for: 0x7c00

...; Ok now we are getting somewhere! Those old vars did the trick. > libguestfs-test-tool launched with qemu-wrapper as expected with the > debug port open. > Now on to the fun part! > > (gdb) set architecture i8086 > The target architecture is assumed to be i8086 > (gdb) break *0x7c00 > Breakpoint 1 at 0x7c00 > (gdb) target remote :1234 > Remote debugging using :1234 > 0x0000fff0 in ?? () > (gdb) cont > Continuing. > > The breakpoint you documented as when the boot sector has been loaded > into memory by the BIOS and control is passed to the boot sect...

...comment for the same(?) code in gptmbr.S: /* here we computer CHS values or just do some dummy computation for EBIOS */ So it's just for simplicity or lazyness. As the code doesn't do any harm (supposedly) in that case the coder just lets it run. > > - I assume that > movw $0x7c00, %bx > movw $4, %cx /* Sector count */ > movl (lba_offset), %eax > 2: > call read_sector > ... > loopw 2b > shall load the bytes of isolinux.bin to address 0x7c00. Yes, I think so. It loads the next bootloader (which is four secors instead of th...

...ging using localhost:1234 0x0000fff0 in ?? () at localboot.inc:68 68 jmp kaboom ; If we returned, oh boy... How does "jmp kaboom" get here? We are at the BIOS entry point: (gdb) display/10i $cs*16+$eip 1: x/10i $cs * 16 + $eip 0xffff0: ljmp $0xf000,$0xe05b [...] (gdb) info symbol 0x7c00 bootsec in section .text (gdb) b bootsec Note: breakpoint -2 also set at pc 0x7c00. Breakpoint 1 at 0x7c00: file extlinux.asm, line 146. Breakpoint -2? That's new for me. Anyway: (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x000005a7 in ?? () 1: x/10i $cs * 16 + $eip 0...

...r. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- mbr/isohdpfx.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S index 17e1efe..a693ccb 100644 --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -48,8 +48,8 @@ isolinux_start_hybrid = 0x7c00+64+4 stack = 0x7c00 partoffset = (stack-8) driveno = (stack-14) -heads = (stack-16) -sectors = (stack-18) +sectors = (stack-16) +heads = (stack-18) ebios_flag = (stack-20) secpercyl = (stack-24) _______________________________________________ Syslinux-commits mailing list Syslinux-comm...

...update of the sector (would be executed only if some of the values changed). Patch should be straightforward. A side "bonus" to that would be a capability to chainload DOSes from drive > 0x80 without a stub. I have one question though: if (!opt.loadfile || data[0].base >= 0x7c00 + SECTOR) { /* Actually read the boot sector */ if (!cur_part) { data[ndata].data = mbr; Both freedos/msdos/pcdos option implicitly assume sethidden, but considering their data[0].base - the condition will always be false (and rightly so as the kernel overlaps with...

HPA, now that syslinux release madness has calmed down, could you provide some info on how we syslinux-minions/wannabes can use bochs and/or qemu to run (sys|pxe|iso|ext)linux in an emulated environment thats more conducive to debugging, single-stepping, and ultimately understanding how the magic happens ? tia jimc

On Thu, Jul 31, 2014 at 03:32:18PM -0700, Zetan Drableg wrote: > Ok - > By the way, I looked into updating out KVM versions. Since we already > have so many KVM servers of this version in production, I can't easily > forklift update everything without much testing. > > exec /usr/libexec/qemu-kvm -s -S "$@" > > export LIBGUESTFS_HV=/root/work/qemu-wrapper

Thomas Schmitt wrote: > I ponder whether it would be possible to create a diagnostic MBR > which does not necessarily have to boot but rather tells what the > isohybrid MBR would perceive: Presence of partition table, > EBIOS or CBIOS, block address used with INT 13, content of the block > read by the first INT 13, ... ... > The diagnostic MBR should only use 432 bytes because at

...id mode. * * This doesn't follow the El Torito spec at all -- it is just a stub * loader of a hard-coded offset, but that's good enough to load * ISOLINUX. */ #define DEBUG_PRINT 1 #include "adjust.h" .code16 .text HYBRID_MAGIC = 0x7078c0fb isolinux_hybrid_signature = 0x7c00+64 isolinux_start_hybrid = 0x7c00+64+4 .globl bootsec /* Important: the top 6 words on the stack are passed to isolinux.bin */ stack = 0x7c00 partoffset = (stack-8) driveno = (stack-14) heads = (stack-16) sectors = (stack-18) ebios_flag = (stack-20) secpercyl = (stack-24) BIOS_kbdflags = 0x...

David Christensen wrote: > It looks like the call to "error" (line 276) is made if a summation of > the bytes in the first four sectors of a partition don't add up to > HYBRID_MAGIC (?). HYBRID_MAGIC = 0x7078c0fb isolinux_hybrid_signature = 0x7c00+64 ... cmpl $HYBRID_MAGIC,(isolinux_hybrid_signature) jne bad_signature ... bad_signature: call error .ascii "isolinux.bin missing or corrupt.\r\n" No. It looks for the value HYBRID_MAGIC at position isolinux_hybrid_signature in memory. -- MartinS

...6) heads = (stack-18) lets my always fail EBIOS detection version to boot the iso. Please David if you see this, try this. Patch: diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S index 6d8ab36..5a8b267 100644 --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -48,8 +48,8 @@ isolinux_start_hybrid = 0x7c00+64+4 stack = 0x7c00 partoffset = (stack-8) driveno = (stack-14) -heads = (stack-16) -sectors = (stack-18) +sectors = (stack-16) +heads = (stack-18) ebios_flag = (stack-20) secpercyl = (stack-24) -- MartinS

...g/commit/48e94f4fa7b3c32cbd43b6e57c64bc933f76d059 > Author: Martin Str|mberg <ams at ludd.ltu.se> ... > diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S > index 17e1efe..a693ccb 100644 > --- a/mbr/isohdpfx.S > +++ b/mbr/isohdpfx.S > @@ -48,8 +48,8 @@ isolinux_start_hybrid = 0x7c00+64+4 > stack = 0x7c00 > partoffset = (stack-8) > driveno = (stack-14) > -heads = (stack-16) > -sectors = (stack-18) > +sectors = (stack-16) > +heads = (stack-18) > ebios_flag = (stack-20) > secpercyl = (stack-24) Yes. It is. However by now we know that that co...

...i8086 > (gdb) symbol-file /usr/lib/debug/lib/modules/2.6.32-431.20.3.el6.x86_64/vmlinux > Reading symbols from > /usr/lib/debug/lib/modules/2.6.32-431.20.3.el6.x86_64/vmlinux...done. > (gdb) target remote :1234 > Remote debugging using :1234 > 0x0000fff0 in ?? () > (gdb) break *0x7c00 > Breakpoint 1 at 0x7c00 This might be the wrong breakpoint ... > (gdb) cont > Continuing. > .... > Didn't hit the breakpoint ... but in any case you can hit ^C at some point to pause the guest and find out where the guest is stuck. Rich. -- Richard Jones, Virtualization Gr...

...EV + +*/ + + .code16 /* generate 16-bit code. doc: 9.13.12 */ + .text /* sub-section (default 0). doc: 7.109 */ + +video_page = 0x462 /* I/O port for video controller page selection (bitmask 0x07) */ +flag_active = 0x80 /* partition table entry active (bootable) flag */ + +stack = 0x7C00 /* top of stack is immediately below where the BIOS loaded this MBR */ +pnp_header = (stack-4) /* The Plug'n'Play header received from BIOS in ES:DI */ +drive_number = (stack-6) /* The boot device as reported by BIOS in DL */ +cylinders = (stack-8) +heads = (stack-10) +sectors = (s...

Hi, given the fact that the conversion has the factor HC*SH = "secpercyl", which is invariant under swapping, there remains as suspect in read_sector_cbios only this division: divb (sectors) There is a suspicious discrepancy in the code: heads = (stack-16) sectors = (stack-18) ... /* here we computer CHS values or just do some dummy computation for EBIOS */ andw $0x3f,

...EV + +*/ + + .code16 /* generate 16-bit code. doc: 9.13.12 */ + .text /* sub-section (default 0). doc: 7.109 */ + +video_page = 0x462 /* I/O port for video controller page selection (bitmask 0x07) */ +flag_active = 0x80 /* partition table entry active (bootable) flag */ + +stack = 0x7C00 /* top of stack is immediately below where the BIOS loaded this MBR */ +pnp_header = (stack-4) /* The Plug'n'Play header received from BIOS in ES:DI */ +drive_number = (stack-6) /* The boot device as reported by BIOS in DL */ +cylinders = (stack-8) +heads = (stack-10) +sectors = (s...

This patch introduces extra functionality to chain.c, mainly with reference to BPB adjustments, but not only that. It expects 3 small patches I sent earlier (they are included for easy reference, patches 1-3/4). The changes introduced are: 1) file and boot sector use separate options to control load address and jump address (if applicable). Options are as described below: *

...EV + +*/ + + .code16 /* generate 16-bit code. doc: 9.13.12 */ + .text /* sub-section (default 0). doc: 7.109 */ + +video_page = 0x462 /* I/O port for video controller page selection (bitmask 0x07) */ +flag_active = 0x80 /* partition table entry active (bootable) flag */ + +stack = 0x7C00 /* top of stack is immediately below where the BIOS loaded this MBR */ +pnp_header = (stack-4) /* The Plug'n'Play header received from BIOS in ES:DI */ +drive_number = (stack-6) /* The boot device as reported by BIOS in DL */ +cylinders = (stack-8) +heads = (stack-10) +sectors = (s...

Hi, C/H/S addressing and reading of first block seems to be ok in isohdpfd.bin. The main suspect for the failure of the attempt with isohdpfd.bin is the number or content of the blocks read after the first one. But i have no clue why isohdpfc.bin should do better than isohdpfd.bin. They differ just by one instruction (JC = 0x72 versus JMP = 0xEB) which both are performed before the reading and

...o byte groups "8f 06 28 30 2e" and "8f 06 2a 30 5a" near byte position 64 of isolinux.bin : fb c0 78 70 59 2e 8f 06 28 30 2e 8f 06 2a 30 5a given that isohdpfx.S has: HYBRID_MAGIC = 0x7078c0fb isolinux_hybrid_signature = 0x7c00+64 isolinux_start_hybrid = 0x7c00+64+4 (One may guess that i will propose to patch the ISO at byte 8444*512+70, if i get a "yes" on this question.) --------------------------------------------------------------------- If this is indeed the wrong sequence in isolinux.bin th...