Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jun 2011 17:30:28 +0200
From:      Guido Falsi <mad@madpilot.net>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: BTX loader problem on specific hardware
Message-ID:  <20110617153028.GB37006@megatron.madpilot.net>
In-Reply-To: <201106131145.08185.jhb@freebsd.org>
References:  <20110609152820.GC57263@megatron.madpilot.net> <201106091543.16028.jhb@freebsd.org> <20110613152653.GA82909@megatron.madpilot.net> <201106131145.08185.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 13, 2011 at 11:45:07AM -0400, John Baldwin wrote:
> 
> Ouch.  Well, these can be a PITA to disassemble.  ndisasm from the devel/nasm
> port is a good x86 disassembler that you can use.  You will need to use dd
> on /dev/mem to extract INT 15's entry point from the IDT.  For example:
> 
> # dd if=/dev/mem bs=4 iseek=0x15 count=1 | hd
> 1+0 records in
> 1+0 records out
> 4 bytes transferred in 0.000021 secs (190650 bytes/sec)
> 00000000  59 f8 00 f0                                       |Y...|
> 00000004
> 
> On this machine that gives a pointer of 0xf000:f859 which is a raw physical
> address of '0xff859'.  You can then grab a block of that to disassemble like
> so:
> 
> # dd if=/dev/mem bs=1 iseek=0xff859 count=100 | ndisasm -
> 00000000  EB00              jmp short 0x2
> 00000002  80FC87            cmp ah,0x87
> 00000005  7503              jnz 0xa
> 00000007  E94CF9            jmp word 0xf956
> ....
> 
> In this case I'd then need to look at what was at 0xff956, etc.

Following your suggestions I finally got through that code. I could
understand just part of it. As I said I have almost no experience
with ASM.

I also disassebled the same function from another PC (same manufacturer)
on which BTX/loader works.

Only thing I could make out is that the 6005Pro BIOS has a part of it's
code where it touches the cr[034] and msr registers. This code if
surrounded by a check on a memory location which, when I dump it, makes
the code run. I don't know if at machine boot this byte has a different
value. There is an instruction near there which makes the code what I
see it, but it's not in the code path from the bios function in
question.

I see that older BTX used to emulate all the operations on CR and MSR
registers, so maybe that's why it went through. Any idea or help on a
possible workaround?

I'm not sure, but maybe rdmsr or wrmsr are generating exceptions which
are not managed by BTX? I could be wrong, I really dont' know that much
about the internals of CPUs.

I obviously have the disassembled code available, but not posting it
here because I'm not sure what policies there are about disassembled
code on the lists.

-- 
Guido Falsi <mad@madpilot.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110617153028.GB37006>