AW: [Oberon] Mounting USB memory on USBOhci.
Stauber, Sven Philipp
staubesv at student.ethz.ch
Thu Jul 21 14:30:34 CEST 2005
Hi!
>So how can Aos.Par be arranged so that Mount is attempted
>after PCIFindOhci is finished?
The call to AosUsbOhci.Init (which again calls PCIFindOhci) is completely synchronous, i.e. the boot process will not continue until the OHCI host controller initialization is completely finished. Otherwise, the host controller would not be available for the USB driver, which is started later (AosUsb.Init).
This is not true, however, for the USB driver: The AosUsb.Init call will start some active objects (threads), which will run concurrently to the boot process. While the boot process continues, these objects will handle bus enumeration, device configuration, etc. Also, the AosUsbStorage.Init call does no more than registering the Mass Storage device driver at the USB system.
At the time you attempted to mount the USB drive, it was not yet avaiable as AosDisks.device object (the USB driver was still working on that).
>(By way of interest, there was no such problem with Uhci.
>With Uhci the memory was USBSCSII rather than USB.)
You were lucky. The problem is not dependent on the host controller type - we had this situation with AosUsbUhci.
For the boot process, this problem has been solved the following way:
The user has to specified whether the system is booted from USB.
--See Aos.Par:
-- #Enable BootFromUsb for booting from USB stick
-- #BootFromUsb="1"
If the config variable BootFromUsb is "1", the AosUsbStorage driver will wait (and therefore block the boot process) until at least one USB mass storage device is available (hopefully the one you're booting from) instead of just register itself at the USB driver.
You could...
- Try to execute the mount command later in the boot process. For example, Boot6="..:", maybe even after "Autostart.Run" is executed. If you're lucky, enough time passed and the USB drive is accessible.
-Write a small module for delayed device mounting, i.e. first wait 1-2 seconds and then execute the mount command. If you don't want to block the boot process, use a thread. This will surely work if you wait long enough.
- Implement a more sophisticated mechanism ;-)
Cheers,
Sven
________________________________
Von: oberon-bounces at lists.inf.ethz.ch im Auftrag von shark at gulfnet.sd64.bc.ca
Gesendet: Mi 20.07.2005 19:39
An: oberon at lists.inf.ethz.ch
Betreff: [Oberon] Mounting USB memory on USBOhci. (Was "compiler".)
Yesterday evening (2005-07-19), being only semi-conscious, I said,
pe> The Ohci driver seems OK but Partitions.Show still ignores
the USB memory.
Well I can mount the USB manually after the system is viable.
A few lines from the Kernel.Log.
AosOhci: Initialised USB Open Host Controller at base 0E5000000H, Irq: 10
AosUsb: Driver UsbHub (integrated USB hub driver) has been added.
AosUsb: USB driver loaded.
AosUsb: Driver UsbStorage (Usb Storage Device Driver) has been added.
AosDiskVolumes: USB0 not found
AosDiskVolumes.New failed
AosUsb: Kingston DataTraveler II+ attached to USBHC0 port 2.
Appears that PCIFindOhci is not finished when
Boot2="AosFSTools.Mount USB AosFS USB0#02 ~"
is attempted.
So how can Aos.Par be arranged so that Mount is attempted
after PCIFindOhci is finished?
(By way of interest, there was no such problem with Uhci.
With Uhci the memory was USBSCSII rather than USB.)
Thanks everyone, this is interesting, ... Peter E.
Desktops.OpenDoc http://carnot.pathology.ubc.ca/
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://www.mail.inf.ethz.ch/lists/listinfo/oberon
More information about the Oberon
mailing list