Hi, On Saturday, October 3, 2015 at 1:39:55 PM UTC+2, Jon Smirl wrote: > > On Sat, Oct 3, 2015 at 3:53 AM, Rock Slate <[email protected] > <javascript:>> wrote: > > Wow, that's a really detailed response. Thanks a lot for the pointers. I > > will definitely look into this and will let you know as I proceed. > > On other processors I have seen people attach SRAM to the LCD > interface. That technique may be possible on Allwinner but it will > need some investigation. > > I've seen the opposite, I'm interested if you have some links, it would be a good point to link FPGA to allwinner devices.
> > > > > On Sat, Oct 3, 2015 at 1:16 PM, Siarhei Siamashka > > <[email protected] <javascript:>> wrote: > >> > >> > On Sat, Oct 3, 2015 at 12:32 PM, Rock Slate <[email protected] > <javascript:>> > >> > wrote: > >> > > >> > > Hi, > >> > > > >> > > Thanks for the reply. Both yes and no. The A13 comes in a nice > >> > > friendly > >> > > package which is easy to solder. However the FBGA on the DDR3 is > >> > > really a > >> > > nightmare. If not placed correctly, I would have to reball the chip > >> > > and > >> > > this is a little tough to do since I am not sure if I have the > right > >> > > experience for achieving this. > >> > > > >> > > However , I have some dedicated code which is really > small(something > >> > > like > >> > > toggling a few pins) to control another interface which I would > like > >> > > to do > >> > > even if the DDR does not work(signal integrity is also a problem , > >> > > even if > >> > > ODT is present). > >> > >> The DDR3 signal integrity also depends on the DRAM controller > >> configuration. And this configuration is done by software on > >> Allwinner A13: http://linux-sunxi.org/DDR_Calibration > >> > >> > > I dont want to put in another MCU just for this purpose. > >> > > > >> > > I was wondering if its possible to run the A13 without the DDRAM > being > >> > > configured. > >> > >> I have already answered this particular question. Yes, it is possible. > >> Your code and data can use a small amount of the on-chip SRAM (48KiB). > >> Moreover, that's how the bootloaders normally work. The boot ROM does > >> not normally initialize the DRAM on ARM devices, because there are no > >> DIMM modules with a nice standardized way to retrieve all the necessary > >> DRAM settings (from SPD). Instead the bootloader code does all this > >> board-specific configuration job on ARM devices. And bootloaders are > >> running in SRAM memory, or at least start executing there. > >> > >> > > Although I havent read the cortex A8 manual , I am assuming > >> > > that UBOOT at some level should be able to achieve what I want. > >> > >> Just take a look at the SPL part of U-Boot. It gets loaded into the > >> SRAM, runs from there, takes care of initializing the DRAM and then > >> loads the main part of U-Boot into the DRAM memory. > >> > >> > > It is also an interesting topic since I dont find many papers > >> > > detailing > >> > > how to use the ARM without external RAM apart from > >> > > http://www.coreboot.org/images/6/6c/LBCar.pdf so that I can use it > as > >> > > a > >> > > microcontroller in the initial stages of development. > >> > >> Is this paper really about ARM? It looks very much x86 to me. > >> > >> Please don't confuse the SRAM memory and CPU L1/L2 caches. You can > >> already use SRAM easily. It is more than enough for storing your code, > >> which is responsible for toggling a few pins. Moreover, if your DRAM > >> happens to be broken, guess how the U-Boot bootloader is able to print > >> an error message about this mishap on the UART serial console? > >> > >> As for the L2 cache, it has a much larger size than SRAM, but it is not > >> normally designed to be used instead of SRAM and DRAM. There might be a > >> way to configure it like this (I did not rule out this possibility > yet), > >> but the documentation needs to be checked (ARM Architecture Reference > >> Manual ARMv7-A and ARMv7-R edition): > >> > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html > >> > >> -- > >> Best regards, > >> Siarhei Siamashka > > > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "linux-sunxi" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Jon Smirl > [email protected] <javascript:> > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
