Skip to contentSkip to conversation

Stored data missed in setup.S

DISCUSSION Andrew Kirilenko 3 participants 8 messages Apr 23, 2003

lore
Share & tools
lore

Andrew Kirilenko

author
#0 lore raw

Hello!

I feel myself stupid, when fighting against setup.S. Here is small piece of code (/arch/i386/boot/setup.S)

--->
start_of_setup: # line 160

	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
        pushw   %ax
        movb    (0x100), %al
        cmpb    $1, %al
        popw    %ax # pop don't change any flags - 386 asm reference
        je     bail820 # and it don't jump -- al != 1
meme820: # line 300
<---

Any ideas? I've spent two days, trying to understand what's going on - no luck at all...

Best regards,
Andrew.

#1 lore raw
Quoted 7 lines · Andrew Kirilenko

Hello!

I feel myself stupid, when fighting against setup.S. Here is small piece of code (/arch/i386/boot/setup.S)

--->
start_of_setup: # line 160

Quoted 7 lines
	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
        pushw   %ax
        movb    (0x100), %al

You put something from offset 0x100 into %al.

Quoted 1 line
        cmpb    $1, %al

Then you compared it against 1. This is where the comparaison occurred.

Quoted 1 line

popw %ax # pop don't change any flags - 386 asm reference

Then you put something else into %ax. Whatever it is, doesn't count.

Quoted 1 line
        je     bail820 # and it don't jump -- al != 1

Then you jumped based upon the comparison you made before you destroyed the contents of %al by poping %eax (%eax is (%ah << 8) | %al).

If you don't want to muck with registers, just do:

		cmpb	$1, (0x100)
		jz	wherever

You don't need to put memory oprands into registers to compare.

Quoted 9 lines

meme820: # line 300
<---

Any ideas? I've spent two days, trying to understand what's going on
- no luck
at all...

Best regards,
Andrew.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

author
#2 lore raw

Hello!

Quoted 29 lines
Quoted 5 lines

I feel myself stupid, when fighting against setup.S. Here is small piece of code (/arch/i386/boot/setup.S)

--->
start_of_setup: # line 160

Quoted 7 lines
	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
        pushw   %ax
        movb    (0x100), %al

You put something from offset 0x100 into %al.

Quoted 1 line
        cmpb    $1, %al

Then you compared it against 1. This is where the comparaison occurred.

Quoted 1 line

popw %ax # pop don't change any flags - 386 asm reference

Then you put something else into %ax. Whatever it is, doesn't count.

Quoted 1 line
        je     bail820 # and it don't jump -- al != 1

Then you jumped based upon the comparison you made before you destroyed the contents of %al by poping %eax (%eax is (%ah << 8) | %al).

Quoted 9 lines

If you don't want to muck with registers, just do:

		cmpb	$1, (0x100)
		jz	wherever

You don't need to put memory oprands into registers to compare.

Quoted 2 lines

meme820: # line 300
<---

OK. And now code looks like:
-->
start_of_setup: # line 160

	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
	cmpb    $1, (0x100)
	je bail820 # and it DON'T jump here
<--

I'm sure, I'm doing something wrong. But what???

Best regards,
Andrew.

#3 lore raw

On Wed, 23 Apr 2003, Andrew Kirilenko wrote:

[SNIPPED...]

Quoted 13 lines

OK. And now code looks like:
-->
start_of_setup: # line 160

	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
	cmpb    $1, (0x100)
	je bail820 # and it DON'T jump here
<--
Quoted 1 line

I'm sure, I'm doing something wrong. But what???

The only possibiity is that the code you just showed is not being executed. Absolute location 0x100 is not being overwritten by some timer-tick (normally) so whatever you write there should remain. You just put a byte of 1 in that location and then you compared against a byte of 1. If the CPU was broken, you wouldn't have even loaded your code.

It is quite likely that the IP is being diverted around your code by some previous code.

FYI, you can check the progress of your code by 'printing' on the screen. Set up ES to point to the screen segment, and write letters there:

	movw	$0xb800, %ax
	movb	%ax, %es
	movb	$'A', %es:(0)

This 'prints' an 'A' at the first location on the screen.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

author
#4 lore raw

Hello!

Quoted 32 lines

[SNIPPED...]

Quoted 13 lines

OK. And now code looks like:
-->
start_of_setup: # line 160

	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
	cmpb    $1, (0x100)
	je bail820 # and it DON'T jump here
<--
Quoted 1 line

I'm sure, I'm doing something wrong. But what???

The only possibiity is that the code you just showed is not being executed. Absolute location 0x100 is not being overwritten by some timer-tick (normally) so whatever you write there should remain. You just put a byte of 1 in that location and then you compared against a byte of 1. If the CPU was broken, you wouldn't have even loaded your code.

It is quite likely that the IP is being diverted around your code by some previous code.

FYI, you can check the progress of your code by 'printing' on the screen. Set up ES to point to the screen segment, and write letters there:

