Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected - VxWorks

This is a discussion on Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected - VxWorks ; There is a 30 second increase in boot time when booting from FLASH with no Ethernet cable connected than when booting from FLASH with an Ethernet device connected. Booting from FLASH is selected via board switch settings, not changing the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected

  1. Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected

    There is a 30 second increase in boot time when booting from FLASH
    with no Ethernet cable connected than when booting from FLASH with an
    Ethernet device connected. Booting from FLASH is selected via board
    switch settings, not changing the bootline. We believe that the boot
    process is in a loop looking for the mgi device. (The mgi device is
    the host device in the bootline. We do not want to remove the host
    device from the bootline since we do need Ethernet access for
    engineering / debugging purposes.) Where in the kernel code is the
    timeout for connecting to the host device? Thanks!


  2. Re: Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected

    On Jun 27, 7:31 pm, rhodaoak...@hotmail.com wrote:
    > There is a 30 second increase in boot time when booting from FLASH
    > with no Ethernet cable connected than when booting from FLASH with an
    > Ethernet device connected. Booting from FLASH is selected via board
    > switch settings, not changing the bootline. We believe that the boot
    > process is in a loop looking for the mgi device. (The mgi device is
    > the host device in the bootline. We do not want to remove the host
    > device from the bootline since we do need Ethernet access for
    > engineering / debugging purposes.) Where in the kernel code is the
    > timeout for connecting to the host device? Thanks!


    This is typical problem you will surely face during the
    flash booting. Normal boot sequence is designed such way that boot
    device specified will be connected to ethernet interface. If the boot
    device is customised such as flash... It runs as faulty sequence. So
    only windriver already provided some of other non network devices such
    as fd,ata,scsi, etc... In this case they do go for other boot field
    parameter to check the availability of ethernet device.

    I would have suggested in better way if you had specified version of
    vxWorks you are currently using. Any way following are the ways to
    come out of this problem.

    (In VxWorks 6.2 and later versions)
    copy the following files to your BSP path.

    $(WIND_BASE)/target/config/comps/src/net/coreip/usrNetBoot.c to
    Create the folder structure in your bsp of /net/coreip/( create this
    path in your bsp), copy usrNetBoot.c.

    Modify usrNetDevNameGet(...) function such that your flash boot
    device verified and try to bring up the available ethernet device
    from the option of other field in the boot parameters list.
    eg:
    .......
    (strncmp (sysBootParams.bootDev,
    "fdev", 4) == 0) ||
    ........

    And WDB Agent connection may fail after all these. You need to do same
    stuff by copying wdbEnd.c to your bsp path.

    Good luck,
    Sadashiv


  3. Re: Increased Boot Time When Booting from FLASH w/ Ethernet Cable Disconnected

    On Jun 27, 10:31 am, rhodaoak...@hotmail.com wrote:
    > There is a 30 second increase in boot time when booting from FLASH
    > with no Ethernet cable connected than when booting from FLASH with an
    > Ethernet device connected. Booting from FLASH is selected via board
    > switch settings, not changing the bootline. We believe that the boot
    > process is in a loop looking for the mgi device. (The mgi device is
    > the host device in the bootline. We do not want to remove the host
    > device from the bootline since we do need Ethernet access for
    > engineering / debugging purposes.) Where in the kernel code is the
    > timeout for connecting to the host device? Thanks!


    This is almost certainly caused by miiLib waiting way too long for an
    auto-negotiate that isn't going to happen.
    Have a look at the source, you can tune this.
    AN only takes at most several seconds.

    HTH,
    GV


+ Reply to Thread