USB HardDisk Booting 2.4.20
Subsystems (5)
PATCH 1/1 USB HardDisk Booting 2.4.20
I recently acquired a USB HardDisk and it seems that the drivers for USB load after attempts to mount the root partition. I saw one patch that just put the root mount code into an endless loop, but didn't like this solution.
What I've done here is add another kernel config option which indicates if you have a USB device you with to boot. If you do then it changes the module_init's in drivers/usb/usb.c and drivers/usb/storage/usb.c to __initcall's. The config option is only enabled when you've selected "Y" for the USB Mass Storage Device.
My tests show that it seems to work, and I haven't noticed any odd side affects by initcall-ing the usb devices (concern over this topic is why I enabled it for static USB MSD only).
Does this seem a reasonable solution, or does anyone have something more elegant?
-- Wes
This patch adds a config option that, if static USB Mass Storage is selected, enabled telling the kernel that you have a bootable USB device (like a Hard Disk). It will then try to load the USB device and Mass Storage code earlier in the boot process so you can mount root USB devices.
Wesley Wright
[email protected]
arch/alpha/defconfig +1 -0
@@ -690,6 +690,7 @@ # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set
arch/i386/defconfig +1 -0
@@ -776,6 +776,7 @@ # CONFIG_USB_BLUETOOTH is not set CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set
arch/ia64/defconfig +1 -0
@@ -848,6 +848,7 @@ # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set
arch/parisc/defconfig +1 -0
@@ -772,6 +772,7 @@ # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set
arch/ppc/defconfig +1 -0
@@ -934,6 +934,7 @@ # CONFIG_USB_MIDI is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set
arch/sparc64/defconfig +1 -0
@@ -779,6 +779,7 @@ CONFIG_USB_MIDI=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_BOOT is not set # CONFIG_USB_STORAGE_DATAFAB is not set CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y
Documentation/Configure.help +7 -0
@@ -24374,6 +24374,13 @@ brave people. System crashes and other bad things are likely to occur if you use this driver. If in doubt, select N. +USB Boot Device Support +CONFIG_USB_STORAGE_BOOT + This option will load the USB controller and USB storage device drivers + earlier in the boot process. This enables systems which want to boot + off of a USB device (like a USB HardDisk) to detect the device before + trying to mount root, thus avoiding a kernel panic. + Winbond W83977AF IrDA Device Driver CONFIG_WINBOND_FIR Say Y here if you want to build IrDA support for the Winbond
drivers/usb/Config.in +3 -0
@@ -39,6 +39,9 @@ fi dep_tristate ' USB Mass Storage support' CONFIG_USB_STORAGE $CONFIG_USB $CONFIG_SCSI dep_mbool ' USB Mass Storage verbose debug' CONFIG_USB_STORAGE_DEBUG $CONFIG_USB_STORAGE + if [ "$CONFIG_USB_STORAGE" = "y" ] ; then + dep_mbool ' USB Boot Device Support' CONFIG_USB_STORAGE_BOOT $CONFIG_USB_STORAGE + fi dep_mbool ' Datafab MDCFE-B Compact Flash Reader support' CONFIG_USB_STORAGE_DATAFAB $CONFIG_USB_STORAGE $CONFIG_EXPERIMENTAL dep_mbool ' Freecom USB/ATAPI Bridge support' CONFIG_USB_STORAGE_FREECOM $CONFIG_USB_STORAGE dep_mbool ' ISD-200 USB/ATA Bridge support' CONFIG_USB_STORAGE_ISD200 $CONFIG_USB_STORAGE
drivers/usb/storage/usb.c +7 -2
@@ -1164,5 +1164,10 @@ } } -module_init (usb_stor_init); -module_exit (usb_stor_exit); +#ifdef CONFIG_USB_STORAGE_BOOT +__initcall (usb_stor_init); +#else +module_init (usb_stor_init); +module_exit (usb_stor_exit); +#endif +
drivers/usb/usb.c +6 -2
@@ -2373,8 +2373,12 @@usb_hub_cleanup (); } -module_init (usb_init); -module_exit (usb_exit); +#ifdef CONFIG_USB_STORAGE_BOOT +__initcall (usb_init); +#else +module_init (usb_init); +module_exit (usb_exit); +#endif /* * USB may be built into the kernel or be built as modules.
Quoted 6 lines · Wesley Wright
My tests show that it seems to work, and I haven't noticed any odd side affects by initcall-ing the usb devices (concern over this topic is why I enabled it for static USB MSD only).
Does this seem a reasonable solution, or does anyone have something more elegant?
Is there a reason for not using initrd for this. That should let you use any kind of root device even ones requiring user space work before the real root is mounted.
Quoted 7 lines · Alan Cox
Quoted 4 lines · Wesley Wright
My tests show that it seems to work, and I haven't noticed any odd side affects by initcall-ing the usb devices (concern over this topic is why I enabled it for static USB MSD only).
Quoted 10 lines
Quoted 4 lines
Does this seem a reasonable solution, or does anyone have something more elegant?
Is there a reason for not using initrd for this. That should let you use any kind of root device even ones requiring user space work before the real root is mounted.
The problem I've seen is there is a several second delay before the
usb device is availble. My solution was to stick a sleep in my initrd before attempting to mount /. A more rational patch might be to retry mounting / after a few seconds delay before giving up. I think I saw patch doing this on the usb list.
Signature · 4 lines
There is no such thing as obsolete hardware. Merely hardware that other people don't want. (The Second Rule of Hardware Acquisition) Sam Flory <[email protected]>
Quoted 5 lines · Samuel Flory
The problem I've seen is there is a several second delay before the
usb device is availble. My solution was to stick a sleep in my initrd before attempting to mount /. A more rational patch might be to retry mounting / after a few seconds delay before giving up. I think I saw patch doing this on the usb list.
Hello !
I'm personnaly using this simple patch with success with an usb disk on key. It adds an option "setuptime" which waits the requested amount of ms before booting. I use it with "setuptime=2500" and my USB works fine.
I think it could be of a more general use, and perhaps it could be accepted into mainstream if it doesn't break anything ?
Cheers,
Willy
init/main.c +24 -0
@@ -126,6 +126,7 @@static char * argv_init[MAX_INIT_ARGS +2 ] = {"init" ,NULL , };char * envp_init[MAX_INIT_ENVS +2 ] = {"HOME=/" ,"TERM=linux" ,NULL , }; +static int setuptime;/* time(ms) to let devices set up before root mount */ static int __init profile_setup (char *str) {
@@ -136,6 +137,15 @@__setup ("profile=" , profile_setup); +static int __init setuptime_setup (char *str) +{ +int par; +if (get_option (&str,&par)) setuptime = par; +return 1 ; +} + +__setup ("setuptime=" , setuptime_setup); +static int __init checksetup (char *line) {struct kernel_param *p;
@@ -546,11 +556,25 @@extern void prepare_namespace (void ); +static int finish_setup () +{ +int tleft; +if (setuptime) { +printk ("Waiting %d ms for devices to set up.\n" , setuptime); + tleft = setuptime *HZ /1000 ; +while (tleft) { +set_current_state (TASK_INTERRUPTIBLE ); + tleft =schedule_timeout (tleft); + } + } +} +static int init (void * unused) {lock_kernel ();do_basic_setup (); +finish_setup ();prepare_namespace ();/*
Quoted 6 lines
I'm personnaly using this simple patch with success with an usb disk on key. It adds an option "setuptime" which waits the requested amount of ms before booting. I use it with "setuptime=2500" and my USB works fine.
I think it could be of a more general use, and perhaps it could be accepted into mainstream if it doesn't break anything ?
The reason I took the other approach is that I didn't want to introduce an arbitrary delay into my startup. I have varying speed machines (ranging from P90 up to Athlon 1800) and wanted a solution consistent across all of them. I think that you can accomplish the delay startup through initrd without a kernel change.
Delay solutions don't directly deal with the race between mounting and detecting the USB device though. If I select a value to small then I still don't get a successful mount.
Maybe this isn't a major concern for this area of the kernel though... at this point there really aren't any other tasks so the delay should have very consistent results.
Thanks,
-- Wes
Quoted 10 lines
Quoted 6 lines
My tests show that it seems to work, and I haven't noticed any odd side affects by initcall-ing the usb devices (concern over this topic is why I enabled it for static USB MSD only).
Does this seem a reasonable solution, or does anyone have something more elegant?
Is there a reason for not using initrd for this. That should let you use any kind of root device even ones requiring user space work before the real root is mounted.
Yes, I believe there is. IMO initrd is too much of an annoyance to setup. I also have a usb hdd and the only thing I did was read from the keyboard waiting for an <ENTER> like it does when it waits on the floppy. Worked quite well for me and USB Hard disks don't really need user space if everything's compiled in (from what I've seen).
Signature · 1 line
Lab tests show that use of micro$oft causes cancer in lab animals
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines
Quoted 3 lines
Is there a reason for not using initrd for this. That should let you use any kind of root device even ones requiring user space work before the real root is mounted.
Yes, I believe there is. IMO initrd is too much of an annoyance to setup.
I believe it's going to be mandatory anyway, perhaps not as initrd, but as initfs, but the result is the same. Besides, it's not that big a deal if rpm -i makes initrd for you automagically.
-- Pete