Re: about freebsd boot1.S
On Wednesday 29 September 2004 03:32 pm, vijay singh wrote: > hello all, i am trying to understand the freebsd boot code. i saw that the > 1st stage boot loader relocates itself from 7c00 to 700. why is this done? > if the run time kernel were to switch to real-mode and transfer control to > this location (0700) would the 1st stage boot program run again? > > for the output below, i used the BIOS debugger and read the 1st sector into > 7c00, and unassebled the text. > > :7C1D cld > :7C1E xor cx, cx/* cx = 0 */ > :7C20 mov es, cx/* es = 0 */ > :7C22 mov ds, cx/* ds = 0 */ > :7C24 mov ss, cx/* ss = 0 */ > :7C26 mov sp, 7C00 /* set SP to current location */ > :7C29 mov si, sp > :7C2B mov di, 0700 /* DS:SI pair denotes the source string > and ES:DI pair the destination string 0:7C00 -> 0:700 */ > :7C2E inc ch/* ch = 1, cx = 100*/ > :7C30 repe /* repeat the movsw instruction cx number of times */ > :7C31 movsw /* moves 200h = 512 bytes from 7C00 to 700*/ > > please cc me in your reply. We copy ourselves down so that we can use 0x7c00 as a buffer to load sectors into off of the disk. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
about freebsd boot1.S
hello all, i am trying to understand the freebsd boot code. i saw that the 1st stage boot loader relocates itself from 7c00 to 700. why is this done? if the run time kernel were to switch to real-mode and transfer control to this location (0700) would the 1st stage boot program run again? for the output below, i used the BIOS debugger and read the 1st sector into 7c00, and unassebled the text. :7C1D cld :7C1E xor cx, cx /* cx = 0 */ :7C20 mov es, cx /* es = 0 */ :7C22 mov ds, cx /* ds = 0 */ :7C24 mov ss, cx /* ss = 0 */ :7C26 mov sp, 7C00 /* set SP to current location */ :7C29 mov si, sp :7C2B mov di, 0700 /* DS:SI pair denotes the source string and ES:DI pair the destination string 0:7C00 -> 0:700 */ :7C2E inc ch /* ch = 1, cx = 100*/ :7C30 repe /* repeat the movsw instruction cx number of times */ :7C31 movsw /* moves 200h = 512 bytes from 7C00 to 700*/ please cc me in your reply. thanks vijay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot1
> On 04-Jan-02 Matthew Emmerton wrote: > >> On 03-Jan-02 David E. Cross wrote: > >> > I'd like to create a /boot.config switch that will have boot1 _not_ read > > from > >> > the console; this is for a secure setup. Would others be interested in > > these > >> > patches when I finish them? > >> > >> Yes. I've seen other places use this, and I would commit it. :) > > > > How would this affect systems where you *have* to hit enter at the first > > "boot:" prompt in order to kick off a boot sequence? I've got two identical > > machines (same hardware, cloned hard drives), and one of them simply won't > > boot unless you hit enter. Turning off console imput would render this > > system useless after a reboot :) > > > > I think there's a PR open about this somewhere. > > Errr, why do you have to hit enter? If this patch does what I think it does, > you won't even get a boot: prompt at all, it will just jump straight into the > loader (or kernel). Besides, it wouldn't be on by default. You would have to > explicitly turn it on via a flag in /boot.config. As Mike Silbersack (sp?) pointed out, it's a rogue problem that people run into every now and then. I think it's BIOS/motherboard related. In any case, if the patch bypasses the prompt entirely, then there's no problem in my case (and would actually make things better for me.) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1
On Thu, 3 Jan 2002, John Baldwin wrote: > Errr, why do you have to hit enter? If this patch does what I think it does, > you won't even get a boot: prompt at all, it will just jump straight into the > loader (or kernel). Besides, it wouldn't be on by default. You would have to > explicitly turn it on via a flag in /boot.config. > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ One of my machines used to pause until I hit enter every time too. Then the motherboard went wacky and I replaced it. With the new motherboard, it auto-boots correctly every time. Just FWIW, Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1
On 04-Jan-02 Matthew Emmerton wrote: >> On 03-Jan-02 David E. Cross wrote: >> > I'd like to create a /boot.config switch that will have boot1 _not_ read > from >> > the console; this is for a secure setup. Would others be interested in > these >> > patches when I finish them? >> >> Yes. I've seen other places use this, and I would commit it. :) > > How would this affect systems where you *have* to hit enter at the first > "boot:" prompt in order to kick off a boot sequence? I've got two identical > machines (same hardware, cloned hard drives), and one of them simply won't > boot unless you hit enter. Turning off console imput would render this > system useless after a reboot :) > > I think there's a PR open about this somewhere. Errr, why do you have to hit enter? If this patch does what I think it does, you won't even get a boot: prompt at all, it will just jump straight into the loader (or kernel). Besides, it wouldn't be on by default. You would have to explicitly turn it on via a flag in /boot.config. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1
On 04-Jan-02 David E. Cross wrote: > Well, I can do the commit, I am just looking for interest, and code reviewers > ;) Oh, right, I'll review. :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1
Well, I can do the commit, I am just looking for interest, and code reviewers ;) -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1
> On 03-Jan-02 David E. Cross wrote: > > I'd like to create a /boot.config switch that will have boot1 _not_ read from > > the console; this is for a secure setup. Would others be interested in these > > patches when I finish them? > > Yes. I've seen other places use this, and I would commit it. :) How would this affect systems where you *have* to hit enter at the first "boot:" prompt in order to kick off a boot sequence? I've got two identical machines (same hardware, cloned hard drives), and one of them simply won't boot unless you hit enter. Turning off console imput would render this system useless after a reboot :) I think there's a PR open about this somewhere. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: boot1
On 03-Jan-02 David E. Cross wrote: > I'd like to create a /boot.config switch that will have boot1 _not_ read from > the console; this is for a secure setup. Would others be interested in these > patches when I finish them? Yes. I've seen other places use this, and I would commit it. :) -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
boot1
I'd like to create a /boot.config switch that will have boot1 _not_ read from the console; this is for a secure setup. Would others be interested in these patches when I finish them? -- David Cross | email: [EMAIL PROTECTED] Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
John Baldwin wrote: > > On 15-Sep-01 David O'Brien wrote: > > On Fri, Sep 14, 2001 at 03:05:01PM -0700, John Baldwin wrote: > >> 'disklabel -B ad0' as root, where 'ad0' is the disk that boots FreeBSD > > > > Isn't `disklable -B ad0sX' more proper? (especially if the disk has > > multiple FreeBSD slices) > > On x86, yes. I think disklabel -B ad0 will still work though. (It finds the > first FreeBSD slice and does it I think). I tried some more things today since I had a running system. The "disklabel -B ad0s3" works on my system. I can't use the ntldr until I replace the boot record used to boot FreeBSD. Once I copied boot1 to bootsect.bsd, which is what I have in boot.ini, W2K would boot FreeBSD. Having to replace what ntldr was using didn't occur to me until I made the W2K partition the active one and it wouldn't boot FreeBSD. Once I had a matched set, everything was ok. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
David O'Brien wrote: > > On Fri, Sep 14, 2001 at 03:05:01PM -0700, John Baldwin wrote: > > 'disklabel -B ad0' as root, where 'ad0' is the disk that boots FreeBSD > > Isn't `disklable -B ad0sX' more proper? (especially if the disk has > multiple FreeBSD slices) I tried ad0s3 and the system was just reinstalled using a binary install. It wouldn't boot past the "-" symbol. Kent > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 15-Sep-01 David O'Brien wrote: > On Fri, Sep 14, 2001 at 03:05:01PM -0700, John Baldwin wrote: >> 'disklabel -B ad0' as root, where 'ad0' is the disk that boots FreeBSD > > Isn't `disklable -B ad0sX' more proper? (especially if the disk has > multiple FreeBSD slices) On x86, yes. I think disklabel -B ad0 will still work though. (It finds the first FreeBSD slice and does it I think). -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On Fri, Sep 14, 2001 at 03:05:01PM -0700, John Baldwin wrote: > 'disklabel -B ad0' as root, where 'ad0' is the disk that boots FreeBSD Isn't `disklable -B ad0sX' more proper? (especially if the disk has multiple FreeBSD slices) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-2001 Peter Pentchev wrote: > So.. if I read you right, booting correctly for > 1024 cylinders works > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd > slice? Does this mean that boot1 and boot2 should work just fine if they > are loaded by another kind of MBR loader (say, Grub), and they find out > that they are placed beyond the 1023th cylinder? FYI the way you actually DO this is run boot0cfg :) eg.. boot0cfg -v -o packet /dev/mydiskdevice --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
>> Umm, ok. Did you do 'disklabel -B' to update the boot blocks on the disk >> (the >> boot blocks do _not_ live in the /boot files, they are part of the >> disklabel) >> when you updated the boot1 in bootsect.bsd? > > That I didn't do. What do I need to do? I'm reading the man page and > this is foreign country. This system was created at 4.2 and they were > created for me at that point. I don't want to have to reset the ntldr > butI could find the floppies to do a console recovery if I have to. > > Kent 'disklabel -B ad0' as root, where 'ad0' is the disk that boots FreeBSD and that the root filesystem is on. The files in /boot are sort of like the 'reference' version of the boot blocks. At the beginning of a FreeBSD slice is a 16-sector disklabel that describes the 'a', 'e', 'f' partitions, etc. The first sector of that is boot1. The second sector is the disklabel table itself, and the remaining 14 sectors hold boot2. Hope that makes sense. Until you use disklabel to update those boot blocks at the start of the slice, you are still using the old boot1 and boot2. However, you are using the ntldr which gets boot1 from somewhere else (not from the slice on the disk). When you updated that file, you ended up with mismatch since the new boot1 is still loading the boot2 off of the front of the slice, thus you end up with a new boot1 and an old boot2. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
John Baldwin wrote: > > On 14-Sep-01 Kent Stewart wrote: > > > > > > John Baldwin wrote: > >> > >> On 14-Sep-01 Kent Stewart wrote: > >> > > >> > > >> > [EMAIL PROTECTED] wrote: > >> >> > >> >> Kent Stewart wrote: > >> >> > >> >> > Mike Smith wrote: > >> >> > > > >> >> > > > So.. if I read you right, booting correctly for > 1024 cylinders > >> >> > > > works > >> >> > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in > >> >> > > > the > >> >> > > > fbsd > >> >> > > > slice? Does this mean that boot1 and boot2 should work just fine > >> >> > > > if > >> >> > > > they > >> >> > > > are loaded by another kind of MBR loader (say, Grub), and they find > >> >> > > > out > >> >> > > > that they are placed beyond the 1023th cylinder? > >> >> > > > >> >> > > This should work, yes. > >> >> > > >> >> > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I > >> >> > had to go back to the boot1 from 4.3 before I could boot. > >> >> > >> >> That could be serious. Can you post a brief description of your > >> >> hardware, together with the BTX register dump if possible? boot1 was > >> >> changed to address some problems with certain hardware, so it is > >> >> important to know if other incompatibilities have been introduced. > >> > > >> > The hardware is Abit VP6 mb w/dual 866 coppermines & 256 MB of PC-133 > >> > memory. Disk0 is a Maxtor 30 GB, disk1&2 are on the HPT-370 controller > >> > and are also Maxtor 30 GB drives. The 2 HD's on the HPT-370 are > >> > identical models. All are rated at ATA-100. The loader has been Win XP > >> > Pro since beta2 and runs FreeBSD about half of the time. > >> > > >> > BTX - Register dump > >> > > >> > int=0006 err= efl=00030216 eip=0de7 > >> > eax=1d3a ebx=30ff ecx=001f edx=00ce > >> > esi=0001 edi=0009 ebp=000003fe esp=03b1 > >> > cs=2364 ds= es=0204 fs= gs= ss=9dc5 > >> > cs:eip=0f 00 00 00 70 00 00 00-00 00 00 68 1e 00 00 00 > >> > ss:esp=b9 0d 00 00 00 fe 03 c2-03 02 01 80 00 1f 00 01 > >> > BTX halted > >> > >> 0000 0Fsldt [bx+si] > >> 0003 007000add [bx+si+0x0],dh > >> 0006 add [bx+si],al > >> 0008 add [bx+si],al > >> 000A 00681Eadd [bx+si+0x1e],ch > >> 000D add [bx+si],al > >> > >> That doesn't look to be very sane. > >> > >> Are you sure you haven't mixed an old version of boot2 with a new boot1 or > >> vice > >> versa? > > > > Yes, > > > > coral# mount_msdos /dev/ad0s1 /mnt > > coral# cmp /mnt/boot1 /boot/boot1 > > coral# > > > > They test identical. Boot1 was copied to bootsect.bsd, which is > > referenced in boot.ini. > > Umm, ok. Did you do 'disklabel -B' to update the boot blocks on the disk (the > boot blocks do _not_ live in the /boot files, they are part of the disklabel) > when you updated the boot1 in bootsect.bsd? That I didn't do. What do I need to do? I'm reading the man page and this is foreign country. This system was created at 4.2 and they were created for me at that point. I don't want to have to reset the ntldr butI could find the floppies to do a console recovery if I have to. Kent > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-01 Kent Stewart wrote: > > > John Baldwin wrote: >> >> On 14-Sep-01 Kent Stewart wrote: >> > >> > >> > [EMAIL PROTECTED] wrote: >> >> >> >> Kent Stewart wrote: >> >> >> >> > Mike Smith wrote: >> >> > > >> >> > > > So.. if I read you right, booting correctly for > 1024 cylinders >> >> > > > works >> >> > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in >> >> > > > the >> >> > > > fbsd >> >> > > > slice? Does this mean that boot1 and boot2 should work just fine >> >> > > > if >> >> > > > they >> >> > > > are loaded by another kind of MBR loader (say, Grub), and they find >> >> > > > out >> >> > > > that they are placed beyond the 1023th cylinder? >> >> > > >> >> > > This should work, yes. >> >> > >> >> > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I >> >> > had to go back to the boot1 from 4.3 before I could boot. >> >> >> >> That could be serious. Can you post a brief description of your >> >> hardware, together with the BTX register dump if possible? boot1 was >> >> changed to address some problems with certain hardware, so it is >> >> important to know if other incompatibilities have been introduced. >> > >> > The hardware is Abit VP6 mb w/dual 866 coppermines & 256 MB of PC-133 >> > memory. Disk0 is a Maxtor 30 GB, disk1&2 are on the HPT-370 controller >> > and are also Maxtor 30 GB drives. The 2 HD's on the HPT-370 are >> > identical models. All are rated at ATA-100. The loader has been Win XP >> > Pro since beta2 and runs FreeBSD about half of the time. >> > >> > BTX - Register dump >> > >> > int=0006 err= efl=00030216 eip=0de7 >> > eax=1d3a ebx=30ff ecx=001f edx=00ce >> > esi=0001 edi=0009 ebp=03fe esp=03b1 >> > cs=2364 ds= es=0204 fs= gs= ss=9dc5 >> > cs:eip=0f 00 00 00 70 00 00 00-00 00 00 68 1e 00 00 00 >> > ss:esp=b9 0d 00 00 00 fe 03 c2-03 02 01 80 00 1f 00 01 >> > BTX halted >> >> 0Fsldt [bx+si] >> 0003 007000add [bx+si+0x0],dh >> 0006 add [bx+si],al >> 0008 add [bx+si],al >> 000A 00681Eadd [bx+si+0x1e],ch >> 000D add [bx+si],al >> >> That doesn't look to be very sane. >> >> Are you sure you haven't mixed an old version of boot2 with a new boot1 or >> vice >> versa? > > Yes, > > coral# mount_msdos /dev/ad0s1 /mnt > coral# cmp /mnt/boot1 /boot/boot1 > coral# > > They test identical. Boot1 was copied to bootsect.bsd, which is > referenced in boot.ini. Umm, ok. Did you do 'disklabel -B' to update the boot blocks on the disk (the boot blocks do _not_ live in the /boot files, they are part of the disklabel) when you updated the boot1 in bootsect.bsd? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
John Baldwin wrote: > > On 14-Sep-01 Kent Stewart wrote: > > > > > > [EMAIL PROTECTED] wrote: > >> > >> Kent Stewart wrote: > >> > >> > Mike Smith wrote: > >> > > > >> > > > So.. if I read you right, booting correctly for > 1024 cylinders works > >> > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the > >> > > > fbsd > >> > > > slice? Does this mean that boot1 and boot2 should work just fine if > >> > > > they > >> > > > are loaded by another kind of MBR loader (say, Grub), and they find > >> > > > out > >> > > > that they are placed beyond the 1023th cylinder? > >> > > > >> > > This should work, yes. > >> > > >> > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I > >> > had to go back to the boot1 from 4.3 before I could boot. > >> > >> That could be serious. Can you post a brief description of your > >> hardware, together with the BTX register dump if possible? boot1 was > >> changed to address some problems with certain hardware, so it is > >> important to know if other incompatibilities have been introduced. > > > > The hardware is Abit VP6 mb w/dual 866 coppermines & 256 MB of PC-133 > > memory. Disk0 is a Maxtor 30 GB, disk1&2 are on the HPT-370 controller > > and are also Maxtor 30 GB drives. The 2 HD's on the HPT-370 are > > identical models. All are rated at ATA-100. The loader has been Win XP > > Pro since beta2 and runs FreeBSD about half of the time. > > > > BTX - Register dump > > > > int=0006 err= efl=00030216 eip=0de7 > > eax=1d3a ebx=30ff ecx=001f edx=00ce > > esi=0001 edi=0009 ebp=03fe esp=03b1 > > cs=2364 ds= es=0204 fs= gs= ss=9dc5 > > cs:eip=0f 00 00 00 70 00 00 00-00 00 00 68 1e 00 00 00 > > ss:esp=b9 0d 00 00 00 fe 03 c2-03 02 01 80 00 1f 00 01 > > BTX halted > > 0F sldt [bx+si] > 0003 007000 add [bx+si+0x0],dh > 0006 add [bx+si],al > 0008 add [bx+si],al > 000A 00681Eadd [bx+si+0x1e],ch > 000D add [bx+si],al > > That doesn't look to be very sane. > > Are you sure you haven't mixed an old version of boot2 with a new boot1 or vice > versa? Yes, coral# mount_msdos /dev/ad0s1 /mnt coral# cmp /mnt/boot1 /boot/boot1 coral# They test identical. Boot1 was copied to bootsect.bsd, which is referenced in boot.ini. Kent > > -- > > John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
John Baldwin writes: | This is for boot0. Nothing should be touching boot1 flags. | My guess is that someone has somehow mixed an old boot2 with the new boot1 | which is jumping to the wrong place to call xread. The "code" at cs:eip looks | a lot like the BPB in boot1 now. Okay that basically how I read the code. Just wanted to make sure I wasn't missing something. Your theory sounds quite possible. Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-01 Doug Ambrisko wrote:
> [EMAIL PROTECTED] writes:
>| Kent Stewart wrote:
>|
>| > Mike Smith wrote:
>| > >
>| > > > So.. if I read you right, booting correctly for > 1024 cylinders works
>| > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the
>| > > > fbsd
>| > > > slice? Does this mean that boot1 and boot2 should work just fine if
>| > > > they
>| > > > are loaded by another kind of MBR loader (say, Grub), and they find
>| > > > out
>| > > > that they are placed beyond the 1023th cylinder?
>| > >
>| > > This should work, yes.
>| >
>| > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I
>| > had to go back to the boot1 from 4.3 before I could boot.
>|
>| That could be serious. Can you post a brief description of your
>| hardware, together with the BTX register dump if possible? boot1 was
>| changed to address some problems with certain hardware, so it is
>| important to know if other incompatibilities have been introduced.
>
> ... in 4.3:
> warp% nm boot1.o | grep flags
> 0199 t flags
> warp%
>
> in -current
> a21p% !nm
> nm boot1.o | grep flags
> 01ba t flags
> a21p%
>
> Is someone writing into boot1 "flags"? Then there is a problem since this
> has moved. We did some work to avoid this "linking type" problem for xread
> in boot2.c to prevent this type of error. Do we have to do it for "flags"?
>
> I see in libdisk:
> static void
> Cfg_Boot_Mgr(u_char *mbr, int edd)
> {
> if (mbr[0x1b0] == 0x66 && mbr[0x1b1] == 0xbb) {
> if (edd)
> mbr[0x1bb] |= 0x80; /* Packet mode on */
> else
> mbr[0x1bb] &= 0x7f; /* Packet mode off */
> }
> }
This is for boot0. Nothing should be touching boot1 flags.
My guess is that someone has somehow mixed an old boot2 with the new boot1
which is jumping to the wrong place to call xread. The "code" at cs:eip looks
a lot like the BPB in boot1 now.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-01 Kent Stewart wrote: > > > [EMAIL PROTECTED] wrote: >> >> Kent Stewart wrote: >> >> > Mike Smith wrote: >> > > >> > > > So.. if I read you right, booting correctly for > 1024 cylinders works >> > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the >> > > > fbsd >> > > > slice? Does this mean that boot1 and boot2 should work just fine if >> > > > they >> > > > are loaded by another kind of MBR loader (say, Grub), and they find >> > > > out >> > > > that they are placed beyond the 1023th cylinder? >> > > >> > > This should work, yes. >> > >> > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I >> > had to go back to the boot1 from 4.3 before I could boot. >> >> That could be serious. Can you post a brief description of your >> hardware, together with the BTX register dump if possible? boot1 was >> changed to address some problems with certain hardware, so it is >> important to know if other incompatibilities have been introduced. > > The hardware is Abit VP6 mb w/dual 866 coppermines & 256 MB of PC-133 > memory. Disk0 is a Maxtor 30 GB, disk1&2 are on the HPT-370 controller > and are also Maxtor 30 GB drives. The 2 HD's on the HPT-370 are > identical models. All are rated at ATA-100. The loader has been Win XP > Pro since beta2 and runs FreeBSD about half of the time. > > BTX - Register dump > > int=0006 err= efl=00030216 eip=0de7 > eax=1d3a ebx=30ff ecx=001f edx=00ce > esi=0001 edi=0009 ebp=03fe esp=03b1 > cs=2364 ds= es=0204 fs= gs= ss=9dc5 > cs:eip=0f 00 00 00 70 00 00 00-00 00 00 68 1e 00 00 00 > ss:esp=b9 0d 00 00 00 fe 03 c2-03 02 01 80 00 1f 00 01 > BTX halted 0Fsldt [bx+si] 0003 007000add [bx+si+0x0],dh 0006 add [bx+si],al 0008 add [bx+si],al 000A 00681Eadd [bx+si+0x1e],ch 000D add [bx+si],al That doesn't look to be very sane. Are you sure you haven't mixed an old version of boot2 with a new boot1 or vice versa? -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
[EMAIL PROTECTED] writes:
| Kent Stewart wrote:
|
| > Mike Smith wrote:
| > >
| > > > So.. if I read you right, booting correctly for > 1024 cylinders works
| > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd
| > > > slice? Does this mean that boot1 and boot2 should work just fine if they
| > > > are loaded by another kind of MBR loader (say, Grub), and they find out
| > > > that they are placed beyond the 1023th cylinder?
| > >
| > > This should work, yes.
| >
| > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I
| > had to go back to the boot1 from 4.3 before I could boot.
|
| That could be serious. Can you post a brief description of your
| hardware, together with the BTX register dump if possible? boot1 was
| changed to address some problems with certain hardware, so it is
| important to know if other incompatibilities have been introduced.
... in 4.3:
warp% nm boot1.o | grep flags
0199 t flags
warp%
in -current
a21p% !nm
nm boot1.o | grep flags
01ba t flags
a21p%
Is someone writing into boot1 "flags"? Then there is a problem since this
has moved. We did some work to avoid this "linking type" problem for xread
in boot2.c to prevent this type of error. Do we have to do it for "flags"?
I see in libdisk:
static void
Cfg_Boot_Mgr(u_char *mbr, int edd)
{
if (mbr[0x1b0] == 0x66 && mbr[0x1b1] == 0xbb) {
if (edd)
mbr[0x1bb] |= 0x80; /* Packet mode on */
else
mbr[0x1bb] &= 0x7f; /* Packet mode off */
}
}
The mbr code it is modifying is in boot0 or mbr since I see in
boot0 that:
a21p% nm boot0.o | grep flags
01bb t flags
a21p%
but I'm not seeing how it gets over to boot1 for this test?
read.7: testb $FL_PACKET,%cs:MEM_REL+flags-start # LBA support e
Doug A.
PS. dhw ... could you try to set packet mode on some machines there
and test it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
[EMAIL PROTECTED] wrote: > > Kent Stewart wrote: > > > Mike Smith wrote: > > > > > > > So.. if I read you right, booting correctly for > 1024 cylinders works > > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd > > > > slice? Does this mean that boot1 and boot2 should work just fine if they > > > > are loaded by another kind of MBR loader (say, Grub), and they find out > > > > that they are placed beyond the 1023th cylinder? > > > > > > This should work, yes. > > > > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I > > had to go back to the boot1 from 4.3 before I could boot. > > That could be serious. Can you post a brief description of your > hardware, together with the BTX register dump if possible? boot1 was > changed to address some problems with certain hardware, so it is > important to know if other incompatibilities have been introduced. The hardware is Abit VP6 mb w/dual 866 coppermines & 256 MB of PC-133 memory. Disk0 is a Maxtor 30 GB, disk1&2 are on the HPT-370 controller and are also Maxtor 30 GB drives. The 2 HD's on the HPT-370 are identical models. All are rated at ATA-100. The loader has been Win XP Pro since beta2 and runs FreeBSD about half of the time. BTX - Register dump int=0006 err= efl=00030216 eip=0de7 eax=1d3a ebx=30ff ecx=001f edx=00ce esi=0001 edi=0009 ebp=03fe esp=03b1 cs=2364 ds= es=0204 fs= gs= ss=9dc5 cs:eip=0f 00 00 00 70 00 00 00-00 00 00 68 1e 00 00 00 ss:esp=b9 0d 00 00 00 fe 03 c2-03 02 01 80 00 1f 00 01 BTX halted Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
Kent Stewart wrote: > Mike Smith wrote: > > > > > So.. if I read you right, booting correctly for > 1024 cylinders works > > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd > > > slice? Does this mean that boot1 and boot2 should work just fine if they > > > are loaded by another kind of MBR loader (say, Grub), and they find out > > > that they are placed beyond the 1023th cylinder? > > > > This should work, yes. > > I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I > had to go back to the boot1 from 4.3 before I could boot. That could be serious. Can you post a brief description of your hardware, together with the BTX register dump if possible? boot1 was changed to address some problems with certain hardware, so it is important to know if other incompatibilities have been introduced. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
Peter Pentchev wrote: > A quote from the end of the boot_i386.8 manual page.. > > IMPORTANT NOTE: Because of limitations imposed by the conventional disk > interface provided by the BIOS, all boot-related files and structures > (including the kernel) that need to be accessed during the boot phase > must reside on the disk at or below cylinder 1023 (as the BIOS under- > stands the geometry). When a ``Disk error 0x1'' is reported by the sec- > ond-stage bootstrap, it generally means that this requirement has not > been adhered to. > > Just today I had a friend ask me if this is still true; I checked CVS > history and found out that this comment was added by rnordier more than > two years ago. Is this still true? As others have already indicated, the info is out of date. There is at least one PR already open for this man page (PR 26692), so I'll try to tidy up this and any other factual inaccuracies when attending to that. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
Mike Smith wrote: > > > So.. if I read you right, booting correctly for > 1024 cylinders works > > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd > > slice? Does this mean that boot1 and boot2 should work just fine if they > > are loaded by another kind of MBR loader (say, Grub), and they find out > > that they are placed beyond the 1023th cylinder? > > This should work, yes. I tried this with a boot1 from FreeBSD 4.4-rc and get a BTX error. I had to go back to the boot1 from 4.3 before I could boot. Kent -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-01 Mike Smith wrote: >> A quote from the end of the boot_i386.8 manual page.. >> >> IMPORTANT NOTE: Because of limitations imposed by the conventional disk >> interface provided by the BIOS, all boot-related files and structures >> (including the kernel) that need to be accessed during the boot phase >> must reside on the disk at or below cylinder 1023 (as the BIOS under- >> stands the geometry). When a ``Disk error 0x1'' is reported by the sec- >> ond-stage bootstrap, it generally means that this requirement has not >> been adhered to. >> >> Just today I had a friend ask me if this is still true; I checked CVS >> history and found out that this comment was added by rnordier more than >> two years ago. Is this still true? > > No; it's quite possible now to boot from beyond the 1024 cylinder mark, > however boot0 does not install in 'packet' mode by default, which means > that you need to manually install/configure it before rebooting after > system installation. > > So we don't cleanly install for > 1024 cylinders, but it works with a > little tweaking. Actually, sysinstall has a hack to turn on EDD (aka packet mode) support if the drive has > 1024 cylinders. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Does boot1 still have a > 1023 cyl limit?
On 14-Sep-01 Peter Pentchev wrote: > Hi, > > A quote from the end of the boot_i386.8 manual page.. > > IMPORTANT NOTE: Because of limitations imposed by the conventional disk > interface provided by the BIOS, all boot-related files and structures > (including the kernel) that need to be accessed during the boot phase > must reside on the disk at or below cylinder 1023 (as the BIOS under- > stands the geometry). When a ``Disk error 0x1'' is reported by the sec- > ond-stage bootstrap, it generally means that this requirement has not > been adhered to. > > Just today I had a friend ask me if this is still true; I checked CVS > history and found out that this comment was added by rnordier more than > two years ago. Is this still true? Not in boot1, boot2, and the loader. boot0 has to have the workaround manually enabled, but sysinstall does that during installation. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
> So.. if I read you right, booting correctly for > 1024 cylinders works > if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd > slice? Does this mean that boot1 and boot2 should work just fine if they > are loaded by another kind of MBR loader (say, Grub), and they find out > that they are placed beyond the 1023th cylinder? This should work, yes. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On Fri, Sep 14, 2001 at 09:50:23AM -0700, Mike Smith wrote: > > A quote from the end of the boot_i386.8 manual page.. > > > > IMPORTANT NOTE: Because of limitations imposed by the conventional disk > > interface provided by the BIOS, all boot-related files and structures > > (including the kernel) that need to be accessed during the boot phase > > must reside on the disk at or below cylinder 1023 (as the BIOS under- > > stands the geometry). When a ``Disk error 0x1'' is reported by the sec- > > ond-stage bootstrap, it generally means that this requirement has not > > been adhered to. > > > > Just today I had a friend ask me if this is still true; I checked CVS > > history and found out that this comment was added by rnordier more than > > two years ago. Is this still true? > > No; it's quite possible now to boot from beyond the 1024 cylinder mark, > however boot0 does not install in 'packet' mode by default, which means > that you need to manually install/configure it before rebooting after > system installation. > > So we don't cleanly install for > 1024 cylinders, but it works with a > little tweaking. So.. if I read you right, booting correctly for > 1024 cylinders works if boot0 knows about it. Isn't boot0 the one in the MBR, not in the fbsd slice? Does this mean that boot1 and boot2 should work just fine if they are loaded by another kind of MBR loader (say, Grub), and they find out that they are placed beyond the 1023th cylinder? G'luck, Peter -- Nostalgia ain't what it used to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
> A quote from the end of the boot_i386.8 manual page.. > > IMPORTANT NOTE: Because of limitations imposed by the conventional disk > interface provided by the BIOS, all boot-related files and structures > (including the kernel) that need to be accessed during the boot phase > must reside on the disk at or below cylinder 1023 (as the BIOS under- > stands the geometry). When a ``Disk error 0x1'' is reported by the sec- > ond-stage bootstrap, it generally means that this requirement has not > been adhered to. > > Just today I had a friend ask me if this is still true; I checked CVS > history and found out that this comment was added by rnordier more than > two years ago. Is this still true? No; it's quite possible now to boot from beyond the 1024 cylinder mark, however boot0 does not install in 'packet' mode by default, which means that you need to manually install/configure it before rebooting after system installation. So we don't cleanly install for > 1024 cylinders, but it works with a little tweaking. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Does boot1 still have a > 1023 cyl limit?
On Fri, Sep 14, 2001 at 06:06:22PM +0300, Peter Pentchev wrote: > Hi, > > A quote from the end of the boot_i386.8 manual page.. > > IMPORTANT NOTE: Because of limitations imposed by the conventional disk > interface provided by the BIOS, all boot-related files and structures > (including the kernel) that need to be accessed during the boot phase > must reside on the disk at or below cylinder 1023 (as the BIOS under- > stands the geometry). When a ``Disk error 0x1'' is reported by the sec- > ond-stage bootstrap, it generally means that this requirement has not > been adhered to. > > Just today I had a friend ask me if this is still true; I checked CVS > history and found out that this comment was added by rnordier more than > two years ago. Is this still true? I think it depends on the BIOS. The first stages of the bootstrap sequence use the BIOS to read from the disk. The original BIOS calls for reading/writing the disk does not support cylinder numbers larger than 1023. On later BIOSes extensions have been added to allow access to cylinders above 1023. Nowadays the FreeBSD bootstrap is able to use these BIOS extensions. This capability was added about a year ago. (From reading the CVS logs it seems 4.1 was the first release to support this.) But to use this requires that the BIOS support these extensions. All modern machines do AFAIK but many older machines don't. To sum it up: If you have a modern BIOS you can boot from anywhere on the disk (assuming a recent version of FreeBSD) but older BIOSes do not support this. Anybody who knows when BIOSes in general were extended to support >1024 cylinders? My *guess* would be 1997 or thereabout. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Does boot1 still have a > 1023 cyl limit?
Hi, A quote from the end of the boot_i386.8 manual page.. IMPORTANT NOTE: Because of limitations imposed by the conventional disk interface provided by the BIOS, all boot-related files and structures (including the kernel) that need to be accessed during the boot phase must reside on the disk at or below cylinder 1023 (as the BIOS under- stands the geometry). When a ``Disk error 0x1'' is reported by the sec- ond-stage bootstrap, it generally means that this requirement has not been adhered to. Just today I had a friend ask me if this is still true; I checked CVS history and found out that this comment was added by rnordier more than two years ago. Is this still true? G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
In message <[EMAIL PROTECTED]> Doug Ambrisko writes: : Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that : comes with any Intel 8XX system so with gzip you could fit a bunch of : stuff in a standard off the shelf motherboard. Also CMOS memory is : increasing and that could be used for some configuration info to be : used as non-flash persistant storage such as IP address and such. Also : having a small BIOS image like General Software would help save space. Hmmm. I had assumed that it was bytes, but it may have been bits. It was an intel 8xx based design... Still, 2MBytes is enough for at least a kernel and the bare minimum to make a router... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Warner Losh writes: | In message <[EMAIL PROTECTED]> Luigi Rizzo writes: | : > We'd also be able to load the kernel out of ROM :-) | : | : the whole issue is the size of the ROM isn't it ? | | Yes. I saw a few datasheets for embedded systems that have 2M or 4M | of flash. Some of that is for the BIOS, but part of it can be used | for a system image. That's a very common thin on other platforms as | well. Is this bits or bytes. The Intel firmware hub can have 4 or 8 Mbits that comes with any Intel 8XX system so with gzip you could fit a bunch of stuff in a standard off the shelf motherboard. Also CMOS memory is increasing and that could be used for some configuration info to be used as non-flash persistant storage such as IP address and such. Also having a small BIOS image like General Software would help save space. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: > > > > + put some conditional-compilation code in boot1.s > > > + have a separate file, say bootrom.s, maybe in the same directory > > > as the existing boot1 > > > + pass the modified code to the etherboot people so they can include > > > in their source tree. > > > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > > rather than have to resort to some external repository. > > > > My preference would be for a separate file in a separate directory, > > more or less similar to cdldr and pxeldr; I'd be least keen on handling > > this with conditional-compilation. > > ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ Yuck, why don't just call it '/sys/i386/romloader/'? I thought the cryptic 8 char name times are over by some years. With "ldr" you save exactly 3 characters but having the full name spelled out makes it far easier on the first glance to see what this is about. > and put there the modified boot1, makefile etc ? > There has been no other feedback so i think most other people is neutral. > > On a separate issue, and for picobsd purposes, it would be very > convenient to have yet another boot sector type that would just > take an ELF kernel appended to it, load into memory and start it. > I suppose this would be a variant of boot2, but do you have any > idea on how complex would it be to write such a beast ? > > If we had it, we could just 'dd' the boot code and the kernel onto > a compactflash and boot from it without having to worry about > creating a filesystem. That would be really cool! -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: > > > + put some conditional-compilation code in boot1.s > > > + have a separate file, say bootrom.s, maybe in the same directory > > > as the existing boot1 > > > + pass the modified code to the etherboot people so they can include > > > in their source tree. > > > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > > rather than have to resort to some external repository. > > > > My preference would be for a separate file in a separate directory, > > more or less similar to cdldr and pxeldr; I'd be least keen on handling > > this with conditional-compilation. > > ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ > and put there the modified boot1, makefile etc ? > There has been no other feedback so i think most other people is neutral. Seems good to me. > On a separate issue, and for picobsd purposes, it would be very > convenient to have yet another boot sector type that would just > take an ELF kernel appended to it, load into memory and start it. > I suppose this would be a variant of boot2, but do you have any > idea on how complex would it be to write such a beast ? I have a generic boot1, that would just about do this. Instead of understanding filesystems or file formats, it works off an embedded list of block address, block count pairs. I've used the same code to boot a.out and ELF kernels off ufs, fat, and iso9660 file systems; but it does need an installation utility rather than just dd. On the other hand, to create exactly what you had in mind isn't all that much work. A sort of combination of logic from boot1.s and btx/btxldr.s (which parses ELF) would do the job in pure assembly language; otherwise just stripping most of the functionality from boot2 should work in C (and would be similar to "rawboot" that phk did using the old aout bootblocks). -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
In message <[EMAIL PROTECTED]> Luigi Rizzo writes: : > We'd also be able to load the kernel out of ROM :-) : : the whole issue is the size of the ROM isn't it ? Yes. I saw a few datasheets for embedded systems that have 2M or 4M of flash. Some of that is for the BIOS, but part of it can be used for a system image. That's a very common thin on other platforms as well. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
> In message <[EMAIL PROTECTED]> Luigi Rizzo writes: > : If we had it, we could just 'dd' the boot code and the kernel onto > : a compactflash and boot from it without having to worry about > : creating a filesystem. > > We'd also be able to load the kernel out of ROM :-) the whole issue is the size of the ROM isn't it ? luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
In message <[EMAIL PROTECTED]> Luigi Rizzo writes: : If we had it, we could just 'dd' the boot code and the kernel onto : a compactflash and boot from it without having to worry about : creating a filesystem. We'd also be able to load the kernel out of ROM :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
> > + put some conditional-compilation code in boot1.s > > + have a separate file, say bootrom.s, maybe in the same directory > > as the existing boot1 > > + pass the modified code to the etherboot people so they can include > > in their source tree. > > > > in all sincerity i'd love to have this code in the FreeBSD source tree > > rather than have to resort to some external repository. > > My preference would be for a separate file in a separate directory, > more or less similar to cdldr and pxeldr; I'd be least keen on handling > this with conditional-compilation. ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ and put there the modified boot1, makefile etc ? There has been no other feedback so i think most other people is neutral. On a separate issue, and for picobsd purposes, it would be very convenient to have yet another boot sector type that would just take an ELF kernel appended to it, load into memory and start it. I suppose this would be a variant of boot2, but do you have any idea on how complex would it be to write such a beast ? If we had it, we could just 'dd' the boot code and the kernel onto a compactflash and boot from it without having to worry about creating a filesystem. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: > > Luigi Rizzo wrote: > > > > > I have spent some time trying to put etherboot[1] code onto the > > > hard disk so that it can be selected using the FreeBSD boot > > > manager. I ended up doing it with a small amt of modifications > > > to the "boot1" code, for which a patch is attached. > > > > > > Maybe it could be interesting in applying this patch to the standard > > > boot1 code (apart for the PRT_BSD change, which should be unmodified). > > > > The size of the boot1 code must be <= 446 bytes. The code already gets > > customised a lot, for example, in embedded work and space needs to be > > left to allow for that. So I wouldn't personally be in favour of adding > > this to the standard boot1. > On the other hand, the ability to load a rom image is very useful, > so i wonder what do you think is the best approach among the following: > > + put some conditional-compilation code in boot1.s > + have a separate file, say bootrom.s, maybe in the same directory > as the existing boot1 > + pass the modified code to the etherboot people so they can include > in their source tree. > > in all sincerity i'd love to have this code in the FreeBSD source tree > rather than have to resort to some external repository. My preference would be for a separate file in a separate directory, more or less similar to cdldr and pxeldr; I'd be least keen on handling this with conditional-compilation. That's just me, though, and this probably isn't a case where the views of the author/maintainer should have any special weight. -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
> Luigi Rizzo wrote: > > > I have spent some time trying to put etherboot[1] code onto the > > hard disk so that it can be selected using the FreeBSD boot > > manager. I ended up doing it with a small amt of modifications > > to the "boot1" code, for which a patch is attached. > > > > Maybe it could be interesting in applying this patch to the standard > > boot1 code (apart for the PRT_BSD change, which should be unmodified). > > The size of the boot1 code must be <= 446 bytes. The code already gets > customised a lot, for example, in embedded work and space needs to be > left to allow for that. So I wouldn't personally be in favour of adding > this to the standard boot1. If your point is that boot1.s should be some basic loader that people can easily customize, then i kind of understand and share your opinion. On the other hand, the ability to load a rom image is very useful, so i wonder what do you think is the best approach among the following: + put some conditional-compilation code in boot1.s + have a separate file, say bootrom.s, maybe in the same directory as the existing boot1 + pass the modified code to the etherboot people so they can include in their source tree. in all sincerity i'd love to have this code in the FreeBSD source tree rather than have to resort to some external repository. cheers luigi --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: > I have spent some time trying to put etherboot[1] code onto the > hard disk so that it can be selected using the FreeBSD boot > manager. I ended up doing it with a small amt of modifications > to the "boot1" code, for which a patch is attached. > > Maybe it could be interesting in applying this patch to the standard > boot1 code (apart for the PRT_BSD change, which should be unmodified). The size of the boot1 code must be <= 446 bytes. The code already gets customised a lot, for example, in embedded work and space needs to be left to allow for that. So I wouldn't personally be in favour of adding this to the standard boot1. -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
boot1 changes and etherboot support
sorry if this is not the most appropriate forum to discuss this, redirects appreciated. I have spent some time trying to put etherboot[1] code onto the hard disk so that it can be selected using the FreeBSD boot manager. I ended up doing it with a small amt of modifications to the "boot1" code, for which a patch is attached. Maybe it could be interesting in applying this patch to the standard boot1 code (apart for the PRT_BSD change, which should be unmodified). While at it, i noticed that fdisk seems to be more "smart" than i'd like, and likes to move the begin and end of partition to align it to a track boundary. This is kind of annoying, 1) because if you change the geometry in a way that has no effect for the loading of the kernel, it can still screw up your partition, and 2) because i would like to squeeze the boot1+etherboot in the spare 62 sectors between the MBR (boot0) and the beginning of the first partition on the disk. Is there any bad side effect in having a slice which starts at sector 1 and is 62 sectors long ? cheers luigi [1] Etherboot code is basically a boot ROM image of reasonably small size (16 or 32K depending on card type), and as part of its standard distribution can be loaded from a floppy using a special-purpose boot sector which is prepended to the image itself. Unfortunately the loader that comes with etherboot assumes the use of a floppy and does not work from a hard drive. [2] The patch for boot1.s is below. --- boot1.s Fri Jul 7 14:12:32 2000 +++ boot1a.sFri Feb 16 18:39:20 2001 @@ -28,7 +28,7 @@ # Partition Constants .set PRT_OFF,0x1be # Partition offset .set PRT_NUM,0x4# Partitions - .set PRT_BSD,0xa5 # Partition type + .set PRT_BSD,0x1# Partition type # Flag Bits .set FL_PACKET,0x80 # Packet mode @@ -147,9 +147,18 @@ # when we use btxld create boot2, we use an entry point of 0x1000. That # entry point is relative to MEM_USR; thus boot2.bin starts at 0xb000. # main.5:mov %dx,MEM_ARG # Save args movb $0x10,%dh # Sector count callw nread # Read disk + cmpw $0xaa55, MEM_BUF+0x200 # rom signature ? + jnz load_btx + movb MEM_BUF+0x202,%dh # Sector count + incb %dh + mov $0x7e00, %bx + callw nreadbx # Read disk + ljmp $0x800,$6 # enter the rom code + +load_btx: mov $MEM_BTX,%bx# BTX mov 0xa(%bx),%si# Get BTX length and set add %bx,%si # %si to start of boot2.bin @@ -184,6 +193,7 @@ # Trampoline used to call read from within boot1. # nread: mov $MEM_BUF,%bx# Transfer buffer +nreadbx: # same but address is in bx mov 0x8(%si),%ax# Get mov 0xa(%si),%cx# LBA push %cs# Read from --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
