Hi, I have hacked NanoBSD locally to deal with generation of images for booting off USB keys. I am using the RELENG_7 branch as real-mode BTX support is necessary to support USB boot. During testing I noticed that whilst the images eventually boot, there is an extremely long delay before doing so, between when the BIOS reads the boot sector and when the BTX loader messages appear. Test system Time ---------------------------- Thinkpad T43 1m 40s ASUS Vintage AH-1 1m 7s Any ideas why this long delay is occuring? I see this with MBR geometries prepared for both USB-HDD (255H/63S/xxC) and USB-ZIP (64H/32S/xxC) modes. I am not using the strict USB-ZIP mode where everything resides on the 4th slice (da0s4) at the moment, as it requires further NanoBSD patches. I am not currently generating images sized to the entire USB key to save space and time, so the cylinder size is smaller than the physical media, this might also be a factor. Thanks for any light you can shed on this. cheers, BMS
Bruce M Simpson wrote:> ... > During testing I noticed that whilst the images eventually boot, there > is an extremely long delay before doing so, between when the BIOS > reads the boot sector and when the BTX loader messages appear.P.S. It appears none of QEMU, VMware 3.0, or VirtualBox 1.6.6 are able to emulate booting from a USB key in their BIOS, and only QEMU seems to support attaching a disk image on USB, making testing this a bit of a pain (real hardware is always needed). cheers BMS
[Ccing to list to track up thread] Douglas Berry wrote:> Perhaps this doesn't help... I do RELENG_7 based images > for USB keys/CDROM using the FreesBIE toolkit, and haven't > noticed such delays. I do fill the stick 'tho. Here's > fdisk output... > > ******* Working on device /dev/md4 ******* > parameters extracted from in-core disklabel are: > cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl) >Interesting, that's classic USB-HDD geometry (255H, 63S). Can you tell me what make, model of stick this is? It could be that the cylinder change is what's confusing the BIOS. I will need to do some tweak to make sure the cylinder calculation is right for the stick's capacity. The A/Open MX3S has no USB-HDD mode. It appears to have the same delay issue, however, it didn't see any difference between the USB-HDD geometry image and the USB-ZIP geometry image. %%% empiric:~/shelf/chipdocs/aopen % camcontrol inquiry da0 pass1: <Kingston DataTraveler 2.0 PMAP> Removable Direct Access SCSI-0 device pass1: Serial Number 40.000MB/s transfers empiric:~/shelf/chipdocs/aopen % camcontrol readcap da0 Last Block: 1953791, Block Length: 512 bytes %%% That device uses USB-ZIP style geometry (64H, 32S), and based on the "last block", 1953792 / 2048 is 954 cylinders exactly, which is how it came factory formatted. So I should probably give it a shot based on this. To get something up and running I've been using generic methods in the NanoBSD patch, I haven't sized the MBR geometry specifically to the device. By my reckoning your stick is just under 512MiB, based on the geometry you provided:> parameters to be used for BIOS calculations are: > cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 32, size 1001440 (488 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 488/ head 63/ sector 32 > The data for partition 2 is: > <UNUSED> > The data for partition 3 is: > <UNUSED> > The data for partition 4 is: > <UNUSED> >cheers BMS
On Thu, Sep 11, 2008 at 01:55:01PM +0100, Bruce M Simpson wrote:> I have hacked NanoBSD locally to deal with generation of images for > booting off USB keys. I am using the RELENG_7 branch as real-mode BTX > support is necessary to support USB boot. > > During testing I noticed that whilst the images eventually boot, there > is an extremely long delay before doing so, between when the BIOS reads > the boot sector and when the BTX loader messages appear. > > Test system Time > ---------------------------- > Thinkpad T43 1m 40s > ASUS Vintage AH-1 1m 7s > > Any ideas why this long delay is occuring?For me, it helps to include these knobs to Nano config file: CONF_WORLD=' BOOT_MBR_FLAGS=0x0 BOOT_BOOT1_FLAGS=0x0 ... ' Eugene Grosbein