From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Date: Mon, 12 Dec 2016 16:32:37 +0000 Subject: [U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support In-Reply-To: References: <1480902750-839-1-git-send-email-andre.przywara@arm.com> <1480902750-839-24-git-send-email-andre.przywara@arm.com> <20161206112842.dofdry3jxy3t42tf@lukather> <3f863007-39a4-38e6-4a52-fb4944741374@arm.com> <20161212151343.dyja6nqm4sefdkkq@lukather> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 12/12/16 16:18, Chen-Yu Tsai wrote: > On Tue, Dec 13, 2016 at 12:04 AM, Andre Przywara wrote: >> Hi, >> >> On 12/12/16 15:13, Maxime Ripard wrote: >>> On Tue, Dec 06, 2016 at 12:22:59PM +0000, Andre Przywara wrote: >>>> Hi, >>>> >>>> On 06/12/16 11:28, Maxime Ripard wrote: >>>>> On Mon, Dec 05, 2016 at 01:52:30AM +0000, Andre Przywara wrote: >>>>>> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't >>>>>> use the more compact Thumb2 encoding, which only exists for AArch32 >>>>>> code. This makes the SPL rather big, up to a point where any code >>>>>> additions or even a different compiler may easily exceed the 32KB limit >>>>>> that the Allwinner BROM imposes. >>>>>> Introduce a separate, mostly generic sun50i-a64 configuration, which >>>>>> defines the CPU_V7 symbol and thus will create a 32-bit binary using >>>>>> the memory-saving Thumb2 encoding. >>>>> >>>>> "mostly generic". Where do you draw the line? How do you deal with a >>>>> board that would use a different UART? a different MMC? different >>>>> memory configuration.? >>>> >>>> My impression was that it's rather pointless to provide another set of >>>> 32-bit SPL defconfigs for each board again, especially given that for >>>> the SPL's needs the boards so far seem to be very similar. >>>> For the loading part we will probably go with what the BROM already >>>> started: load more data from one of the BROM boot sources, which is >>>> fixed in the SoC and can't be really changed by a board vendor anyway. >>>> Which really leaves the DRAM setup and the UART. >>> >>> So you plan on enabling all BROM boot sources as well (NAND, SPI) ? >> >> In fact SPI works already (with little to no changes). >> And I don't care about NAND, really ;-) >> Is anyone aware of an A64 board using this? >> >>>> I can't predict the future, but so far those A64 boards look fairly >>>> similar in this respect. So I just avoid having another SPL defconfig >>>> for the BananaPi M64, for instance. I just added MMC_SUNXI_SLOT_EXTRA >>>> because this doesn't hurt on the Pine64, so less churn here. >>>> >>>> So if you know of any board which breaks this assumption, I am happy to >>>> hear about it and see if it can be integrated. >>> >>> I know at least of one board that uses the UART3 on A33, instead of >>> UART0. The trend is very clear on the A64 and the previous SoCs, but >>> we also had some variations, so we need to take that into >>> account. Which brings me back to my original question, where do you >>> draw the line ? :) >> >> I don't know, and to make this clear: I see the point in having separate >> configs for the SPL, but due to the 32-bit/64-bit split we probably need >> _two_ sets of defconfigs, which gets pretty messy very quickly. >> Especially given that they are very similar. >> >> So how do we avoid this? Can we somehow share a defconfig between armv8 >> and armv7? In the moment "CONFIG_CPU_V7" and "CONFIG_ARM64" conflict in >> the same file. >> >>> And that would prevent us from doing any kind of DRAM settings >>> enhancements in the future, every one using the best common >>> denominator, which seems inefficient. >> >> Yeah, I think this is a much better point. I was a lot in DRAM land in >> the past few days, and I think we _have_ different DRAMs already: >> 1) The Pine64 uses DDR3-1333 DRAM chips @ 672 MHz >> 2) The SoPine and the Pinebook use LPDDR3 DRAM, which requires a >> slightly different setup, also the stock frequency in that one boot0.bin >> floating around is much lower (524 MHz, IIRC). >> 3) The BananaPi M64 and Theobroma's board use SKhynix DDR3 DRAM chips >> which are from a DDR3-1600 bin. I think Philipp reported to have it >> running at 800 MHz with some sane JEDEC based timing happily, so it's >> worth to enable this there. >> >> Which brings us to the following complications: >> a) We have similar, but still different DRAM _controllers_ (H3, A64, >> H5). Those have a slightly different register set, though it seems to be >> mostly missing/added features, so nothing really conflicting. >> b) We have different DRAM _chips_ being used on top of possibly any of >> those controllers. >> >> So this brings us from "one type of DRAM chip on top of one DRAM >> controller" today for the H3 driver to "multiple DRAM chips on top of >> slightly different controllers", which is a totally different story. >> I was looking into significantly reworking the DRAM driver to address >> that, but was hoping to defer this to a later stage. >> >> While the DRAM controller part can probably be solved by #ifdef'ing or >> static parameters, I wonder if we should really explore how to address >> different DRAM chips properly: >> I) We create a DT binding loosely based on the "jedec,lpddr2-timings" >> one in the kernel and use of-platdata as Simon suggested. >> II) We create some fixed tables of standard (JEDEC) timings in the >> driver and let one of those tables be selected at runtime based on some >> parameters, for instance in the SPL header. This could as easy as >> "DDR3-1333" vs. "LPDDR3-1066". This would allow us to adopt an existing >> SPL to multiple chips/boards without needing to rebuild it, possibly >> even open the door to auto-detection. For instance I found the LPDDR3 >> boot0 bailing out on the Pine64, so we might at least detect the >> difference there. > > Bailing out should be expected. LPDDR3 runs at a lower voltage, so the > standard DDR3 chip w/ LPDDR3 boot0 would not get sufficient power to > work. I don't think this is the reason. The AXP803 has a pin to externally select a reset voltage for DCDC5, which drives the DRAM chips. So a board vendor would connect this pin appropriately to match the _soldered_ DRAM chips. > Also, it seems LPDDR3 uses a different protocol. Yes, that's what I found also, and I hope that this is sufficient enough to reliably tell the two apart. Somehow the algorithm found out that something is wrong and quit. I was wondering if this could be used in a reliable way. > I'm not an expert > on this though. See > > https://blogs.synopsys.com/committedtomemory/2014/01/10/when-is-lpddr3-not-lpddr3-when-its-ddr3l/ > https://blogs.synopsys.com/committedtomemory/files/2014/01/DDR3-DDR3L-LPDDR3-Comparison.jpg Thanks for those links, I will add these to my constantly piling up heap of "how DRAM works" documents that populate my desktop lately, leading to the OOM killer going 'round yesterday on my machine ;-) > As I see it, there would need to be 2 settings: > > a) RAM type. We already have a Kconfig option to support LPDDR2 for > the A83T. Yes, though it's just DDR3 vs LPDDR3 in our case. > b) DRAM speed bin. This would probably select one of the standard > JEDEC timings for the selected DRAM type. Yes. > > Note that Allwinner's boot0 supposedly just has all the DRAM parameters > in its header, including options to use standard or custom timings. By staring at the boot0 disassembly lately I believe the existing boot0's ignore all those numerous parameters unless a bit in this tpr13 parameter is set (which is clear on the A64 one). Instead they just derive the timing parameters from the given frequency, though in a slightly non-standard (wrong?) way. So yes: I hope that just "memory type" and "frequency/JEDEC speed bin" should be sufficient to get the right DRAM setup, which could then happily live as two Kconfig parameters. Cheers, Andre. > >> III) Something in between. >> >> It's just a pity that this could hold off upstreaming the Pine64 SPL >> support. >> >> Cheers, >> Andre. >> >>>> Actually I had the idea of eventually going the other way around: >>>> Providing one U-Boot proper A64 defconfig and let the DT (provided by >>>> the SPL) sort out the differences. Then we might be able to live with >>>> separate SPL defconfigs. But that's another patchset and probably quite >>>> some work. >>> >>> That would work for MMC and UART (in u-boot, not in the SPL), but not >>> for the RAM setup.