PicoMOD7A Starter Kit

    Hi everybody,


    We are migrating from PicoMOD6 to PicoMOD7A. From the begining we were using two boards, to try the PicoMOD functionality before connecting on our own board:
    PicoMOD to NetDCU starter kit adapter board
    PicoMOD-Startintf2 REV 1.10 (2008)


    NetDCU starter kit
    NetDCU-Startintf4 REV 1.00 (2006)


    If we use them with the PicoMOD7A board, we aren't able to to flash the board from an USB Stich neither from SD or microSD.


    Is there any known uncompatibility issue between these boards? Could you give us any recommendation about it?


    Best regads

    What files do you want to install? Are we talking about NBoot, U-Boot or Linux? What are the steps you have tried already? Have you already followed the steps in Chapter 4: Bringing up the system of the First Steps Documentation?

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    I want to install U-Boot, Linux and Filesystem, but right now (only for testing the install process), I am using que binary files that you provide in the "multiplatform-linux-f+s-V2.0".
    I have copied three files into the root folder:
    -> install.scr (renamed to update.scr)
    -> zImage-fss5pv210-V2.0
    -> rootfs_std-PicoMOD7A-V2.0.ubifs


    I have copied into a micro SD card, a SD card and a USB drive, I have tested one by one, and I get the same output from U-Boot:



    I have updated de NBoot to V20, previously the PicoMOD7 had V18, but the behaviour still the same.
    I guess that the U-Boot version is the lastest one because as you can read in the output: U-Boot 2012.07 (Nov 22 2012 - 11:51:14) for F&S and the one I found in "multiplatform-linux-f+s-V2.0" is "u-boot-2012.07-f+s-V2.0.tar"


    I thought that the best approach to start with the board is to use the binaries that you provide in the BSP, just to be sure about what I'm doing.


    NBoot does not detect any SD Card neither U-Boot, when using the command availables for that purpose.

    Quote from "gct"

    I want to install U-Boot, Linux and Filesystem, but right now (only for testing the install process), I am using que binary files that you provide in the "multiplatform-linux-f+s-V2.0".


    Good idea.


    Quote

    I have copied three files into the root folder:
    -> install.scr (renamed to update.scr)
    -> zImage-fss5pv210-V2.0
    -> rootfs_std-PicoMOD7A-V2.0.ubifs


    Here is the first mistake. The FirstStep docu tells to store the files from the sd-card (!) subdir to the card, not from the binaries subdir. And there the files are named zImage-fss5pv210 and rootfs-PicoMOD7A.ubifs. The reason for skipping the version numbers is that we don't want to change the install script with every version and that you can still use the install script even if you have other images. However renaming install.scr to update.scr is of course OK.


    Quote

    I have copied into a micro SD card, a SD card and a USB drive, I have tested one by one, and I get the same output from U-Boot:


    OK, this looks strange. We have some issues with some high speed SD cards, see here. Maybe this is the reason why SD card access fails. However why USB is not working is a complete puzzle to me.


    Quote

    I have updated de NBoot to V20, previously the PicoMOD7 had V18, but the behaviour still the same.


    OK, this doesn't hurt.


    Quote

    I guess that the U-Boot version is the lastest one because as you can read in the output: U-Boot 2012.07 (Nov 22 2012 - 11:51:14) for F&S and the one I found in "multiplatform-linux-f+s-V2.0" is "u-boot-2012.07-f+s-V2.0.tar"


    If you take the images from the release packet, then this is the latest.


    Quote

    NBoot does not detect any SD Card neither U-Boot, when using the command availables for that purpose.


    Are you sure? NBoot does not detect the SD-Card, too? Can you give me the output of NBoot if you give command 'c'?


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Quote


    Here is the first mistake. The FirstStep docu tells to store the files from the sd-card (!) subdir to the card, not from the binaries subdir. And there the files are named zImage-fss5pv210 and rootfs-PicoMOD7A.ubifs. The reason for skipping the version numbers is that we don't want to change the install script with every version and that you can still use the install script even if you have other images. However renaming install.scr to update.scr is of course OK.


    OK. So in the root folder of the SD Card I have copied the following:
    --> install.scr (renamed to update.scr)
    --> zImage-fss5pv210
    --> rootfs-PicoMOD7A.ubifs


    Quote

    OK, this looks strange. We have some issues with some high speed SD cards, see here. Maybe this is the reason why SD card access fails. However why USB is not working is a complete puzzle to me.


    I'm using a MicroSD Kingston 2GB - Model SD-C02G.
    The USB is not detected by U-Boot, neither the USB Drive is turned on. But when the kernel is loaded it detects the USB Drive, and I am able to mount it and access the files.


    When I try to acces the SD-Card from NBoot I get the following message:


    Code
    1. Can't access SD card in FAT mode


    As I explained I am using:


    Quote

    PicoMOD to NetDCU starter kit adapter board
    PicoMOD-Startintf2 REV 1.10 (2008)


    NetDCU starter kit
    NetDCU-Startintf4 REV 1.00 (2006)


    Not the PicoMOD-Startintf Board. Maybe there is some hardware uncompatibility. Are you able to try this configuration in your facilities?

    I have found out what was the problem, there are two variables in UBoot with the following value:


    Code
    1. installcheck=mmc0,mmc1, usb
    2. updatecheck=mmc0,mmc1, usb


    In this way I always got the following message when Uboot was trying to find an USB device:

    Code
    1. ---- Trying update with update.scr from usb ----
    2. Unknown device, ignored
    3. ---- No update script found ----


    I have been diving into the Uboot source code, then I realized that I have modified these variables, deleting the whitespace:

    Code
    1. installcheck=mmc0,mmc1,usb
    2. updatecheck=mmc0,mmc1,usb



    Code
    1. ---- Trying update with update.scr from usb0:1 ----
    2. USB: Register 1111 NbrPorts 1
    3. USB EHCI 1.00
    4. scanning bus for devices... 3 USB Device(s) found
    5. scanning bus for storage devices... 1 Storage Device(s) found
    6. Loading /update.scr ... done!
    7. Success!


    But I still have an issue, UBoot does not detect the USB Drive when it is connected directly to the board, but it I connect the USB Drive though an USB Hub UBoot recognizes correctly it, and looks for the "update.scr" file.
    Finally I have modified the update.scr script to load from USB not from MMC, and everything is working.


    Do you have any idea about what is causing the USB issue? Maybe is there some hardware uncompatibility in the USB part with the boards I'm using?
    SD Card and MicroSD cards are not recognized by U-Boot neither the Kernel when the system is loaded.


    Thanks in advance

    OK, now I am relieved that USB is working. Yes, the blank at the beginning of " usb" was the problem. I have added some code right now that skips such blanks in the future.


    Is the USB stick some special stick? USB3.0 for example? In U-Boot we only have a EHCI driver active, which means that it might have problems with mice and keyboards, that are USB1.0 and need OHCI. But USB2.0 sticks should work. I have never tried USB3.0.


    Inserting a USB hub makes a difference from the USB protocol. A hub switches the protocol to its own version. So if you have a USB 2.0 hub, you can also connect mice and keyboards, because our board then only sees the hub and even the data from such a mouse is then packed in a USB2.0 stream. So our driver will work with a mouse on a USB hub, but it won't work with a mouse that is directly connected. So maybe if your USB stick is USB3.0 then the EHCI driver may refuse to work with it, but when connected to a hub, the protocol is simple USB2.0 because of the hub and then the driver will understand it. Just a guess...


    For the SD-Card: of course you have to format it using FAT, not NTFS. Do you use several partitions on the card? Even if you only have one partition, is there a partition table present?


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    I've been looking for any idea reading the UBoot source code, I've made a modification into the "usb_hub_power_on" function. In this way, now there is a 1 second wait time after the hub is powered on. After this time the USB Drive is ready to be accessed. We had similar issues with the PicoMOD6 board, but in that case, the board detected the USB drive on the second boot, not in the first one.



    It would be nice if you confirm this behaviour, is it a correct solution? Maybe it is interesing to modify UBoot sources to solve this in the next release.


    We are not planning to use SD Card/Micro SD Card by the moment. I've have checked the Filesystem and the partition table, but everything looks OK.

    As far as I can see you just have changed the minimum delay value from 100 to 1000. Isn't something like 150 or 200 more appropriate? The problem is that USB is usually activated at each boot process to check for the update script. If you insert a one second delay here, all boot processes of all boards will be delayed by one second. This may be OK for you, but I'm not sure if all customers will agree on that.


    On the other side, the board actually does not need a full second to make the voltage stable. With my USB sticks it worked perfectly with 100ms. So the long time is only required by your specific USB stick. But I can not believe that a standard USB hub will wait one full second after switching power on until it starts talking to the devices. So I would rather believe that your USB stick is not behaving 100% correctly. Have you tried different memory devices already?


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.