Booting Beagle Bone Black using Custom NOR Cape using GPMC Interface

mhada

Hi jonathan,

This is a new thread in continuation with the earlier thread:-

http://valentfx.com/vanilla/discussion/comment/674/#Comment_674

A good news is that using bare metal programming i have been able to load configuration file to logi bone using SPI-1 and I2C2 interface. Now as I told earlier, I want to first boot BBB using a custom NOR Cape [GPMC Interface] and want to reset eMMC for doing that. NOR Cape will hold configuration files for logi bone. I will use bare metal programming.

Your earlier reply on this was:-

Yes this should be possible because this how things are handlheld by the
Kernel when the dvice tree configuration disable eMMC. On first version
(without device tree) the eMMC was put in the reset state directly by
the u-Boot bootloader with the line :

mmcreset=mmc dev 1; mmc rstn 1; gpio set 52

But I am not able to get this as I am not doing OS based thing. My first doubt is if i want to boot through GPMC, my SYSBOOT should be configured as XIP. Then How do I reset eMMC ? I know it may be a very naive question but will require your help.

Again in case you want the bare metal code for programming FPGA, please let me know, I will readily share...

Regards.

mhada

Any of the friends here who could reply on it....

jpiat

This is something very unsual that you want to do so i don't have a direct answer ... I guess that you could probably boot from the eMMC then load the FPGA and disable the eMMC before configuring the GPMC. You should have a look at the BBb schematic because I think that a GPIO control the reset line of the eMMC so disabling the eMMC could only be a problem of configuring this GPIO to the correct state. What communication speed do you need with the FPGA ? If it's low, you can also rely on SPI for communication (~2MB/s).

mhada

Hi johnathan,

The custom hardware that I want to design requires to boot from a NOR Flash using GPMC interface which will also hold the config files for a xilinx FPGA.

Now to emulate this exercise I have chosen BBB, Logi Bone V2 and a custom NOR Cape designed by me. I have been able to do the second part of my exercise i.e. configuring the FPGAs from BBB but the first part is having problem. Now here the problem is this eMMC sitting on BBB which is causing trouble in my exercise and I want this to not interfere in my GPMC line w/o physically removing it as it may damage the board.

Now eMMC data sheet as well as Gerald who designed the board BBB says that :-

Reset: The RST_n signal is used by the host for resetting the device, moving the device to the preidle state. By default, the RST_n signal is temporarily disabled in the device. The host must set ECSD register byte 162, bits[1:0] to 0x1 to enable this functionality before the host can use it.

Now how can I circumvent this with minimum hassle? Whether using GPIO reset will solve is doubted. Else the whole picture looks very tricky as to booting from GPMC but still RST_n on eMMC and using it.

mhada

SPI is fine for loading to FPGA. I do not want GPMC to load on FPGA but I want to boot my device using GPMC for a custom hardware that I want to design..

mhada

Can erasing eMMC help me Johnathan?

jpiat

My question was : do you need the GPMC to communicate with the design inside the FPGA ? If not then there is no problem, you can use the eMMC and use SPI to transfer data to/from the FPGA.
If you plan is to have the am3359 + NOR + FPGA, there is no problem either because the NOR will use the GPMC and the FPGA can also use the GPMC if it uses a different chip select. The problem with the eMMC is that it uses a specific controller (not GPMC) whose pins overlaps the GPMC pins.

mhada

Right... The place where I am still doubtful is that if I try and boot BBB with my NOR Flash using GPMC controller, can it still conflict with eMMC functionally or electrically? Whether resetting eMMC is a must when using the shared lines as GPMC bus?

I

mhada

These lines of SRM of BBB of scetion 8.1.2 bother me:-

BEFORE the SW reinitializes the pins, it MUST put the eMMC in reset. This is done by taking eMMC_RSTn (GPIO1_20) LOW after the eMMC has been put into a mode to
enable the reset line. This pin does not connect to the expansion header and is accessible only on the board.

DO NOT automatically drive any conflicting pins until the SW enables it. This puts the SW in control to ensure that the eMMC is in reset before the signals are used from the
cape. You can use a GPIO pin for this. No, we will not designate a pin for this function. It will be determined on a cape by cape basis by the designer of the respective cape.

With these lines as per my understanding I will never be able to boot from GPMC...

mhada

Hi Jonathan,

I tried to use eMMC lines going from uC as GPIO and toggled them. I found that everythng was fine. Except that when I toggled MMC1_CLK or MMC1_CMD, I found that MMC1_DAT0 started toggling between 3.3V and 2.5V and it also remained to 2.5V when set to permanent low. All the other data lines were toggling fine only '0' started causing mis-behave. Again when stopped toggling MMC1_CLK or MMC1_CMD. I found MMC1_DAT0 toggled between 0 to 3.3V. If you could say why this might be happening.

Nothing connected on expanders yet, no logi bone v2 etc. nothing..

This is what i attempted first hand before using these pins as GPMC bus. I am scared of the board does not fry... so just being cautious.

mjones

If you want to disable the emmc,  why not just tie the emmc_RSTn signal low using with some solder points?

Based upon the schematics there is R162 which you you could permanently pull low (on the emmc side) by soldering to ground.  This would ensure that you are completely removing the emmc from the equation and you won't have to deal with SW.  

mhada

Just check this line:-

BEFORE the SW reinitializes the pins, it MUST put the eMMC in reset.
This is done by taking eMMC_RSTn (GPIO1_20) LOW after the eMMC has been
put into a mode to
enable the reset line.

eMMC during power on is not in a mode that it can accept reset input. It has to be first put into a mode by writing some ESD [or smthng of this name i vaguely remember from the datasheet of the device of BBB] internal register of eMMC. Gerald Cooley also said the same.

I have no idea of how to control eMMC with bare metal thing...

mjones

Is this the state you are still working on: "Reset: The RST_n signal is used by the host for resetting the device, moving the device to the preidle state. By default, the RST_n signal is temporarily disabled in the device. The host must set ECSD register byte 162, bits[1:0] to 0x1 to enable this functionality before the host can use it.

Now how can I circumvent this with minimum hassle? Whether using GPIO reset will solve is doubted. Else the whole picture looks very tricky as to booting from GPMC but still RST_n on eMMC and using it." 

So you just need to reset the emmc once you have successfully booted?

mhada

Hi mjones,

You can consider me very naive in this area but doing what you suggest gives we shocks as I perceive it in this way:-

1) Booting from GPMC NOR Flash
2) Switching to eMMC and resetting it
3) Again going to GPMC mode as my application code resides there...

I do not know how will all this sequence up besides I do not have a bare metal reference for eMMC. If you can help, I will try.

So what i am doing now is just forget about eMMC assuming that It may never respond if I use GPMC controller on those physical lines. I do not know how far I may go with this but this is what I am doing..

mjones

As jpiat suggests, this is pretty sophisticated problem very specific to the BBB and not so much the FPGA.  I am not sure I can be of much help here as I have only used the BBB in standard modes of operation.

Perhaps Jpiat has some more ideas.  Otherwise gerald may be the best person to get a suggested solution from. 

mhada

Thanks mjones.

I would try eMMC lines directly as GPMC and drive a custom NOR CAPE. May be once i get through I will close this thread as answered.

Thanks for all the help.