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
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
+ 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
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
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: : 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
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
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: 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
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: 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
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
