In message: <20030728044238.GW45069_at_wantadilla.lemis.com> "Greg 'groggy' Lehey" <grog_at_FreeBSD.org> writes: : On Sunday, 27 July 2003 at 22:32:42 -0600, M. Warner Losh wrote: : > In message: <20030728043155.GV45069_at_wantadilla.lemis.com> : > "Greg 'groggy' Lehey" <grog_at_FreeBSD.org> writes: : >> On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote: : >>> In message: <20030728041557.GU45069_at_wantadilla.lemis.com> : >>> "Greg 'groggy' Lehey" <grog_at_freebsd.org> writes: : >>>> On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : >>>>> Where are you getting the data? A windows tool? : >>>> : >>>> If you're talking about the BIOS contents I'm printing, yes, I'm using : >>>> a Microsoft tool called DEBUG (which has been around since before : >>>> Microsoft bought DOS :-). : >>> : >>> I don't suppose that you could use FreeBSD's /dev/mem + od? : >> : >> Yup, can do. : >> : >>> dd if=/dev/mem bs=64k skip=12 count=1 | hd | less : >> : >> 00000000 55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...........| : >> 00000010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |........h.....IB| : >> ... : >> 0000bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 |........ ...>.._at_| : >> 0000c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| : >> * : >> 00010000 : >> : >> That's pretty much what I expected. Up to offset bff0, it's identical : >> with the Microsoft dump. : > : > Shouldn't you be looking at 0x000c0000 instead of 0x0000c000? : : Yes, I am. Look at the calculations in the dd above: skip 12 blocks : of 64 kB, or 0xc0000. If you mean the output of Microsoft's DEBUG, : that's in 8086 real mode, segment:offset. The segment registers are : logically shifted 4 bits to the left, so C000:0000 is 0xc0000. No, didn't see the skip. Looks like weird things are going on :-( WarnerReceived on Sun Jul 27 2003 - 19:48:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:16 UTC