Quoted 5 lines
	movw	$0xb800, %ax
	movb	%ax, %es
	movb	$'A', %es:(0)

This 'prints' an 'A' at the first location on the screen.

Ha! I don't have video adapter not keyboard on that PC :) And, when I change je to jmp it works perfectly.

Best regards,
Andrew.

#5 lore raw
Quoted 33 lines · Andrew Kirilenko

Hello!

Quoted 32 lines

[SNIPPED...]

Quoted 13 lines

OK. And now code looks like:
-->
start_of_setup: # line 160

	# bla bla bla - some checking code
        movb    $1, %al
        movb    %al, (0x100)
....
....
	cmpb    $1, (0x100)
	je bail820 # and it DON'T jump here
<--
Quoted 1 line

I'm sure, I'm doing something wrong. But what???

The only possibiity is that the code you just showed is not being executed. Absolute location 0x100 is not being overwritten by some timer-tick (normally) so whatever you write there should remain. You just put a byte of 1 in that location and then you compared against a byte of 1. If the CPU was broken, you wouldn't have even loaded your code.

It is quite likely that the IP is being diverted around your code by some previous code.

FYI, you can check the progress of your code by 'printing' on the screen. Set up ES to point to the screen segment, and write letters there:

Quoted 9 lines
Quoted 5 lines
	movw	$0xb800, %ax
	movb	%ax, %es
	movb	$'A', %es:(0)

This 'prints' an 'A' at the first location on the screen.

Ha! I don't have video adapter not keyboard on that PC :) And, when I change je to jmp it works perfectly.

Then the only possibility is that your DS segment has not been set to somewhere that's writable so that your movb $1, (0x100) didn't "take". The BIOS normally sets DS to 0x40, but if you want to read/write at offset 0x100, it's probably better to set DS to 0. You do this as :

	xorw	%ax,%ax
	movw	%ax,%ds

You need to put the value into a register, then from the register into a data segment. In real-mode, the absolute memory location is the segment (address * 16) + the offset. If you left it at 0x40, you have (0x40 * 0x10) + 0x100 = 0x500 which is truly writable if you got through POST.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

#6 lore raw
In reply to Richard B. Johnson

On Wed, 23 Apr 2003 10:36:55 -0400 (EDT) "Richard B. Johnson" <[email protected]> wrote:

| On Wed, 23 Apr 2003, Andrew Kirilenko wrote:
| 
| [SNIPPED...]
| 
| > OK. And now code looks like:
| > -->
| > start_of_setup: # line 160
| > 	# bla bla bla - some checking code
| >         movb    $1, %al
| >         movb    %al, (0x100)
| > ....
| > ....
| > 	cmpb    $1, (0x100)
| > 	je bail820 # and it DON'T jump here
| > <--
| >
| 
| > I'm sure, I'm doing something wrong. But what???
| 
| The only possibiity is that the code you just showed is not
| being executed. Absolute location 0x100 is not being overwritten
| by some timer-tick (normally) so whatever you write there should
| remain. You just put a byte of 1 in that location and then
| you compared against a byte of 1. If the CPU was broken, you
| wouldn't have even loaded your code.

Could possibly be that DS (seg register) is altered between the store and the comparison...

| It is quite likely that the IP is being diverted around your code
| by some previous code.
| 
| FYI, you can check the progress of your code by 'printing' on
| the screen. Set up ES to point to the screen segment, and write
| letters there:
| 
| 	movw	$0xb800, %ax
| 	movb	%ax, %es
| 	movb	$'A', %es:(0)
| 
| This 'prints' an 'A' at the first location on the screen.

--
~Randy

#7 lore raw
Quoted 28 lines · Randy.Dunlap

On Wed, 23 Apr 2003 10:36:55 -0400 (EDT) "Richard B. Johnson" <[email protected]> wrote:

| On Wed, 23 Apr 2003, Andrew Kirilenko wrote:
|
| [SNIPPED...]
|
| > OK. And now code looks like:
| > -->
| > start_of_setup: # line 160
| > 	# bla bla bla - some checking code
| >         movb    $1, %al
| >         movb    %al, (0x100)
| > ....
| > ....
| > 	cmpb    $1, (0x100)
| > 	je bail820 # and it DON'T jump here
| > <--
| >
|
| > I'm sure, I'm doing something wrong. But what???
|
| The only possibiity is that the code you just showed is not
| being executed. Absolute location 0x100 is not being overwritten
| by some timer-tick (normally) so whatever you write there should
| remain. You just put a byte of 1 in that location and then
| you compared against a byte of 1. If the CPU was broken, you
| wouldn't have even loaded your code.
Quoted 2 lines

Could possibly be that DS (seg register) is altered between the store and the comparison...

I can only assume that the code presented is the only code that was executed. You are correct that DS may have never even been set. The data segment may be in some non-writable space, which is hard to find now-days with most evenything being shadowed and left writable. Many modern chip-sets can't turn off write, maybe it was too expensive from a performance standpoint.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.