Bootable USB flash drive in 6.6
link...@gmail.com
I can use a usb drive instead of a floppy as a bootloader which loads
the vxworks image off ftp, no problems. What I really need though is
to be able ot use the usb drive as a bootloader the loads the image
from itself. Any ideas? I could find anything, even in the 6.6 release
documentation.
link...@gmail.com
Michael R. Kesti
>specifically I need to know what to modify the default boot line to
Type '?' and enter at the boot line editor prompt and the boot ROM
program will output, along with a list of valid commands, lists of
bootable devices and examples of how to set the boot line's "boot
device" and "file name" fields to boot from those devices.
--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mrkesti at hotmail dot com | - The Who, Bargain
link...@gmail.com
wrote:
The list of available boot devices only specifies gei0 and gei1
Michael R. Kesti
>On Jan 14, 9:09 pm, "Michael R. Kesti" <michaelke...@nospam.net>
>wrote:
>> "linknu...@gmail.com" wrote:
>> >Anyone know about the possibility of booting vxworks off a usb drive?
>> >I can use a usb drive instead of a floppy as a bootloader which loads
>> >the vxworks image off ftp, no problems. What I really need though is
>> >to be able ot use the usb drive as a bootloader the loads the image
>> >from itself. Any ideas? I could find anything, even in the 6.6 release
>> >documentation.
>> >specifically I need to know what to modify the default boot line to
>>
>> Type '?' and enter at the boot line editor prompt and the boot ROM
>> program will output, along with a list of valid commands, lists of
>> bootable devices and examples of how to set the boot line's "boot
>> device" and "file name" fields to boot from those devices.
>
>
>The list of available boot devices only specifies gei0 and gei1
I'm guessing that gei0 and gei1 are network interfaces (Hint: always
specify your target, tools set, and OS version when asking for help
in this newsgroup!) so it would seem that a USB driver was not included
in your boot ROM. Check your BSP's config.h and, if available, define
the appropriate component(s), rebuild the BSP, and burn and install a
new boot ROM.
link...@gmail.com
correct, I fixed it and now have bd0 as an available boot device.
When booting it errs out tho.
Booting from USB file - /bd0/vxWorks
failed to open "/bd0/vxWorks", attempt 1 of 4
failed to open "/bd0/vxWorks", attempt 2 of 4
failed to open "/bd0/vxWorks", attempt 3 of 4
cannot open "/bd0/vxWorks"
errno 0x41
im using vxworks 6.6 release
in my config.h file i added the following:
#define INCLUDE_USB
#define INCLUDE_USB_INIT
#define INCLUDE_EHCI
#define INCLUDE_EHCI_INIT
#define INCLUDE_EHCI_BUS
#define INCLUDE_OHCI
#define INCLUDE_OHCI_INIT
#define INCLUDE_OHCI_BUS
#define INCLUDE_UHCI
#define INCLUDE_UHCI_BUS
#define INCLUDE_UHCI_INIT
#define INCLUDE_USB_MS_BULKONLY
#define INCLUDE_USB_MS_BULKONLY_INIT
#define INCLUDE_BOOT_USB_FS_LOADER
/* File System Stuff 4 usb boot test */
#define INCLUDE_DOSFS
#define INCLUDE_DOSFS_MAIN
#define INCLUDE_DOSFS_CHKDSK
#define INCLUDE_DOSFS_FMT
#define INCLUDE_FS_MONITOR
#define INCLUDE_ERF
#define INCLUDE_XBD
#define INCLUDE_DEVICE_MANAGER
#define INCLUDE_XBD_PART_LIB
Michael R. Kesti
>On Jan 15, 10:04 am, "Michael R. Kesti" <michaelke...@nospam.net> wrote:
>
>> I'm guessing that gei0 and gei1 are network interfaces (Hint: always
>> specify your target, tools set, and OS version when asking for help
>> in this newsgroup!) so it would seem that a USB driver was not included
>> in your boot ROM. Check your BSP's config.h and, if available, define
>> the appropriate component(s), rebuild the BSP, and burn and install a
>> new boot ROM.
>
>correct, I fixed it and now have bd0 as an available boot device.
>
>When booting it errs out tho.
>
>Booting from USB file - /bd0/vxWorks
>
>failed to open "/bd0/vxWorks", attempt 1 of 4
>failed to open "/bd0/vxWorks", attempt 2 of 4
>failed to open "/bd0/vxWorks", attempt 3 of 4
>
>cannot open "/bd0/vxWorks"
Is there a file named "vxWorks" on your USB device?
>errno 0x41
Error 0x41 is EHOSTUNREACH (The error numbers are specified in the docs
in your distribution but I find its often easier to Google "vxworks error
numbers" to find this site.
www.slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/errno/errnoNumList.html)
Host unreachable implies that you still have the boot device configured
to a network interface (gei0 or gei1) rather than your USB device (bd0).
Please post the output of the boot line editor's 'p' command. It should
look something (but probably not exactly) like this.
boot device : bd=0
processor number : 0
host name :
file name : /bd0/vxworks
inet on ethernet (e) : 192.168.100.123::ffffff00
flags (f) : 0x8
target name (tn) : target
other (o) : gei0
When booting from a non-network device the other field is used to specify
a network interface that is to be initialized anyway.
These look like an appropriate set of options which is supported by
your boot ROM recognizing that your USB device is bootable.
link...@gmail.com
wrote:
> "linknu...@gmail.com" wrote:
> >On Jan 15, 10:04 am, "Michael R. Kesti" <michaelke...@nospam.net> wrote:
>
> >> I'm guessing that gei0 and gei1 are network interfaces (Hint: always
> >> specify your target, tools set, and OS version when asking for help
> >> in this newsgroup!) so it would seem that a USB driver was not included
> >> in your boot ROM. Check your BSP's config.h and, if available, define
> >> the appropriate component(s), rebuild the BSP, and burn and install a
> >> new boot ROM.
>
> >correct, I fixed it and now have bd0 as an available boot device.
>
> >When booting it errs out tho.
>
> >Booting from USB file - /bd0/vxWorks
>
> >failed to open "/bd0/vxWorks", attempt 1 of 4
> >failed to open "/bd0/vxWorks", attempt 2 of 4
> >failed to open "/bd0/vxWorks", attempt 3 of 4
>
> >cannot open "/bd0/vxWorks"
>
> Is there a file named "vxWorks" on your USB device?
>
> >errno 0x41
>
> Error 0x41 is EHOSTUNREACH (The error numbers are specified in the docs
> in your distribution but I find its often easier to Google "vxworks error
> numbers" to find this site.
>
boot device : usb0
processor number : 0
host name :host
file name : /bd0/vxworks
inet on ethernet (e) :
flags (f) :
target name (tn) :
other (o) :
I dont think the usb is getting initialized properly though, when I
try devs at the boot prompt i dont see /bd0.
link...@gmail.com
and yes there is a file named vxworks
Michael R. Kesti
>> On Jan 15, 8:53 pm, "Michael R. Kesti" <michaelke...@nospam.net>
>> wrote:
>
>> > Please post the output of the boot line editor's 'p' command. It should
>> > look something (but probably not exactly) like this.
>>
>> > boot device : bd=0
>> > processor number : 0
>> > host name :
>> > file name : /bd0/vxworks
>> > inet on ethernet (e) : 192.168.100.123::ffffff00
>> > flags (f) : 0x8
>> > target name (tn) : target
>> > other (o) : gei0
>
>> boot device : usb0
>> processor number : 0
>> host name :host
>> file name : /bd0/vxworks
>> inet on ethernet (e) :
>> flags (f) :
>> target name (tn) :
>> other (o) :
>>
>> I dont think the usb is getting initialized properly though, when I
>> try devs at the boot prompt i dont see /bd0.
>
>and yes there is a file named vxworks
I thought that boot device entry should be "bd=0" or maybe "usb=0". Is
the example provided in response to the '?' command really "usb0"?
If the problem is not the boot device field then I agree that the USB
device may not be getting initialized correctly. Does the USB interface
work if, in addition to your boor ROM image, you configure a bootable
image to include the USB device and load that image via a network
interface?
link...@gmail.com
wrote:
I type usb and when i type c in the shell again it appends the 0 to
make usb0 so i assume that is the correct format.
Yes it does work after the os is loaded off the ethernet. Using the
same config file.
We found that usbBulkDevInit is returning an error, usbBulkDevInit
returns ERROR flashes on the screen for a split second.
Michael R. Kesti
>On Jan 16, 10:05 am, "Michael R. Kesti" <michaelke...@nospam.net>
>wrote:
>
>> I thought that boot device entry should be "bd=0" or maybe "usb=0". Is
>> the example provided in response to the '?' command really "usb0"?
>>
>> If the problem is not the boot device field then I agree that the USB
>> device may not be getting initialized correctly. Does the USB interface
>> work if, in addition to your boor ROM image, you configure a bootable
>> image to include the USB device and load that image via a network
>> interface?
>
>I type usb and when i type c in the shell again it appends the 0 to
>make usb0 so i assume that is the correct format.
Please post the output of the boot line editor's '?' command.
>Yes it does work after the os is loaded off the ethernet. Using the
>same config file.
No, the bootable OS is probably not built using the same config file.
A BSP's config.h is used to configure boot ROM builds and bootable OSs
are configured using project facilities. It is easy for one to be
configured in entirely separate ways!
>We found that usbBulkDevInit is returning an error, usbBulkDevInit
>returns ERROR flashes on the screen for a split second.
Then there is a clue! The problem is that, because there is little
debugging support in the boot ROM, you need an ICE or logic analyzer
to determine why functions fail. Alternatively, you can read the code,
if available, and try to figure out what is happening.
link...@gmail.com
wrote:
I successfully got the usb initialized at boot time! Just had to
increase the address (#define RAM_LOW_ADRS 0x0204000) that the vxWorks
image was loaded to.We replaced every 00204000 in the code with
0060000. It loads the image off the usb drive and starts to boot
then ... restarts. We think that it may have something to do with a
dependency that wasn't satisfied when the image address was changed.
It also does the same thing after loading the image off the network.
Something in the image is hosed. Just have to figuire out what now.
Any ideas?
link...@gmail.com
Success!! We reloaded everything from version control, and repeated
the last step and it works!!
link...@gmail.com
Having to change the RAM_LOW_ADRS was an artifact of a bad
configuration. RAM_LOW_ADRS was greater than RAM_HIGH_ADRS. oops!.
Also as a note the following wasn't included in our final version of
config.h i believe some problems exist between ehci and ohci have not
confirmed yet though.