> lines 21-32 in boot0.S there are some empty #ifdef statements. I was
> wondering a) where are these paramaters defined and if they are defined,
> what difference does it make since it looks like it doesn't change anything
> since they're empty?
>
>
> #ifdef
I sent this to freebsd-drives too but I think that might not be the right
list for it so here it is: I am starting to learn how the kernel works and
have started by going through the boot loader and I've noticed that between
lines 21-32 in boot0.S there are some empty #ifdef statements.
On 01/15/2011 05:10, Aryeh Friedman wrote:
> I have 2 different versions of FB running on the same drive (-STABLE
> and -CURRENT) and want to know a) is it possible and b) how to change
> the boot0 "F?" labels so that "F1" (slice 1) is "FreeBSD-STABLE" a
On 15/01/2011, at 22:10, Aryeh Friedman wrote:
> I have 2 different versions of FB running on the same drive (-STABLE
> and -CURRENT) and want to know a) is it possible and b) how to change
> the boot0 "F?" labels so that "F1" (slice 1) is "FreeBSD-STABLE" a
I have 2 different versions of FB running on the same drive (-STABLE
and -CURRENT) and want to know a) is it possible and b) how to change
the boot0 "F?" labels so that "F1" (slice 1) is "FreeBSD-STABLE" and
&quo
ummarize, I guess that a possible fix (that does not involve
> > using gpart, or even worse, modifying boot0.S, which probably does
> > not have any spare space) is to modify boot0cfg so that it sets the
> > 'active' flag for the partition corresponding to the default entry.
&
On 11.01.2011 02:33, Luigi Rizzo wrote:
> As a consequence, if we reboot without pressing an F-key, the system
> boots from partition s1 even though the boot loader indicates F2.
> So, to summarize, I guess that a possible fix (that does not involve
> using gpart, or even worse, modif
ndeed 0xb1 is
probably the correct initial value of the byte at 0x1b4, probably
I/we forgot to initialize the field.
So, to summarize, I guess that a possible fix (that does not involve
using gpart, or even worse, modifying boot0.S, which probably does
not have any spare space) is to modify bo
rious stages
> indicated below:
>
Paths to the files inline.
>>
>
> DUMP #1: ORIGINAL BOOT SECTOR
http://www.tomjudge.com/tmp/boot0/file1
>
>
>
> DUMP #2: AFTER THE BOOT SECTOR UPDATE
http://www.tomjudge.com/tmp/boot0/file2
>
>
>
&
tition.
arguable, since it used to work.
If this is not a bug in boot0 then its a bug in the man pages for
boot0cfg as it does make reference to having to change the active slice
to make this work.
the problem is not as simple as it looks, and I don't have all the answers, but
after spendig
t seem to be in boot0cfg as:
>
> 1) It succeeds to write the new configuration to the boot block every
> time i have tried.
> 2) It does not touch the partition table at all only the mbr, so it was
> never designed to change the active partition.
arguable, since it used to work.
On Sun, Jan 09, 2011 at 12:57:24PM -0600, Tom Judge wrote:
> On 09/01/2011 12:33, Luigi Rizzo wrote:
> > On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote:
> >> Hi,
> >>
> >> Today I ran into an issue where setting the default slice with boot0cfg
> >> -s is broken.
> > a few questions inlin
offset size
1 0x80 0: 1: 1 0xa5494: 15:63 63 498897
2 0x00495: 1: 1 0xa5989: 15:63 499023 498897
3 0x00990: 0: 1 0xa5992: 15:63 997920 3024
version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x2
ms that boot0cfg does not re-read
data from disk so if the write for some reason fails
(e.g. kern.geom.debugflags=0) you don't see the actual configuration
of the boot sector.
Looking at the code there should be an error message if writing
to disk fails, but maybe the error reporting oes not work well..
the new configuration to the boot block every
time i have tried.
2) It does not touch the partition table at all only the mbr, so it was
never designed to change the active partition.
If this is not a bug in boot0 then its a bug in the man pages for
boot0cfg as it does make reference to having to change the active slice
to make this work.
Tom
signature.asc
Description: OpenPGP digital signature
3 498897
> 3 0x00990: 0: 1 0xa5992: 15:63 997920 3024
>
> version=3D2.0 drive=3D0x80 mask=3D0x3 ticks=3D182 bell=3D# (0x23)
> options=3Dpacket,update,nosetdrv
> volume serial ID 9090-9090
> default_selection=3DF2 (Slice 2)
> =3D=3D=3D
>
> Rebo
0: 0: 1 0xa5992: 15:63 997920 3024
version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23)
options=packet,update,nosetdrv
volume serial ID 9090-9090
default_selection=F2 (Slice 2)
===
Reboot and let boot0 time out and boot default slice 2:
===
# boot0cfg -v ad0
# flag s
o relocated code
93
94 main:
95 #if defined(SIO) && COMSPEED != 0
LOAD is set to 0x7c00:
27 .set LOAD,0x7c00# Load address
You should be able to get the offset of main by looking at boot0.o once
assembled. The start origin doesn't appear to be
Hi,
I am reading the code for boot0 (/usr/src/sys/boot/i386/boot0/boot0.S).
This is the part i am trying to understand:
/*
* Initialise segments and registers to known values.
* segments
Daniel O'Connor wrote:
I recently reinstalled Windows XP on my laptop (I barely use it but
occasionally it comes in handy :) and when I did the install it made
the base drive E (no idea why, and I couldn't see how to change it).
This is a well-known problem (at least to those who deal with
du
e the swapfile location
is now incorrect :(
I was wondering if it would be possible to modify boot0cfg (and boot0 I
guess) so that it avoids touching these bytes.
I found some details here ->
http://www.goodells.net/multiboot/partsigs.htm
Basically it would appear to be the 4 bytes just be
John Baldwin wrote:
jhb 2006-05-03 13:43:46 UTC
FreeBSD src repository
Modified files:
sys/boot/i386/boot0 boot0.S
Log:
Restore the pre-5.x behavior of only beeping if the user makes a bad
selection and not always beeping on startup. The two bytes for the extra
also.
I must say that these systems are MCA boxes, but I am pretty confident
for the boot0 program that should make no difference. I should also
say the boot floppy used was a 1.44Meg normal boot floppy that had
started many other systems.
If this indeed is a little bug, is there anything I can do
On Fri, Apr 23, 2004 at 03:18:59PM -0600, Ryan Sommers wrote:
> I was browsing over the boot0 makefiles and source when I was playing with
> some boot sector code of mine and I was wondering why the designers chose
> to use objcopy to output a binary file instead of just using the
I was browsing over the boot0 makefiles and source when I was playing with
some boot sector code of mine and I was wondering why the designers chose
to use objcopy to output a binary file instead of just using the --oformat
option when it's run over the linker.
I'm guessing it's ju
>> > %dl register when it invokes the MBR bootstrap program, boot0.
>> > This forces me to configure the MBR bootstrap with the setdrv option.
>> > The noupdate option must also be set because otherwise I risk writing
>> > the MBR partition table back to the wrong
On 22 Oct 2003 John Baldwin wrote:
>
> On 22-Oct-2003 Dan Strick wrote:
> > I seem to have stubbed my toe on another nasty little bootstrap problem.
> > My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the
> > %dl register when it invokes the MBR
On 22-Oct-2003 Dan Strick wrote:
> I seem to have stubbed my toe on another nasty little bootstrap problem.
> My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the
> %dl register when it invokes the MBR bootstrap program, boot0.
> This forces me to configure the M
I seem to have stubbed my toe on another nasty little bootstrap problem.
My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the
%dl register when it invokes the MBR bootstrap program, boot0.
This forces me to configure the MBR bootstrap with the setdrv option.
The noupdate option
On Fri, Oct 17, 2003 at 01:25:04PM +0930, Daniel O'Connor wrote:
> Basically, no. There is no room left in boot0 :(
>
> I think you could do it by squeezing down some text strings, and removing
> other [less common] entries though.
That's what I had to do when I speci
t "DOS" (or whatever else). I
> couldn't see where the "os_misc" string would be printed in the case of an
> error of any sort, so can I assume that all is well with this partition and
> dual boot combo and just ignore the '??'? Is it possible to add i
Hello all, a quick question about boot0. I recently put together a new machine
and had always planned to dual-boot FreeBSD -current and WinXP on it. At first
I used FreeBSD to partition the 120Gb drive into roughly "half". I installed
FreeBSD on the second slice and just last night in
On Thu, 20 Dec 2001 11:58:12 +0800 Leslie Jackson <[EMAIL PROTECTED]>
wrote:
> That means that BIOS saves the current drive number in register %dl??
>
> Could you give a hint about _where_ BIOS stores _what_??
> I've searched the google.com, but got no valuable resource.
a great tool for system
rding to the BIOS.
Thanks for your help, Mike.
So stupid i am, i treated 0x475 as an immediate operand !
Now i know that's an address.
>
>The code is not very clear (being written for compactness), but if you
>are familiar with how PCs boot, it's pretty straightforward.
I'm
Hi.
I'm reading the code /usr/src/sys/boot/i386/boot0/boot0.s.
And i've found that the FreeBSD Boot Manager is really smart & cool.
But i've got some problems in this source code.
I got puzzled from this line: cmpb cmpb NHRDRV,%al.
I don't know what it's for and go
John Baldwin wrote:
> No. It's the offset in memory of the number of hard drives in the BIOS. The
> BIOS has a data segment at 0x40, and at 0x40:0x75 (whose physical address is
> 0x475) it has a byte which is a count of the number of hard drives installed.
Specifically, Hiten, see:
Pag
On 15-Dec-01 Hiten Pandya wrote:
> hi,
> I found this piece of code in boot0.s, is it possible
> if you could explain me a bit about it.
>
> .set NHRDRV,0x475# Number of hard drives
>
> The hex value comes out to: 1141.
>
> Does that mean, that this is t
Hiten Pandya wrote:
> I found this piece of code in boot0.s, is it possible
> if you could explain me a bit about it.
>
> .set NHRDRV,0x475# Number of hard drives
>
> The hex value comes out to: 1141.
>
> Does that mean, that this is the amound of maximum
>
hi,
I found this piece of code in boot0.s, is it possible
if you could explain me a bit about it.
.set NHRDRV,0x475# Number of hard drives
The hex value comes out to: 1141.
Does that mean, that this is the amound of maximum
hard drives a user can have on FreeBSD?
If that is so, is
On 09-Dec-01 Hiten Pandya wrote:
> hi all,
> is there a reason behind.. why all Windows related
> boot
> options are marked as DOS?...
>
> src/sys/boot/i386/boot0.s
>
> is it because of the 512-byte limit...
Yes. There used to be a 1024 byte boot0 which did use dif
- DOS.
--
Matt Emmerton
> hi all,
> is there a reason behind.. why all Windows related
> boot
> options are marked as DOS?...
>
> src/sys/boot/i386/boot0.s
>
> is it because of the 512-byte limit...
>
> =
> -Hiten,
>
> Thank You,
> Yours
hi all,
is there a reason behind.. why all Windows related
boot
options are marked as DOS?...
src/sys/boot/i386/boot0.s
is it because of the 512-byte limit...
=
-Hiten,
Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>
<http://www.geocities.com/hi
42 matches
Mail list logo
