Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
20 years ago

CF Issues

Hey all,

I'm now running into some problems with integrating the compact flash. I've read through all the forum posts regarding this area that I could find here, and they've helped get me get to this point. Again, using the Stratix II DSP Dev Board with v1.4 uClinux here.

concern 1 -

At boot-up, I get the following response: 

ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
CF: ctl=1
Unable to initialize compact flash card. Please re-insert
Altera NDK flash (AMD): Found 1 x16 devices at 0x0 in 8-bit bank

First off, from some earlier posts it's mentioned that the ctl=1 means the CF controller is not being powered. However, I'm sending the nios sopc cf_power line to what the Altera documentation declares to be the right pin for this board, AB11. Am I incorrect here, or could there be another reason?

concern 2 -

Upon loging in and re-insertion of this card I get this following response: 

# hda: SanDisk SDCFB-512, CFA DISK drive
/cygdrive/c/altera/kits/nios2/bin/eclipse/plugins/com.microtronix.nios2linux.kernel_1.4.0/linux-2.6.x/arch/nios2nommu/kernel/irq.c(48): default irq handler vec=5 
ide0 at 0x80030880-0x80030887,0x800308b8 on irq 5
hda: max request size: 128KiB
hda: 1000944 sectors (512 MB) w/1KiB Cache, CHS=993/16/63
 hda: hda1

That's all fine, but I'd rather see that at boot-up. Another earlier post made reference to the fact that there are issues regarding instertion of the card pre-boot. If this is true, is there a fix for this problem? Otherwise, what else could be going wrong here? I'd like to have this card in before starting the system.

concern 3 -

I've formatted my card with a pc to FAT and FAT32 on seperate trial runs, without a label. When trying to mount the CF I get the following error: 

# /bin/mount -t vfat /dev/hda1 /mnt/ide0 -n
 hda: hda1
FAT: codepage cp437 not found
 hda: hda1
mount: wrong fs type, bad option, bad superblock on /dev/hda1, or too many mounted file systems

I don't know enough about codepages to speculate, but I did check the card back when formatting on the pc. Under MSDOS, I entered the drive and ran the command chcp to retrieve the active codepage of 437. If it's there according to the pc, why wouldn't the mount command recognize it also?

Maybe this is all related to one common error, but each concern worries me at this time.

Thanks again for your attention,

Matt

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Matt,

    With regards to concern 3, it looks like you need to configure the kernel to support Codepage 437 (U.S. & Canada) so it will support filenames for the FAT file system.

    When configuring the kernel, go to:

    File Systems --->

    Native Language Support --->

    Code 437 (United States & Canada)

    Sincerely,

    Brad.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Oh, there's something I missed. That resolves concern 3, thanks Brad!

    Now all that remains are the ctl=1 (power issue?) and the failure to recognize cf at boot-up. These sound like they could be one related problem to me. Looking forward to some input.

    - Matt
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    I'm just checking back to see if anyone is looking into this.

    - Matt
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi Matt,

    We found that certain compact flash cards do not fully power-down when the power switch on the Altera boards is used to remove power from the compact flash socket. This is the root of the startup issues.

    The desired start up sequence is as follows:

    1. The board powers up and the card goes into memory mode. (We desire True IDE mode, but at this point have no control because the FPGA is not yet configured)

    2. FPGA finishes its configuration and the operating system boots up.

    3. The compact flash driver detects a card in the socket.

    4. The compact flash driver toggles the power to the socket to reset the card.

    5. When power returns the the card it will be in True IDE mode (once the FPGA is configured it can perform the required signalling to change card modes)

    6. The compact flash driver recognises the card and all is well.

    We run into a problem with step 4 when using some compact flash cards. When their power supply is toggled they still seem to draw power from other signals. Since they never truely power-down, when the power supply is restored, they do not enter True IDE mode and the driver does not properly recognise them. This generates the "Unable to initialize compact flash card. Please re-insert" error.

    Unfortunately, the only way to power-down and properly configure these problem cards to True IDE mode is to remove them from the socket and re-insert them once the FPGA has configured itself.

    Dennis Scott

    Microtronix Datacom
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Thank you for your clear and concise explanation, Dennis. This leads me to a follow-up question, is there a list of known compact flash cards with manufacturer and model information that cycles power in a fashion that will be recognized by this boot-up sequence?

    - Matt
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi,

    We have had many woes with the compact flash interfaces. The best cards so far seem to be the Kingston 4GB cards. The following code will initialise them in IDE mode, even if they are already inserted:

    //this is required to start the CF in IDE mode

    void CF_Reset()

    {

    alt_u32 cf_status;

    //reset

    cf_status = ALTERA_AVALON_CF_CTL_STATUS_RESET_MSK;

    IOWR(CFLASH_CTL_BASE, 0, cf_status);

    Sleep(100); //let it reset

    cf_status = CF_POWER_ON;

    //power up

    IOWR(CFLASH_CTL_BASE, 0, cf_status);

    Sleep(100); //let it power up

    //get status

    cf_status = IORD(CFLASH_CTL_BASE, 0);

    printfEx("CF Status: %ld\n", cf_status);

    }

    Regards,

    Richard
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    Hi Richard,

    Thanks for your advice. I have not had a chance to try it out until now, and I am running into some minor issues. I can see by your code that you're using the HAL interface supplied by Nios2. Are you doing this from a Linux IDE app standpoint or a pure Nios IDE app angle? I've been unsuccessful in my initial attempts in trying to setup the include paths to the HAL components under a Linux app and am unsure if its even an option.

    Thanks again,

    Matt
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    20 years ago

    On a side note here... If I were to bypass the HAL interface all together, how would I go about writing states to output PIOs from a Linux application standpoint? To this point, I haven't run into any issues reading directly from memory locations to resolve values for input PIOs. However, my efforts in writing vals to outputs don't seem to work.

    Any guidance here will help out tremendously.

    Thanks,

    Matt