[linux-sunxi] Re: [RFC PATCH 1/3] sunxi: Extend SPL header versioning
ble. > /* The header must be a multiple of 32 bytes (for VBAR alignment) */ > }; > > diff --git a/board/sunxi/board.c b/board/sunxi/board.c > index 3d364c6db5..a105d0a5ab 100644 > --- a/board/sunxi/board.c > +++ b/board/sunxi/board.c > @@ -631,9 +631,9 @@ static void parse_spl_header(const uint32_t spl_addr) > return; /* signature mismatch, no usable header */ > > uint8_t spl_header_version = spl->spl_signature[3]; > - if (spl_header_version != SPL_HEADER_VERSION) { > + if (spl_header_version < SPL_ENV_HEADER_VERSION) { We have already discussed this particular part of code earlier: https://lists.denx.de/pipermail/u-boot/2015-September/227999.html Essentially, unless we have a real use case for mixing the SPL and the main U-Boot parts built from different U-Boot versions, I don't see any purpose for doing anything other than just exact version check here. If this particular check fails (the SPL part does not match the main U-Boot part), then something is already very wrong. > printf("sunxi SPL version mismatch: expected %u, got %u\n", > -SPL_HEADER_VERSION, spl_header_version); > +SPL_ENV_HEADER_VERSION, spl_header_version); > return; > } > if (!spl->fel_script_address) -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v2 5/6] sunxi: add code for recalculating the DRAM size in U-Boot
On Tue, 3 Apr 2018 13:43:43 +0100 Andre Przywara wrote: > Hi Icenowy, > > On 03/04/18 12:51, Icenowy Zheng wrote: > > > > > > 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard > > 写到: > >> On Tue, Apr 03, 2018 at 11:13:17AM +0100, Andre Przywara wrote: > >>>>>>> For hacking it, see my implementation in v1, which assumes the > >>>>>>> only size supported bigger than 2GiB is 3GiB (which is > >>>>>>> acceptable on sunxi, but might not work on other platforms). > >>>>>>> > >>>>>>> As Andre said, that function has another big problem -- it > >> detects > >>>>>>> memory with writing to it. This is risky. > >>>>>> > >>>>>> How is it risky when it's done by the SPL? > >>>>> > >>>>> Originally that was my confusion as well: It's not the SPL calling > >> that > >>>>> function. The DRAM controller init function in there knows very > >>>>> precisely how much DRAM we have, but we don't communicate this to > >> U-Boot > >>>>> proper. So U-Boot *proper* goes ahead and probes the DRAM. This > >> means it > >>>>> could step into secure memory, for instance. On sunxi64 we have > >> the ATF > >>>>> running between SPL and U-Boot, also all kind of secure payloads > >> could > >>>>> already have been registered. > >>>>> So I wonder if it would be easier to somehow pass on this *one* > >> word of > >>>>> information between SPL and U-Boot proper to avoid calling this > >> function > >>>>> altogether? > >>>> > >>>> That would definitely make sense yes. > >>> > >>> So since the SPL loads the DT anyway (from the FIT image) and puts it > >> at > >>> the end of the U-Boot (proper) binary, wouldn't it be the easiest to > >>> just patch the actual DRAM size in there? > >>> IIRC we don't have any FDT write code in the SPL at the moment, and > >>> pulling it in would probably push it over the edge again, but: > >> > >> That assumes that you are loading a FIT image, which might or might > >> not be the case, and on most arm32 chips, most likely won't. > >> > >> I guess we'd need to find another way (put some information in an > >> SRAM somewhere?) to try to do that for all variants. > > > > Extend the SPL header again? If we found SPL v3+, use > > the DRAM size encoded and bypass ram_get_size, > > otherwise fallback to ram_get_size? > > Yes, that would be a possibility as well. Though I believe at the moment > we don't access the SPL header from U-Boot proper, do we? We do. The boot device and also the boot.scr location (in the case of FEL boot) is read from the SPL header by the main U-Boot part. > Not a real show-stopper, but we probably need to document that the SPL > header would need to stay around. Maybe. > But if we have a fallback anyway ... Which fallback? Do you mean calling things like ram_get_size() from U-Boot? We should never do this because this is very wrong. The D-Cache may be already enabled, causing all kinds of weird effects. Also modifying data in DRAM (even temporarily) while our code is already running from DRAM is dangerous. > > (Although it will lead to some days of mess on sunxi-tools, > > this is a reasonable choice.) > > True, but actually I wonder why we have SPL_MAX_VERSION in there in the > first place. Can't we just postulate that every new SPL version stays > backwards compatible? So if sunxi-tools can deal with v2, a v3 SPL would > still be fine, you would just loose the v3 features (if at all)? > We can just put a warning in there, to ask users to upgrade. > That would have worked already with the v1/v2 transition, I believe. Yes, that's more or less how this was supposed to work in sunxi-tools from the very beginning. Except that we unfortunately got a bug in this code, which has been reported back in July 2017 and is still not resolved due to various reasons: https://github.com/linux-sunxi/sunxi-tools/issues/104 But hopefully it can be fixed sooner or later. > Probably worth a separate discussion with some sunxi-tools stakeholders. On the U-Boot side we can just increase the version number as long as the new header is a backwards compatible superset of the old one. In the unlikely case if we suddenly have to introduce a compatibility breaking change to the SPL header format, we can always change the SPL header signature from 'SPL' to something else. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] sunxi-tools v1.5 release
Hello All, The last version of sunxi-tools v1.4.2 has been released almost a year ago. So it's a high time to tag a new one soon. I propose to set a deadline for pull requests one week from now on the next Sunday (24.09.2017), then dedicate a week primarily to testing and improving documentation with the intention to tag the v1.5 release on 01.10.2017 If necessary, we may have follow-up bugfix releases v1.5.1, v1.5.2, ... I can step up and nominate myself as a temporary sunxi-tools maintainer for this particular release if Bernhard Nortmann does not have any objections. As for the features, which should go into this release. First we need to resolve bug https://github.com/linux-sunxi/sunxi-tools/issues/104 People reported that v.1.4.2 has a problem in the compatible version checking code and fails to FEL boot newer U-Boot images with the following error message: sunxi SPL version mismatch: found 0x02 > maximum supported 0x01 You need a more recent version of this (sunxi-tools) fel utility. The other things in the top priority list are the FIT container format support for the main U-Boot binary and TOC0 container format for the SPL. Currently sunxi-tools does not recognize either of these. And these features are needed to get full support for modern 64-bit Allwinner SoCs (A64/H64/H5). We also need to go through the list of bugreports and do something about them. Because way too many people have commit access to the sunxi-tools repository, I would like to see the following rules respected (this is nothing new, I've been following this practice myself since a while ago): 1. All features should go in via reviewed pull requests. One of the reasons for this is that we have travis-ci active, which does the initial basic QA check for any pull request submissions. 2. Never merge any pull requests without giving a 2-3 days notice via a github comment. Because absence of activity on some pull request does not automatically mean that nobody has any objections. But if you get no objections within this short notice period, then go ahead. The timeline is preliminary and we can extend the deadlines a bit if some features need more time (but preferably by no more than one extra week). Do you have any comments or suggestions? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3 1/3] video: sunxi: extract simplefb match code to a new file
; if (offset < 0) { > eprintf("Cannot setup simplefb: node not found\n"); > return 0; /* Keep older kernels working */ Here is the "git blame" output for this part of code that you are moving around by your patch: 2dae800f drivers/video/sunxi_display.c (Hans de Goede 2014-12-21 16:28:32 +0100 1380) /* Find a prefilled simpefb node, matching out pipeline config */ 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1381) offset = fdt_node_offset_by_compatible(blob, -1, 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1382) "allwinner,simple-framebuffer"); 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1383) while (offset >= 0) { b02e4044 drivers/video/sunxi_display.c (Simon Glass 2016-10-02 17:59:28 -0600 1384) ret = fdt_stringlist_search(blob, offset, "allwinner,pipeline", 6e67f176 drivers/video/sunxi_display.c (Masahiro Yamada 2016-10-17 20:43:01 +0900 1385) pipeline); 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1386) if (ret == 0) 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1387) break; 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1388) offset = fdt_node_offset_by_compatible(blob, offset, 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1389) "allwinner,simple-framebuffer"); 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1390) } 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1391) if (offset < 0) { 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1392) eprintf("Cannot setup simplefb: node not found\n"); 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1393) return 0; /* Keep older kernels working */ 2d7a084b drivers/video/sunxi_display.c (Luc Verhaegen 2014-08-13 07:55:07 +0200 1394) } Luc Verhaegen is the real author of the sunxi DE1 simplefb code in U-Boot. If you need to pick only one copyright line from the old code, then you should mention Luc instead of Hans. Hans de Goede surely has done a lot of massaging for this code later (plus added EDID and LCD support). But it was Luc, who made it happen back in 2014 by providing a usable graphics support for the mainline kernel users and laid down the foundation for all the further incremental improvements. If not for Luc Verhaegen, we don't even know what would be the current state of the graphics support on sunxi hardware. And the number of commits does not matter, what matters is having the job done. And Luc did just that. So let's give credit where it is due. With a proper copyright notice, this patch is Acked-by: Siarhei Siamashka -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner A13 could support DDR1 sdram or not?
On Tue, 18 Jul 2017 13:28:40 -0700 (PDT) mehdi soheili wrote: > hi everyone > i have some problem to use multilayer pcb for my design. > i found ddr1 package is not bga and allwinner a13 package is lqfp. > so we could route trace in 2-layer pcb easily if core support ddr1 memory > chip. > anybody could tell me is it possible or not? > tnx alot. > > DDR vs DDR2 <http://www.diffen.com/difference/DDR_vs_DDR2> Well, you can check the A13 datasheet and it says "Support DDR2 SDRAM and DDR3 SDRAM up to 533MHz". So DDR1 is not in the list. But you can send your query to Allwinner and maybe they can help. Even DDR2 is currently not supported in the mainline U-Boot on A13. Simply because we never had any such hardware to actually test the code. Also my understanding is that DDR3 is currently the cheapest memory that you can get anyway, so it is economically unreasonable to design boards with anything older. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v2 00/12] Big work on sunxi DW DRAM controllers and some new DDR type support
On Sat, 3 Jun 2017 17:10:13 +0800 Icenowy Zheng wrote: > This patchset contains several works on the sunxi DesignWare DRAM > controllers. > > The 1st patch made an option for H3-like DRAM controllers > (DesignWare ones), which can ease further import of alike controllers. > > The 2nd and 3rd patches are for supporting 16-bit DW DRAM controllers, > in order to add V3s DRAM support (The controller on V3s is 16-bit). > > The 4th patch adds bank detection code, in order to support some DDR2 > chips. > > The 5th patch adds a framework for select DRAM type and timing -- it's > needed for boards that use DRAM chips rather than DDR3. > > The 6th patch enables dual rank detection in the DW DRAM code on SoCs > except R40. For R40 the dual rank facility is still not so clear, so it's > temporarily disabled. > > The 7th~9th patches enables support for DRAM initialization and SPL for > the V3s SoC, which integrates a DDR2 chip. > > The 10th and 11th patches adds support for LPDDR3, with the stock boot0 > timing. (Seen in A83T boot0 source and some leaked H5/R40 libdram source) > > The 12th patches adds a defconfig for SoPine w/ official baseboard, which > utilizes LPDDR3. > > Icenowy Zheng (12): > sunxi: makes an invisible option for H3-like DRAM controllers > sunxi: Rename bus-width related macros in H3 DRAM code > sunxi: add option for 16-bit DW DRAM controller > sunxi: add bank detection code to H3 DRAM initialization code > sunxi: Add selective DRAM type and timing > sunxi: enable dual rank detection in DesignWare-like DRAM code > sunxi: add support for the DDR2 in V3s SoC > sunxi: add support for V3s DRAM controller > sunxi: enable DRAM initialization and SPL for V3s SoC > sunxi: add LPDDR3 DRAM type support for DesignWare-like DRAM > controller > sunxi: add LPDDR3 timing from stock boot0 > sunxi: add a defconfig for SoPine w/ official baseboard > > arch/arm/include/asm/arch-sunxi/dram.h | 6 +- > .../{dram_sun8i_h3.h => dram_sunxi_dw.h} | 36 +++- > arch/arm/mach-sunxi/Kconfig| 75 - > arch/arm/mach-sunxi/Makefile | 5 +- > .../{dram_sun8i_h3.c => dram_sunxi_dw.c} | 187 > +++-- > arch/arm/mach-sunxi/dram_timings/Makefile | 3 + > arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c| 84 + > arch/arm/mach-sunxi/dram_timings/ddr3_1333.c | 87 ++ > arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c| 83 + > configs/sopine_baseboard_defconfig | 22 +++ > 10 files changed, 453 insertions(+), 135 deletions(-) > rename arch/arm/include/asm/arch-sunxi/{dram_sun8i_h3.h => dram_sunxi_dw.h} > (86%) > rename arch/arm/mach-sunxi/{dram_sun8i_h3.c => dram_sunxi_dw.c} (84%) > create mode 100644 arch/arm/mach-sunxi/dram_timings/Makefile > create mode 100644 arch/arm/mach-sunxi/dram_timings/ddr2_v3s.c > create mode 100644 arch/arm/mach-sunxi/dram_timings/ddr3_1333.c > create mode 100644 arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c > create mode 100644 configs/sopine_baseboard_defconfig > I'll have time to review your patchset on the coming weekend. Thanks! -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2] ARM: spi/sun7i: Add Master Sample Data Mode for SPI
On Sun, 26 Feb 2017 06:10:50 -0800 (PST) Vinicius Maciel wrote: > Em segunda-feira, 13 de fevereiro de 2017 09:52:53 UTC-3, Mark Brown > escreveu: > > > > This should be controlled by the SPI mode settings, different chips have > > different requirements. If the controller supports multiple modes then > > it should expose that and let the drivers and system integrations > > choose. > > > Do you mean SPI_CPHA/SPI_CPOL, right? Well, I don't know how this mode can > to fit in existing modes. Since this bit is to control when the data will > be sampled, in the same clock edge or at the edge that is half cycle > delayed. That has nothing to do with SPI_CPHA/SPI_CPOL. I'm not sure if it is realistic to make any progress with this issue any time soon, but I would suggest you to re-send the patch with an updated commit message, which could better explain what's going on. I still think that your bugfix is good, that's why you got my Reviewed-by tag. And we had an older discussion about it (Mark was not participating there, so probably he missed it): https://patchwork.kernel.org/patch/9567547/ Here is a short summary. Older Allwinner A10/A13 SoCs used to have reserved RAZ/WI (Read-As-Zero, Writes Ignored) bits 20-31 in the SPI_CTL register. Newer Allwinner A20 SoC introduced some sort of a wacky half-cycle delay mode and used the previously reserved bit 20 from the SPI_CTL to enable/disable it. Now the tricky part is that the meaning of this new bit is inverted for some unknown reason: the wacky mode is activated when the bit is set to zero, while the standard behaviour (same as A10/A13) is preserved when this bit is set to 1. The reset default of this bit is 1 on A20 (normal SPI behaviour). The problem of the current SPI driver is that it clears bits 20-31 of SPI_CTL, which results in normal SPI behaviour on A10/A13, and a wacky half-cycle delayed mode on A20. Your bugfix just makes A20 behave in the same way as A10/A13. We have exactly zero users of the wacky half-cycle delayed mode. Moreover, if it gets enabled accidentally (due to a bug in the SPI_CTL register initialization in the SPI driver as explained above), then it breaks your max11043 ADC chip. Also even if we assume that there is some hypothetical equipment, which actually needs this wacky mode to function preperly, then this equipment is not compatible with older A10/A13 SoCs because the older SoCs did not implement this mode at all. You could rephrase the above two paragraphs and use them as the commit message for the v3 patch. And maybe also add an extra comment to the SPI driver code. If Mark has any comments on this, then I would be very happy to hear them. So far his suggestion looks like he prefers to see a support for this wacky mode implemented in the SPI driver (a *new feature*, which has no actual users and can't be realistically tested). While your patch just prevents accidental and undesired activation of the wacky mode (an *important bugfix* for a real problem encountered in the wild). -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Tue, 28 Feb 2017 09:16:11 + Andre Przywara wrote: > Hi, > > On 28/02/17 03:08, Siarhei Siamashka wrote: > > On Mon, 27 Feb 2017 20:55:53 + > > Andre Przywara wrote: > > > >> On Mon, 27 Feb 2017 05:48:48 +0200 > >> Siarhei Siamashka wrote: > >> > >>> On Mon, 27 Feb 2017 02:22:08 + > >>> André Przywara wrote: > >>> > >>>> On 27/02/17 01:20, Siarhei Siamashka wrote: > >>>>> On Wed, 22 Feb 2017 17:08:47 + > >>>>> Andre Przywara wrote: > >>>>> > >>>>>> If an SoC has the "secure boot" fuse burned, it will enter FEL > >>>>>> mode in non-secure state, so with the SCR.NS bit set. Since in > >>>>>> this mode the secure/non-secure state restrictions are actually > >>>>>> observed, we suffer from several restrictions: > >>>>>> - No access to the SID information (both via memory mapped and > >>>>>> "register"). > >>>>>> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > >>>>>> - No access to the secure side of the GIC, so it can't be > >>>>>> configured to be accessible from non-secure world. > >>>>>> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > >>>>>> Those limitations make a board pretty useless for many > >>>>>> applications. > >>>>>> > >>>>>> However it has been found out that a simple "smc" call will > >>>>>> immediately return from monitor mode, but with the NS bit > >>>>>> cleared, so access to all secure peripherals is suddenly > >>>>>> possible. > >>>>>> > >>>>>> Add a sunxi-fel command called "smc" which will issue exactly > >>>>>> this instruction to make those boards useful in "secure boot" > >>>>>> FEL mode. > >>>>>> > >>>>>> It should be given early in the command queue to given > >>>>>> subsequent code full access to the system: > >>>>>> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > >>>>>> > >>>>>> Signed-off-by: Andre Przywara > >>>>>> > >>>>>> --- > >>>>>> Hi, > >>>>>> > >>>>>> if that sounds vaguely useful (it definitedly is for me to get > >>>>>> the Remix Mini PC started), I can follow the Github process if > >>>>>> you prefer that. > >>>>>> > >>>>>> Cheers, > >>>>>> Andre. > >>>>> > >>>>> Hi Andre, > >>>>> > >>>>> Why don't we just do this automatically without adding a new > >>>>> special command? > >>>>> > >>>>> We are not allowed to read the SCR register for detecting this > >>>>> state, right? But can we still use some other detection method? > >>>>> For example, maybe try to read SID and assume that we need the > >>>>> SMC workaround if it reads back as zero? > >>>> > >>>> Yes, indeed I was thinking about exactly that ;-) > >>>> From actually using this feature I realized that its usage is error > >>>> prone: non-secure boards crash on calling it, secure board just > >>>> don't work without it. > >>>> And indeed there is no architectural way of checking whether you are > >>>> running secure or non-secure (as reading a secure-only register like > >>>> NSACR or SCR will trap, which means crash in our case). > >>>> > >>>> So (trying to) read the SID is indeed the best workaround I came up > >>>> with: If it's all zero, we are probably secure and need the smc. > >>>> There is still a slight chance that the SID is all zero even on a > >>>> non-secure board (I think this was the case for some older SoCs?), > >>>> so maybe we need an option to suppress using this heuristic? > >>> > >>> At least we should report every taken action in the sunxi-fel verbose > >>> log (about the SMC workaround getting applied) because it greatly > >>> simplifies troubleshooting. > >>> > >>> A
Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Tue, 28 Feb 2017 05:14:27 +0800 Icenowy Zheng wrote: > 2017年2月28日 04:55于 Andre Przywara 写道: > > > > On Mon, 27 Feb 2017 05:48:48 +0200 > > Siarhei Siamashka wrote: > > > > > On Mon, 27 Feb 2017 02:22:08 + > > > André Przywara wrote: > > > > > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > > > On Wed, 22 Feb 2017 17:08:47 + > > > > > Andre Przywara wrote: > > > > > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > > > >> this mode the secure/non-secure state restrictions are actually > > > > >> observed, we suffer from several restrictions: > > > > >> - No access to the SID information (both via memory mapped and > > > > >> "register"). > > > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > > > >> - No access to the secure side of the GIC, so it can't be > > > > >> configured to be accessible from non-secure world. > > > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > > > >> Those limitations make a board pretty useless for many > > > > >> applications. > > > > >> > > > > >> However it has been found out that a simple "smc" call will > > > > >> immediately return from monitor mode, but with the NS bit > > > > >> cleared, so access to all secure peripherals is suddenly > > > > >> possible. > > > > >> > > > > >> Add a sunxi-fel command called "smc" which will issue exactly > > > > >> this instruction to make those boards useful in "secure boot" > > > > >> FEL mode. > > > > >> > > > > >> It should be given early in the command queue to given > > > > >> subsequent code full access to the system: > > > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > > > >> > > > > >> Signed-off-by: Andre Przywara > > > > >> > > > > >> --- > > > > >> Hi, > > > > >> > > > > >> if that sounds vaguely useful (it definitedly is for me to get > > > > >> the Remix Mini PC started), I can follow the Github process if > > > > >> you prefer that. > > > > >> > > > > >> Cheers, > > > > >> Andre. > > > > > > > > > > Hi Andre, > > > > > > > > > > Why don't we just do this automatically without adding a new > > > > > special command? > > > > > > > > > > We are not allowed to read the SCR register for detecting this > > > > > state, right? But can we still use some other detection method? > > > > > For example, maybe try to read SID and assume that we need the > > > > > SMC workaround if it reads back as zero? > > > > > > > > Yes, indeed I was thinking about exactly that ;-) > > > > From actually using this feature I realized that its usage is error > > > > prone: non-secure boards crash on calling it, secure board just > > > > don't work without it. > > > > And indeed there is no architectural way of checking whether you are > > > > running secure or non-secure (as reading a secure-only register like > > > > NSACR or SCR will trap, which means crash in our case). > > > > > > > > So (trying to) read the SID is indeed the best workaround I came up > > > > with: If it's all zero, we are probably secure and need the smc. > > > > There is still a slight chance that the SID is all zero even on a > > > > non-secure board (I think this was the case for some older SoCs?), > > > > so maybe we need an option to suppress using this heuristic? > > > > > > At least we should report every taken action in the sunxi-fel verbose > > > log (about the SMC workaround getting applied) because it greatly > > > simplifies troubleshooting. > > > > > > And IMHO having any options to suppress this workaround is a bit > > > premature until we encounter a real A64/H64/H5 chip where it fails > > >
Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Mon, 27 Feb 2017 20:55:53 + Andre Przywara wrote: > On Mon, 27 Feb 2017 05:48:48 +0200 > Siarhei Siamashka wrote: > > > On Mon, 27 Feb 2017 02:22:08 + > > André Przywara wrote: > > > > > On 27/02/17 01:20, Siarhei Siamashka wrote: > > > > On Wed, 22 Feb 2017 17:08:47 + > > > > Andre Przywara wrote: > > > > > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL > > > >> mode in non-secure state, so with the SCR.NS bit set. Since in > > > >> this mode the secure/non-secure state restrictions are actually > > > >> observed, we suffer from several restrictions: > > > >> - No access to the SID information (both via memory mapped and > > > >> "register"). > > > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > > > >> - No access to the secure side of the GIC, so it can't be > > > >> configured to be accessible from non-secure world. > > > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > > > >> Those limitations make a board pretty useless for many > > > >> applications. > > > >> > > > >> However it has been found out that a simple "smc" call will > > > >> immediately return from monitor mode, but with the NS bit > > > >> cleared, so access to all secure peripherals is suddenly > > > >> possible. > > > >> > > > >> Add a sunxi-fel command called "smc" which will issue exactly > > > >> this instruction to make those boards useful in "secure boot" > > > >> FEL mode. > > > >> > > > >> It should be given early in the command queue to given > > > >> subsequent code full access to the system: > > > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > > >> > > > >> Signed-off-by: Andre Przywara > > > >> > > > >> --- > > > >> Hi, > > > >> > > > >> if that sounds vaguely useful (it definitedly is for me to get > > > >> the Remix Mini PC started), I can follow the Github process if > > > >> you prefer that. > > > >> > > > >> Cheers, > > > >> Andre. > > > > > > > > Hi Andre, > > > > > > > > Why don't we just do this automatically without adding a new > > > > special command? > > > > > > > > We are not allowed to read the SCR register for detecting this > > > > state, right? But can we still use some other detection method? > > > > For example, maybe try to read SID and assume that we need the > > > > SMC workaround if it reads back as zero? > > > > > > Yes, indeed I was thinking about exactly that ;-) > > > From actually using this feature I realized that its usage is error > > > prone: non-secure boards crash on calling it, secure board just > > > don't work without it. > > > And indeed there is no architectural way of checking whether you are > > > running secure or non-secure (as reading a secure-only register like > > > NSACR or SCR will trap, which means crash in our case). > > > > > > So (trying to) read the SID is indeed the best workaround I came up > > > with: If it's all zero, we are probably secure and need the smc. > > > There is still a slight chance that the SID is all zero even on a > > > non-secure board (I think this was the case for some older SoCs?), > > > so maybe we need an option to suppress using this heuristic? > > > > At least we should report every taken action in the sunxi-fel verbose > > log (about the SMC workaround getting applied) because it greatly > > simplifies troubleshooting. > > > > And IMHO having any options to suppress this workaround is a bit > > premature until we encounter a real A64/H64/H5 chip where it fails > > in the wild. > > > > Another variant of the detection heuristics could just use SRAM A2 > > (well, not quite "SRAM", but the OpenRISC reset vector area). I'm > > getting the following output on my Jide Remix Mini (Allwinner H64): > > > > $ ./sunxi-fel readl 0x40004 > > 0x > > > > $ ./sunxi-fel smc > > > > $ ./sunxi-fel readl 0x40004 > > 0x1500 > > > > We are either reading zer
Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Mon, 27 Feb 2017 02:22:08 + André Przywara wrote: > On 27/02/17 01:20, Siarhei Siamashka wrote: > > On Wed, 22 Feb 2017 17:08:47 + > > Andre Przywara wrote: > > > >> If an SoC has the "secure boot" fuse burned, it will enter FEL mode in > >> non-secure state, so with the SCR.NS bit set. Since in this mode the > >> secure/non-secure state restrictions are actually observed, we suffer > >> from several restrictions: > >> - No access to the SID information (both via memory mapped and "register"). > >> - No access to secure SRAM (SRAM A2 on H3/A64/H5). > >> - No access to the secure side of the GIC, so it can't be configured to > >> be accessible from non-secure world. > >> - No RMR trigger on ARMv8 cores to bring the core into AArch64. > >> Those limitations make a board pretty useless for many applications. > >> > >> However it has been found out that a simple "smc" call will immediately > >> return from monitor mode, but with the NS bit cleared, so access to all > >> secure peripherals is suddenly possible. > >> > >> Add a sunxi-fel command called "smc" which will issue exactly this > >> instruction to make those boards useful in "secure boot" FEL mode. > >> > >> It should be given early in the command queue to given subsequent code > >> full access to the system: > >> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > >> > >> Signed-off-by: Andre Przywara > >> > >> --- > >> Hi, > >> > >> if that sounds vaguely useful (it definitedly is for me to get the Remix > >> Mini PC started), I can follow the Github process if you prefer that. > >> > >> Cheers, > >> Andre. > > > > Hi Andre, > > > > Why don't we just do this automatically without adding a new special > > command? > > > > We are not allowed to read the SCR register for detecting this state, > > right? But can we still use some other detection method? For example, > > maybe try to read SID and assume that we need the SMC workaround if > > it reads back as zero? > > Yes, indeed I was thinking about exactly that ;-) > From actually using this feature I realized that its usage is error > prone: non-secure boards crash on calling it, secure board just don't > work without it. > And indeed there is no architectural way of checking whether you are > running secure or non-secure (as reading a secure-only register like > NSACR or SCR will trap, which means crash in our case). > > So (trying to) read the SID is indeed the best workaround I came up > with: If it's all zero, we are probably secure and need the smc. There > is still a slight chance that the SID is all zero even on a non-secure > board (I think this was the case for some older SoCs?), so maybe we need > an option to suppress using this heuristic? At least we should report every taken action in the sunxi-fel verbose log (about the SMC workaround getting applied) because it greatly simplifies troubleshooting. And IMHO having any options to suppress this workaround is a bit premature until we encounter a real A64/H64/H5 chip where it fails in the wild. Another variant of the detection heuristics could just use SRAM A2 (well, not quite "SRAM", but the OpenRISC reset vector area). I'm getting the following output on my Jide Remix Mini (Allwinner H64): $ ./sunxi-fel readl 0x40004 0x $ ./sunxi-fel smc $ ./sunxi-fel readl 0x40004 0x1500 We are either reading zero from there, or it is a hardwired OpenRISC instruction L.NOP. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command
On Wed, 22 Feb 2017 17:08:47 + Andre Przywara wrote: > If an SoC has the "secure boot" fuse burned, it will enter FEL mode in > non-secure state, so with the SCR.NS bit set. Since in this mode the > secure/non-secure state restrictions are actually observed, we suffer > from several restrictions: > - No access to the SID information (both via memory mapped and "register"). > - No access to secure SRAM (SRAM A2 on H3/A64/H5). > - No access to the secure side of the GIC, so it can't be configured to > be accessible from non-secure world. > - No RMR trigger on ARMv8 cores to bring the core into AArch64. > Those limitations make a board pretty useless for many applications. > > However it has been found out that a simple "smc" call will immediately > return from monitor mode, but with the NS bit cleared, so access to all > secure peripherals is suddenly possible. > > Add a sunxi-fel command called "smc" which will issue exactly this > instruction to make those boards useful in "secure boot" FEL mode. > > It should be given early in the command queue to given subsequent code > full access to the system: > $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... > > Signed-off-by: Andre Przywara > > --- > Hi, > > if that sounds vaguely useful (it definitedly is for me to get the Remix > Mini PC started), I can follow the Github process if you prefer that. > > Cheers, > Andre. Hi Andre, Why don't we just do this automatically without adding a new special command? We are not allowed to read the SCR register for detecting this state, right? But can we still use some other detection method? For example, maybe try to read SID and assume that we need the SMC workaround if it reads back as zero? -- Best regards, Siarhei Siamashka > fel.c | 21 + > 1 file changed, 21 insertions(+) > > diff --git a/fel.c b/fel.c > index 295d5d8..9364fc0 100644 > --- a/fel.c > +++ b/fel.c > @@ -403,6 +403,24 @@ void aw_set_sctlr(feldev_handle *dev, soc_info_t > *soc_info, > } > > /* > + * Issue a "smc #0" instruction. This brings a SoC booted in "secure boot" > + * state from the default non-secure FEL into secure FEL. > + * This crashes on devices using "non-secure boot", as the BROM does not > + * provide a handler address in MVBAR. > + */ > +void aw_do_smc(feldev_handle *dev) > +{ > + soc_info_t *soc_info = dev->soc_info; > + uint32_t arm_code[] = { > + htole32(0xe1600070), /* smc #0 */ > + htole32(0xe12fff1e), /* bx lr */ > + }; > + > + aw_fel_write(dev, arm_code, soc_info->scratch_addr, sizeof(arm_code)); > + aw_fel_execute(dev, soc_info->scratch_addr); > +} > + > +/* > * Reconstruct the same MMU translation table as used by the A20 BROM. > * We are basically reverting the changes, introduced in newer SoC > * variants. This works fine for the SoC variants with the memory > @@ -994,6 +1012,7 @@ void usage(const char *cmd) { > " dump address length Binary memory dump\n" > " exe[cute] address Call function address\n" > " reset64 address RMR request for AArch64 > warm boot\n" > + " smc issue smc #0 > instruction\n" > " memmove dest source sizeCopy bytes > within device memory\n" > " readl address Read 32-bit value from > device memory\n" > " writel address valueWrite 32-bit value to > device memory\n" > @@ -1127,6 +1146,8 @@ int main(int argc, char **argv) > aw_fel_print_sid(handle, false); > } else if (strcmp(argv[1], "sid-registers") == 0) { > aw_fel_print_sid(handle, true); /* enforce register > access */ > + } else if (strcmp(argv[1], "smc") == 0) { > + aw_do_smc(handle); > } else if (strcmp(argv[1], "write") == 0 && argc > 3) { > skip += 2 * file_upload(handle, 1, argc - 2, argv + 2, > pflag_active ? progress_bar : NULL); -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Add Master Sample Data Mode for SPI
On Sat, 11 Feb 2017 00:05:42 -0300 Vinicius Maciel wrote: > Em 10 de fev de 2017 23:53, "Siarhei Siamashka" > escreveu: > > > On Fri, 10 Feb 2017 19:02:47 -0300 > > Vinicius Maciel wrote: > > > > > In order to work appropriately, the max11043 ADC chip and probably > > > others, needs SPI master samples the data at the correct edge. From > > > max11043 datasheet: "The data at DIN is latched on the rising edge > > > of SCLK". Same to DOUT. > > > > > > This patch add Master Sample Data Mode bit in normal sample mode. > > > > > > Signed-off-by: Vinicius Maciel > > > --- > > > drivers/spi/spi-sun4i.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c > > > index c5cd635c28f3..6325be2ce8d9 100644 > > > --- a/drivers/spi/spi-sun4i.c > > > +++ b/drivers/spi/spi-sun4i.c > > > @@ -44,6 +44,7 @@ > > > #define SUN4I_CTL_CS_MANUAL BIT(16) > > > #define SUN4I_CTL_CS_LEVEL BIT(17) > > > #define SUN4I_CTL_TP BIT(18) > > > +#define SUN4I_CTL_SDMBIT(20) > > > > > > #define SUN4I_INT_CTL_REG0x0c > > > #define SUN4I_INT_CTL_RF_F34 BIT(4) > > > @@ -407,7 +408,8 @@ static int sun4i_spi_runtime_resume(struct device > > *dev) > > > } > > > > > > sun4i_spi_write(sspi, SUN4I_CTL_REG, > > > - SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | > > SUN4I_CTL_TP); > > > + SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP > > | > > > + SUN4I_CTL_SDM); > > > > > > return 0; > > > > > > > Thanks! That's a good catch. This particular bit is actually set in the > > reset default register value, according to the Allwinner A20 manual. > > But on Allwinner A10 and Allwinner A13 it is documented as unused and > > can't be changed (it remains zero even if we try to modify it). > > > > So looks like only A20 is affected, because the kernel currently sets a > > non-standard mode, deviating from both Allwinner's default and normal > > SPI behaviour. > > > > You still need to update the summary line to add all the necessary > > sunxi and spi specific prefixes (see similar commits). Also a similar > > fix most likely needs to be applied to the spi-sun6i.c file too (due > > to the copy-paste curse and code duplication), but I'm not sure if it > > needs to be a part of this patch or a separate one. > > > > Reviewed-by: Siarhei Siamashka > Hi Siarhei, > > I was really aiming only A20 in this patch. Well, regardless of whether you like it or not, A10 and A13 are also currently using the same code path. So they are potentially affected. Yes, we may try to introduce a separate compatible property to describe this particular new A20-specific feature, which did not exist in the older A10/A13 SoCs and then set this bit only for A20 in the SPI driver. But since A20 is backwards compatible with A10/A13 (as long as we don't override the default values of the reserved bits in hardware registers) and enabling this particular feature is apparently undesired (it breaks your max11043 ADC use case), it does not seem to be necessary to me right now. Maxime and others may have a different opinion though. As for the spi-sun6i.c file, somebody else might encounter the same problem on A23/A33/H3/H5/A83T/A64 later and waste time debugging something that had been already resolved by you now. Also having the spi-sun4i.c and spi-sun6i.c files diverge even more than they are now is not nice. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] Add Master Sample Data Mode for SPI
On Fri, 10 Feb 2017 19:02:47 -0300 Vinicius Maciel wrote: > In order to work appropriately, the max11043 ADC chip and probably > others, needs SPI master samples the data at the correct edge. From > max11043 datasheet: "The data at DIN is latched on the rising edge > of SCLK". Same to DOUT. > > This patch add Master Sample Data Mode bit in normal sample mode. > > Signed-off-by: Vinicius Maciel > --- > drivers/spi/spi-sun4i.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c > index c5cd635c28f3..6325be2ce8d9 100644 > --- a/drivers/spi/spi-sun4i.c > +++ b/drivers/spi/spi-sun4i.c > @@ -44,6 +44,7 @@ > #define SUN4I_CTL_CS_MANUAL BIT(16) > #define SUN4I_CTL_CS_LEVEL BIT(17) > #define SUN4I_CTL_TP BIT(18) > +#define SUN4I_CTL_SDMBIT(20) > > #define SUN4I_INT_CTL_REG0x0c > #define SUN4I_INT_CTL_RF_F34 BIT(4) > @@ -407,7 +408,8 @@ static int sun4i_spi_runtime_resume(struct device *dev) > } > > sun4i_spi_write(sspi, SUN4I_CTL_REG, > - SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP); > + SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP | > + SUN4I_CTL_SDM); > > return 0; > Thanks! That's a good catch. This particular bit is actually set in the reset default register value, according to the Allwinner A20 manual. But on Allwinner A10 and Allwinner A13 it is documented as unused and can't be changed (it remains zero even if we try to modify it). So looks like only A20 is affected, because the kernel currently sets a non-standard mode, deviating from both Allwinner's default and normal SPI behaviour. You still need to update the summary line to add all the necessary sunxi and spi specific prefixes (see similar commits). Also a similar fix most likely needs to be applied to the spi-sun6i.c file too (due to the copy-paste curse and code duplication), but I'm not sure if it needs to be a part of this patch or a separate one. Reviewed-by: Siarhei Siamashka -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 05/11] tools: mksunxiboot: allow larger SPL binaries
_out = open(argv[ac], O_WRONLY | O_CREAT, 0666); > + if (fd_out < 0) { > + perror("Open output file"); > + return EXIT_FAILURE; > + } > } > > /* read file to buffer to calculate checksum */ > @@ -115,7 +140,7 @@ int main(int argc, char *argv[]) >& 0x00FF); > memcpy(img.header.magic, BOOT0_MAGIC, 8); /* no '0' termination */ > img.header.length = > - ALIGN(file_size + sizeof(struct boot_file_head), BLOCK_SIZE); > + ALIGN(file_size + sizeof(struct boot_file_head), block_size); > img.header.b_instruction = cpu_to_le32(img.header.b_instruction); > img.header.length = cpu_to_le32(img.header.length); > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 08/11] sunxi: SPL: add FIT config selector for Pine64 boards
On Fri, 20 Jan 2017 21:55:53 + André Przywara wrote: > On 20/01/17 21:35, Maxime Ripard wrote: > > Hi Maxime, > > thanks for having a look! > > > On Fri, Jan 20, 2017 at 01:53:28AM +, Andre Przywara wrote: > >> For a board or platform to support FIT loading in the SPL, it has to > >> provide a board_fit_config_name_match() routine, which helps to select > >> one of possibly multiple DTBs contained in a FIT image. > >> Provide a simple function to cover the two different Pine64 models, > >> which can be easily told apart by looking at the amount of installed > >> RAM. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> board/sunxi/board.c | 13 + > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/board/sunxi/board.c b/board/sunxi/board.c > >> index 5365638..826 100644 > >> --- a/board/sunxi/board.c > >> +++ b/board/sunxi/board.c > >> @@ -726,3 +726,16 @@ int ft_board_setup(void *blob, bd_t *bd) > >> #endif > >>return 0; > >> } > >> + > >> +#ifdef CONFIG_SPL_LOAD_FIT > >> +int board_fit_config_name_match(const char *name) > >> +{ > >> +#ifdef CONFIG_MACH_SUN50I > >> + if ((gd->ram_size > 512 * 1024 * 1024)) > >> + return !strcmp(name, "sun50i-a64-pine64-plus"); > >> + else > >> + return !strcmp(name, "sun50i-a64-pine64"); > >> +#endif > >> + return -1; > >> +} > > > > That looks fishy. It means that any A64 board with CONFIG_SPL_LOAD_FIT > > enabled will be considered a pine64 board? > > Yes, at least for now, because that's the only A64 board we officially > support so far. > And yes again, it is fishy. It is more a demo or a placeholder for now, > because you _need_ an implementation of board_fit_config_name_match() > once you enable CONFIG_SPL_LOAD_FIT. > > One solution would be to have only one DTB supported per build, so > board_fit_config_name_match() always returns 0. > > Another (better) solution would be to store the board name in the SPL > header, which could be done later when flashing the image. Then this > function would just return strcmp(name, spl_header_name) or 0 if no name > is found for whatever reason. Yes, this is a good solution in the case if we have some non-removable storage on the board (SPI NOR flash, NAND, EEPROM or something else). We can discuss it separately. But the current generation of Pine64 boards don't have any non-removable storage yet. My understanding is that you tried to provide the DTB selection, which is based on circumstantial evidences, such as the RAM size. IMHO this is also a valid selection method, because it can reduce the number of required OS image variants. Yes, this is not urgent and we can indeed temporarily use separate defconfigs for different Pine64 board variants. > Ideas welcome. To be honest, this .dtb selection is nice, but I am not > married to it. It usefulness maybe limited at the moment. The board specific information is normally stored either in the defconfig file or in the device tree, rather than gets hardcoded in the sources. We can probably add some extra constraints information to the device tree. And these extra constraints can be passed to the board_fit_config_name_match() function in some way. Then the sun50i-a64-pine64 device tree file can specify that this board is expected to have exactly 512 MiB of RAM. Having this information, the board_fit_config_name_match() function will fail to match it if the actual RAM size is wrong. This approach is similar to what I used in https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype http://lists.denx.de/pipermail/u-boot/2015-January/202306.html The sunxi-bootsetup stub used the SoC type id and RAM size to filter the list of potentially matching boards. It worked very nicely in practice. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] sunxi: fix SID read on H3
On Tue, 20 Dec 2016 02:03:36 +0800 Icenowy Zheng wrote: > H3 SID controller has some bug, which makes the initial SID value at > SUNXI_SID_BASE wrong when boot. > > Change the SID retrieve code to call the SID Controller directly on H3, > which can get the correct value, and also fix the SID value at > SUNXI_SID_BASE, so that it can be used by further operations. > > Signed-off-by: Icenowy Zheng > --- > arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 1 + > arch/arm/mach-sunxi/cpu_info.c | 44 > + > 2 files changed, 45 insertions(+) > > diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > index 7232f6d927..3c852224e6 100644 > --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h > @@ -97,6 +97,7 @@ > #if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN8I_H3) || \ > defined(CONFIG_MACH_SUN50I) > /* SID address space starts at 0x01c1400, but e-fuse is at offset 0x200 */ > +#define SUNXI_SIDC_BASE 0x01c14000 > #define SUNXI_SID_BASE 0x01c14200 > #else > #define SUNXI_SID_BASE 0x01c23800 > diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c > index 76b6719d99..f1f6fd5ba4 100644 > --- a/arch/arm/mach-sunxi/cpu_info.c > +++ b/arch/arm/mach-sunxi/cpu_info.c > @@ -99,10 +99,54 @@ int print_cpuinfo(void) > } > #endif > > +#ifdef CONFIG_MACH_SUN8I_H3 > + > +#define SIDC_PRCTL 0x40 > +#define SIDC_RDKEY 0x60 > + > +#define SIDC_OP_LOCK 0xAC > + > +uint32_t sun8i_efuse_read(uint32_t offset) > +{ > + uint32_t reg_val; > + > + reg_val = readl(SUNXI_SIDC_BASE + SIDC_PRCTL); > + reg_val &= ~(((0x1ff) << 16) | 0x3); > + reg_val |= (offset << 16); > + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL); Normally clrsetbits_le32() is used for this kind of code in U-Boot. > + > + reg_val &= ~(((0xff) << 8) | 0x3); > + reg_val |= (SIDC_OP_LOCK << 8) | 0x2; > + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL); > + > + while (readl(SUNXI_SIDC_BASE + SIDC_PRCTL) & 0x2); > + > + reg_val &= ~(((0x1ff) << 16) | ((0xff) << 8) | 0x3); > + writel(reg_val, SUNXI_SIDC_BASE + SIDC_PRCTL); Same here. > + > + reg_val = readl(SUNXI_SIDC_BASE + SIDC_RDKEY); > + return reg_val; > +} > +#endif > + > int sunxi_get_sid(unsigned int *sid) > { > #ifdef CONFIG_AXP221_POWER > return axp_get_sid(sid); > +#elif defined CONFIG_MACH_SUN8I_H3 > + /* > + * H3 SID controller has a bug, which makes the initial value of > + * SUNXI_SID_BASE at boot wrong. > + * Read the value directly from SID controller, in order to get > + * the correct value, and also refresh the wrong value at > + * SUNXI_SID_BASE. > + */ > + int i; > + > + for (i = 0; i< 4; i++) > + sid[i] = sun8i_efuse_read(i * 4); > + > + return 0; > #elif defined SUNXI_SID_BASE > int i; > Thanks for this workaround. This problem has buggered some people since a while ago. It's good that you took time to investigate and fix it. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Bare metal example for cubietruck
On Thu, 13 Oct 2016 22:08:15 +0200 Paolo De Luca Bosso wrote: > However I have used makefile in the linux-tools. > > It has produced ELF file. How can i boot Cubietruck with it? > Thanks > > 2016-10-13 21:21 GMT+02:00 Paolo De Luca Bosso > : > > > Following previous mail: > > how can i try that example on my cubietruck if it is compatible with A20?? > > > > Thanks > > > > 2016-10-13 21:18 GMT+02:00 Paolo De Luca Bosso < > > paolo.delucabo...@gmail.com>: > > > >> Hello!! > >> First of all, thanks for the answer > >> > >> About the example you said, is it usable for Cubietruck?? I should try a > >> simple example bare-metal on it. > >> > >> Can you help me? > >> > >> Thanks > >> > >> 2016-10-13 20:52 GMT+02:00 Siarhei Siamashka >> >: > >> > >>> On Wed, 12 Oct 2016 14:45:01 -0700 (PDT) > >>> dlbp wrote: > >>> > >>> > Hello! > >>> > I'm using a cubietruck and because i Need to port an operating system > >>> > from x86 to ARM architecture, i need an example of bare metal > >>> > software for a Cubietruck (with Cortex A-7). It's good also a simple > >>> > hello world bare metal. > >>> > > >>> > It is very important! > >>> > > >>> > Thanks in advance > >>> > >>> Hello, > >>> > >>> You can check the uart0-helloworld-sdboot.c code from sunxi-tools: > >>> https://github.com/linux-sunxi/sunxi-tools > >>> > >>> I believe that it does exactly what you need. It uses the GPL > >>> license though. So if your operating system is proprietary, then > >>> you can't copy/paste this code directly. > >>> > >>> If your operating system is open source, then I'm quite curious > >>> to have a look at it. > >>> > >>> -- > >>> Best regards, > >>> Siarhei Siamashka > >>> Please be sure to keep the linux-sunxi mailing list in CC (I have added it back). I generally don't provide private personalized support, unless it's a paid job. If you have the mksunxiboot tool (which is one of the command line tools from U-Boot), then the makefile should produce the uart0-helloworld-sdboot.sunxi file. See more details at https://linux-sunxi.org/BROM Then you can write this uart0-helloworld-sdboot.sunxi file to the SD card in the same way as you write the U-Boot bootloader. For example the following commands will download and write a precompiled binary: wget https://github.com/linux-sunxi/sunxi-tools/raw/master/bin/uart0-helloworld-sdboot.sunxi dd if=uart0-helloworld-sdboot.sunxi of=/dev/sdX bs=1024 seek=8 Alternatively, you can load and execute this file to the device over Mini- or Micro- USB cable (after switching the device into FEL mode): sunxi-fel spl uart0-helloworld-sdboot.sunxi Using FEL boot method is typically much more convenient for development and debugging. Because you don't need to repeatedly insert/remove the SD card between your device and your card reader. I hope that this information can help you to get your secret operating system up and running on your Cubietruck :-) -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Bare metal example for cubietruck
On Wed, 12 Oct 2016 14:45:01 -0700 (PDT) dlbp wrote: > Hello! > I'm using a cubietruck and because i Need to port an operating system > from x86 to ARM architecture, i need an example of bare metal > software for a Cubietruck (with Cortex A-7). It's good also a simple > hello world bare metal. > > It is very important! > > Thanks in advance Hello, You can check the uart0-helloworld-sdboot.c code from sunxi-tools: https://github.com/linux-sunxi/sunxi-tools I believe that it does exactly what you need. It uses the GPL license though. So if your operating system is proprietary, then you can't copy/paste this code directly. If your operating system is open source, then I'm quite curious to have a look at it. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low
On Sun, 25 Sep 2016 10:19:55 +0200 Danny Milosavljevic wrote: > On Fri, 23 Sep 2016 04:03:57 +0300 > Siarhei Siamashka wrote: > > I'm not sure, but something like this might be somehow related: > > https://patchwork.kernel.org/patch/7960811/ > > > > As a random thing to check, I would also advise to verify the > > pull-up/pull-down settings for the SCLK pin. > > Where are they in mainline? The device tree file sun7i-a20.dtsi says > SUN4I_PINCTRL_NO_PULL for spi2_pins_a - but do you mean more > up-to-date runtime information? Yes, you can check the exact pin settings by reading hardware registers. Or by using the sunxi-pio tool from https://github.com/linux-sunxi/sunxi-tools > > And maybe as another test, change the driver to automatically > > drive the SSEL pin instead of doing this manually. > > What should I change exactly? "Patching the driver (again, only as a troubleshooting experiment) should be relatively easy: the code that changes the CS pin state just needs to be commented out and the manual mode disabled." > I see that the patch changed it to manual slave selection - > I can try to revert that one. Still you can first try to just experiment with the SCLK and SSEL pins alone via GPIO, even without SPI. Try to assert the SSEL pin and check what happens to the SCLK pin. You can also have a look at the schematics of your slave device. I suspect that there might be a pull-down resistor on the SCLK line. You mentioned that the polarity settings are somewhat unusual. Maybe the slave device expects the SCLK line to be initially low? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low
On Fri, 23 Sep 2016 10:48:11 +0300 Maxime Ripard wrote: > On Fri, Sep 23, 2016 at 04:03:57AM +0300, Siarhei Siamashka wrote: > > On Thu, 22 Sep 2016 23:52:52 +0200 > > Danny Milosavljevic wrote: > > > > > Hello, > > > > > > when using SPI on Allwinner A20 with CPOL=1 and CPHA=1 with Linux > > > 4.8.0-rc6 Psychotic Stoned Sheep I see a weird dip in the beginning > > > (which also confuses the slave) on the SCLK line right when SSEL goes low > > > - see attachment. > > > > > > The lines are, starting from the top, SCLK MOSI MISO SSEL. > > > > > > I'm using spidev. > > > > > > Did anyone see this problem before? > > > > Hi, > > > > I'm not sure, but something like this might be somehow related: > > https://patchwork.kernel.org/patch/7960811/ > > > > As a random thing to check, I would also advise to verify the > > pull-up/pull-down settings for the SCLK pin. > > > > And maybe as another test, change the driver to automatically > > drive the SSEL pin instead of doing this manually. > > We cannot do that Well, of course we can do that. At least for the troubleshooting purposes. And it's somewhat better than giving up and just going to cry in a corner ;-) > this would break the framework's expectations with > the behaviour you're suposed to have in set_cs (which is why we ended > up using the manual mode), and especially that it's supposed to happen > right away and control the logical level of the CS line. My understanding is that the framework is probably designed this way in order to be able to use any *arbitrary* GPIO pin for the chip select role. But the SPI controller itself can take care of the *dedicated* chip select pin and assert/deassert it before/after doing SPI message transfers. Patching the driver (again, only as a troubleshooting experiment) should be relatively easy: the code that changes the CS pin state just needs to be commented out and the manual mode disabled. My random guess about what might be happening is the following: The SoC has a weak pull-up for the SCLK pin. And the slave device has this pin in a high impedance state when the chip select pin is deasserted. But after the SPI driver manually asserts the chip select pin, the slave device probably changes the SCLK pin to a strong pull-down state, overpowering the SoC pull-up for a while. Then the SPI message transfer gets started by the SPI driver and the SPI controller starts driving the SCLK pin for real. Again, this is only a random guess and it definitely needs to be verified. Only Danny is lucky enough to have the right tools and a perfectly reproducible test case. We can think about a proper fix (compatible with the framework expectations) after we figure out what is actually going on. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC 0/2] A33 SPI support
Hello Karsten, On Sun, 4 Sep 2016 18:53:13 +0200 Karsten Merker wrote: > Hello everybody, > > during the mainlining discussion in the Olimex blog at > https://olimex.wordpress.com/2016/08/30/free-electrons-add-mainline-linux-kernel-support-for-the-a13-allwinner-vpu/#comments > the topic of A33 SPI support came up. Chen-Yu and Siarhei have > pointed out that the chances are good that the A33 can work with > the already existing SPI drivers and that simply nobody has taken > a look at those in the context of the A33 yet - so I have taken > that as an inspiration to take a look :-). Yes, probably nobody just had an A33 board with SPI pins on an expansion header. The A33 SoC is primarily used in tablets. > From the description in the docs published by Allwinner, the > A23/A33 SPI controller is clearly derived from the one in the > A31, but it is not completely identical. The biggest difference > is that the RX and TX FIFOs on the A23/A33 are only 64 Bytes deep > while they are 128 Bytes deep on the A31. Documentation source: > > Page 463 of the A33 manual: > https://github.com/allwinner-zh/documents/raw/master/A33/A33%20user%20manual%20release%201.1.pdf > > Page 889 of the A31 manual: > https://github.com/allwinner-zh/documents/raw/master/A31/A31_User_Manual_v1.3_20150510.pdf > > The current spi-sun6i driver hardcodes the FIFO depth to 128 > Bytes, so that needs to be changed depending on the SoC type. > > Another difference is an additional configuration option > influencing the signal sampling on the A23/A33. This is handled > by bit 13 of the SPI_INTCTL register. The description states: > > "Master Sample Data Mode >1-Normal Sample Mode >0-Delay Sample Mode >In Normal Sample Mode,SPI Master samples the data at >the correct edge for each SPI mode. >In Delay Sample Mode,SPI master samples data at the >edge that is half cycle delayed by the correct edge defined >in respective SPI mode." > > The manual states that "Delay Sample Mode" is the default, which > sounds a bit strange to me. Can somebody with a deeper knowledge > of SPI comment on that? > > There are some additional test modes on the A23/33 compared to the A31, > but those should be irrelevant for normal operations. > > Following are two RFC patches based on Maxime Ripard's sunxi/for-next > branch at > > > https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next > > that modify the spi-sun6i driver to handle different FIFO depths and add the > relevant nodes (clock, pinctrl, spi0 controller) to the A23/A33 dtsi files. > Please note that this is largely untested as I currently don't have any > A23/A33 hardware (an A33 board is on the way to me but will probably take > some time to arrive). All I can say at the moment is that the code > compiles. I would apprechiate very much if people could take a look at it > and provide feedback, and if somebody has appropriate hardware, I would > welcome very much if you could subject the code to some practical tests. Well, basically it is really difficult to get people interested in spending their time to look at this code at this point :-) Please first test it on real hardware when the hardware arrives. And then submit patches to the appropriate mailing list. > Btw, while checking the docs I have stumbled over one thing that strikes me > as rather strange: the A23/A33 has two SPI controllers (SPI0 and SPI1), but > there is no documented pinmux that makes SPI1 available on any pins, so SPI1 > appears to be completely useless? > > Regards, > Karsten > > > Karsten Merker (2): > spi: sunxi: Add Allwinner A23/A33 support to spi-sun6i > ARM: dts: sun8i: Add SPI support to the Allwinner A23/A33 dtsi. > > .../devicetree/bindings/spi/spi-sun6i.txt | 6 ++- > arch/arm/boot/dts/sun8i-a23-a33.dtsi | 38 +++ > arch/arm/boot/dts/sun8i-a23.dtsi | 12 ++ > arch/arm/boot/dts/sun8i-a33.dtsi | 12 ++ > drivers/spi/spi-sun6i.c| 43 > +++--- > 5 files changed, 103 insertions(+), 8 deletions(-) > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] SPI in Linux 4.8.0-rc6: Weird dip in SCLK right when slave select goes low
On Thu, 22 Sep 2016 23:52:52 +0200 Danny Milosavljevic wrote: > Hello, > > when using SPI on Allwinner A20 with CPOL=1 and CPHA=1 with Linux 4.8.0-rc6 > Psychotic Stoned Sheep I see a weird dip in the beginning (which also > confuses the slave) on the SCLK line right when SSEL goes low - see > attachment. > > The lines are, starting from the top, SCLK MOSI MISO SSEL. > > I'm using spidev. > > Did anyone see this problem before? Hi, I'm not sure, but something like this might be somehow related: https://patchwork.kernel.org/patch/7960811/ As a random thing to check, I would also advise to verify the pull-up/pull-down settings for the SCLK pin. And maybe as another test, change the driver to automatically drive the SSEL pin instead of doing this manually. Also try to contact the author of the SPI driver via the mainline kernel mailing list. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64
On Mon, 19 Sep 2016 09:07:39 -0700 (PDT) TsvetanUsunov wrote: > Hi, > > We make our final touch of A64-OLinuXino PCB and there we add option eMMC > Flash to work on dual voltages 1.8V and 3.3V. > The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that when > A64 boots and AXP803 is not initialized it outputs default 0.8V then after > initialization driver takes care to drive it 1.8V or 3.3V. > This makes impossible to boot from eMMC which is not good. We now think for > solution which to drive eMMC at 3.3V initially when AXP803 output is below > 1.8V but this adds unnecessary hardware complexity. > For hardware point of view it will be much more simplier if dedigated A64 > GPIO is used and initially is pulled down and after AXP803 is initialized > is pulled up. > How would you suggest us to implement it? Will this additional GPIO create > troubles in eMMC driver philosophy? > For the SDMMC we are still hesitating what to do as we don't know if the > card which will be inserted will support low voltage and higher speeds at > all. Also eMMC Flash and SDMMC card should be driven by separate voltages, > as they may work in any combinations. > This means we need another AXP803 LDO and another GPIO for the SDMMC card. > > By the way the current eMMC from Micron we use has 11MB Write speed no > matter what is the voltage and this is written in the datasheet, so maybe > we should switch and add this dual voltage to the SD MMC where someone > could use SD MMC card supporting higher clocks? > > I would love to hear your opinion. Hi, I have only skimmed through the JEDEC MMC standard, but got an impression that it is perfectly safe to run dual voltage cards at 1.8V voltage all the time. At least that's how I'm interpreting the first and the last paragraphs of the "7.4.2 Operating voltage range validation" section of the JESD84-A44 MMC Version 4.4 standard. Basically, it looks like when you are running with the 1.8V voltage, you can do everything that is possible with 3.3V and it just additionally allows higher speed modes (HS200). Presumably also consuming less power. The init sequence also involves starting the card with 3.3V. Then doing the voltage negotiation. Then powering the card off, switching to 1.8V and basically repeating the same steps. But if the card is 1.8V capable, then the initial negotiation step looks redundant. It can also run at 1.8V instead of 3.3V without affecting anything. Thus it seems to be a ridiculous idea to implement the runtime 1.8V/3.3V voltage switching for a dual voltage capable eMMC chip that is soldered to the PCB. You can probably just connect it to a fixed 1.8V voltage regulator and be done with that. The voltage switching and negotiation seems to be only useful for removable SD cards, where you don't have any idea if the connected SD card actually supports 1.8V or not. But I'm not an eMMC expert, so please correct me if I got everything wrong. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Flashing NAND on SinA33
On Thu, 8 Sep 2016 03:06:55 -0700 (PDT) Ciprian Manea wrote: > BLOKS.de cares about Allwinner's U-boot! ;) > > So I tried the latest U-boot, configuring it using > *Sinlinx_SinA33_defconfig.* > Then I used this how-to web page https://linux-sunxi.org/Bootable_SD_card > to prepare SinA33 nand and write the u-boot-spl & u-boot. > Doing: > # dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=1 > # dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8 This looks like you are doing it right. > Got the following error at boot time: > *U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) > DRAM: 1024 MiB > Trying to boot from MMC2 Looks like the SPL is able to identify the right boot source. > MMC Device 1 not found spl: could not find mmc But something goes wrong here. > device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### > Please RESET the board ###* > > The I tried with *sunxi-spl.bin *and *u-boot.bin * > # dd if=spl/sunxi-spl.bin of=/dev/mmcblk1 bs=1024 seek=8 > # dd if=u-boot.bin of=/dev/mmcblk1 bs=1024 seek=32 > > But I got the same errors! > > > Am I missing any steps in between? It looks like there is some bug in U-Boot. Please try to check who is the maintainer of the SinA33 board in the mainline U-Boot. Then send a bugreport to the mainline U-Boot mailing, also adding the board maintainer to CC. And please do it *fast* because the time is running out. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Flashing NAND on SinA33
On Tue, 6 Sep 2016 18:24:28 +0800 Chen-Yu Tsai wrote: > On Tue, Sep 6, 2016 at 6:20 PM, Siarhei Siamashka > wrote: > > Hi, > > > > On Tue, 6 Sep 2016 02:51:29 -0700 (PDT) > > Ciprian Manea wrote: > > > >> Hi, > >> > >> I'm using the Sina33 dev board and as the wiki page says, it has a 4GB > >> eMMC (Toshiba THGBM5G5A1JBAIR). I'm trying to flash and boot a custom made > >> debian based Linux image from the eMMC at the moment. > >> I'm able to boot this image from the SD card, but no luck so far with > >> booting from the eMMC. > >> > >> What I did and got so far is trying to > >> follow https://linux-sunxi.org/Bootable_SD_card and flash the eMMC while > >> booted from the SD card: > >> > >> 1. *# mkfs.ext4 /dev/mmcblk1* > >> > >> > >> *root@sina33:~# cat /proc/partitions major minor #blocks name 179 > >> 0 30183936 mmcblk0 17918209408 mmcblk0p1 1798 > >> 3866624 mmcblk1 179 24 2048 mmcblk1boot1 179 16 > >> 2048 mmcblk1boot0I don't understand why the boot partitions are not > >> wiped.* > > > > That's because boot partitions are separate block devices. > > > > The whole idea of having boot partitions is that with eMMC you can have > > your bootloader/firmware in its own special place, which is not sharing > > the same block device with your primary storage media /dev/mmcblk1 > > So that it's more difficult to accidentally (or maliciously) corrupt > > your fiwmware. And also you can have proper GPT partitioning without > > the bootloader special areas getting in the way. > > > > > >> 2. *# root@sina33:~# fdisk -l* > >> > >> > >> *Disk /dev/mmcblk0: 28.8 GiB, 30908350464 bytes, 60367872 sectorsUnits: > >> sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / > >> 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: > >> dosDisk identifier: 0x6706f5d0Device Boot Start End Sectors > >> Size Id Type/dev/mmcblk0p1 2048 16420863 16418816 7.8G 83 LinuxDisk > >> /dev/mmcblk1: 3.7 GiB, 3959422976 bytes, 7733248 sectorsUnits: sectors of 1 > >> * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O > >> size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mmcblk1boot1: 2 MiB, > >> 2097152 bytes, 4096 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size > >> (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 > >> bytes / 512 bytesDisk /dev/mmcblk1boot0: 2 MiB, 2097152 bytes, 4096 > >> sectorsUnits: sectors of 1 * 512 = 512 bytesSector size (logical/physical): > >> 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytes* > >> > >> > >> 3. *# dd if=sdcard-sina33.img of=/dev/mmcblk1 bs=1M* > >> *( The SD-card bootable image)* > >> > >> > >> 4.* # root@sina33:~# fdisk -l* > >> > >> > >> *Disk /dev/mmcblk0: 28.8 GiB, 30908350464 bytes, 60367872 sectorsUnits: > >> sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / > >> 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: > >> dosDisk identifier: 0x6706f5d0Device Boot Start End Sectors > >> Size Id Type/dev/mmcblk0p1 2048 16420863 16418816 7.8G 83 LinuxDisk > >> /dev/mmcblk1: 3.7 GiB, 3959422976 bytes, 7733248 sectorsUnits: sectors of 1 > >> * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O > >> size (minimum/optimal): 512 bytes / 512 bytesDisklabel type: dosDisk > >> identifier: 0x6706f5d0Device Boot Start End Sectors Size Id > >> Type/dev/mmcblk1p1 2048 4194303 4192256 2G 83 LinuxDisk > >> /dev/mmcblk1boot1: 2 MiB, 2097152 bytes, 4096 sectorsUnits: sectors of 1 * > >> 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O > >> size (minimum/optimal): 512 bytes / 512 bytesDisk /dev/mmcblk1boot0: 2 MiB, > >> 2097152 bytes, 4096 sectorsUnits: sectors of 1 * 512 = 512 bytesSector size > >> (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 > >> bytes / 512 bytes* > >> > >> > >> 5. Trying to boot without an sdcard connected > >> > >> > >> *�` 08x x �|> � �HELLO! BOOT0 is starting!boot0 version : > >> 3.1.0reg_addr 0x01f00100 =0xreg_addr 0x01f00104 =0xreg_addr > >> 0x01f00108 =0x
Re: [linux-sunxi] Flashing NAND on SinA33
On Tue, 6 Sep 2016 06:09:13 -0700 (PDT) Ciprian Manea wrote: > So I zeroed the 2 boot partitions! > > Then I used mkfs.ext4 command for /dev/mmcblk1 ( eMMC is mounted like that > ) > *root@sina33:~# mkfs.ext4 /dev/mmcblk1* > *mke2fs 1.43.1 (08-Jun-2016)* > *Found a dos partition table in /dev/mmcblk1* > *Proceed anyway? (y,n) y* > *Discarding device blocks: done* > *Creating filesystem with 966656 4k blocks and 241920 inodes* > *Filesystem UUID: 0781019c-2095-4f9f-ac5b-5be68d807d63* > *Superblock backups stored on blocks: * > * 32768, 98304, 163840, 229376, 294912, 819200, 884736* > > *Allocating group tables: done* > *Writing inode tables: done* > *Creating journal (16384 blocks): done* > *Writing superblocks and filesystem accounting information: done* > > Then I dd-ed the sdcard image on the /dev/mmcblk1: > *dd if=sdcard-sina33.img of=/dev/mmcblk1 bs=1M* > > But now, when I'm trying to boot from the nand, I get the following: > > > * U-Boot SPL 2015.07-rc2-00119-g32c5be7 (Jun 14 2016 - 10:57:02) > DRAM: 1024 MiB This is already a lot better. It means that you get your bootloader loaded instead of boot0. Now it's only a matter to make it work right. > Card did not respond to voltage select! > Could not determine boot source > > * resetting ... * > > And is resetting over and over again! > The thing is that this is the u-boot built by me (which is working for > booting from the sd-card), but why the error messages? > What's going wrong there ? You get the SPL part successfully loaded by the boot ROM into the SRAM. Then the SPL tries to load the rest of the U-Boot code into the DRAM but fails to find and read it from your storage media. Please try the latest U-Boot from git. It is about to be released as v2016.09 in a week and you have a good chance to make sure that it works perfectly for you. There were recent changes, which rework the boot source detection a bit: http://git.denx.de/?p=u-boot.git;a=commit;h=b19236fd1c1ef289bab9e243ee5b50d658fcac3f http://git.denx.de/?p=u-boot.git;a=commit;h=9acebe8a18788c5a0d7b154e812cf2d9dfbab68f http://git.denx.de/?p=u-boot.git;a=commit;h=ef36d9ae1646e5aee7c1425ee507d275699a072e There is no guarantee that it will work and I don't have the same board as you. But if there are any problems left, they should not be very difficult to fix. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Flashing NAND on SinA33
.Jump to > Fel.* > > > *What am I missing here ? Why can't I wipe the 2 *boot partitions? Should I > write the U-Boot & U-Boot SPL to one of those ?* If you want to use the eMMC in an sdcard-alike way and have your bootloader on /dev/mmcblk1, then you can try to erase the content of the boot partitions. Or you can try to use eMMC boot partitions for your own bootloader. The U-Boot bootloader is not quite ready for this though and may need some fixes (it needs to differentiate booting from the eMMC boot partitions and booting from the eMMC data area). There are special magic codes for the boot media type returned by the boot ROM: https://irclog.whitequark.org/linux-sunxi/2016-06-11#16717168; -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One
On Thu, 30 Jun 2016 13:13:48 +0200 Michal Suchanek wrote: > Hello, > > On 25 June 2016 at 05:45, wrote: > > From: Ondrej Jirman > > > > Use Xulong Orange Pi One GPIO based regulator for > > passive cooling and thermal management. > > > > Signed-off-by: Ondrej Jirman > > --- > > arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 > > + > > 1 file changed, 39 insertions(+) > > > > diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts > > b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts > > index b1bd6b0..a38d871 100644 > > --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts > > +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts > > @@ -109,6 +109,45 @@ > > }; > > }; > > > > +&cpu0 { > > + operating-points = < > > + /* kHzuV */ > > + 1296000 130 > > + 120 130 > > First problem is that the board boots at 1008000 which is not listed > and the kernel complains. > > Second problem is that the board locks up during boot with this enabled. > > Do you have some suggestion for alternate configuration to test? Maybe try the Allwinner's original DVFS table instead of these undervolted values and see if it helps? https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC&oldid=17753#CPU_clock_speed_limit While undervolting is tempting because it helps to decrease the SoC temperature and avoid throttling, different units may have different tolerances and one needs to be very careful when picking defaults that are intended to work correctly on all boards. Some safety headroom exists there for a reason. If I remember correctly, some people pushed for undervolting experiments at least twice in the past (on the Banana Pi and C.H.I.P.). In both cases this did not end up well and had to be fixed later to solve reliability problems. In order to allow individual per-unit tuning, a concept of "speed grading" may be probably introduced later. So that the board is tested for reliability and then the speed grade rating is stored somewhere on the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC manufacturers, such as Samsung, are already doing this with their chips. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash
On Thu, 9 Jun 2016 19:42:55 -0700 Simon Glass wrote: > Hi, > > On 9 June 2016 at 18:33, Siarhei Siamashka > wrote: > > Hi Simon, > > > > On Thu, 9 Jun 2016 17:36:10 -0700 > > Simon Glass wrote: > > > >> Hi, > >> > >> On 7 June 2016 at 05:28, Siarhei Siamashka > >> wrote: > >> > Allwinner devices support SPI flash as one of the possible > >> > bootable media type. The SPI flash chip needs to be connected > >> > to SPI0 pins (port C) to make this work. More information is > >> > available at: > >> > > >> > https://linux-sunxi.org/Bootable_SPI_flash > >> > > >> > This patch adds the initial support for booting from SPI flash. > >> > The existing SPI frameworks are not used in order to reduce the > >> > SPL code size. Right now the SPL size grows by ~370 bytes when > >> > CONFIG_SPL_SPI_SUNXI option is enabled. > >> > > >> > While there are no popular Allwinner devices with SPI flash at > >> > the moment, testing can be done using a SPI flash module (it > >> > can be bought for ~2$ on ebay) and jumper wires with the boards, > >> > which expose relevant pins on the expansion header. The SPI flash > >> > chips themselves are very cheap (some prices are even listed as > >> > low as 4 cents) and should not cost much if somebody decides to > >> > design a development board with an SPI flash chip soldered on > >> > the PCB. > >> > > >> > Another nice feature of the SPI flash is that it can be safely > >> > accessed in a device-independent way (since we know that the > >> > boot ROM is already probing these pins during the boot time). > >> > And if, for example, Olimex boards opted to use SPI flash instead > >> > of EEPROM, then they would have been able to have U-Boot installed > >> > in the SPI flash now and boot the rest of the system from the SATA > >> > hard drive. Hopefully we may see new interesting Allwinner based > >> > development boards in the future, now that the software support > >> > for the SPI flash is in a better shape :-) > >> > > >> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option > >> > in a board defconfig, then building U-Boot and finally flashing > >> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with > >> > a help of the sunxi-fel tool: > >> > > >> >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin > >> > > >> > The device needs to be switched into FEL (USB recovery) mode first. > >> > The most suitable boards for testing are Orange Pi PC and Pine64. > >> > Because these boards are cheap, have no built-in NAND/eMMC and > >> > expose SPI0 pins on the Raspberry Pi compatible expansion header. > >> > The A13-OLinuXino-Micro board also can be used. > >> > > >> > Signed-off-by: Siarhei Siamashka > >> > --- > >> > > >> > Changes in v2: > >> > - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash > >> >support code into a separate source file > >> > - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant > >> > - Deinitialize the SPI controller and undo pin muxing after the job > >> >is done > >> > - Size reduction of the SPI transfer function > >> > - Add delay after each SPI transfer to ensure that the chip select > >> >deassert timing requirements (tSHSL) are always satisfied > >> > - More comments in the code > >> > > >> > > >> > arch/arm/include/asm/arch-sunxi/gpio.h | 3 + > >> > arch/arm/mach-sunxi/board.c| 5 + > >> > common/spl/spl.c | 4 +- > >> > drivers/mtd/spi/Kconfig| 12 ++ > >> > drivers/mtd/spi/Makefile | 1 + > >> > drivers/mtd/spi/sunxi_spi_spl.c| 283 > >> > + > >> > include/configs/sunxi-common.h | 5 + > >> > 7 files changed, 311 insertions(+), 2 deletions(-) > >> > create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c > >> > >> Shouldn't this be a normal SPI driver? Then you could put this in > >> common/spl/spl_spi.c. > > > > This source file contains both a sunxi SPI controller support and a > > basic SPI flash
[linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash
Hi Simon, On Thu, 9 Jun 2016 17:36:10 -0700 Simon Glass wrote: > Hi, > > On 7 June 2016 at 05:28, Siarhei Siamashka > wrote: > > Allwinner devices support SPI flash as one of the possible > > bootable media type. The SPI flash chip needs to be connected > > to SPI0 pins (port C) to make this work. More information is > > available at: > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > This patch adds the initial support for booting from SPI flash. > > The existing SPI frameworks are not used in order to reduce the > > SPL code size. Right now the SPL size grows by ~370 bytes when > > CONFIG_SPL_SPI_SUNXI option is enabled. > > > > While there are no popular Allwinner devices with SPI flash at > > the moment, testing can be done using a SPI flash module (it > > can be bought for ~2$ on ebay) and jumper wires with the boards, > > which expose relevant pins on the expansion header. The SPI flash > > chips themselves are very cheap (some prices are even listed as > > low as 4 cents) and should not cost much if somebody decides to > > design a development board with an SPI flash chip soldered on > > the PCB. > > > > Another nice feature of the SPI flash is that it can be safely > > accessed in a device-independent way (since we know that the > > boot ROM is already probing these pins during the boot time). > > And if, for example, Olimex boards opted to use SPI flash instead > > of EEPROM, then they would have been able to have U-Boot installed > > in the SPI flash now and boot the rest of the system from the SATA > > hard drive. Hopefully we may see new interesting Allwinner based > > development boards in the future, now that the software support > > for the SPI flash is in a better shape :-) > > > > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option > > in a board defconfig, then building U-Boot and finally flashing > > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with > > a help of the sunxi-fel tool: > > > >sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin > > > > The device needs to be switched into FEL (USB recovery) mode first. > > The most suitable boards for testing are Orange Pi PC and Pine64. > > Because these boards are cheap, have no built-in NAND/eMMC and > > expose SPI0 pins on the Raspberry Pi compatible expansion header. > > The A13-OLinuXino-Micro board also can be used. > > > > Signed-off-by: Siarhei Siamashka > > --- > > > > Changes in v2: > > - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash > >support code into a separate source file > > - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant > > - Deinitialize the SPI controller and undo pin muxing after the job > >is done > > - Size reduction of the SPI transfer function > > - Add delay after each SPI transfer to ensure that the chip select > >deassert timing requirements (tSHSL) are always satisfied > > - More comments in the code > > > > > > arch/arm/include/asm/arch-sunxi/gpio.h | 3 + > > arch/arm/mach-sunxi/board.c| 5 + > > common/spl/spl.c | 4 +- > > drivers/mtd/spi/Kconfig| 12 ++ > > drivers/mtd/spi/Makefile | 1 + > > drivers/mtd/spi/sunxi_spi_spl.c| 283 > > + > > include/configs/sunxi-common.h | 5 + > > 7 files changed, 311 insertions(+), 2 deletions(-) > > create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c > > Shouldn't this be a normal SPI driver? Then you could put this in > common/spl/spl_spi.c. This source file contains both a sunxi SPI controller support and a basic SPI flash read functionality glued together for size reduction purposes. We are interested in implementing the "spl_spi_load_image()" function, because this is what gets called when handling the BOOT_DEVICE_SPI case. The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file, which implements this particular function with the help of the generic SPI flash support code from "spi_flash.c" and the generic SPI bus support provided by the code from the "drivers/spi" directory. What I'm doing in this patch is an implementation of a size reduced sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper (where the code size is not a problem anymore) we will need a real sunxi SPI driver. -- Regards, Sierž -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Wed, 1 Jun 2016 14:54:24 +0200 Boris Brezillon wrote: > On Wed, 1 Jun 2016 14:41:36 +0300 > Siarhei Siamashka wrote: > > > On Mon, 30 May 2016 19:02:13 +0200 > > Boris Brezillon wrote: > > > > > On Mon, 30 May 2016 19:46:17 +0300 > > > Siarhei Siamashka wrote: > > > > > > > On Mon, 30 May 2016 17:24:16 +0200 > > > > Boris Brezillon wrote: > > > > > > > > > Hi Hans, > > > > > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > > > Boris Brezillon wrote: > > > > > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > > > creation since the mainline driver is not supporting the funky > > > > > > layout > > > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > > > partitions > > > > > > so that they can be flashed before soldering on the NAND on the > > > > > > board > > > > > > (using a regular NAND programmer). > > > > > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > > > expected by the NAND controller, and re-arranging the ECC/data > > > > > > sections > > > > > > correctly. > > > > > > > > > > Don't know how you want to proceed regarding NAND SPL image creation > > > > > in > > > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > > > installed on his build platform. > > > > > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > > > image suitable for MLC NANDs. > > > > > > > > Hi, > > > > > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > > > boot support at the moment. And some information about the progress is > > > > available here: > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > > > > > IMHO one of the most important requirements is to ensure that the device > > > > can be always unbricked by the end users in a very simple way. That's > > > > why I have added the SPI flash programming feature to the sunxi-fel > > > > tool and it is available in a wip branch since about a week ago: > > > > > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > > > > > There is still some work left to do. For example, just having SPI > > > > flash read/write functionality (which already works btw) is not > > > > good enough because it is not sufficiently foolproof. There will > > > > be a dedicated high level "spiflash-program" commmand to flash > > > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > > > We had discussed this a bit on the IRC earlier: > > > > > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > > > image to automatically add some redundancy (two copies of the SPL): > > > > > > > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > > > And also pass some information about the SPI flash type via the SPL > > > > header (for example, the single/dual SPI mode, the maximum SPI clock > > > > speed, etc.). So that the SPL can use this information directly > > > > without any need to have extra code bloat responsible for doing > > > > runtime discovery of all these parameters. > > > > > > > > But the most important foolproof feature would be of course a warning > > > > "You are trying to flash a firmware for an incompatible board, are > > > > you really sure?" :-) Later we can also have digital signatures > > > > verification built into the sunxi-fel, and other nice things. > > > > > > >
Re: [linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash
Hello, On Wed, 8 Jun 2016 02:56:41 -0700 (PDT) boob...@gmail.com wrote: > Hello > > Nice to see new entry to boot. > I would like to know if sdcard wired in spi mode can working with > this spi boot support. No, it can't. The SPI protocol used by the SD card is different from the SPI protocol used by the SPI flash chips. The SPI is just an underlying bus to send and receive data, but the higher level protocols are incompatible. > Why put sdcard in spi when i have an sdcard slot? :) > Just to solder it for bypass crappy sdcard socket pin contact You can still solder the SD card instead of plugging it into the SD card slot. In fact, that's how it is usually done with eMMC. And you can even buy some development boards with eMMC instead of experimenting with this stuff yourself. > then boot from usb. > microsd was cheap in 512mb size or less. The price difference between the Orange Pi PC and the Orange Pi PC Plus boards is not very big: http://www.aliexpress.com/store/product/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32448079125.html http://www.aliexpress.com/store/product/Orange-Pi-PC-Plus-ubuntu-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32668618847.html For extra 4.45 EUR you get a 8GB eMMC and also some sort of WiFi. And the eMMC is also much faster than a regular SD card, so it's not a very bad deal. > Is there limitation in chip memory selection? Any SPI flash chip should be supported if it uses the right voltage (compatible with 3.3V) and supports the Read Data Bytes command (the opcode 0x03, followed by a 24-bit address). You can always check the datasheet. A suitable SPI flash chip, which seems to cost only 4 cents, is sold here: http://www.aliexpress.com/item/W25Q16BVSSIG-W25Q16BVSIG-2MB-SOP8/32660083443.html But I have no idea if this particular seller is trustworthy. One can still easily find similar chips for around 10 cents in other places. The SPI flash is cheaper than the eMMC if we look at the absolute price. But the price per megabyte is an entirely different story. For U-Boot you would need a 1 MiB (8 Mbit) chip, just check the size of the u-boot-sunxi-with-spl.bin file and ensure a bit of extra headroom. > Anyway thank for new support Thanks. -- Regards, Sierž -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v2] sunxi: Support booting from SPI flash
Allwinner devices support SPI flash as one of the possible bootable media type. The SPI flash chip needs to be connected to SPI0 pins (port C) to make this work. More information is available at: https://linux-sunxi.org/Bootable_SPI_flash This patch adds the initial support for booting from SPI flash. The existing SPI frameworks are not used in order to reduce the SPL code size. Right now the SPL size grows by ~370 bytes when CONFIG_SPL_SPI_SUNXI option is enabled. While there are no popular Allwinner devices with SPI flash at the moment, testing can be done using a SPI flash module (it can be bought for ~2$ on ebay) and jumper wires with the boards, which expose relevant pins on the expansion header. The SPI flash chips themselves are very cheap (some prices are even listed as low as 4 cents) and should not cost much if somebody decides to design a development board with an SPI flash chip soldered on the PCB. Another nice feature of the SPI flash is that it can be safely accessed in a device-independent way (since we know that the boot ROM is already probing these pins during the boot time). And if, for example, Olimex boards opted to use SPI flash instead of EEPROM, then they would have been able to have U-Boot installed in the SPI flash now and boot the rest of the system from the SATA hard drive. Hopefully we may see new interesting Allwinner based development boards in the future, now that the software support for the SPI flash is in a better shape :-) Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option in a board defconfig, then building U-Boot and finally flashing the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with a help of the sunxi-fel tool: sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin The device needs to be switched into FEL (USB recovery) mode first. The most suitable boards for testing are Orange Pi PC and Pine64. Because these boards are cheap, have no built-in NAND/eMMC and expose SPI0 pins on the Raspberry Pi compatible expansion header. The A13-OLinuXino-Micro board also can be used. Signed-off-by: Siarhei Siamashka --- Changes in v2: - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash support code into a separate source file - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant - Deinitialize the SPI controller and undo pin muxing after the job is done - Size reduction of the SPI transfer function - Add delay after each SPI transfer to ensure that the chip select deassert timing requirements (tSHSL) are always satisfied - More comments in the code arch/arm/include/asm/arch-sunxi/gpio.h | 3 + arch/arm/mach-sunxi/board.c| 5 + common/spl/spl.c | 4 +- drivers/mtd/spi/Kconfig| 12 ++ drivers/mtd/spi/Makefile | 1 + drivers/mtd/spi/sunxi_spi_spl.c| 283 + include/configs/sunxi-common.h | 5 + 7 files changed, 311 insertions(+), 2 deletions(-) create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h index 1ace548..bff7d14 100644 --- a/arch/arm/include/asm/arch-sunxi/gpio.h +++ b/arch/arm/include/asm/arch-sunxi/gpio.h @@ -141,6 +141,7 @@ enum sunxi_gpio_number { /* GPIO pin function config */ #define SUNXI_GPIO_INPUT 0 #define SUNXI_GPIO_OUTPUT 1 +#define SUNXI_GPIO_DISABLE 7 #define SUNXI_GPA_EMAC 2 #define SUN6I_GPA_GMAC 2 @@ -162,8 +163,10 @@ enum sunxi_gpio_number { #define SUN50I_GPB_UART0 4 #define SUNXI_GPC_NAND 2 +#define SUNXI_GPC_SPI0 3 #define SUNXI_GPC_SDC2 3 #define SUN6I_GPC_SDC3 4 +#define SUN50I_GPC_SPI04 #define SUN8I_GPD_SDC1 3 #define SUNXI_GPD_LCD0 2 diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index bd15b9b..025df4d 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -223,6 +223,11 @@ u32 spl_boot_device(void) if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */ return BOOT_DEVICE_BOARD; +#ifdef CONFIG_SPL_SPI_SUNXI + if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_SPI) + return BOOT_DEVICE_SPI; +#endif + /* The BROM will try to boot from mmc0 first, so try that first. */ #ifdef CONFIG_MMC mmc_initialize(gd->bd); diff --git a/common/spl/spl.c b/common/spl/spl.c index c8dfc14..d49ce2b 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -265,7 +265,7 @@ struct boot_device_name boot_name_table[] = { #ifdef CONFIG_SPL_YMODEM_SUPPORT { BOOT_DEVICE_UART, "UART" }, #endif -#ifdef CONFIG_SPL_SPI_SUPPORT +#if defined(CONFIG_SPL_SPI_SUPPORT) || defined(CONFIG_SPL_SPI_FLASH_SUPPORT) { BOOT_DEVICE_SPI, "SPI" }, #endif #ifdef CONFIG_SPL_ETH_SUPPORT @@ -341,7 +341,7 @@ static int spl_load_image(u32 bo
Re: [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection
On Wed, 1 Jun 2016 13:23:24 +0200 Boris Brezillon wrote: > NAND chips are supposed to expose their capabilities through advanced > mechanisms like READID, ONFI or JEDEC parameter tables. While those > methods are appropriate for the bootloader itself, it's way to > complicated and takes too much space to fit in the SPL. > > Replace those mechanisms by a dumb 'trial and error' mechanism. > > With this new approach we can get rid of the fixed config list that was > used in the sunxi NAND SPL driver. > > Signed-off-by: Boris Brezillon > Acked-by: Hans de Goede We can also have these NAND parameters stored in the SPL header and added there by a NAND image builder tool. This may save some precious space in the SPL and also improve the reliability of detection. Yes, this brings the necessity of the image builder tool into the spotlight (something that converts the "u-boot-sunxi-with-spl.bin" to a NAND image) but this has always been a problem. We have some ongoing discussion about this in the linux-sunxi mailing list: https://groups.google.com/forum/#!topic/linux-sunxi/HsWRG-nuV-w It also makes a lot of sense to have the NAND support functionality enabled in the SPL for all sunxi boards by default, so the code size does matter. We still do have the runtime decompression opportunity as the strategic reserve [1], which should provide additional 4 or 5 KiB of space for the code. Still we need to be very careful about using up this reserve, to ensure that it is well spent on something useful (such as NAND support) instead of being just wasted by the bloatware cultists :-) [1] http://lists.denx.de/pipermail/u-boot/2015-September/226963.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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 19:02:13 +0200 Boris Brezillon wrote: > On Mon, 30 May 2016 19:46:17 +0300 > Siarhei Siamashka wrote: > > > On Mon, 30 May 2016 17:24:16 +0200 > > Boris Brezillon wrote: > > > > > Hi Hans, > > > > > > On Mon, 30 May 2016 17:12:53 +0200 > > > Boris Brezillon wrote: > > > > > > > Generating raw NAND images is particularly useful for boot0 images > > > > creation since the mainline driver is not supporting the funky layout > > > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > > > > > This tools also allows one to generate raw images for 'normal' > > > > partitions > > > > so that they can be flashed before soldering on the NAND on the board > > > > (using a regular NAND programmer). > > > > > > > > The tool takes care of generating ECC bytes and randomizing data as > > > > expected by the NAND controller, and re-arranging the ECC/data sections > > > > correctly. > > > > > > Don't know how you want to proceed regarding NAND SPL image creation in > > > u-boot. We could either copy the sunxi-nand-image-builder sources in > > > u-boot or provide a macro to pass the sunxi-tools binaries path > > > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > > > installed on his build platform. > > > > > > Note that we'll need extra padding/concatenation steps to build an SPL > > > image suitable for MLC NANDs. > > > > Hi, > > > > I guess, it is not a big secret that I'm also working on the SPI flash > > boot support at the moment. And some information about the progress is > > available here: > > > > https://linux-sunxi.org/Bootable_SPI_flash > > > > IMHO one of the most important requirements is to ensure that the device > > can be always unbricked by the end users in a very simple way. That's > > why I have added the SPI flash programming feature to the sunxi-fel > > tool and it is available in a wip branch since about a week ago: > > > > https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip > > > > There is still some work left to do. For example, just having SPI > > flash read/write functionality (which already works btw) is not > > good enough because it is not sufficiently foolproof. There will > > be a dedicated high level "spiflash-program" commmand to flash > > the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. > > We had discussed this a bit on the IRC earlier: > > > > http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; > > > > The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin > > image to automatically add some redundancy (two copies of the SPL): > > https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations > > And also pass some information about the SPI flash type via the SPL > > header (for example, the single/dual SPI mode, the maximum SPI clock > > speed, etc.). So that the SPL can use this information directly > > without any need to have extra code bloat responsible for doing > > runtime discovery of all these parameters. > > > > But the most important foolproof feature would be of course a warning > > "You are trying to flash a firmware for an incompatible board, are > > you really sure?" :-) Later we can also have digital signatures > > verification built into the sunxi-fel, and other nice things. > > > > > > Boris, I think that your NAND use case is not very much different in > > principle. You can't expect the users to desolder the NAND chip and > > use an external NAND programmer tool when they need to unbrick their > > device, right? > > > > That's absolutely not the goal of this tool. It's just here to generate > raw NAND images. Ultimately we want to have a complete solution. So that the NAND flash can be programmed both at the production line and by the end users of the devices. How many more tools do we need to achieve this goal? > Now, if there's a way to export NAND memory organization through the > SPL header, that's even better, Currently the U-Boot build system produces the u-boot-sunxi-with-spl.bin file. This file consists of the SPL part in the beginning and the main U-Boot binary (in a legacy format now, but maybe moving to FIT later). The SPL part has the 64 byte header in the beginning (the size can be increased if necessary):
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 17:24:16 +0200 Boris Brezillon wrote: > Hi Hans, > > On Mon, 30 May 2016 17:12:53 +0200 > Boris Brezillon wrote: > > > Generating raw NAND images is particularly useful for boot0 images > > creation since the mainline driver is not supporting the funky layout > > used by Allwinner's ROM code to load the boot0 binary from NAND. > > > > This tools also allows one to generate raw images for 'normal' partitions > > so that they can be flashed before soldering on the NAND on the board > > (using a regular NAND programmer). > > > > The tool takes care of generating ECC bytes and randomizing data as > > expected by the NAND controller, and re-arranging the ECC/data sections > > correctly. > > Don't know how you want to proceed regarding NAND SPL image creation in > u-boot. We could either copy the sunxi-nand-image-builder sources in > u-boot or provide a macro to pass the sunxi-tools binaries path > (SUNXI_TOOLS_PATH?) and force the user to have the sunxi-tools > installed on his build platform. > > Note that we'll need extra padding/concatenation steps to build an SPL > image suitable for MLC NANDs. Hi, I guess, it is not a big secret that I'm also working on the SPI flash boot support at the moment. And some information about the progress is available here: https://linux-sunxi.org/Bootable_SPI_flash IMHO one of the most important requirements is to ensure that the device can be always unbricked by the end users in a very simple way. That's why I have added the SPI flash programming feature to the sunxi-fel tool and it is available in a wip branch since about a week ago: https://github.com/ssvb/sunxi-tools/commits/20160523-spiflash-wip There is still some work left to do. For example, just having SPI flash read/write functionality (which already works btw) is not good enough because it is not sufficiently foolproof. There will be a dedicated high level "spiflash-program" commmand to flash the standard "u-boot-sunxi-with-spl.bin" file generated by U-Boot. We had discussed this a bit on the IRC earlier: http://irclog.whitequark.org/linux-sunxi/2016-05-13#16443894; The sunxi-fel flasher tool can modify the u-boot-sunxi-with-spl.bin image to automatically add some redundancy (two copies of the SPL): https://linux-sunxi.org/Bootable_SPI_flash#Reliability_considerations And also pass some information about the SPI flash type via the SPL header (for example, the single/dual SPI mode, the maximum SPI clock speed, etc.). So that the SPL can use this information directly without any need to have extra code bloat responsible for doing runtime discovery of all these parameters. But the most important foolproof feature would be of course a warning "You are trying to flash a firmware for an incompatible board, are you really sure?" :-) Later we can also have digital signatures verification built into the sunxi-fel, and other nice things. Boris, I think that your NAND use case is not very much different in principle. You can't expect the users to desolder the NAND chip and use an external NAND programmer tool when they need to unbrick their device, right? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images
On Mon, 30 May 2016 17:12:53 +0200 Boris Brezillon wrote: > Generating raw NAND images is particularly useful for boot0 images > creation since the mainline driver is not supporting the funky layout > used by Allwinner's ROM code to load the boot0 binary from NAND. > > This tools also allows one to generate raw images for 'normal' partitions > so that they can be flashed before soldering on the NAND on the board > (using a regular NAND programmer). > > The tool takes care of generating ECC bytes and randomizing data as > expected by the NAND controller, and re-arranging the ECC/data sections > correctly. > > Signed-off-by: Boris Brezillon > --- > Hi Siarhei, > > You seem to be the one maintaining the sunxi-tools repo, and I'm not sure > what's the process to submit patches (PR from github, or submitting > patches to the linux-sunxi ML). > > The tool I'm adding here is really useful when it comes to creating NAND > images, and I'd like to see it included in the sunxi-tools. > > Let me know if you have any questions. Hi Boris, Regarding the sunxi-tools repository maintenance, personally I'm trying my best to slack off and offload all the bureaucratic duties to Bernhard :-) About submitting patches. Yes, we used to post them to the linux-sunxi mailing list. However it did not look like anyone was interested in reviewing them there anyway. Moreover, Bernhard enabled Travis CI on github, and this allows us to at least easily prevent FTBFS bugs from landing to the repository and also to catch the cases of accidental use of the "%d" printf format modifiers for size_t variables. In the future we may also add a checkpatch.pl based check for ensuring the coding style consistency. We are only getting familiar with the github pull requests based workflow, so not everything is fully settled yet. So opening a pull request on github is welcome. One the other hand, IMHO having some discussion on the U-Boot mailing list would be useful too. You can probably post some basic information to the U-Boot mailing list (with the linux-sunxi mailing list also in CC) and provide a link to the sunxi-tools pull request in it. -- Siarhei > > Thanks, > > Boris > > Makefile |2 +- > README.md|3 + > nand-image-builder.c | 1122 > ++ > 3 files changed, 1126 insertions(+), 1 deletion(-) > create mode 100644 nand-image-builder.c > > diff --git a/Makefile b/Makefile > index 623dda1..434f084 100644 > --- a/Makefile > +++ b/Makefile > @@ -33,7 +33,7 @@ DEFINES += -D_NETBSD_SOURCE > endif > > # Tools useful on host and target > -TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > +TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part > sunxi-nand-image-builder > > # Symlinks to sunxi-fexc > FEXC_LINKS = bin2fex fex2bin > diff --git a/README.md b/README.md > index ada5432..b0d8788 100644 > --- a/README.md > +++ b/README.md > @@ -46,6 +46,9 @@ Manipulate PIO register dumps > ### sunxi-nand-part > Tool for manipulating Allwinner NAND partition tables > > +### sunxi-nand-image-builder > +Tool used to create raw NAND images (including boot0 images) > + > ### jtag-loop.sunxi > ARM native boot helper to force the SD port into JTAG and then stop, > to ease debugging of bootloaders. > diff --git a/nand-image-builder.c b/nand-image-builder.c > new file mode 100644 > index 000..f3ad03c > --- /dev/null > +++ b/nand-image-builder.c > @@ -0,0 +1,1122 @@ > +/* > + * Generic binary BCH encoding/decoding library > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 as published > by > + * the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for > + * more details. > + * > + * You should have received a copy of the GNU General Public License along > with > + * this program; if not, write to the Free Software Foundation, Inc., 51 > + * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Copyright © 2011 Parrot S.A. > + * > + * Author: Ivan Djelic > + * > + * Description: > + * > + * This library provides runtime configurable encoding/decoding of binary > + * Bose-Chaudhuri-Hocquenghem (BCH) codes. > + * > + * Call init_bch to get a pointer to a newly allocated bch_control structure > for > + * the given m (Galois field order), t (error correction capability) and > + * (optional) primitive polynomial parameters. > + * > + * Call encode_bch to compute and store ecc parity bytes to a given buffer. > + * Call decode_bch to detect and locate errors in received data. > + * > + * On systems supporting hw BCH features, intermediate results may be > provided > + * to decode_bch in order to skip certain steps.
Re: [linux-sunxi] Pine64 unreview
On Thu, 21 Apr 2016 20:50:23 +0200 Benjamin Henrion wrote: > http://hackaday.com/2016/04/21/pine64-the-un-review/ > > Sad to see all the complaints, but it is recurrent with Allwinner boards... It's recurrent with any boards. The Raspberry Pi people use censorship in their forums and just delete blatant rants. Still, the users initially want just *one* tested and known to work SD card image, a very simple tutorial and a troubleshooting FAQ. Just to make sure that the hardware is working as expected. Otherwise they tend to become nervous. Having too much poorly structured information and too many SD card images to try actually does more harm than good. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
On Thu, 21 Apr 2016 19:56:10 -0400 "jonsm...@gmail.com" wrote: > On Thu, Apr 21, 2016 at 7:45 PM, jonsm...@gmail.com > wrote: > > On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka > > wrote: > >> As for designing an A64 board, unless you really want a 64-bit > >> processor, something like Allwinner H3 might be a better choice > >> right now. At least it is currently better supported in software > >> and has more USB ports. ARM Cortex-A53 is faster than ARM Cortex-A7 > >> per MHz, but it is also more power hungry. > >> > >> Do you have any contacts at Allwinner? Probably not, because otherwise > >> you would not be asking the A64 boot sequence questions here. > > > > We require Android 5.1, not an option on H3. > > I am interested in getting AW Android running on mainline. System is > headless so there is no messing with video. Does the ordinary GNU/Linux not work good enough for this particular headless use case? Why Android? And even why specifically Android 5.1? I'm not trying to criticize your design, but you got me intrigued. Again, if you want a usable mainline kernel on A64 (let alone usable in Android), then it may take a while. I guess, Olimex and Xunlong probably have their A64 based boards ready by now, but are simply waiting for better software support before flooding the market with their hardware. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
On Thu, 21 Apr 2016 16:14:13 -0400 "jonsm...@gmail.com" wrote: > On Thu, Apr 21, 2016 at 4:09 PM, Siarhei Siamashka > wrote: > > On Thu, 21 Apr 2016 13:38:19 -0400 > > "jonsm...@gmail.com" wrote: > > > >> On Thu, Apr 21, 2016 at 1:17 PM, Siarhei Siamashka > >> wrote: > >> > Hello, > >> > > >> > On Thu, 21 Apr 2016 11:24:56 -0400 > >> > "jonsm...@gmail.com" wrote: > >> > > >> >> The manual is very sparse on this subject. Does anyone know what order > >> >> it looks at the MMC options? > >> >> > >> >> For example - MMC flash and an SD Card socket. For brick recovery it > >> >> should be possible to put in an SD Card with a proper boot sector > >> >> (right signature) and then boot from the SD Card overriding the MMC > >> >> flash. > >> > >> Thanks for info. > >> > >> > > >> > We don't have full details yet, but it looks like the boot order > >> > on Allwinner A64 is somewhat similar to > >> > https://linux-sunxi.org/Boot#A31 > >> > > >> > For example, the Jide Remix Mini device boots from the internal > >> > eMMC by default, but the user can override the boot order by > >> > pressing the FEL button: > >> > https://linux-sunxi.org/Jide_Remix_Mini#FEL_mode > >> > > >> > And if I understand it correctly, most of the Allwinner based devices > >> > (at least the ones which do not deviate from the reference schematics) > >> > are perfectly unbrickable: > >> > > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380686.html > >> > > >> > When somebody gets an A64 tablet, I strongly suspect that one of the > >> > volume control buttons is going to be connected to the FEL pin too. > >> > But we can't be 100% sure until somebody confirms this. > >> > > >> > Why are you asking this question? > >> > >> We are designing A64 board for an embedded system. > >> > >> I don't see any boot A64 jumpers for picking one of the four modes -- > >> sel[0:1] > > > > You are right. There are no UBOOT_SEL pins in the A64 datasheet. This > > probably means that there is some hardcoded boot order in the case if > > the FEL button is not pressed. But we haven't seen anything other than > > the SD card and the eMMC as a bootable media yet > > > > BTW, did you reply off-list on purpose? > > no, i just must have touched wrong reply key OK, adding the linux-sunxi mailing list back to CC :-) I have also tried to experiment a bit and added the actual A64 boot sequence information to the wiki: https://linux-sunxi.org/BROM#A64 As for designing an A64 board, unless you really want a 64-bit processor, something like Allwinner H3 might be a better choice right now. At least it is currently better supported in software and has more USB ports. ARM Cortex-A53 is faster than ARM Cortex-A7 per MHz, but it is also more power hungry. Do you have any contacts at Allwinner? Probably not, because otherwise you would not be asking the A64 boot sequence questions here. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
Hello, On Thu, 21 Apr 2016 11:24:56 -0400 "jonsm...@gmail.com" wrote: > The manual is very sparse on this subject. Does anyone know what order > it looks at the MMC options? > > For example - MMC flash and an SD Card socket. For brick recovery it > should be possible to put in an SD Card with a proper boot sector > (right signature) and then boot from the SD Card overriding the MMC > flash. We don't have full details yet, but it looks like the boot order on Allwinner A64 is somewhat similar to https://linux-sunxi.org/Boot#A31 For example, the Jide Remix Mini device boots from the internal eMMC by default, but the user can override the boot order by pressing the FEL button: https://linux-sunxi.org/Jide_Remix_Mini#FEL_mode And if I understand it correctly, most of the Allwinner based devices (at least the ones which do not deviate from the reference schematics) are perfectly unbrickable: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380686.html When somebody gets an A64 tablet, I strongly suspect that one of the volume control buttons is going to be connected to the FEL pin too. But we can't be 100% sure until somebody confirms this. Why are you asking this question? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A10 bring up and DRAM configuration procedure
mster is by far more sensitive to DRAM misconfiguration than the usual software. So the borderline unreliable DRAM settings may not exhibit any visible bad effects (the system is able to boot, the usual linux software works fine too), but easily detected by lima-memtester. Because the system is sufficiently usable at such borderline unstable DRAM settings, we can run automation scripts to do a bruteforce search, which is probing different TPR3 values without human supervision. That's what is explained at: https://linux-sunxi.org/A10_DRAM_Controller_Calibration But in your case, you can try different ZQ and TPR3 settings manually in the U-Boot defconfig and instead of running lima-memtester (which first needs a bootable userland) just monitor how far the system is able to boot as an alternative selection criteria for picking better configuration values. If you manage to boot the system up to a semi-working userland, then you can switch to using lima-memtester for the final tuning and validation. > If anyone more experienced can advise what can be done at this point I would > appreciate. Maybe ask the hardware people if they have done the DDR3 routing right? Also if it is just a single board, then it might be not misconfigured, but defective. Trying another sample could be a good idea. > [1] > http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR3/1Gb_DDR3_SDRAM.pdf > [2] > http://git.denx.de/?p=u-boot.git;a=blob;f=lib/crc32.c;h=97592124867abb815d576899f8789545c3aef1aa;hb=HEAD#l200 > [3] https://gist.github.com/pietrushnic/ea41a4ae38b7af8a6fa456113ce19af8 > [4] http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation > [5] https://gist.github.com/pietrushnic/d6a3d6c0b4a20a3226dfb67c4d129142 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/2] fel: add fel spl support for Allwinner A80
On Mon, 21 Mar 2016 14:24:15 +0100 Jens Kuske wrote: > The A80 has the V bit in SCTLR set to 0 because of the BROM > being at 0x now, so the SCTLR check has to be relaxed. > > Signed-off-by: Jens Kuske Thanks! > --- > fel.c | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > > diff --git a/fel.c b/fel.c > index ba58105..dedde55 100644 > --- a/fel.c > +++ b/fel.c > @@ -489,6 +489,16 @@ sram_swap_buffers a31_sram_swap_buffers[] = { > { 0 } /* End of the table */ > }; > > +/* > + * A80 has 40KiB SRAM A1 at 0x1 where the SPL has to be loaded to. The > + * secure SRAM B at 0x2 is used as backup area for FEL stacks and data. > + */ > +sram_swap_buffers a80_sram_swap_buffers[] = { > + { .buf1 = 0x11800, .buf2 = 0x2, .size = 0x800 }, > + { .buf1 = 0x15400, .buf2 = 0x20800, .size = 0x18000 - 0x15400 }, > + { 0 } /* End of the table */ > +}; > + > soc_sram_info soc_sram_info_table[] = { > { > .soc_id = 0x1623, /* Allwinner A10 */ > @@ -541,6 +551,13 @@ soc_sram_info soc_sram_info_table[] = { > .thunk_addr = 0x46E00, .thunk_size = 0x200, > .swap_buffers = a31_sram_swap_buffers, > }, > + { > + .soc_id = 0x1639, /* Allwinner A80 */ > + .spl_addr = 0x1, > + .scratch_addr = 0x12000, We have a reason to use 0x11000 instead of 0x12000 here: http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/21153 But I'll just add this change into my old patch and re-send an updated version of it. > + .thunk_addr = 0x23400, .thunk_size = 0x200, > + .swap_buffers = a80_sram_swap_buffers, > + }, > { 0 } /* End of the table */ > }; > > @@ -792,9 +809,9 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, >* checks needs to be relaxed). >*/ > > - /* Basically, ignore M/Z/I bits and expect no TEX remap */ > + /* Basically, ignore M/Z/I/V bits and expect no TEX remap */ > sctlr = aw_get_sctlr(usb, sram_info); > - if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) { > + if ((sctlr & ~((0x7 << 11) | 1)) != 0x00C50078) { > fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr); > exit(1); > } Reviewed-by: Siarhei Siamashka And pushed to github. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 1/2] fel: only read MMU control registers if MMU is enabled
On Mon, 21 Mar 2016 14:24:14 +0100 Jens Kuske wrote: > This workaround is necessary for A80, which sometimes > fails at reading DACR. > > Signed-off-by: Jens Kuske > --- > fel.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/fel.c b/fel.c > index a905ad5..ba58105 100644 > --- a/fel.c > +++ b/fel.c > @@ -767,10 +767,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, > soc_sram_info *sram_info) > { > uint32_t *tt = NULL; > - uint32_t ttbr0 = aw_get_ttbr0(usb, sram_info); > - uint32_t sctlr = aw_get_sctlr(usb, sram_info); > - uint32_t ttbcr = aw_get_ttbcr(usb, sram_info); > - uint32_t dacr = aw_get_dacr(usb, sram_info); > + uint32_t sctlr, ttbr0, ttbcr, dacr; > uint32_t i; > > uint32_t arm_code[] = { > @@ -796,6 +793,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, >*/ > > /* Basically, ignore M/Z/I bits and expect no TEX remap */ > + sctlr = aw_get_sctlr(usb, sram_info); > if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) { > fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr); > exit(1); > @@ -806,16 +804,19 @@ uint32_t > *aw_backup_and_disable_mmu(libusb_device_handle *usb, > return NULL; > } > > + dacr = aw_get_dacr(usb, sram_info); > if (dacr != 0x) { > fprintf(stderr, "Unexpected DACR (%08X)\n", dacr); > exit(1); > } > > + ttbcr = aw_get_ttbcr(usb, sram_info); > if (ttbcr != 0x) { > fprintf(stderr, "Unexpected TTBCR (%08X)\n", ttbcr); > exit(1); > } > > + ttbr0 = aw_get_ttbr0(usb, sram_info); > if (ttbr0 & 0x3FFF) { > fprintf(stderr, "Unexpected TTBR0 (%08X)\n", ttbr0); > exit(1); As we discussed on IRC earlier, having this patch is reasonable as it workarounds A80 problems and makes FEL boot usable on it. So Reviewed-by: Siarhei Siamashka I have already pushed it to github, thanks! Too bad that we still don't know what's going on. We can probably add a comment to the Notes column in the SoC support status table and warn the users, so that they watch out and report any possible irregularities: https://linux-sunxi.org/FEL/USBBoot#SoC_support_status Can you probably try to read the MIDR register to check if the A80 SoC initially boots on a Cortex A15 or a Cortex A7 core? If it is A7, then something is really odd. But if it is A15, then aggressive instructions reordering may be exposing a missing barrier instruction here or there. There are also some configuration knobs in the A15 too, which allow to partially enforce in-order behaviour: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438i/BABGHIBG.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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands
On Sun, 20 Mar 2016 16:09:40 +0100 Bernhard Nortmann wrote: > Hi Siarhei! > > Am 20.03.2016 um 15:49 schrieb Siarhei Siamashka: > > This patch is just unsafe if pushed alone, that's why it implicitly > > depends on the other "fel: Move the temporary scratch buffer under the > > IRQ stack" patch. > > I see. My impression was that while "unclean" on its own, it's still > functional - at least to a degree where stuff like "sunxi-fel sid" might > actually allow device identification before doing more complicated stuff > (in a second sunxi-fel invocation). But of course it's preferable to > properly resolve the dependenices first. It is functional as long as you are fine with corrupting memory at 0x2000 as a side effect. This address 0x2000 is special because it is the usual location where sunxi-fel users are supposed to upload their code for execution, as instructed by many existing examples and tutorials. Consider the following shell code: if [ "`sunxi-fel ver | grep \(A10\)`" ] ; then sunxi-fel write 0x2000 some_code_for_a10_soc if [ "`sunxi-fel sid | grep 16236747-80728452-50574848-064163D5`" ] ; then sunxi-fel exe 0x2000 else echo "Oh, wrong device, nevermind" fi else echo "Oh, wrong SoC type, nevermind" fi > > And instead of cluttering the documentation with the "Use these commands > > with caution!" warnings (which many people will miss or ignore anyway), > > it's better to do a proper job in the first place. > > It would simply give us something to point users to, if they try antics > like "./sunxi-fel readl 0x" and come back complaining "That > always fails with: libusb usb_bulk_send error -7". (Just like you) I > suspect people will do this anyway, no matter where / how we put up > warning signs in the first place... :-P The user may run into a trouble by using the documented functionality in a wrong way. But this is relatively easy to debug and makes the user learn his lesson pretty fast. But running into a trouble because of an undocumented (or poorly documented) side effect is entirely different. Such problems are usually much harder to debug. Check the https://en.wikipedia.org/wiki/Principle_of_least_astonishment Corrupting memory at 0x2000 clearly violates this principle, even if we bother to document this behaviour somewhere. Still I don't understand why we are even discussing this. A simple patch to address this issue already exists. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands
On Sun, 20 Mar 2016 15:18:10 +0100 Bernhard Nortmann wrote: > One thing that came to my mind while playing around with this: Should we > add something like this to the commit message? > > "Caveat: Use these commands with caution! Errors during execution of > the scratch buffer code, e.g. attempts to access an invalid memory > location, might crash the FEL; requiring you to reset the device." We already have a detailed explanation about all the implications in the commit message here: http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/21153 The new "readl" and "writel" commands are the examples of the "advanced-command-which-uploads-and-executes-code" mentioned there. > I think this particular patch has merits of it own, and might be useful > even if isolated from the rest of the series (e.g. when implementing a > future "sid" command). This patch is just unsafe if pushed alone, that's why it implicitly depends on the other "fel: Move the temporary scratch buffer under the IRQ stack" patch. And instead of cluttering the documentation with the "Use these commands with caution!" warnings (which many people will miss or ignore anyway), it's better to do a proper job in the first place. > By now it has received a bit of testing on various hardware (during the > course of https://github.com/linux-sunxi/sunxi-tools/issues/37), so feel > free to commit it. > > Reviewed-by: Bernhard Nortmann Thanks. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools v5] fel: support selection of specific USB bus and device number
On Sun, 20 Mar 2016 14:03:24 +0100 Bernhard Nortmann wrote: > Am 20.03.2016 um 13:53 schrieb Siarhei Siamashka: > > Thanks, also adding an extra > > > >|| busnum < 0 || devnum < 0 > > > > check here would make it perfect. > > > > If the user tries to provide negative numbers in the command line, then > > it is reasonable to fail with an error instead of silently reverting to > > the default "pick any FEL device" behaviour. > > Should we extend that to be "|| busnum <= 0 || devnum <= 0"? > > Afaik, a zero bus or device number would be impossible to match anyway. Yes, this makes sense. Feel free to do this adjustment when pushing the patch to git. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands
On Sat, 19 Mar 2016 18:29:40 +0100 Bernhard Nortmann wrote: > Am 17.03.2016 um 13:55 schrieb Bernhard Nortmann: > > > > I can confirm/reproduce this behaviour on my A20 when accessing the > > SID register. Interesting enough, the bytes that actually do get read > > (i.e. end up != 0) are "correct", as if the aw_usb_read() somehow > > truncates everything down to single-byte range: > > > > sunxi-tools # ./sunxi-fel hexdump 0x01c23800 16 > > 01c23800: 4f 00 00 00 86 00 00 00 48 00 00 00 e9 00 00 00 > > > > Btw: This "MSB zero" problem doesn't seem related to the FEL protocol in > any way, but looks like a more general hardware limitation. U-Boot's > memory display exposes the very same quirk when not accessing the SID > registers as "long" (i.e. 32-bit) values: > > => md.l 0x01c23800 4 > 01c23800: 1651664f 80485686 53504848 0702dde9OfQ..VH.HHPS > => md.w 0x01c23800 8 > 01c23800: 664f 5686 4848 dde9 Of...V..HH.. > => md.b 0x01c23800 10 > 01c23800: 4f 00 00 00 86 00 00 00 48 00 00 00 e9 00 00 00 O...H... Yes, it's a well known fact about accessing hardware registers in general. Because partial read/write of such 32-bit hardware registers makes no sense, the hardware does not need to be excessively complicated and is allowed to talk back only when getting exact match on the address bus. The commit message was only speculating about the FEL implementation in the BROM, which is very likely relying on a naive "one byte at a time" memcpy implementation here. So we need to introduce these extra helper functions to read/write 32-bit values because the basic FEL protocol can't provide the needed functionality. These helper functions have a very broad use, starting from just reading the SID value (it is simple and easy to verify example) or asserting/deasserting the OpenRISC core reset. And potentially ending even with implementing or prototyping some bigger drivers for the hardware via some sort of RPC MMIO approach. Also because we need to upload and execute some code for implementing this, we have to review how the SRAM memory is managed. That's what the rest of this patch series is all about (move the scratch area under the IRQ stack, support 40KiB SPL size for making future improvements possible, avoid clashing with the SRAM area reserved for the OpenRISC firmware). Regarding the SRAM memory layout in the FEL mode, the following wiki page provides some information: https://linux-sunxi.org/SRAM_dumps_from_A13_in_FEL_mode -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools] fel: Add release USB interface to allow proper operation on Mac OS X.
On Thu, 17 Mar 2016 19:38:54 +0100 Bernhard Nortmann wrote: > From: Lourens Rozema > > Tested-by: Bernhard Nortmann > --- > This picks up a long-standing pull request from the github repo that seemingly > noone cared to take forward to the mailing list. The one-line change looks > sane, > and reportedly is needed for proper operation when issuing repeated sunxi-fel > commands on Mac OS X. NextThingCo also uses it in their > https://github.com/NextThingCo/sunxi-tools/commit/09cf8e3 Thanks! This is indeed a generic fix for a libusb API misuse bug and not something that is somehow specific to Mac OS X. Considering that NextThingCo has apparently tested and taken this patch into use, it makes a lot of sense to apply this fix too. > fel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fel.c b/fel.c > index 59f0f72..c81077f 100644 > --- a/fel.c > +++ b/fel.c > @@ -1437,6 +1437,7 @@ int main(int argc, char **argv) > aw_fel_execute(handle, uboot_entry); > } > > + libusb_release_interface(handle, 0); > #if defined(__linux__) > if (iface_detached >= 0) > libusb_attach_kernel_driver(handle, iface_detached); Reviewed-by: Siarhei Siamashka -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 5/7] fel: Move the temporary scratch buffer under the IRQ stack
On Thu, 17 Mar 2016 18:31:42 +0100 Bernhard Nortmann wrote: > Am Montag, 25. Januar 2016 05:51:02 UTC+1 schrieb Siarhei Siamashka: > > Doing certain operations may need uploading and executing code > > on the device. For example, such operations right now are > > reading/writing ARM CP15 coprocessor registers. Uploading the > > code to the device is naturally overwriting some part of SRAM > > as a side effect. Right now it is not a problem, because the > > CP15 coprocessor registers are only accessed as part of uploading > > and executing U-Boot SPL. They are nicely timed not to cause > > problems and the temporary scratch area gets overwritten by > > the SPL code anyway. > > > > But if we decide to provide access to such operations via > > command line interface, then any side effects may potentially > > cause problems for the users. Consider the following scenario: > > > > sunxi-fel clear 0x2000 0x100 \ > > advanced-command-which-uploads-and-executes-code \ > > hexdump 0x2000 0x100 > > > > The user may rightfully expect that clearing a buffer in SRAM > > to zero and then reading it back should show all zero bytes. > > But inserting advanced commands in the middle may cause data > > corruption. > > > > In order to resolve this problem, just move the scratch area > > away from the 0x2000-0x5BFF addresses range. These particular > > addresses are already known to the users as a safe place for > > their bare metal expariments in FEL mode. The "sunxi-fel spl" > > command is a special case though and it is expected to > > overwrite data in this area too. > > > > A possible alternative would be to just backup & restore data > > in the scratch area. But this has some disadvantages: > > 1. Extra code in the sunxi-fel tool and extra roundtrips over > > USB to do the backup/restore job. > > 2. If we allow the OpenRISC core to use the 0x2000-0x5C00 > > range in SRAM A1, then this becomes unsafe and racy > > (we can't really backup & restore data without causing > > a temporarily glitch for the currently running code on > > the OpenRISC core). > > > > To sum it up. With this patch we make it so that now the > > 0x2000-0x5BFF range is freely available for the users of the > > sunxi-fel tool. The 0x1000-0x1FFF range is off limits (the > > upper part of it is used by the FEL IRQ handler, the lower > > part of it is reserved for internal use by the sunxi-fel > > tool). The 0x-0x1FFF addresses range is reserved for BTW, just noticed, it was a typo and this comment should read as "0x-0x0FFF addresses". > > passing data from the SPL to the main U-Boot binary (via > > the SPL header) and is also off limits. > > > > Signed-off-by: Siarhei Siamashka > > --- > > fel.c | 16 > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/fel.c b/fel.c > > index 40cb82a..a597e11 100644 > > --- a/fel.c > > +++ b/fel.c > > @@ -505,51 +505,51 @@ sram_swap_buffers ar100_abusing_sram_swap_buffers[] = > > { > > soc_sram_info soc_sram_info_table[] = { > > { > > .soc_id = 0x1623, /* Allwinner A10 */ > > - .scratch_addr = 0x2000, > > + .scratch_addr = 0x1000, > > .thunk_addr = 0xA200, .thunk_size = 0x200, > > .swap_buffers = a10_a13_a20_sram_swap_buffers, > > .needs_l2en = 1, > > }, > > { > > .soc_id = 0x1625, /* Allwinner A13 */ > > - .scratch_addr = 0x2000, > > + .scratch_addr = 0x1000, > > .thunk_addr = 0xA200, .thunk_size = 0x200, > > .swap_buffers = a10_a13_a20_sram_swap_buffers, > > .needs_l2en = 1, > > }, > > { > > .soc_id = 0x1651, /* Allwinner A20 */ > > - .scratch_addr = 0x2000, > > + .scratch_addr = 0x1000, > > .thunk_addr = 0xA200, .thunk_size = 0x200, > > .swap_buffers = a10_a13_a20_sram_swap_buffers, > > }, > > { > > .soc_id = 0x1650, /* Allwinner A23 */ > > - .scratch_addr = 0x2000, > > + .scratch_addr = 0x1000, > > .thunk_addr = 0x46E00, .thunk_size = 0x200, > > .swap_buffers = ar100_abusing_sram_swap_buffers, > > }, > > { > > .soc_id = 0x1633, /* Allwinner A31 */ > > - .scratch_addr = 0x20
[linux-sunxi] Re: [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands
On Thu, 17 Mar 2016 13:55:25 +0100 Bernhard Nortmann wrote: > Am Montag, 25. Januar 2016 05:51:02 UTC+1 schrieb Siarhei Siamashka: > > The read/write operations done by FEL are not suitable for accessing > > hardware registers. For example, trying to read a SID value using > > the "read" or "hexdump" commands results in the following: > > > > $ sunxi-fel hexdump 0x01c23800 4 > > 01c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ > > > > Apparently, FEL tries to read data one byte at a time and this does > > not always work correctly. Introducing new commands to explicitly > > do 32-bit reads and writes helps: > > > > $ sunxi-fel readl 0x01c23800 > > 0x16254187 > > > > Signed-off-by: Siarhei Siamashka > > I can confirm/reproduce this behaviour on my A20 when accessing the SID > register. Interesting enough, the bytes that actually do get read (i.e. > end up != 0) are "correct", as if the aw_usb_read() somehow truncates > everything down to single-byte range: > > sunxi-tools # ./sunxi-fel hexdump 0x01c23800 16 > 01c23800: 4f 00 00 00 86 00 00 00 48 00 00 00 e9 00 00 00 > > Your "readl" retrieves the expected results (correct 32-bit values for > the SID registers). > > > > --- > > fel.c | 44 > > 1 file changed, 44 insertions(+) > > > > diff --git a/fel.c b/fel.c > > index a597e11..d3d6f62 100644 > > --- a/fel.c > > +++ b/fel.c > > @@ -654,6 +654,38 @@ void aw_write_arm_cp_reg(libusb_device_handle *usb, > > soc_sram_info *sram_info, > > aw_fel_execute(usb, sram_info->scratch_addr); > > } > > > > +uint32_t aw_fel_readl(libusb_device_handle *usb, uint32_t addr) > > +{ > > + soc_sram_info *sram_info = aw_fel_get_sram_info(usb); > > + uint32_t val = 0; > > + uint32_t arm_code[] = { > > + htole32(0xe59f0008), /* ldrr0, [pc, #8] */ > > + htole32(0xe590), /* ldrr0, [r0] */ > > + htole32(0xe58f), /* strr0, [pc] */ > > + htole32(0xe12fff1e), /* bx lr */ > > + htole32(addr) > > + }; > > + aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code)); > > + aw_fel_execute(usb, sram_info->scratch_addr); > > + aw_fel_read(usb, sram_info->scratch_addr + 16, &val, sizeof(val)); > > + return le32toh(val); > > +} > > + > > +void aw_fel_writel(libusb_device_handle *usb, uint32_t addr, uint32_t val) > > +{ > > + soc_sram_info *sram_info = aw_fel_get_sram_info(usb); > > + uint32_t arm_code[] = { > > + htole32(0xe59f0008), /* ldrr0, [pc, #8] */ > > + htole32(0xe59f1008), /* ldrr1, [pc, #8] */ > > + htole32(0xe5801000), /* strr1, [r0] */ > > + htole32(0xe12fff1e), /* bx lr */ > > + htole32(addr), > > + htole32(val) > > + }; > > + aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code)); > > + aw_fel_execute(usb, sram_info->scratch_addr); > > +} > > + > > void aw_enable_l2_cache(libusb_device_handle *usb, soc_sram_info > > *sram_info) > > { > > uint32_t arm_code[] = { > > @@ -1314,6 +1346,8 @@ int main(int argc, char **argv) > > " hex[dump] address lengthDumps memory > > region in hex\n" > > " dump address length Binary memory > > dump\n" > > " exe[cute] address Call function > > address\n" > > + " readl address Read 32-bit > > value from device memory\n" > > + " writel address valueWrite 32-bit > > value to device memory\n" > > " read address length fileWrite memory > > contents into file\n" > > " write address file Store file > > contents into memory\n" > > " write-with-progress addr file \"write\" with > > progress bar\n" > > @@ -1380,6 +1414,16 @@ int main(int argc, char **argv) > > } else if (strncmp(argv[1], "dump", 4) == 0 && argc > 3) { > > aw_
[linux-sunxi] Re: [PATCH sunxi-tools v5] fel: support selection of specific USB bus and device number
tostart */ > bool pflag_active = false; /* -p switch, causing "write" to output > progress */ > - int rc; > - libusb_device_handle *handle = NULL; > + libusb_device_handle *handle; > + int busnum = -1, devnum = -1; > int iface_detached = -1; > - rc = libusb_init(NULL); > + int rc = libusb_init(NULL); > assert(rc == 0); > > if (argc <= 1) { > printf("Usage: %s [options] command arguments... [command...]\n" > " -v, --verbose Verbose > logging\n" > " -p, --progress \"write\" > transfers show a progress bar\n" > + " -d, --dev bus:devnumUse specific > USB bus and device number\n" > "\n" > " spl fileLoad and > execute U-Boot SPL\n" > " If file additionally contains a main > U-Boot binary\n" > @@ -1316,18 +1391,32 @@ int main(int argc, char **argv) > ); > } > > - handle = libusb_open_device_with_vid_pid(NULL, 0x1f3a, 0xefe8); > - if (!handle) { > - switch (errno) { > - case EACCES: > - fprintf(stderr, "ERROR: You don't have permission to > access Allwinner USB FEL device\n"); > - break; > - default: > - fprintf(stderr, "ERROR: Allwinner USB FEL device not > found!\n"); > - break; > - } > - exit(1); > + /* process all "prefix"-type arguments first */ > + while (argc > 1) { > + if (strcmp(argv[1], "--verbose") == 0 || strcmp(argv[1], "-v") > == 0) > + verbose = true; > + else if (strcmp(argv[1], "--progress") == 0 || strcmp(argv[1], > "-p") == 0) > + pflag_active = true; > + else if (strncmp(argv[1], "--dev", 5) == 0 || strncmp(argv[1], > "-d", 2) == 0) { > + char *dev_arg = argv[1]; > + dev_arg += strspn(dev_arg, "-dev="); /* skip option > chars, ignore '=' */ > + if (*dev_arg == 0 && argc > 2) { /* at end of argument, > use the next one instead */ > + dev_arg = argv[2]; > + argc -= 1; > + argv += 1; > + } > + if (sscanf(dev_arg, "%d:%d", &busnum, &devnum) != 2) { Thanks, also adding an extra || busnum < 0 || devnum < 0 check here would make it perfect. If the user tries to provide negative numbers in the command line, then it is reasonable to fail with an error instead of silently reverting to the default "pick any FEL device" behaviour. > + fprintf(stderr, "ERROR: Expected 'bus:devnum', > got '%s'.\n", dev_arg); > + exit(1); > + } > + } else > + break; /* no valid (prefix) option detected, exit loop > */ > + argc -= 1; > + argv += 1; > } > + > + handle = open_fel_device(busnum, devnum, AW_USB_VENDOR_ID, > AW_USB_PRODUCT_ID); > + assert(handle != NULL); > rc = libusb_claim_interface(handle, 0); > #if defined(__linux__) > if (rc != LIBUSB_SUCCESS) { > @@ -1343,18 +1432,6 @@ int main(int argc, char **argv) > exit(1); > } > > - /* process all "prefix"-type arguments first */ > - while (argc > 1) { > - if (strcmp(argv[1], "--verbose") == 0 || strcmp(argv[1], "-v") > == 0) > - verbose = true; > - else if (strcmp(argv[1], "--progress") == 0 || strcmp(argv[1], > "-p") == 0) > - pflag_active = true; > - else > - break; /* no valid (prefix) option detected, exit loop > */ > - argc -= 1; > - argv += 1; > - } > - > while (argc > 1 ) { > int skip = 1; > Reviewed-by: Siarhei Siamashka -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools v3] fel: support selection of specific USB bus and device number
break; /* no valid (prefix) option detected, exit loop > */ > + argc -= 1; > + argv += 1; > } > + > + request_libusb_handle(&handle, busnum, devnum, 0x1f3a, 0xefe8); > rc = libusb_claim_interface(handle, 0); > #if defined(__linux__) > if (rc != LIBUSB_SUCCESS) { > @@ -1343,18 +1410,6 @@ int main(int argc, char **argv) > exit(1); > } > > - /* process all "prefix"-type arguments first */ > - while (argc > 1) { > - if (strcmp(argv[1], "--verbose") == 0 || strcmp(argv[1], "-v") > == 0) > - verbose = true; > - else if (strcmp(argv[1], "--progress") == 0 || strcmp(argv[1], > "-p") == 0) > - pflag_active = true; > - else > - break; /* no valid (prefix) option detected, exit loop > */ > - argc -= 1; > - argv += 1; > - } > - > while (argc > 1 ) { > int skip = 1; > -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] ./lima-memtester failed to open /dev/mali but mali.ko inserted
On Wed, 16 Mar 2016 20:06:00 -0700 (PDT) kimdou wrote: > # insmod /lib/modules/3.4.39/mali.ko > [ 315.790108] mali_platform_init(184): get ahb_mali handle success! > [ 315.797536] mali_platform_init(192): get mali handle success! > [ 315.803983] mali_platform_init(199): get ve_pll handle success! > [ 315.810945] mali_platform_init(206): set mali clock source success! > [ 315.818145] mali_platform_init(210): get ve pll rate 33600! > [ 315.824767] mali_platform_init(213): get mali_para->mali_used success! > mali_use 1 > [ 315.833349] mali_platform_init(217): get mali_para->mali_clkdiv success! > clk_drv 1 > [ 315.841955] mali_platform_init(226): mali_clk_div 1 > [ 315.847540] mali_platform_init(232): set mali clock rate success! > [ 315.854353] mali_platform_init(238): reset release success! > [ 315.860751] Mali: enable mali clock > [ 315.864661] Mali: sun7i_mali_platform_device_register() sucess!! > [ 315.871566] axp20_buck3: Failed to create debugfs directory > [ 315.878369] mali_freq_init(696): get mali_para->mali_used success! > mali_use 1 > [ 315.889067] Mali: Mali device driver loaded > > but lima-memtester failed: > > # ./lima-memtester 100M > This is a simple textured cube demo from the lima driver and > a memtester. Both combined in a single program. The mali400 > hardware is only used to stress RAM in the background. But > this happens to significantly increase chances of exposing > memory stability related problems. > > Error: Failed to open /dev/mali: No such device or address > Aborted > > ls mali is ok: > # ls /dev/mali -l > crw-r--r--1 root root 230, 0 Jan 1 00:07 /dev/mali > > and i enable the frame buffer module in kernel. Well, still the error message just means that the open() call fails and strerror(errno) reports "No such device or address" as the reason. You can always debug the lima-memtester code and add more debugging prints of necessary. It is a free open source software, which does not rely on proprietary binaries. What kind of kernel and mali module is that? And what kind of Allwinner A20 device are you using? The 3.4.39 version number looks rather suspicious for it. If you are only interested in testing the RAM settings reliability on your board, then you can use a USB FEL based launch method similar to https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test Just compile the kernel using the sun7i_lima_memtester_defconfig from the following git branch: https://github.com/ssvb/linux-sunxi/commits/20151206-embedded-lima-memtester Also compile the right mainline U-Boot binary for your board and generate the right script.bin from your FEX file. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Is it possible to boot the A13 chip without DDR3 RAM?
On Wed, 2 Mar 2016 08:31:03 -0800 (PST) alexey_11 via linux-sunxi wrote: > Any progress? > I am currently working with arm a13 allwinner. I look at > how to avoid external DDR3 memory, because the program size is less > than 128k, boot with sd-card and loader , which fed program into the > l2 cache. The original discussion thread has more than enough hints about what can be tried to implement this. So feel free to start coding and share your findings with us. Or are you actually trying to hire somebody to do this job for you? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC
On Mon, 1 Feb 2016 22:49:16 + André Przywara wrote: > On 01/02/16 18:27, Karsten Merker wrote: > > Hi Karsten, > > thank you very much for your feedback! > > > On Mon, Feb 01, 2016 at 05:39:24PM +, Andre Przywara wrote: > >> Based on the Allwinner A64 user manual and on the previous sunxi > >> pinctrl drivers this introduces the pin multiplex assignments for > >> the ARMv8 Allwinner A64 SoC. > >> Port A is apparently used for the fixed function DRAM controller, so > >> the ports start at B here (the manual mentions "n from 1 to 7", so > >> not starting at 0). > >> > >> Signed-off-by: Andre Przywara > >> --- > >> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + > >> arch/arm64/Kconfig.platforms | 1 + > >> drivers/pinctrl/sunxi/Kconfig | 4 + > >> drivers/pinctrl/sunxi/Makefile | 1 + > >> drivers/pinctrl/sunxi/pinctrl-a64.c| 606 > >> + > >> 5 files changed, 613 insertions(+) > >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c > >> > >> diff --git > >> a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> index 9213b27..9050002 100644 > >> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt > >> @@ -21,6 +21,7 @@ Required properties: > >>"allwinner,sun9i-a80-r-pinctrl" > >>"allwinner,sun8i-a83t-pinctrl" > >>"allwinner,sun8i-h3-pinctrl" > >> + "allwinner,a64-pinctrl" > > > > Hello, > > > > on all other Allwinner SoCs we use the SoC family as part of the > > compatible, as well as in the names of the Kconfig options. To > > keep things consistent, I would like to propose doing the same on > > Arm64, i.e. using allwinner,sun50i-a64-pinctrl instead of > > allwinner,a64-pinctrl. > > Yes, I have been told this already. However I don't like this idea so > much, for the following reasons: > a) It is mostly redundant. The actual SoC (marketing) name is unique, > there is no sun6i-a20 or sun7i-a23. > b) It is not even helpful. If I got Maxime correctly, then the newer > sunxi generation numbers depend on the ARM _cores_ used in the SoC, > which is frankly the least interesting part from a Linux support > perspective. I would see some sense if it would reflect the generation > of IP blocks used, but so it is even more confusing to see that > sun7i-a20 and sun8i-a23 are related, but sun8i-h3 is a completely > different beast. The Allwinner marketing name tells you that, but the > sunxi one does not. > c) It is very confusing for people not dealing with it everyday. Just > because I own a BananaPi I know that the A20 is sun7i, but I am totally > lost when it comes to all the other names. And even now it took me about > a minute to find the appropriate Wiki page which explains part of that > story. > d) Most importantly ;-): It kills TAB completion, unless you know the > sunxi number, which is mostly not true as pointed out in c) > > So while I see that just a is not really very specific, I'd > rather do away with current naming scheme for the future. In this > particular case we have the vendor name as a name space identifier > already, so there is no possible confusion with ARM Cortex naming, for > instance. > > Also as this is now moving into the arm64 world, I'd like to use the > opportunity to fix things that are not really optimal, the naming is one > of them. One of the problems is that A64 name is not unique. We have reasons to believe that there are also H64 and R18 out there using exactly the same die, but possibly available in different packaging (a different ball grid pitch? or maybe a different set of peripherals routed to the outside?). Early prototypes of the Pine64 board were using Allwinner R18 and the Jide Remix Mini HTPC box is using Allwinner H64. The bootloader sources from Allwinner are also referring to A64 as AW1689, which makes some sense because it is the chip id number that is accessible for runtime identification via reading the SRAM_VER_REG hardware register: http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG So would it be a good idea to use "aw1689" as a compatible property in the DT instead of "a64"? Or maybe have "aw1689-a64" and "aw1689-h64", which would be similar to the existing "sun5i-a13" and "sun5i-a10s" naming convention? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Is a somewhat maintained 3.4 kernel branch needed for Allwinner H3?
Hello, Basically, do we want to have some usable 3.4 kernel for Allwinner H3 in one of the https://github.com/linux-sunxi/linux-sunxi branches? Right now there is 'sunxi-3.4' branch, which supports A10/A13/A20. Also since some time ago, Allwinner provides their 3.4 kernel at https://github.com/allwinner-zh/linux-3.4-sunxi with the readme, which mentions "Support A31/A31s, A23, A33 and A80 platforms". But right now there is no H3 support there: https://github.com/allwinner-zh/linux-3.4-sunxi/issues/14 Personally, I would like to see Allwinner taking care of their 3.4 kernel, so preferably https://github.com/allwinner-zh/linux-3.4-sunxi should eventually become usable for H3 too. But it does not look like this issue is going to be addressed any time soon. Now about my involvement in this whole Allwinner H3 story. I did some experiments with the Allwinner's 3.4 kernel some time ago. Specifically with the following two purposes in mind: 1) Ensure that we can easily check default clocks and hardware registers configuration as used by Allwinner and use them as a reference. So that the same setup can be replicated in the mainline U-Boot and the kernel: http://git.denx.de/?p=u-boot.git;a=commit;h=52d093112a307b2dd1ae46f8bd6ba7904760ac57 2) Validate the reliability of the DRAM setup. Poorly selected DRAM configuration used to be a rather common occurrence on A10/A13/A20 hardware (and still probably is because there are too many various boards and not all of them have been tested). So it was reasonable to do the same lima-memtester test on H3 hardware too: https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test http://git.denx.de/?p=u-boot.git;a=commit;h=e7d6aa0b74b7f4d08ee68da8a586c76c761348e2 While at it, I had also added a link to my 3.4 kernel branch and some basic compilation/usage instructions at http://linux-sunxi.org/Orange_Pi_PC#Sunxi.2FLegacy_Kernel with the hope that some other people may find it useful. But I have no interest the the Allwinner's 3.4 kernel and have no plans to do anything else with it any time soon. Still I got a pull request some days ago: https://github.com/ssvb/linux-sunxi/pull/1 Which brings us to this discussion. So does anyone have any good ideas about how to move forward? Or is anyone willing to step up as the 3.4 kernel maintainer for Allwinner H3? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 7/7] fel: Add fel spl command support for Allwinner A64
On Mon, 25 Jan 2016 06:50:54 +0200 Siarhei Siamashka wrote: > The SCTLR bits are somewhat different because the V bit is set > to 0 on A64 (Low exception vectors, base address 0x) and > the UNK bit (Reads of this bit return an UNKNOWN value) is also not > the same as on the other SoCs. So the SCTLR check can be relaxed. > > Signed-off-by: Siarhei Siamashka > --- > fel.c | 23 +-- > 1 file changed, 21 insertions(+), 2 deletions(-) > > diff --git a/fel.c b/fel.c > index d3d6f62..ee76f98 100644 > --- a/fel.c > +++ b/fel.c > @@ -247,6 +247,7 @@ void aw_fel_print_version(libusb_device_handle *usb) > case 0x1633: soc_name="A31";break; > case 0x1651: soc_name="A20";break; > case 0x1650: soc_name="A23";break; > + case 0x1689: soc_name="A64";break; > case 0x1639: soc_name="A80";break; > case 0x1667: soc_name="A33";break; > case 0x1673: soc_name="A83T";break; > @@ -492,6 +493,17 @@ sram_swap_buffers a31_sram_swap_buffers[] = { > }; > > /* > + * A64 has a large SRAM C at 0x18000, which we use as a backup storage > + * for FEL stacks. Also the SPL load address is 0x1 and it makes this > + * SoC rather unique. > + */ > +sram_swap_buffers a64_sram_swap_buffers[] = { > + { .buf1 = 0x11800, .buf2 = 0x18000, .size = 0x800 }, > + { .buf1 = 0x15C00, .buf2 = 0x18800, .size = 0x8000 - 0x5C00 }, > + { 0 } /* End of the table */ > +}; When creating this patch, I did not notice that the SRAM A1 and SRAM C don't have a gap between them, but together provide a large contiguous 192 KiB area. So this table should be adjusted to allow having 40 KiB of SRAM space for the SPL (the 32 KiB - 40 KiB area can be used for stack). I'll make an updated patch. > +/* > * Use the SRAM section at 0x44000 as the backup storage. This is the memory, > * which is normally shared with the OpenRISC core (should we do an extra > check > * to ensure that this core is powered off and can't interfere?). > @@ -542,6 +554,13 @@ soc_sram_info soc_sram_info_table[] = { > .swap_buffers = ar100_abusing_sram_swap_buffers, > }, > { > + .soc_id = 0x1689, /* Allwinner A64 */ > + .spl_addr = 0x1, > + .scratch_addr = 0x11000, > + .thunk_addr = 0x1AE00, .thunk_size = 0x200, > + .swap_buffers = a64_sram_swap_buffers, > + }, > + { > .soc_id = 0x1673, /* Allwinner A83T */ > .scratch_addr = 0x1000, > .thunk_addr = 0x46E00, .thunk_size = 0x200, > @@ -840,8 +859,8 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle > *usb, >* checks needs to be relaxed). >*/ > > - /* Basically, ignore M/Z/I bits and expect no TEX remap */ > - if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) { > + /* Basically, ignore V/M/Z/I/UNK bits and expect no TEX remap */ > + if ((sctlr & ~((3 << 11) | (1 << 6) | 1)) != 0x00C50038) { > fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr); > exit(1); > } -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 7/7] fel: Add fel spl command support for Allwinner A64
The SCTLR bits are somewhat different because the V bit is set to 0 on A64 (Low exception vectors, base address 0x) and the UNK bit (Reads of this bit return an UNKNOWN value) is also not the same as on the other SoCs. So the SCTLR check can be relaxed. Signed-off-by: Siarhei Siamashka --- fel.c | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/fel.c b/fel.c index d3d6f62..ee76f98 100644 --- a/fel.c +++ b/fel.c @@ -247,6 +247,7 @@ void aw_fel_print_version(libusb_device_handle *usb) case 0x1633: soc_name="A31";break; case 0x1651: soc_name="A20";break; case 0x1650: soc_name="A23";break; + case 0x1689: soc_name="A64";break; case 0x1639: soc_name="A80";break; case 0x1667: soc_name="A33";break; case 0x1673: soc_name="A83T";break; @@ -492,6 +493,17 @@ sram_swap_buffers a31_sram_swap_buffers[] = { }; /* + * A64 has a large SRAM C at 0x18000, which we use as a backup storage + * for FEL stacks. Also the SPL load address is 0x1 and it makes this + * SoC rather unique. + */ +sram_swap_buffers a64_sram_swap_buffers[] = { + { .buf1 = 0x11800, .buf2 = 0x18000, .size = 0x800 }, + { .buf1 = 0x15C00, .buf2 = 0x18800, .size = 0x8000 - 0x5C00 }, + { 0 } /* End of the table */ +}; + +/* * Use the SRAM section at 0x44000 as the backup storage. This is the memory, * which is normally shared with the OpenRISC core (should we do an extra check * to ensure that this core is powered off and can't interfere?). @@ -542,6 +554,13 @@ soc_sram_info soc_sram_info_table[] = { .swap_buffers = ar100_abusing_sram_swap_buffers, }, { + .soc_id = 0x1689, /* Allwinner A64 */ + .spl_addr = 0x1, + .scratch_addr = 0x11000, + .thunk_addr = 0x1AE00, .thunk_size = 0x200, + .swap_buffers = a64_sram_swap_buffers, + }, + { .soc_id = 0x1673, /* Allwinner A83T */ .scratch_addr = 0x1000, .thunk_addr = 0x46E00, .thunk_size = 0x200, @@ -840,8 +859,8 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle *usb, * checks needs to be relaxed). */ - /* Basically, ignore M/Z/I bits and expect no TEX remap */ - if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) { + /* Basically, ignore V/M/Z/I/UNK bits and expect no TEX remap */ + if ((sctlr & ~((3 << 11) | (1 << 6) | 1)) != 0x00C50038) { fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr); exit(1); } -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands
The read/write operations done by FEL are not suitable for accessing hardware registers. For example, trying to read a SID value using the "read" or "hexdump" commands results in the following: $ sunxi-fel hexdump 0x01c23800 4 01c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __ Apparently, FEL tries to read data one byte at a time and this does not always work correctly. Introducing new commands to explicitly do 32-bit reads and writes helps: $ sunxi-fel readl 0x01c23800 0x16254187 Signed-off-by: Siarhei Siamashka --- fel.c | 44 1 file changed, 44 insertions(+) diff --git a/fel.c b/fel.c index a597e11..d3d6f62 100644 --- a/fel.c +++ b/fel.c @@ -654,6 +654,38 @@ void aw_write_arm_cp_reg(libusb_device_handle *usb, soc_sram_info *sram_info, aw_fel_execute(usb, sram_info->scratch_addr); } +uint32_t aw_fel_readl(libusb_device_handle *usb, uint32_t addr) +{ + soc_sram_info *sram_info = aw_fel_get_sram_info(usb); + uint32_t val = 0; + uint32_t arm_code[] = { + htole32(0xe59f0008), /* ldrr0, [pc, #8] */ + htole32(0xe590), /* ldrr0, [r0] */ + htole32(0xe58f), /* strr0, [pc] */ + htole32(0xe12fff1e), /* bx lr */ + htole32(addr) + }; + aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code)); + aw_fel_execute(usb, sram_info->scratch_addr); + aw_fel_read(usb, sram_info->scratch_addr + 16, &val, sizeof(val)); + return le32toh(val); +} + +void aw_fel_writel(libusb_device_handle *usb, uint32_t addr, uint32_t val) +{ + soc_sram_info *sram_info = aw_fel_get_sram_info(usb); + uint32_t arm_code[] = { + htole32(0xe59f0008), /* ldrr0, [pc, #8] */ + htole32(0xe59f1008), /* ldrr1, [pc, #8] */ + htole32(0xe5801000), /* strr1, [r0] */ + htole32(0xe12fff1e), /* bx lr */ + htole32(addr), + htole32(val) + }; + aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code)); + aw_fel_execute(usb, sram_info->scratch_addr); +} + void aw_enable_l2_cache(libusb_device_handle *usb, soc_sram_info *sram_info) { uint32_t arm_code[] = { @@ -1314,6 +1346,8 @@ int main(int argc, char **argv) " hex[dump] address lengthDumps memory region in hex\n" " dump address length Binary memory dump\n" " exe[cute] address Call function address\n" + " readl address Read 32-bit value from device memory\n" + " writel address valueWrite 32-bit value to device memory\n" " read address length fileWrite memory contents into file\n" " write address file Store file contents into memory\n" " write-with-progress addr file \"write\" with progress bar\n" @@ -1380,6 +1414,16 @@ int main(int argc, char **argv) } else if (strncmp(argv[1], "dump", 4) == 0 && argc > 3) { aw_fel_dump(handle, strtoul(argv[2], NULL, 0), strtoul(argv[3], NULL, 0)); skip = 3; + } else if (strcmp(argv[1], "readl") == 0 && argc > 2) { + uint32_t addr = strtoul(argv[2], NULL, 0); + uint32_t val = aw_fel_readl(handle, addr); + printf("0x%08x\n", val); + skip = 2; + } else if (strcmp(argv[1], "writel") == 0 && argc > 2) { + uint32_t addr = strtoul(argv[2], NULL, 0); + uint32_t val = strtoul(argv[3], NULL, 0); + aw_fel_writel(handle, addr, val); + skip = 3; } else if (strncmp(argv[1], "exe", 3) == 0 && argc > 2) { aw_fel_execute(handle, strtoul(argv[2], NULL, 0)); skip=3; -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 1/7] fel: Move backup area to higher addresses in SRAM on A10/A13/A20
Previously the backup area was allocated at the address 0x8000. This is not very good because it means that the U-Boot SPL can only safely use memory at addresses 0x-0x7FFF (32 KiB). But if we move the backup area to the end of the SRAM A4, this can allow U-Boot SPL to use memory 0x-0x9FFF (40 KiB). The BROM can't load such large SPLs from the SD card. But the SPL still can move its stack up to the 40 KiB boundary or do UCL or LZO decompression at runtime to squeeze more code into it. This patch makes the sunxi-fel tool compatible with 40 KiB SPLs, even though the current U-Boot releases do not use them yet. Signed-off-by: Siarhei Siamashka --- fel.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/fel.c b/fel.c index 59f0f72..0da3dc7 100644 --- a/fel.c +++ b/fel.c @@ -464,13 +464,17 @@ typedef struct { * at 0x2000 (and growing down) for the IRQ handler. And another one at 0x7000 * (and also growing down) for the regular code. In order to use the whole * 32 KiB in the A1/A2 sections of SRAM, we need to temporarily move these - * stacks elsewhere. And the addresses above 0x7000 are also a bit suspicious, - * so it might be safer to backup the 0x7000-0x8000 area too. On A10/A13/A20 - * we can use the SRAM section A3 (0x8000) for this purpose. + * stacks elsewhere. And the addresses 0x7D00-0x7FFF contain something + * importantant too (overwriting them kills FEL). On A10/A13/A20 we can use + * the SRAM sections A3/A4 (0x8000-0xBFFF) for this purpose. */ sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = { - { .buf1 = 0x01800, .buf2 = 0x8000, .size = 0x800 }, - { .buf1 = 0x05C00, .buf2 = 0x8800, .size = 0x8000 - 0x5C00 }, + /* 0x1C00-0x1FFF (IRQ stack) */ + { .buf1 = 0x01C00, .buf2 = 0xA400, .size = 0x0400 }, + /* 0x5C00-0x6FFF (Stack) */ + { .buf1 = 0x05C00, .buf2 = 0xA800, .size = 0x1400 }, + /* 0x7C00-0x7FFF (Something important) */ + { .buf1 = 0x07C00, .buf2 = 0xBC00, .size = 0x0400 }, { 0 } /* End of the table */ }; @@ -490,21 +494,21 @@ soc_sram_info soc_sram_info_table[] = { { .soc_id = 0x1623, /* Allwinner A10 */ .scratch_addr = 0x2000, - .thunk_addr = 0xAE00, .thunk_size = 0x200, + .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, .needs_l2en = 1, }, { .soc_id = 0x1625, /* Allwinner A13 */ .scratch_addr = 0x2000, - .thunk_addr = 0xAE00, .thunk_size = 0x200, + .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, .needs_l2en = 1, }, { .soc_id = 0x1651, /* Allwinner A20 */ .scratch_addr = 0x2000, - .thunk_addr = 0xAE00, .thunk_size = 0x200, + .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, }, { -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 2/7] fel: Rename the backup buffers which use AR100 (OpenRISC) SRAM
That would be a more appropriate name. And A31 is going to implement this in a different way and give the SRAM back to OpenRISC. Signed-off-by: Siarhei Siamashka --- fel.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/fel.c b/fel.c index 0da3dc7..419f16a 100644 --- a/fel.c +++ b/fel.c @@ -479,12 +479,11 @@ sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = { }; /* - * A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000. - * So we use the SRAM section at 0x44000 instead. This is the memory, which - * is normally shared with the OpenRISC core (should we do an extra check to - * ensure that this core is powered off and can't interfere?). + * Use the SRAM section at 0x44000 as the backup storage. This is the memory, + * which is normally shared with the OpenRISC core (should we do an extra check + * to ensure that this core is powered off and can't interfere?). */ -sram_swap_buffers a31_sram_swap_buffers[] = { +sram_swap_buffers ar100_abusing_sram_swap_buffers[] = { { .buf1 = 0x01800, .buf2 = 0x44000, .size = 0x800 }, { .buf1 = 0x05C00, .buf2 = 0x44800, .size = 0x8000 - 0x5C00 }, { 0 } /* End of the table */ @@ -515,32 +514,32 @@ soc_sram_info soc_sram_info_table[] = { .soc_id = 0x1650, /* Allwinner A23 */ .scratch_addr = 0x2000, .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = a31_sram_swap_buffers, + .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1633, /* Allwinner A31 */ .scratch_addr = 0x2000, .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = a31_sram_swap_buffers, + .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1667, /* Allwinner A33 */ .scratch_addr = 0x2000, .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = a31_sram_swap_buffers, + .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1673, /* Allwinner A83T */ .scratch_addr = 0x2000, .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = a31_sram_swap_buffers, + .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1680, /* Allwinner H3 */ .scratch_addr = 0x2000, .mmu_tt_addr = 0x44000, .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = a31_sram_swap_buffers, + .swap_buffers = ar100_abusing_sram_swap_buffers, }, { 0 } /* End of the table */ }; -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 5/7] fel: Move the temporary scratch buffer under the IRQ stack
Doing certain operations may need uploading and executing code on the device. For example, such operations right now are reading/writing ARM CP15 coprocessor registers. Uploading the code to the device is naturally overwriting some part of SRAM as a side effect. Right now it is not a problem, because the CP15 coprocessor registers are only accessed as part of uploading and executing U-Boot SPL. They are nicely timed not to cause problems and the temporary scratch area gets overwritten by the SPL code anyway. But if we decide to provide access to such operations via command line interface, then any side effects may potentially cause problems for the users. Consider the following scenario: sunxi-fel clear 0x2000 0x100 \ advanced-command-which-uploads-and-executes-code \ hexdump 0x2000 0x100 The user may rightfully expect that clearing a buffer in SRAM to zero and then reading it back should show all zero bytes. But inserting advanced commands in the middle may cause data corruption. In order to resolve this problem, just move the scratch area away from the 0x2000-0x5BFF addresses range. These particular addresses are already known to the users as a safe place for their bare metal expariments in FEL mode. The "sunxi-fel spl" command is a special case though and it is expected to overwrite data in this area too. A possible alternative would be to just backup & restore data in the scratch area. But this has some disadvantages: 1. Extra code in the sunxi-fel tool and extra roundtrips over USB to do the backup/restore job. 2. If we allow the OpenRISC core to use the 0x2000-0x5C00 range in SRAM A1, then this becomes unsafe and racy (we can't really backup & restore data without causing a temporarily glitch for the currently running code on the OpenRISC core). To sum it up. With this patch we make it so that now the 0x2000-0x5BFF range is freely available for the users of the sunxi-fel tool. The 0x1000-0x1FFF range is off limits (the upper part of it is used by the FEL IRQ handler, the lower part of it is reserved for internal use by the sunxi-fel tool). The 0x-0x1FFF addresses range is reserved for passing data from the SPL to the main U-Boot binary (via the SPL header) and is also off limits. Signed-off-by: Siarhei Siamashka --- fel.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/fel.c b/fel.c index 40cb82a..a597e11 100644 --- a/fel.c +++ b/fel.c @@ -505,51 +505,51 @@ sram_swap_buffers ar100_abusing_sram_swap_buffers[] = { soc_sram_info soc_sram_info_table[] = { { .soc_id = 0x1623, /* Allwinner A10 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, .needs_l2en = 1, }, { .soc_id = 0x1625, /* Allwinner A13 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, .needs_l2en = 1, }, { .soc_id = 0x1651, /* Allwinner A20 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a13_a20_sram_swap_buffers, }, { .soc_id = 0x1650, /* Allwinner A23 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0x46E00, .thunk_size = 0x200, .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1633, /* Allwinner A31 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0x22E00, .thunk_size = 0x200, .swap_buffers = a31_sram_swap_buffers, }, { .soc_id = 0x1667, /* Allwinner A33 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0x46E00, .thunk_size = 0x200, .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1673, /* Allwinner A83T */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .thunk_addr = 0x46E00, .thunk_size = 0x200, .swap_buffers = ar100_abusing_sram_swap_buffers, }, { .soc_id = 0x1680, /* Allwinner H3 */ - .scratch_addr = 0x2000, + .scratch_addr = 0x1000, .mmu_tt_addr = 0x8000, .thunk_addr = 0xA200, .thunk_size = 0x200, .swap_buffers = a10_a1
[linux-sunxi] [PATCH sunxi-tools 3/7] fel: Move the backup storage to the SRAM B on A31
This allows the SRAM section A2 to be exclusively used by the OpenRISC core. Regarding the potential U-Boot SPL size. The SRAM section A1 only has 32 KiB. But at least the stack can be set at the end of the SRAM section B. Or runtime UCL or LZO decompression can be used to unpack the SPL code to 0x24000-0x2 and have 48 KiB of available space there. Signed-off-by: Siarhei Siamashka --- fel.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/fel.c b/fel.c index 419f16a..71b12b5 100644 --- a/fel.c +++ b/fel.c @@ -479,6 +479,19 @@ sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = { }; /* + * A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000. + * So we use the SRAM section B at 0x2-0x2 instead. In the FEL mode, + * the MMU translation table is allocated by the BROM at 0x2. But we can + * also safely use it as the backup storage because the MMU is temporarily + * disabled during the time of the SPL execution. + */ +sram_swap_buffers a31_sram_swap_buffers[] = { + { .buf1 = 0x01800, .buf2 = 0x2, .size = 0x800 }, + { .buf1 = 0x05C00, .buf2 = 0x20800, .size = 0x8000 - 0x5C00 }, + { 0 } /* End of the table */ +}; + +/* * Use the SRAM section at 0x44000 as the backup storage. This is the memory, * which is normally shared with the OpenRISC core (should we do an extra check * to ensure that this core is powered off and can't interfere?). @@ -519,8 +532,8 @@ soc_sram_info soc_sram_info_table[] = { { .soc_id = 0x1633, /* Allwinner A31 */ .scratch_addr = 0x2000, - .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = ar100_abusing_sram_swap_buffers, + .thunk_addr = 0x22E00, .thunk_size = 0x200, + .swap_buffers = a31_sram_swap_buffers, }, { .soc_id = 0x1667, /* Allwinner A33 */ -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 4/7] fel: Move the backup storage to the SRAM section A1 on H3
This allows the SRAM section A2 to be exclusively used by the OpenRISC core. There are no substantial differences between H3 and A10/A13/A20. It just has 64 KiB of SRAM starting at the address 0x0 instead of 48 KiB. Signed-off-by: Siarhei Siamashka --- fel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fel.c b/fel.c index 71b12b5..40cb82a 100644 --- a/fel.c +++ b/fel.c @@ -550,9 +550,9 @@ soc_sram_info soc_sram_info_table[] = { { .soc_id = 0x1680, /* Allwinner H3 */ .scratch_addr = 0x2000, - .mmu_tt_addr = 0x44000, - .thunk_addr = 0x46E00, .thunk_size = 0x200, - .swap_buffers = ar100_abusing_sram_swap_buffers, + .mmu_tt_addr = 0x8000, + .thunk_addr = 0xA200, .thunk_size = 0x200, + .swap_buffers = a10_a13_a20_sram_swap_buffers, }, { 0 } /* End of the table */ }; -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-tools 0/7] fel: OpenRISC preparations and A64 support
The current sunxi-fel tool uses SRAM A2 as a backup storage for FEL stacks and a place to allocate the MMU translation table. But SRAM A2 is the fastest memory for the OpenRISC core and should be reserved for OpenRISC if we want to use it on A31/H3/A64. This patchset moves the FEL stacks backup storage and the MMU translation table to other SRAM areas. This fixes problems with the ar100-info application in the case when it is used after the DRAM is initialized by the "sunxi-fel spl" command (having the MMU table overwritten in SRAM A2 by the OpenRISC code is not good). Also because the SRAM layout gets changed anyway, ensure that the contiguous SRAM area available to the SPL is at least 40 KiB. The extra area beyond 32 KiB can be used at least for the stack and also provides an opportunity to support "oversized" SPL via LZO or UCL runtime decompression in the future. New readl/writel commands for reading/writing hardware registers, which can be used for various useful things (a more advanced OpenRISC support will need this functionality). The last patch (unrelated to the OpenRISC core) adds USB FEL boot support for Allwinner A64. Siarhei Siamashka (7): fel: Move backup area to higher addresses in SRAM on A10/A13/A20 fel: Rename the backup buffers which use AR100 (OpenRISC) SRAM fel: Move the backup storage to the SRAM B on A31 fel: Move the backup storage to the SRAM section A1 on H3 fel: Move the temporary scratch buffer under the IRQ stack fel: Add "readl" and "writel" commands fel: Add fel spl command support for Allwinner A64 fel.c | 135 -- 1 file changed, 107 insertions(+), 28 deletions(-) -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64, arisc, SCPI and regulator handling
dling directly from the ARM core (as it > has been done for all other Allwinner SoCs) and not use the arisc > at all if that is technically feasible. Well, this would prevent us from ever having a decent suspend support among other things. PS. As you can see from my last linux-sunxi wiki edits, I've been doing some OpenRISC hacking recently. The ar100-info application [1] got Allwinner H3 support and everyone is welcome to try it on the boards like Orange Pi PC. I also have some sunxi-tools improvements in the queue, which are going to make developing code for the OpenRISC core and debugging it much easier. Wanted to make an announcement when everything is ready, but you are kinda pushing me to let the cat out of the bag prematurely :-) [1] https://github.com/skristiansson/ar100-info -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: fel-sdboot.sunxi problems on Cubietruck and A20-OLinuXino-MICRO
On Fri, 1 Jan 2016 12:38:53 +0900 Naoki FUKAUMI wrote: > in addition to add "-marm" to gcc, add "-R .note.gnu.build-id" to objcopy. I would appreciate if somebody could submit a complete patch with the necessary fixes and a proper commit message. Of course, it also needs to be tested and confirmed to actually help. If nothing happens in a reasonable timeframe, I will probably try to download the problematic toolchain and find a way to experiment with it myself. That said, I generally don't like downloading an running third-party binary blobs on my computer. Thanks! -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Another take on sunxi-tools.
Hello Eddy, On Tue, 5 Jan 2016 22:55:40 -0500 Eddy Beaupré wrote: > A few weeks ago, i kinda got angry at the command line parser of > sunxi-nand-part and its inability to figure out on what kind of device > it is running. What started as a simple hack to at least make it figure > out the current partition scheme of the device became a complete rewrite. > > My version can create, delete, and insert partitions, it can create a > brand new MBR on the device, it can work on image file directly. It can > do silly things like creating a SUN4I partition on a SUN7I device. It > can backup or restore MBR, and it can figure out the current type of > partition. Thanks for announcing your work on the mailing list. Just as I said in the github pull request, any useful improvements to the 'sunxi-nand-part' are welcome: https://github.com/linux-sunxi/sunxi-tools/pull/36#issuecomment-167857022 I understand that you feel that the current 'sunxi-nand-part' is not perfect and deserves a "complete rewrite". I don't know if there are many users of the current version of the 'sunxi-nand-part' tool, but we have it packaged in the Linux distributions. And we want to ensure a smooth and painless upgrade for them. Basically, if you want this tool to be used by the other people, a usable howto documentation would really help a lot. The easiest and least time consuming way to draft such documentation is to use the wiki. But any other forms of documentation are also welcome. For example, the USB boot feature is documented at: https://linux-sunxi.org/FEL/USBBoot But NAND support still seems to be in a relatively bad shape (both the code and the documentation). Now you may have implemented a perfect tool, but many people will not be able to use it until they get a decent howto guide. Going forward, sunxi-tools will probably eventually gain the ability to backup/restore NAND (with some help from U-Boot) and also parse the raw Allwinner's NAND images to extract FEX files. > Since that went well, i told myself, that i could probably make the > build process a little bit more user friendly, So i rewrote it to work > with autoconf/automake (forgetting that i already did that about 3 years > ago and it was already in another branch of the official sunxi-tools). > But did it more wisely this time. > > Each tool is built by its own set of tools. The main builder just try to > figure out what tools can be build and chain them, It can cross-compile > almost everything (the only tool that can't be cross-compiled is > sunxi-fel, because of its dependency with libusb). It will avoid doing > silly things (like build an x86 version of sunxi-pio). > > The main drawback of the new modular build system is its speed. It take > a whooping 2m7s on a Cubetruck to configure and build everything (tools > and bare metal tools). We basically follow what the distribution maintainers want (Debian, Fedora, Buildroot). There was a discussion on the mailing list some time ago and the consensus was that autotools is not a panacea and the current makefile based build system is good enough. Either way, this is completely orthogonal to the 'sunxi-nand-part' tool improvements. And if you are piling too many unrelated changes in one patch set, then reviewing it becomes unnecessarily difficult. > Another thing that bugged me was the lack of man pages, so i wrote a > bunch of man pages to document a bit each tools. That's a good point. The sunxi-tools package needs man pages. Patches are surely welcome. > To continue on what has been done, i added a sunxi- prefix to all the > tools that didn't had one. Even fex2bin and bin2fex are now prefixed > with sunxi- (sunxi-fexc now just check if bin2fex or fex2bin appear in > its executable name to select its mode, no longer an exact match). > > Since theses changes ended up with something very different than the > current tools, and after a little chat with Siarhei Siamashka, i think > the best thing to do is just keep all this as a fork of sunxi-tools and > not submit many many many patches and try to have this merge with the > official sunxi-tools. > > Everything is available on my fork if you want to play with it: > > https://github.com/armStrapTools/sunxi-tools Thanks! If your 'sunxi-nand-part' improvements are useful and people figure out how to use them, then these improvements will eventually find their way into https://github.com/linux-sunxi/sunxi-tools too. Again, as I mentioned in the github pull request, links to your git repository in the relevant sections of the linux-sunxi wiki will make your work easier to find and test. I personally have nothing against forks. Moreover, that's a great feature of git and provides a complete freedom of experimentat
Re: [linux-sunxi] [PATCH] Add FEX file for Foxconn Super Pi
On Wed, 6 Jan 2016 00:45:00 -0800 (PST) Hsüan-Ming Ko(vickycq) wrote: > Hello, > > This so-called 'Foxconn Super Pi' <http://linux-sunxi.org/Foxconn_Super_Pi> > is > a Foxconn redesigned Banana Pi with different PCB layout and connector > positions. Things are supposed to be compatible with the Banana Pi but > further tests must be conducted to confirm. > > This FEX file is retrieved from the manufacturer provided Android OS, with > no modifications applied. As expected it's more or less 'broken'. Fixes > will be submitted in upcoming patches. > > Thanks! > > Regards > > --- > sys_config/a20/superpi.fex | 1059 > > 1 file changed, 1059 insertions(+) > create mode 100644 sys_config/a20/superpi.fex > > diff --git a/sys_config/a20/superpi.fex b/sys_config/a20/superpi.fex Hi, Thanks. Would it be probably better to push it to sunxi-boards as "foxconn_superpi.fex" in order to avoid any potential namespace clashes with LeMaker, SinoVoip and any other possible contenders? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: fel-sdboot.sunxi problems on Cubietruck and A20-OLinuXino-MICRO
323945 cmp r1, r7 0x00346753 strh r7, [r4, r5] 0x0036f158 ldr r1, [r6, r3] 0x003829a9 add r1, sp, 0xa4 0x003af212 asrs r2, r6, 0xb 0x003cfd4d ldr r5, [pc, 0x3f4] ; [:4]=0xff00 ; 1076 0x003e5924 movs r4, 0x59 0x00401e98 ldr r0, [sp, 0x78] 0x00426ba7 adr r7, 0x1ac 0x0044004b ldr r3, [pc, 0] ; [:4]=0x0020 ; 'H' `=< 0x00461847 bx r3 0x00482000 movs r0, r4 0x004a invalid After doing some rather strange manipulations in the beginning, it tries to jump to 0x0020 in the end (the FEL handler address in the BROM). > > My random guess is that your toolchain is probably generating thumb2 > > code by default. We might need to add '-marm' option to CFLAGS in the > > makefile. > > Tried that, unfortunately doesn't help. Well, we do want to have 32-bit ARM code in "fel-sdboot.sunxi", so using the -marm option in the makefile would be still the right thing to do. Your toolchain may be still problematic though. Because even after artificially adding -mthumb option when using my toolchain, I get a much more reasonable short thumb2 code without any junk in the beginning: $ r2 -a arm -b 16 fel-sdboot.sunxi [0x]> s 0x20 [0x0020]> pd 0x002008b5 push {r3, lr} 0x0022014b ldr r3, [pc, 4] ; [:4]=0x0020 ; '(' 0x00249847 blx r3 0x002608bd pop {r3, pc} 0x00282000 movs r0, r4 0x002a invalid -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: fel-sdboot.sunxi problems on Cubietruck and A20-OLinuXino-MICRO
00465474f4e cdpmi p7, 4, c4, c15, c5, 3 | 0x00082e425430 subslo r4, r4, lr, lsr 4 | 0x000c2cc70742 andmi ip, r7, 0xb0 | 0x00100002 andeq r0, r0, r0, lsl 4 | 0x0014 andeq r0, r0, r0 | 0x0018 andeq r0, r0, r0 | 0x001c andeq r0, r0, r0 `-> 0x002008402de9 push {r3, lr} 0x002408309fe5 ldr r3, [pc, 8] ; [:4]=0x0020 ; '4' 0x00280fe0a0e1 mov lr, pc ,==< 0x002c13ff2fe1 bx r3 |0x00300880bde8 pop {r3, pc} My random guess is that your toolchain is probably generating thumb2 code by default. We might need to add '-marm' option to CFLAGS in the makefile. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: PSCI for H3
On Wed, 23 Dec 2015 22:36:19 +0800 Chen-Yu Tsai wrote: > On Wed, Dec 23, 2015 at 6:14 PM, Siarhei Siamashka > wrote: > > On Tue, 17 Nov 2015 15:32:30 +0100 > > Jens Kuske wrote: > > > >> On 16/11/15 07:26, Chen-Yu Tsai wrote: > >> > Hi everyone, > >> > > >> > I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch > >> > that > >> > includes Jens' patches. > >> > > >> > For PSCI and SMP, it seems the H3 follows the structure of previous > >> > sun8i SoCs. > >> > The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll > >> > have to > >> > dig through the SDK. > >> > > >> > One other thing is the SMTA, or Secure Memory Touch Arbiter, which we > >> > last > >> > encountered issues with on the A31s. This controls non-secure access to > >> > a whole > >> > bunch of peripherals, which we'll need to enable for Linux to run > >> > non-secure. > >> > >> There is also register 0x2f0 in the CCU, it defaults to disabling > >> non-secure access to all clock registers. > >> > >> Jens > >> > > > > How about just enabling SMP on Allwinner H3 in an old unfashionable way > > while all these non-secure access limiters are still being under > > investigation? > > I'm not against it, though I was considering removing the SMP code. > > BTW, without docs on the PRCM, do we know if the H3 has the same power clamps > as the A31? FYI the A23 SMP code is the same as A31, just without the power > clamps. Yes. I inspected the kernel sources from the Allwinner SDK and it looks like A31 and H3 are taking exactly the same code path (using the same ifdef guards everywhere): https://github.com/allwinner-zh/linux-3.4-sunxi/blob/55599b8209bb7150140e4d45ef460dbff6c876dd/arch/arm/mach-sunxi/include/mach/sun8i/platsmp.h#L124-L139 "SUN8IW1 = A31" and "SUN8IW7 = H3" according to http://linux-sunxi.org/Allwinner_SoC_Family#2013_naming_scheme_change I'll also try to see if I can get PSCI working on H3, but it seems to be a real PITA to debug. Also some parts of the H3 documentation are missing (PRCM is a good example) and if there happens to be an undocumented configuration knob responsible to allowing non-secure access to some important resource, then we hit a brick wall... -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: PSCI for H3
On Tue, 17 Nov 2015 15:32:30 +0100 Jens Kuske wrote: > On 16/11/15 07:26, Chen-Yu Tsai wrote: > > Hi everyone, > > > > I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch that > > includes Jens' patches. > > > > For PSCI and SMP, it seems the H3 follows the structure of previous sun8i > > SoCs. > > The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll > > have to > > dig through the SDK. > > > > One other thing is the SMTA, or Secure Memory Touch Arbiter, which we last > > encountered issues with on the A31s. This controls non-secure access to a > > whole > > bunch of peripherals, which we'll need to enable for Linux to run > > non-secure. > > There is also register 0x2f0 in the CCU, it defaults to disabling > non-secure access to all clock registers. > > Jens > How about just enabling SMP on Allwinner H3 in an old unfashionable way while all these non-secure access limiters are still being under investigation? diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi index 0faa38a..d23ed84 100644 --- a/arch/arm/boot/dts/sun8i-h3.dtsi +++ b/arch/arm/boot/dts/sun8i-h3.dtsi @@ -51,6 +51,7 @@ cpus { #address-cells = <1>; #size-cells = <0>; + enable-method = "allwinner,sun6i-a31"; cpu@0 { compatible = "arm,cortex-a7"; @@ -591,5 +592,15 @@ interrupts = , ; }; + + prcm@01f01400 { + compatible = "allwinner,sun8i-h3-prcm"; + reg = <0x01f01400 0x200>; + }; + + cpucfg@01f01c00 { + compatible = "allwinner,sun8i-h3-cpuconfig"; + reg = <0x01f01c00 0x300>; + }; }; }; diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c index e8483ec..8ca4064 100644 --- a/arch/arm/mach-sunxi/platsmp.c +++ b/arch/arm/mach-sunxi/platsmp.c @@ -44,6 +44,9 @@ static void __init sun6i_smp_prepare_cpus(unsigned int max_cpus) struct device_node *node; node = of_find_compatible_node(NULL, NULL, "allwinner,sun6i-a31-prcm"); + if (!node) + node = of_find_compatible_node(NULL, NULL, + "allwinner,sun8i-h3-prcm"); if (!node) { pr_err("Missing A31 PRCM node in the device tree\n"); return; @@ -57,6 +60,9 @@ static void __init sun6i_smp_prepare_cpus(unsigned int max_cpus) node = of_find_compatible_node(NULL, NULL, "allwinner,sun6i-a31-cpuconfig"); + if (!node) + node = of_find_compatible_node(NULL, NULL, + "allwinner,sun8i-h3-cpuconfig"); if (!node) { pr_err("Missing A31 CPU config node in the device tree\n"); return; -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support
Hi, On Wed, 16 Dec 2015 10:11:38 +0100 Hans de Goede wrote: > Hi, > > On 16-12-15 08:35, Siarhei Siamashka wrote: > > On Thu, 10 Dec 2015 04:31:05 -0800 (PST) > > Thomas Kaiser wrote: > > > >> Hi, > >> > >> Hans de Goede wrote: > >>> > >>> ? if I understand things correctly your patch make lima-memtester pass > >>> at 672 MHz (which is our current configured speed) on both your > >>> and Siarhei's boards, to me that seems that it fixes things. > >>> > >> > >> A few more boards were tested but 672 MHz seem still questionable: > >> > >> http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit > >> http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=257&pid=7465 > >> > > > > Yes, the 672 MHz DRAM clock speed does not look like a good choice > > for Orange Pi PC. Either we find better delays & zq settings and > > improve reliability, or the DRAM clock speed needs to be decreased > > (also ensuring a little bit of safety headroom). > > > >> (the latter interesting since he uses a huge 35x35x25mm heatsink that > >> covers also DRAM) > > > > Some outliers are always possible and we have only one sample, which > > can be clocked somewhat higher than the others. It is hard to make any > > conclusions with the available data and the heatsink may be unrelated. > > > > Unless we get more test results in a few days which radically change > > the statistics, probably using 624 MHz for DRAM on Orange Pi PC would > > be reasonable. > > Reducing the DRAM speed to 624 seems like a good idea to me, can someone > send me a patch for this please? We still have a hope to collect more statistics at: http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit The Orange Pi PC DRAM clock speed needs to be adjusted before the U-Boot v2016.01 release, and we still have to decide what would be the best default. But the time is running out. So if anyone wants to do a useful contribution by submitting lima-memtester results from his/her Orange Pi PC board, then now is the last chance. Steven, if you have access to many Orange Pi PC boards, maybe you could try to run some tests on them too? -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC
On Sat, 19 Dec 2015 22:18:28 +0100 Thomas Kaiser wrote: > Siarhei Siamashka wrote: > > > It's likely that the credit for "unlocking" the 1.5 GHz clock speed > > actually belongs to third-party modders. > > Thanks for clarifying this (and all the additional informations). I'll > try to correct this where I spread wrong "informations"/assumptions > asapissimo. > > > As there were no real objections, I have just pushed the Orange Pi PC > > fex file to the sunxi-boards repository. This makes it the first FEX > > file for the H3 SoC :-) > > Great. Only one single question (I've overlooked before). Why > > boot_clock = 1200 > > (especially since you wrote about SY8106A's default 1.2V voltage being > safe for operation at 1008 MHz) Thanks, that was a good question. The "boot_clock" parameter is not used by the linux kernel. It's the Allwinner's bootloader thing. You can grep the H3 SDK sources to check this. As for the other things left to do, the DRAM clock speed needs to be adjusted in the FEX file after we find a reasonable default DRAM clock speed. The reason is that on every cooling state change in the 3.4 kernel (after crossing any temperature threshold, for example 70C), there is a hook into the DRAM reclocking code. This code simply sets 480MHz DRAM clock speed if the temperature is 100C or higher. And if the temperature is below 100C, then the dram clock value from FEX is used. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC
On Wed, 9 Dec 2015 00:40:18 -0800 (PST) Thomas Kaiser wrote: > Siarhei Siamashka: > > > Extracted from the Lubuntu_1404_For_OrangePiPC_v0_8_0_.img.xz image: > > > > http://www.orangepi.org/downloadresources/orangepipc/oragepipc_4a0e8d960f7f0a52606dfaba58.html > > > > > > Not necessarily the best one > > > > This is the worst one since it's the origin of all thermal problems with > Orange Pis It is not the worst one. This particular FEX file only allows clock speeds up to 1.2 GHz because the CPU clock frequency must satisfy *both* cpufreq and also cooling state requirements at once. Yes, the cpufreq table lists 1.5GHz as the maximum clock frequency. But at the same time, the highest cooling state only allows 4 cores running at 1.2GHz in this FEX. I had some explanations about this in my third patch "h3: Update cpufreq and cooling state tables on Orange Pi PC". It's likely that the credit for "unlocking" the 1.5 GHz clock speed actually belongs to third-party modders. > and the result of product marketing: Advertising the H3 to be > able to run at "up to 1.6Ghz". Right now http://www.orangepi.org/orangepipc/ page does not say anything about the CPU clock frequency. I guess, there was a time period when nobody had any idea about what would be the CPU clock speed limit because Allwinner does not really provide this information in the H3 manual. Regarding the product marketing. The primary competitors are probably the Raspberry Pi 2 running at 900 MHz and the ODROID C1 running at 1.5 GHz. So 1.6 GHz would definitely look attractive in the marketing materials if this was true. It looks like H3 can be clocked at least up to 1.3 GHz with the CPU core voltage not exceeding the 1.4V limit specified in the H3 manual. But running all 4 cores at this clock speeds for prolonged periods of time may be difficult because of thermal throttling. On the other hand, a single-threaded workload at 1.3 GHz is probably perfectly fine. It's roughly the same as https://en.wikipedia.org/wiki/Intel_Turbo_Boost Intel is playing safe and provides two clock frequencies in the marketing materials (the "nominal" clock frequency and the "boosted" one). Maybe that's the way to go? A heatsink is just an optional performance feature, which may allow your system to run faster and keep the cores always running at full speed. It is not necessary for reliable operation, but the peak performance may degrade without it. > All Steven did was to increase clockspeeds > and to adjust the Vcore voltage of the two available operting points in the > dvs table he took from Draco by 200mV (to be able to reach the > extremity_freq as scaling_max_freq). > > And the result is that everyone using OS images for H3 based Orange Pi > models has to suffer from heat/stability problems. When you replace this > moronic dvfs table with something sane (a few more operating points and not > only 2 already exceeding the recommended maximum values), you won't even > need a heatsink: > > http://linux-sunxi.org/User_talk:Tkaiser#Lessons_to_learn_from_Xunlong > > With Xunlong's dvfs settings switching between 1.2 Ghz and 1.56 GHz *while > being idle* the SoC's temperature increases by 12°C. > > I don't know what I'm doing wrong but I can fire up cpuburn-a7 running on > all 4 CPU cores at 1.2Ghz on my Orange Pi PC without thermal throttling, > without CPU cores being dropped and also without heatsink/fan attached. Can > please anyone explain to me what's wrong with my Orange Pi? This is called undervolting. With overclocking one is pushing the absolute performance limits. And with undervolting one pushing the performance/watt limits. But there is some variation in voltage tolerances between different samples, so sufficient safety headroom must be provided in the general purpose configuration to make it suitable for everyone. Even if you can reduce the voltage to the very minimum on your board, this does not automatically mean that any other guy with a different Orange Pi PC board would be also able to use the same voltage safely. As there were no real objections, I have just pushed the Orange Pi PC fex file to the sunxi-boards repository. This makes it the first FEX file for the H3 SoC :-) -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] sunxi-tools: some trivial fixes
On Wed, 16 Dec 2015 12:14:10 +0100 Bernhard Nortmann wrote: > Am 16.12.2015 um 08:16 schrieb Siarhei Siamashka: > > [...] > > After this change, now both "spl" and "uboot" commands always execute > > U-Boot in the end :-( > > > > Right now I'm playing with AR100 (an extra OpenRISC core in H3) and a > > properly working "spl" command in "sunxi-fel" is quite useful for > > initializing DRAM before uploading and running some OpenRISC code. > > > > [...] > > > > Well, last minute changes are always a sort of a lottery. It would > > have been a bit nicer if we did not include this bug into a "release > > point" ;-) > > Ouch. Well, I guess it kind of proves your point... :-P Fix attached. > > Regards, B. Nortmann Thanks, reviewed and pushed to sunxi-tools git. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support
On Thu, 10 Dec 2015 10:29:52 +0100 Jens Kuske wrote: > On 10/12/15 03:13, Siarhei Siamashka wrote: > > Hello, > > > > On Wed, 9 Dec 2015 19:29:49 +0100 > > Jens Kuske wrote: > > > >> On 09/12/15 09:40, Siarhei Siamashka wrote: > >> The read delays (except for dqs) are doubled in boot0 before > >> writing them to the registers. Looks like they suddenly needed > >> higher values than possible with 4 bit. The register seems to > >> take 6 bit wide values. > > > > Well, we can always change the layout of data in this struct and > > allocate 8 bits per each delay value instead of 4 bits: > > > > struct dram_para para = { > > .read_delays = 0x7979, > > .write_delays = 0x6aaa, > > .dual_rank = 0, > > .bus_width = 32, > > .row_bits = 15, > > .page_size = 4096, > > }; > > > > Are they originally the 'tpr11' and 'tpr12' parameters from FEX? > > Yes, they are. I just gave them meaningful names. > Each nibble represents delay of one byte lane, the lower 4 for the DQ > lines, the upper 4 for the DQS/DQS# lines. > > > Maybe they belong in Kconfig, with a comment about how to do all > > the needed conversion from FEX (multiplication by 2)? > > If it turns out that they should be different between boards, sure. But > all FEX files I checked had the same values. Maybe the board vendors > don't even know about these, Allwinner provided these somewhat strange > numbers (why does lane 4 have a much shorter dqs write delay) and they > adopted them... It looks like exactly the same story as with A10/A13/A20. All the device vendors are using the same set of settings, while these settings are not necessarily optimal (or even good) specifically for their hardware. > Maybe something like this would be a good idea: > > CONFIG_DRAM_DQ_READ_DELAY = 0x0e120e12 > CONFIG_DRAM_DQS_READ_DELAY = 0x > CONFIG_DRAM_DQ_WRITE_DELAY = 0x > CONFIG_DRAM_DQS_WRITE_DELAY = 0x060a0a0a > > Or we find values that work well on all boards. This may be tricky. H3 still needs some automation. Because just randomly trying different settings in a manual way is not a very productive use of anyone's time. Also active users engagement is critical, or we have no chance to collect enough statistics from different board samples. Fortunately Orange Pi PC seems to be quite popular, so it is likely to be one of the best supported and well configured boards. Another alternative is the board manufacturer's engagement. > > BTW, do these delays serve a somewhat similar purpose as the 'tpr3' > > parameter in A10/A13/A20? Later we could adapt the a10-tpr3-scan > > script and make a h3 variant of it for bruteforce searching optimal > > values of these delays. > > I think they are comparable with tpr3. The hardware would even support > individual delays for each bit, but the combinations get endless then. Yes, A10/A13/A20 also had many configuration knobs. Some configuration knobs appear to be more important than the others in practice. This needs to be figured out in an experimental way. The Orange Pi PC has DDR3L-1600 memory chips. If the H3 DRAM controller configuration is the only limiting factor, then there may be potentially a way up to clock DRAM up to 800 MHz. And there is never too much memory bandwidth for graphics and multimedia :-) Still the first priority is of course trying to ensure reliable operation at the specified/advertised ~667 MHz. But I'm not sure if I want to do any work on this myself, unless enough people register their interest and at least promise to participate in testing. > > > > With the lima-memtester test failures, we have already discovered > > in an experimental way that correctly configuring these delays > > apparently affects reliability :-) > > > >> After fixing that, lima-memtester doesn't fail at 672 MHz anymore > >> on my Orange Pi Plus. Before it failed at 552 and higher. > >> Patch below. > > > > Thanks. With this U-Boot patch, lima-memtester does not fail anymore > > at 672 MHz on my Orange Pi PC board too. That's a major improvement > > over what is in U-boot 2016.01-rc2. If you are going to submit this > > patch to U-Boot, you can have my > > > > Tested-by: Siarhei Siamashka > > Should I submit it as a fix? I mean, it seems it doesn't really fix it > at least on some Orange Pi PCs, but only improves the situation. > My OPi Plus now passes 744 MHz too (maybe even higher, didn't try), so > there are definitely differences between the boards. We can always have this patch and also reduce the DRAM clock speed to a safer level. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support
On Thu, 10 Dec 2015 04:31:05 -0800 (PST) Thomas Kaiser wrote: > Hi, > > Hans de Goede wrote: > > > > ? if I understand things correctly your patch make lima-memtester pass > > at 672 MHz (which is our current configured speed) on both your > > and Siarhei's boards, to me that seems that it fixes things. > > > > A few more boards were tested but 672 MHz seem still questionable: > > http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit > http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect&goto=findpost&ptid=257&pid=7465 Yes, the 672 MHz DRAM clock speed does not look like a good choice for Orange Pi PC. Either we find better delays & zq settings and improve reliability, or the DRAM clock speed needs to be decreased (also ensuring a little bit of safety headroom). > (the latter interesting since he uses a huge 35x35x25mm heatsink that > covers also DRAM) Some outliers are always possible and we have only one sample, which can be clocked somewhat higher than the others. It is hard to make any conclusions with the available data and the heatsink may be unrelated. Unless we get more test results in a few days which radically change the statistics, probably using 624 MHz for DRAM on Orange Pi PC would be reasonable. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 1/2] sunxi-tools: some trivial fixes
On Thu, 19 Nov 2015 16:01:37 +0100 Bernhard Nortmann wrote: > - get rid of double includes > - fix U-Boot source reference > - get rid of "uboot_autostart" variable > > Signed-off-by: Bernhard Nortmann > --- > fel.c | 12 > 1 file changed, 4 insertions(+), 8 deletions(-) > > diff --git a/fel.c b/fel.c > index e9f6450..4561d02 100644 > --- a/fel.c > +++ b/fel.c > @@ -28,8 +28,6 @@ > #include > #include > #include > -#include > -#include > #include > #include > #include > @@ -988,8 +986,8 @@ int have_sunxi_spl(libusb_device_handle *usb, uint32_t > spl_addr) > > /* > * Pass information to U-Boot via specialized fields in the SPL header > - * (see "boot_file_head" in ${U-BOOT}/tools/mksunxiboot.c), providing > - * information about the boot script address (DRAM location of boot.scr). > + * (see "boot_file_head" in ${U-BOOT}/arch/arm/include/asm/arch-sunxi/spl.h), > + * providing the boot script address (DRAM location of boot.scr). > */ > void pass_fel_information(libusb_device_handle *usb, uint32_t script_address) > { > @@ -1054,7 +1052,6 @@ static double gettime(void) > > int main(int argc, char **argv) > { > - int uboot_autostart = 0; /* flag for "uboot" command = U-Boot autostart > */ > int rc; > libusb_device_handle *handle = NULL; > int iface_detached = -1; > @@ -1175,8 +1172,7 @@ int main(int argc, char **argv) > skip=2; > } else if (strcmp(argv[1], "uboot") == 0 && argc > 2) { > aw_fel_process_spl_and_uboot(handle, argv[2]); > - uboot_autostart = (uboot_entry > 0 && uboot_size > 0); > - if (!uboot_autostart) > + if (!uboot_entry) > printf("Warning: \"uboot\" command failed to > detect image! Can't execute U-Boot.\n"); > skip=2; > } else { > @@ -1188,7 +1184,7 @@ int main(int argc, char **argv) > } > > // auto-start U-Boot if requested (by the "uboot" command) > - if (uboot_autostart) { > + if (uboot_entry > 0 && uboot_size > 0) { > pr_info("Starting U-Boot (0x%08X).\n", uboot_entry); > aw_fel_execute(handle, uboot_entry); After this change, now both "spl" and "uboot" commands always execute U-Boot in the end :-( Right now I'm playing with AR100 (an extra OpenRISC core in H3) and a properly working "spl" command in "sunxi-fel" is quite useful for initializing DRAM before uploading and running some OpenRISC code. > } > Siarhei: Here are the proposed changes that I would like to go into > sunxi-tools, possibly before you tag a 1.3 release. It's not urgent > (could be postponed to a later point in time), but I think it would > be nice to include these into a "release point". Well, last minute changes are always a sort of a lottery. It would have been a bit nicer if we did not include this bug into a "release point" ;-) But better OpenRISC support still needs some other changes in sunxi-tools anyway. And we can probably introduce them in the next tagged release. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 3/3] sunxi-tools: README: Cross-compilation examples
On Wed, 2 Dec 2015 01:45:32 +0200 Justin Swartz wrote: > The meminfo example has been corrected to match the Makefile's > "sunxi-meminfo" target, and an example has been added for the > "sunxi-script_extractor" target. > > Signed-off-by: Justin Swartz > --- > README | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/README b/README > index 073b3ba..27742be 100644 > --- a/README > +++ b/README > @@ -57,15 +57,17 @@ phoenix_info: > phoenixcard utility and optionally extracts the embedded boot > code & firmware file from their hidden partitions. > > -meminfo: > +sunxi-meminfo: > Tool for reading DRAM settings from registers. Compiled as a > static binary for use on android and other OSes. To build this, > get a toolchain, and run: > - make CROSS_COMPILE=arm-linux-gnueabihf- meminfo > + make CROSS_COMPILE=arm-linux-gnueabihf- sunxi-meminfo > > -script-extractor: > +sunxi-script_extractor: > A simple tool, which can be executed on a rooted Android device > to dump the script.bin blob from RAM via reading /dev/mem. > + To build this, get a toolchain, and run: > + make CROSS_COMPILE=arm-linux-gnueabihf- sunxi-script_extractor > > This software is licensed under the terms of GPLv2+ as defined by the > Free Software Foundation, details can be read in the COPYING file. Thanks, pushed to git. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 2/3] sunxi-tools: Makefile: Add sunxi-script_extractor target
On Wed, 2 Dec 2015 01:45:31 +0200 Justin Swartz wrote: > Signed-off-by: Justin Swartz > --- > Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Makefile b/Makefile > index 53d6a0d..df7085a 100644 > --- a/Makefile > +++ b/Makefile > @@ -145,6 +145,9 @@ sunxi-bootinfo: bootinfo.c > sunxi-meminfo: meminfo.c > $(CROSS_COMPILE)gcc -g -O0 -Wall -static -o $@ $^ > > +sunxi-script_extractor: script_extractor.c > + $(CROSS_COMPILE)gcc -g -O0 -Wall -static -o $@ $^ > + > .gitignore: Makefile > @for x in $(TOOLS) $(FEXC_LINKS) $(TARGET_TOOLS) '*.o' '*.swp'; do \ > echo "$$x"; \ Thanks, pushed to git. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 1/3] sunxi-tools: script_extractor: bug fixes
Hello Justin, On Wed, 2 Dec 2015 01:45:30 +0200 Justin Swartz wrote: > Script size argument detection: argc should be greater than one, > rather than not equal to zero. > > Output loop termination: the index variable should be compared against > the value of the size variable, as opposed to the default SCRIPT_SIZE > definition. > > munmap: the mapping returned by mmap, addr, should be unmapped instead > of NULL. > > Signed-off-by: Justin Swartz > --- > script_extractor.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/script_extractor.c b/script_extractor.c > index 52d817f..bc67b7a 100644 > --- a/script_extractor.c > +++ b/script_extractor.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -34,13 +35,13 @@ int main(int argc, char *argv[]) { > fd = open("/dev/mem", O_RDONLY); > > size = SCRIPT_SIZE; > - if (argc) > + if (argc > 1) > size = atoi(argv[1]); > > addr = (char *)mmap(NULL, size, PROT_READ, MAP_SHARED, fd, > SCRIPT_START); > - for (i = 0; i < SCRIPT_SIZE; i++) > + for (i = 0; i < size; i++) > putchar(addr[i]); > - munmap(NULL, SCRIPT_SIZE); > + munmap(addr, size); > close(fd); > > return 0; Thanks for the patch. But looks like Hans de Goede has also independently encountered the same bugs and already fixed them: https://github.com/linux-sunxi/sunxi-tools/commit/55eec70ceafc4b8b25b4ddcd613c9ca10e41dcf7 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 6/9] sunxi-tools: Add file_size() and factor out a reusable file_upload()
On Mon, 7 Dec 2015 12:03:41 +0100 Bernhard Nortmann wrote: > Am 30.11.2015 um 12:30 schrieb Siarhei Siamashka: > > What if "name" is, for example, a directory instead of a file? > > > > [...] > > If the file does not exist, what is the "sunxi-fel" tool supposed to do? > > Do we want to silently ignore this? > > Agreed. That was too much on the "quick and dirty side". I've reworked > file_size() to give proper error messages, requiring to specify > a regular file. It's size may be 0 (no error). > > Considering your other comments for the patches that build on file_upload(), > I had to rethink that one too. What we actually want is a "multi_upload", > where the file count is possibly 1 (for the single-file commands), and the > ability to specify the progress callback routine to use. I've now chosen an > implementation of file_upload() that works on multiple file arguments (each > being an offset + filename pair), while accessing the command line arguments > as needed. Thanks for making these corrections. I have pushed your updated patches to the sunxi-tools git repository. If there are still some minor problems, they can be corrected separately before tagging the next sunxi-tools release. For example, I can see that the 'size_t' vs. 'unsigned int' problem strikes again: fel.c: In function ‘aw_write_buffer’: fel.c:299:4: warning: format ‘%X’ expects argument of type ‘unsigned int’, but argument 4 has type ‘size_t’ [-Wformat=] uboot_entry, uboot_entry + uboot_size); ^ But this had been already introduced as a part of the earlier patch set. I'm going to do a more thorough testing of this new code and will prepare the necessary fixes. It might be a good idea to also do some extra tests with valgrind and static code analysis tools. Thanks again. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v5 0/8] sunxi-tools: support progress display for FEL utility
On Mon, 7 Dec 2015 12:17:04 +0100 Bernhard Nortmann wrote: > Hi Siarhei! > > Am 30.11.2015 um 12:44 schrieb Siarhei Siamashka: > > Hello, > > > > I think that patches 1-5 can be pushed to github, even though I'm not > > completely happy about certain aspects of them. The patches 6-9 may > > need some additional fixes. > > > > Oh, by the way. The "sunxi-tools:" prefix in the commit summaries is > > redundant in the github repository (because we already know that the > > whole thing is "sunxi-tools"). A better prefix would be "fel:". This > > minor commit summary tweak can be done when pushing patches. > > > > Thanks for working on this. Looks like we are now very close to having > > a perfect progress bar implementation in sunxi-fel. > > > > I'll take that as your "ACK" and push those first five commits to the > sunxi-tools repo then (with the suggested fixes applied). > > Thanks for reviewing it all! Thanks. -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support
Hello, On Wed, 9 Dec 2015 19:29:49 +0100 Jens Kuske wrote: > On 09/12/15 09:40, Siarhei Siamashka wrote: > > Thanks for the explanations. I finally got lima-memtester up and > > running on H3 hardware (not that it was difficult, but just the amount > > of unnecessary compatibility breaks in the H3 SDK kernel was a bit > > unexpected and really discouraging, they are really doing almost > > *everything* in a different way compared to A10/A20 SDK kernel just > > for the sake of making things different): > > > > > > https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test > > > > Currently U-Boot v2016.01-rc2 fails the lima-memtester check unless > > the DRAM clock speed is reduced to 456 MHz on my Orange Pi PC. But > > if I use the boot0 bootloader to boot the same kernel image > > (uImage-3.4-sun8i-h3-lima-memtester), then the test works fine. > > This means that there must be still something wrong with the H3 > > DRAM init code in U-Boot, or maybe some clocks are wrong > > > > I tried to compare boot0 and the SDK source again and actually > found another difference. Did you dump the DRAM controller registers to find this difference between U-Boot and boot0? > The read delays (except for dqs) are doubled in boot0 before > writing them to the registers. Looks like they suddenly needed > higher values than possible with 4 bit. The register seems to > take 6 bit wide values. Well, we can always change the layout of data in this struct and allocate 8 bits per each delay value instead of 4 bits: struct dram_para para = { .read_delays = 0x7979, .write_delays = 0x6aaa, .dual_rank = 0, .bus_width = 32, .row_bits = 15, .page_size = 4096, }; Are they originally the 'tpr11' and 'tpr12' parameters from FEX? Maybe they belong in Kconfig, with a comment about how to do all the needed conversion from FEX (multiplication by 2)? BTW, do these delays serve a somewhat similar purpose as the 'tpr3' parameter in A10/A13/A20? Later we could adapt the a10-tpr3-scan script and make a h3 variant of it for bruteforce searching optimal values of these delays. With the lima-memtester test failures, we have already discovered in an experimental way that correctly configuring these delays apparently affects reliability :-) > After fixing that, lima-memtester doesn't fail at 672 MHz anymore > on my Orange Pi Plus. Before it failed at 552 and higher. > Patch below. Thanks. With this U-Boot patch, lima-memtester does not fail anymore at 672 MHz on my Orange Pi PC board too. That's a major improvement over what is in U-boot 2016.01-rc2. If you are going to submit this patch to U-Boot, you can have my Tested-by: Siarhei Siamashka Still increasing the DRAM clock speed even by one 24 MHz step to 696 MHz makes it fail again. So there does not seem to be much safety headroom available. I have prepared an updated v3 tarball with your fix and added a table to the wiki page: http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit Maybe other people could test their Orange Pi PC boards too in order to see if the results are generally similar, better or worse. Your Orange Pi Plus is a different board and may in theory have a slightly different DRAM tracks routing. > Maybe we could also replaced the setbits with writel, because I > don't see a good reason not to overwrite the registers, they are > all zero after reset and have 0x3f3f mask. Or maybe "clrsetbits_le32"? The use of "setbits_le32" indeed looks a bit strange here. I'm fine with "writel" too. In fact I would be fine with any fix that can quickly resolve the problem. > Jens > > > > diff --git a/arch/arm/cpu/armv7/sunxi/dram_sun8i_h3.c > b/arch/arm/cpu/armv7/sunxi/dram_sun8i_h3.c > index b721d60..03bd013 100644 > --- a/arch/arm/cpu/armv7/sunxi/dram_sun8i_h3.c > +++ b/arch/arm/cpu/armv7/sunxi/dram_sun8i_h3.c > @@ -73,10 +73,10 @@ static void mctl_dq_delay(u32 read, u32 write) > > for (i = 0; i < 4; i++) { > val = DATX_IOCR_WRITE_DELAY((write >> (i * 4)) & 0xf) | > - DATX_IOCR_READ_DELAY((read >> (i * 4)) & 0xf); > + DATX_IOCR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2); > > for (j = DATX_IOCR_DQ(0); j <= DATX_IOCR_DM; j++) > - setbits_le32(&mctl_ctl->datx[i].iocr[j], val); > + writel(val, &mctl_ctl->datx[i].iocr[j]); > } > > clrbits_le32(&mctl_ctl->pgcr[0], 1 << 26); > @@ -85,8 +85,8 @@ st
Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support
On Fri, 13 Nov 2015 18:22:10 +0100 Jens Kuske wrote: > On 13/11/15 13:36, Siarhei Siamashka wrote: > > On Wed, 11 Nov 2015 18:26:54 +0100 > > Jens Kuske wrote: > > > >> Based on some guessing and comparing with the parts I initially started > >> disassembling (before this SDK appeared), I think it's I20. The I20 dram > >> init code matched the disassembled parts exactly, except the ZQ > >> calibration part... > >> So, looks like it might not be correct to assume I20 == H3. > > > > The magic constants in mctl_set_master_priority() seem to be a bit > > different too. This explains why I could not find the matching code > > in the SDK. > > Indeed, didn't remember that. > > > > >> This is the ZQ calibration function I got by disassembling, but I dropped > >> it since the SDK version worked well too. Maybe I should have done the > >> opposite and drop the SDK... > > > > Agreed, it's safer to prefer the variant of code that is actually > > used in production on real devices. > > > >> It looks a bit strange, like if they are always calibrating the > >> first channel and then copying to the others, maybe there is some > >> hardware bug they work around. > >> > >> static void mctl_zq_calibration(struct dram_para *para) > >> { > >>struct sunxi_mctl_ctl_reg * const mctl_ctl = > >>(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE; > >> > >>int i; > >>u16 zq_val[6]; > >>u32 reg_val, val; > >> > >>mctl_dbg("ZQ calibration... "); > >> > >>writel(0x0a0a0a0a, &mctl_ctl->zqdr[2]); > >> > >>for (i = 0; i < 6; i++) > >>{ > >>u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf; > >> > >>writel((zq << 20) | (zq << 16) | (zq << 12) | > >>(zq << 8) | (zq << 4) | (zq << 0), > >>&mctl_ctl->zqcr); > >> > >>writel(PIR_CLRSR, &mctl_ctl->pir); > >>mctl_phy_init(PIR_ZCAL); > >> > >>val = readl(&mctl_ctl->zqdr[0]) & 0xff; > >>writel((val << 24) | (val << 16) | (val << 8) | (val << 0), > >> &mctl_ctl->zqdr[2]); > >> > >>writel(PIR_CLRSR, &mctl_ctl->pir); > >>mctl_phy_init(PIR_ZCAL); > >> > >>zq_val[i] = val | > >> (bin_to_mgray(mgray_to_bin(readl(&mctl_ctl->zqdr[0]) >> 24) - 1) << 8); > >>} > >> > >>writel((zq_val[1] << 16) | zq_val[0], &mctl_ctl->zqdr[0]); > >>writel((zq_val[3] << 16) | zq_val[2], &mctl_ctl->zqdr[1]); > >>writel((zq_val[5] << 16) | zq_val[4], &mctl_ctl->zqdr[2]); > >> > >>mctl_dbg((mctl_ctl->zqsr & (1 << 30)) ? "ERROR\n" : "DONE\n"); > >> } > > > > Thanks, using this implementation fixes the reliability problems at > > 672MHz on my Orange Pi PC board. > > Ok, I'll replace the SDK version then. > > > > >> And while trying to figure out what's the reason for this I used the > >> following debug function, it might help you if you want to debug ZQ cal: > >> > >> static void dump_zq(void) > >> { > >>struct sunxi_mctl_ctl_reg * const mctl_ctl = > >>(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE; > >> > >>int i; > >>static const char *mod[3] = { "control", "DX0/DX1", "DX2/DX3" }; > >>static const char *error[4] = { "\t", "overflow", > >>"underflow", "in progress" }; > >> > >>printf("== ZQ calibration %s %s ==\n", > >>(mctl_ctl->zqsr & (1 << 31)) ? "DONE" : "", > >>(mctl_ctl->zqsr & (1 << 30)) ? "ERROR" : ""); > >> > >>printf("\tODT pull-up\tODT pull-down\tDRV pull-up\tDRV pull-down\n"); > >> > >>for (i = 0; i < 3; i++) > >>printf("%s\t%2u %s\t%2u %s\t%2u %s\t%2u %s\n", mod[i], > >>mgray_to_
[linux-sunxi] [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC
Extracted from the Lubuntu_1404_For_OrangePiPC_v0_8_0_.img.xz image: http://www.orangepi.org/downloadresources/orangepipc/oragepipc_4a0e8d960f7f0a52606dfaba58.html Not necessarily the best one, but at least it comes from the board manufacturer and may be used as a starting point for further improvements. Signed-off-by: Siarhei Siamashka --- sys_config/h3/xunlong_orange_pi_pc.fex | 814 + 1 file changed, 814 insertions(+) create mode 100644 sys_config/h3/xunlong_orange_pi_pc.fex diff --git a/sys_config/h3/xunlong_orange_pi_pc.fex b/sys_config/h3/xunlong_orange_pi_pc.fex new file mode 100644 index 000..93e8c4c --- /dev/null +++ b/sys_config/h3/xunlong_orange_pi_pc.fex @@ -0,0 +1,814 @@ +[product] +version = "100" +machine = "orangepi-plus" + +[platform] +debug_mode = 1 +eraseflag = 1 +next_work = 2 + +[target] +#boot_clock = 1008 +boot_clock = 1200 +storage_type = -1 + +[key_detect_en] +keyen_flag = 0 + +[fel_key] +fel_key_max = 7 +fel_key_min = 2 + +[card_boot] +logical_start = 40960 +sprite_work_delay = 500 +sprite_err_delay = 200 +sprite_gpio0 = port:PA15<1> +next_work = 3 + +[box_start_os] +used = 1 +start_type = 1 +irkey_used = 1 +pmukey_used = 1 +pmukey_num = 3 +led_power = 0 +led_state = 0 + +[boot_init_gpio] +used = 1 +gpio0 = port:PA15<1><1> +gpio1 = port:PG11<1><1> + +[recovery_para] +used = 1 +mode = 2 +recovery_key = port:PL04<0> + +[pm_para] +standby_mode = 1 + +[card0_boot_para] +card_ctrl = 0 +card_high_speed = 1 +card_line = 4 +sdc_d1 = port:PF00<2><1><2> +sdc_d0 = port:PF01<2><1><2> +sdc_clk = port:PF02<2><1><2> +sdc_cmd = port:PF03<2><1><2> +sdc_d3 = port:PF04<2><1><2> +sdc_d2 = port:PF05<2><1><2> + +[card2_boot_para] +card_ctrl = 2 +card_high_speed = 1 +card_line = 8 +sdc_cmd = port:PC06<3><1><2> +sdc_clk = port:PC05<3><1><2> +sdc_d0 = port:PC08<3><1><2> +sdc_d1 = port:PC09<3><1><2> +sdc_d2 = port:PC10<3><1><2> +sdc_d3 = port:PC11<3><1><2> +sdc_d4 = port:PC12<3><1><2> +sdc_d5 = port:PC13<3><1><2> +sdc_d6 = port:PC14<3><1><2> +sdc_d7 = port:PC15<3><1><2> +sdc_2xmode = 1 +sdc_ddrmode = 1 + +[twi_para] +twi_port = 0 +twi_scl = port:PA11<2> +twi_sda = port:PA12<2> + +[uart_para] +uart_debug_port = 0 +uart_debug_tx = port:PA04<2><1> +uart_debug_rx = port:PA05<2><1> + +[force_uart_para] +force_uart_port = 0 +force_uart_tx = port:PF02<3><1> +force_uart_rx = port:PF04<3><1> + +[jtag_para] +jtag_enable = 0 +jtag_ms = port:PA00<3> +jtag_ck = port:PA01<3> +jtag_do = port:PA02<3> +jtag_di = port:PA03<3> + +[clock] +pll_video = 297 +pll_ve = 402 +pll_periph0 = 600 +pll_gpu = 576 +pll_periph1 = 600 +pll_de = 864 + +[dram_para] +dram_clk = 672 +dram_type = 3 +dram_zq = 0x3b3bfb +dram_odt_en = 1 +dram_para1 = 283377664 +dram_para2 = 0 +dram_mr0 = 6208 +dram_mr1 = 64 +dram_mr2 = 24 +dram_mr3 = 2 +dram_tpr0 = 0x48a192 +dram_tpr1 = 0x1c2418d +dram_tpr2 = 0x76051 +dram_tpr3 = 0x0 +dram_tpr4 = 0x0 +dram_tpr5 = 0x0 +dram_tpr6 = 0x64 +dram_tpr7 = 0x0 +dram_tpr8 = 0x0 +dram_tpr9 = 0x0 +dram_tpr10 = 0x0 +dram_tpr11 = 0x6aaa +dram_tpr12 = 0x7979 +dram_tpr13 = 0x800800 + +[wakeup_src_para] +cpu_en = 0 +cpu_freq = 48 +pll_ratio = 273 +dram_selfresh_en = 1 +dram_freq = 36 +wakeup_src0 = +wakeup_src_wl = port:PG10<4><0> + +[twi0] +twi_used = 1 +twi_scl = port:PA11<2> +twi_sda = port:PA12<2> + +[twi1] +twi_used = 0 +twi_scl = port:PA18<3> +twi_sda = port:PA19<3> + +[twi2] +twi_used = 0 +twi_scl = port:PE12<3> +twi_sda = port:PE13<3> + +[uart0] +uart_used = 1 +uart_port = 0 +uart_type = 2 +uart_tx = port:PA04<2><1> +uart_rx = port:PA05<2><1> + +[uart1] +uart_used = 0 +uart_port = 1 +uart_type = 4 +uart_tx = port:PG06<2><1> +uart_rx = port:PG07<2><1> +uart_rts = port:PG08<2><1> +uart_cts = port:PG09<2><1> + +[uart2] +uart_used = 0 +uart_port = 2 +uart_type = 4 +uart_tx = port:PA00<2><1> +uart_rx = port:PA01<2><1> +uart_rts = port:PA02<2><1> +uart_cts = port:PA03<2><1> + +[uart3] +uart_used = 0 +uart_port = 3 +uart_type = 4 +uart_tx = port:PA13<3><1> +uart_rx = port:PA14<3><1> +uart_rts = port:PA15<3><1> +uart_cts = port:PA16<3><1> + +[spi0] +spi_used = 0 +spi_cs_bitmap = 1 +spi_mosi = port:PC00<3> +spi_miso = port:PC01<3> +spi_sclk = port:PC02<3> +spi_cs0 = port:PC03<3><1> + +[spi1] +spi_used = 0 +spi_cs_bitmap = 1 +spi_cs0 = port:PA13<2><1> +spi_sclk = port:PA14<2> +spi_mosi = port:PA15<
[linux-sunxi] [PATCH sunxi-boards 2/3] h3: Make LEDs available in /sys/class/leds on Orange Pi PC
This patch makes both red and green LEDs available in /sys/class/leds instead of probably having them reserved for some special purposes (such as a standby mode indicator?). Being able to control the state of LEDs from applications and scripts is quite useful. Signed-off-by: Siarhei Siamashka --- sys_config/h3/xunlong_orange_pi_pc.fex | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/sys_config/h3/xunlong_orange_pi_pc.fex b/sys_config/h3/xunlong_orange_pi_pc.fex index 93e8c4c..56a9b60 100644 --- a/sys_config/h3/xunlong_orange_pi_pc.fex +++ b/sys_config/h3/xunlong_orange_pi_pc.fex @@ -219,8 +219,8 @@ mode = 0 [gpio_para] gpio_used = 1 gpio_num = 30 -gpio_pin_1 = port:PL10<1><1> -gpio_pin_2 = port:PA15<1><0> +; gpio_pin_1 = port:PL10<1><1> +; gpio_pin_2 = port:PA15<1><0> gpio_pin_3 = port:PA12<1><0> gpio_pin_4 = port:PA11<1><0> gpio_pin_5 = port:PA06<1><0> @@ -250,9 +250,16 @@ gpio_pin_28 = port:PA20<1><0> gpio_pin_29 = port:PG06<1><0> gpio_pin_30 = port:PG07<1><0> -[led_assign] -normal_led = "gpio_pin_2" -standby_led = "gpio_pin_1" +;[led_assign] +;normal_led = "gpio_pin_2" +;standby_led = "gpio_pin_1" + +[leds_para] +leds_used = 1 +green_led = port:PL10<1><0> +green_led_active_low = 0 +red_led = port:PA15<1><0> +red_led_active_low = 0 [ths_para] ths_used = 1 -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH sunxi-boards 3/3] h3: Update cpufreq and cooling state tables on Orange Pi PC
The current FEX file does not allow the CPU frequencies higher than 1.2GHz and also sets the VDD_CPUX voltage to 1.3V (the cooling states table overrides the questionable 1536MHz @1.5V cpufreq operating point). The comments in FEX files from H3 SDK sources are describing the cpufreq operating points and looks like the information provided by Allwinner (the same comments are also present in the Draco H3 SDK). So use these operating points instead. Also the H3 datasheet specifies 1.5V as the absolute maximum for the VDD_CPUX voltage and 1.4V as the recommended maximum. The datasheet says that "Absolute Maximum Ratings are those values beyond which damage to the device may occur" and "Functional operation of the device *at these* or any other conditions beyond those indicated in the operational sections of this standard may damage to the device". Basically, the recommended voltage limit is 1.4V while the range between 1.4V and 1.5V is a buffer zone for extra safety. For this reason, the 1536MHz operating point is removed. Tests with libjpeg-turbo decoding show that there is at least some safety headroom (no corruption detected until these voltages are reduced by more than 0.07V). Regarding the cooling states, the old FEX file was instructing the kernel to disable CPU cores as the temperature increases while keeping the CPU clock speed limit at all the same 1.2GHz. Probably the intention was to ensure that the single-threaded performance remains good. But the problem with this approach is that once a CPU core is disabled, it does not come back anymore when using the Allwinner's 3.4 SDK kernel. An alternative solution is to keep all the CPU cores operational as long as possible, but reduce the CPU clock speed limit at higher temperatures. Such adjustment is also done by this patch. Signed-off-by: Siarhei Siamashka --- sys_config/h3/xunlong_orange_pi_pc.fex | 86 -- 1 file changed, 52 insertions(+), 34 deletions(-) diff --git a/sys_config/h3/xunlong_orange_pi_pc.fex b/sys_config/h3/xunlong_orange_pi_pc.fex index 56a9b60..88ee928 100644 --- a/sys_config/h3/xunlong_orange_pi_pc.fex +++ b/sys_config/h3/xunlong_orange_pi_pc.fex @@ -263,13 +263,13 @@ red_led_active_low = 0 [ths_para] ths_used = 1 -ths_trip1_count = 5 +ths_trip1_count = 6 ths_trip1_0 = 70 ths_trip1_1 = 80 -ths_trip1_2 = 90 -ths_trip1_3 = 100 -ths_trip1_4 = 105 -ths_trip1_5 = 0 +ths_trip1_2 = 85 +ths_trip1_3 = 90 +ths_trip1_4 = 95 +ths_trip1_5 = 100 ths_trip1_6 = 0 ths_trip1_7 = 0 ths_trip1_0_min = 0 @@ -281,21 +281,22 @@ ths_trip1_2_max = 3 ths_trip1_3_min = 3 ths_trip1_3_max = 4 ths_trip1_4_min = 4 -ths_trip1_4_max = 4 -ths_trip1_5_min = 0 -ths_trip1_5_max = 0 +ths_trip1_4_max = 5 +ths_trip1_5_min = 5 +ths_trip1_5_max = 5 ths_trip1_6_min = 0 ths_trip1_6_max = 0 ths_trip2_count = 1 ths_trip2_0 = 105 [cooler_table] -cooler_count = 5 -cooler0 = "120 4 4294967295 0" -cooler1 = "120 3 4294967295 0" -cooler2 = "120 2 4294967295 0" -cooler3 = "120 1 4294967295 0" -cooler4 = "504000 1 4294967295 0" +cooler_count = 6 +cooler0 = "1296000 4 4294967295 0" +cooler1 = "120 4 4294967295 0" +cooler2 = "1008000 4 4294967295 0" +cooler3 = "816000 4 4294967295 0" +cooler4 = "648000 4 4294967295 0" +cooler5 = "48 1 4294967295 0" [nand0_para] nand_support_2ch = 0 @@ -709,37 +710,54 @@ ir_addr_code12 = 65344 ir_used = 1 ir_tx = port:PH07<2> +;-- +; dvfs voltage-frequency table configuration +; +; pmuic_type:0:none, 1:gpio, 2:i2c +; pmu_gpio0: gpio config. +; pmu_levelx: 0~: voltage(mV), 1~9:gpio0 state. voltage form high to low. +; +; extremity_freq(Hz): cpu extremity frequency when run benckmark or demo apk +; 1536MHz@1500mV with radiator, 1296MHz@1340mV without radiator +; max_freq: cpu maximum frequency, based on Hz, can not be more than 1200MHz +; min_freq: cpu minimum frequency, based on Hz, can not be less than 60MHz +; +; LV_count: count of LV_freq/LV_volt, must be < 16 +; +; LV1: core vdd is 1.50v if cpu frequency is (1296Mhz, 1536Mhz] +; LV2: core vdd is 1.34v if cpu frequency is (1200Mhz, 1296Mhz] +; LV3: core vdd is 1.32v if cpu frequency is (1008Mhz, 1200Mhz] +; LV4: core vdd is 1.20v if cpu frequency is (816Mhz, 1008Mhz] +; LV5: core vdd is 1.10v if cpu frequency is (648Mhz,816Mhz] +; LV6: core vdd is 1.04v if cpu frequency is (0Mhz, 648Mhz] +; LV7: core vdd is 1.04v if cpu frequency is (0Mhz, 648Mhz] +; LV8: core vdd is 1.04v if cpu frequency is (0Mhz, 648Mhz] +; +;-- [dvfs_table] pmuic_type = 2 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 -#max_
[linux-sunxi] [PATCH 3.4 9/9] sunxi: cedar: Allocate memory buffer only when /dev/cedar_dev is open
Previously the 80MB memory buffer was allocated from CMA when the cedar module is loaded and kept in use until the module is removed. Now the buffer is only allocated when /dev/cedar_dev is opened and deallocated when it is closed. Additionally, the kernel cmdline parameter 'sunxi_ve_mem_reserve' can be used to change the cedar memory buffer size to something larger than 80MB. Since libvdpau-sunxi implemented subtitles support, it needs more memory and 80MB may be not enough. Signed-off-by: Siarhei Siamashka --- drivers/media/video/sunxi/sunxi_cedar.c | 61 - 1 file changed, 29 insertions(+), 32 deletions(-) diff --git a/drivers/media/video/sunxi/sunxi_cedar.c b/drivers/media/video/sunxi/sunxi_cedar.c index 64f4151..b0374ad 100644 --- a/drivers/media/video/sunxi/sunxi_cedar.c +++ b/drivers/media/video/sunxi/sunxi_cedar.c @@ -790,6 +790,9 @@ long cedardev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) static int cedardev_open(struct inode *inode, struct file *filp) { +#ifdef CONFIG_CMA + resource_size_t pa; +#endif struct cedar_dev *devp; devp = container_of(inode->i_cdev, struct cedar_dev, cdev); filp->private_data = devp; @@ -797,6 +800,29 @@ static int cedardev_open(struct inode *inode, struct file *filp) return -ERESTARTSYS; } /* init other resource here */ +#ifdef CONFIG_CMA + ve_size = max(ve_size, 80UL * SZ_1M); + ve_start_virt = dma_alloc_coherent(NULL, ve_size, &pa, + GFP_KERNEL | GFP_DMA); + if (!ve_start_virt) { + printk(KERN_NOTICE "cedar: failed to allocate memory buffer\n"); + up(&devp->sem); + return -ENOMEM; + } + ve_start = pa; + if (ve_start + ve_size > SW_PA_SDRAM_START + SZ_256M) { + printk(KERN_NOTICE "cedar: buffer is above 256MB limit\n"); + dma_free_coherent(NULL, ve_size, ve_start_virt, ve_start); + up(&devp->sem); + return -ENOMEM; + } +#else + if (ve_size == 0) { + printk("[cedar dev]: not installed! ve_mem_reserve=0\n"); + up(&devp->sem); + return -ENOMEM; + } +#endif devp->irq_flag = 0; nonseekable_open(inode, filp); return 0; @@ -810,6 +836,9 @@ static int cedardev_release(struct inode *inode, struct file *filp) /* release other resource here */ devp->irq_flag = 1; +#ifdef CONFIG_CMA + dma_free_coherent(NULL, ve_size, ve_start_virt, ve_start); +#endif up(&devp->sem); return 0; } @@ -925,30 +954,6 @@ static int __init cedardev_init(void) unsigned int val; dev_t dev = 0; -#ifdef CONFIG_CMA - /* If having CMA enabled, just rely on CMA for memory allocation */ - resource_size_t pa; - ve_size = 80 * SZ_1M; - ve_start_virt = dma_alloc_coherent(NULL, ve_size, &pa, - GFP_KERNEL | GFP_DMA); - if (!ve_start_virt) { - printk(KERN_NOTICE "cedar: failed to allocate memory buffer\n"); - return -ENODEV; - } - ve_start = pa; - if (ve_start + ve_size > SW_PA_SDRAM_START + SZ_256M) { - printk(KERN_NOTICE "cedar: buffer is above 256MB limit\n"); - dma_free_coherent(NULL, ve_size, ve_start_virt, ve_start); - ve_start_virt = 0; - ve_size = 0; - return -ENODEV; - } -#else - if (ve_size == 0) { - printk("[cedar dev]: not installed! ve_mem_reserve=0\n"); - return -ENODEV; - } -#endif printk("[cedar dev]: install start!!!\n"); if((platform_device_register(&sw_device_cedar))<0) @@ -1094,14 +1099,6 @@ static void __exit cedardev_exit(void) if (cedar_devp) { kfree(cedar_devp); } - -#ifdef CONFIG_CMA - if (ve_start_virt) { - dma_free_coherent(NULL, ve_size, ve_start_virt, ve_start); - ve_start_virt = 0; - ve_size = 0; - } -#endif } module_exit(cedardev_exit); -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 2/9] sunxi: defconfig: Enable ROOT_NFS support
This patch ensures that default configs allow multiple sun4i, sun5i and sun7i devices boot and work nicely with the same NFS root. Tested with Cubietruck, Cubieboard2 and A10-Lime. ROOT_NFS is enabled in sun4i_defconfig. GMAC is enabled in sun7i_defconfig for Cubietruck support. USB_NET is enabled for sun5i because it can allow to use USB ethernet dongles. Also different localversion identifiers are set for in the config files to avoid a possible clash between the names of directories with kernel modules. Signed-off-by: Siarhei Siamashka --- arch/arm/configs/sun4i_defconfig | 6 ++ arch/arm/configs/sun5i_defconfig | 7 +++ arch/arm/configs/sun7i_defconfig | 8 +++- 3 files changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/sun4i_defconfig b/arch/arm/configs/sun4i_defconfig index dcd586d..38a6073 100644 --- a/arch/arm/configs/sun4i_defconfig +++ b/arch/arm/configs/sun4i_defconfig @@ -1,4 +1,5 @@ CONFIG_EXPERIMENTAL=y +CONFIG_LOCALVERSION="-sun4i" CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -69,6 +70,10 @@ CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y @@ -286,6 +291,7 @@ CONFIG_CONFIGFS_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y CONFIG_CIFS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig index 7b0d01d..c01d2f4 100644 --- a/arch/arm/configs/sun5i_defconfig +++ b/arch/arm/configs/sun5i_defconfig @@ -1,4 +1,5 @@ CONFIG_EXPERIMENTAL=y +CONFIG_LOCALVERSION="-sun5i" CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -66,6 +67,10 @@ CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y @@ -104,6 +109,7 @@ CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_SUNXI_EMAC=y CONFIG_PHYLIB=y +CONFIG_USB_USBNET=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set @@ -217,6 +223,7 @@ CONFIG_CONFIGFS_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y CONFIG_CIFS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig index b463645..a7c8d94 100644 --- a/arch/arm/configs/sun7i_defconfig +++ b/arch/arm/configs/sun7i_defconfig @@ -1,4 +1,5 @@ CONFIG_EXPERIMENTAL=y +CONFIG_LOCALVERSION="-sun7i" CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -70,6 +71,10 @@ CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y @@ -119,7 +124,7 @@ CONFIG_SATA_AHCI_PLATFORM=y CONFIG_SW_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_SUNXI_EMAC=y -CONFIG_PHYLIB=y +CONFIG_SUNXI_GMAC=y CONFIG_RTL8192CU_SW=m CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y @@ -286,6 +291,7 @@ CONFIG_CONFIGFS_FS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V4=y +CONFIG_ROOT_NFS=y CONFIG_CIFS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 5/9] sunxi: disp: Tweak framebuffer size for best X11 GLES/DRI2 performance
Zero-copy buffer swaps can be used in xf86-video-fbturbo for GLES/DRI2 applications only when a certain minimal framebuffer size is available. In order to make everything easier for the end users, just override the fb0_framebuffer_num/fb1_framebuffer_num settings from FEX and increase them when necessary. Do it only when CMA is enabled. Otherwise this may be dangerous when the user controls the size of disp framebuffer reservation via kernel cmdline. Signed-off-by: Siarhei Siamashka --- drivers/video/sunxi/disp/dev_fb.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/video/sunxi/disp/dev_fb.c b/drivers/video/sunxi/disp/dev_fb.c index 6946222..aae088e 100644 --- a/drivers/video/sunxi/disp/dev_fb.c +++ b/drivers/video/sunxi/disp/dev_fb.c @@ -339,6 +339,27 @@ parser_disp_init_para(__disp_init_t *init_para) } init_para->scaler_mode[1] = value; +#if defined(CONFIG_MALI) && defined(CONFIG_FB_SUNXI_UMP) && defined(CONFIG_CMA) + /* +* It is best to ensure that the offscreen framebuffer area has +* enough space for two more frames with 32-bit color depth. This +* is needed for zero-copy buffer swaps in xf86-video-fbturbo DDX. +*/ + for (i = 0; i < 2; i++) { + if (init_para->format[i] == DISP_FORMAT_ARGB || + init_para->format[i] == DISP_FORMAT_ARGB888) { + init_para->buffer_num[i] = + max(init_para->buffer_num[i], 3U); + } else if (init_para->format[i] == DISP_FORMAT_RGB888) { + init_para->buffer_num[i] = + max(init_para->buffer_num[i], 4U); + } else { + init_para->buffer_num[i] = + max(init_para->buffer_num[i], 5U); + } + } +#endif + __inf("display init para begin\n"); __inf("b_init:%d\n", init_para->b_init); __inf("disp_mode:%d\n\n", init_para->disp_mode); -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 3/9] sunxi: disp: Allocate framebuffers from the CMA area
This allows to get rid of the fragile boot time memory reservation. Now the amount of required framebuffer memory is calculated at runtime, depending on the screen resolution (which may come from FEX or from EDID). Signed-off-by: Siarhei Siamashka --- drivers/video/Kconfig | 3 +-- drivers/video/sunxi/disp/dev_fb.c | 33 + 2 files changed, 34 insertions(+), 2 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index df63338..ba43686 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -275,7 +275,6 @@ config FB_GRVGA config FB_SUNXI tristate "DISP Driver Support(sunxi)" depends on FB && (ARCH_SUN4I || ARCH_SUN5I || ARCH_SUN7I) - select FB_SUNXI_RESERVED_MEM if MALI select FB_MODE_HELPERS select FB_CFB_FILLRECT select FB_CFB_COPYAREA @@ -286,7 +285,7 @@ config FB_SUNXI config FB_SUNXI_RESERVED_MEM bool "Reserve memory block for sunxi/fb" depends on FB_SUNXI - default y + default !CMA config FB_SUNXI_UMP bool "Enable FB/UMP Integration" diff --git a/drivers/video/sunxi/disp/dev_fb.c b/drivers/video/sunxi/disp/dev_fb.c index a453b6f..7500764 100644 --- a/drivers/video/sunxi/disp/dev_fb.c +++ b/drivers/video/sunxi/disp/dev_fb.c @@ -21,6 +21,7 @@ #include #include #include +#include #ifdef CONFIG_FB_SUNXI_UMP #include @@ -463,8 +464,35 @@ fb_draw_gray_pictures(__u32 base, __u32 width, __u32 height, } #endif /* UNUSED */ +#ifdef CONFIG_CMA +static int Fb_map_cma_video_memory(__u32 fb_id, struct fb_info *info) +{ + resource_size_t pa; + g_fbi.malloc_screen_base[fb_id] = dma_alloc_coherent(NULL, info->fix.smem_len, &pa, + GFP_KERNEL | GFP_DMA); + if (g_fbi.malloc_screen_base[fb_id] == NULL) + return -ENOMEM; + info->fix.smem_start = pa; + info->screen_base = g_fbi.malloc_screen_base[fb_id]; + memset(info->screen_base, 0, info->fix.smem_len); + return 0; +} + +static void Fb_unmap_cma_video_memory(__u32 fb_id, struct fb_info *info) +{ + if (g_fbi.malloc_screen_base[fb_id] != NULL) { + dma_free_coherent(NULL, info->fix.smem_len, + g_fbi.malloc_screen_base[fb_id], info->fix.smem_start); + g_fbi.malloc_screen_base[fb_id] = NULL; + } +} +#endif + static int __init Fb_map_video_memory(__u32 fb_id, struct fb_info *info) { +#ifdef CONFIG_CMA + return Fb_map_cma_video_memory(fb_id, info); +#else unsigned map_size = PAGE_ALIGN(info->fix.smem_len); struct page *page; @@ -507,10 +535,14 @@ use_reserved_mem: return 0; #endif +#endif } static inline void Fb_unmap_video_memory(__u32 fb_id, struct fb_info *info) { +#ifdef CONFIG_CMA + Fb_unmap_cma_video_memory(fb_id, info); +#else unsigned map_size = PAGE_ALIGN(info->fix.smem_len); #ifdef CONFIG_FB_SUNXI_RESERVED_MEM if (fb_size) { @@ -527,6 +559,7 @@ static inline void Fb_unmap_video_memory(__u32 fb_id, struct fb_info *info) #endif free_pages((unsigned long)info->screen_base, get_order(map_size)); +#endif } /* -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 8/9] sunxi: cedar: Allow only one /dev/cedar_dev user at a time
The existing cedar driver code already has a semaphore, but is only doing some strange and pointless manipulations with it. Now use this semaphore to actually protect /dev/cedar_dev from being simultaneously opened by multiple users. When the cedar driver is already occupied, any new attempts to open /dev/cedar_dev just block until the current user closes it. Signed-off-by: Siarhei Siamashka --- drivers/media/video/sunxi/sunxi_cedar.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/media/video/sunxi/sunxi_cedar.c b/drivers/media/video/sunxi/sunxi_cedar.c index f30d086..64f4151 100644 --- a/drivers/media/video/sunxi/sunxi_cedar.c +++ b/drivers/media/video/sunxi/sunxi_cedar.c @@ -797,8 +797,7 @@ static int cedardev_open(struct inode *inode, struct file *filp) return -ERESTARTSYS; } /* init other resource here */ -devp->irq_flag = 0; - up(&devp->sem); + devp->irq_flag = 0; nonseekable_open(inode, filp); return 0; } @@ -808,11 +807,9 @@ static int cedardev_release(struct inode *inode, struct file *filp) struct cedar_dev *devp; devp = filp->private_data; - if (down_interruptible(&devp->sem)) { - return -ERESTARTSYS; - } + /* release other resource here */ -devp->irq_flag = 1; + devp->irq_flag = 1; up(&devp->sem); return 0; } -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 0/9] Better out of the box behavior for sunxi-3.4
This patch set moves more of the buffer allocation work to CMA. So that we don't waste RAM unnecessarily and ensure that the graphics/multimedia drivers (Mali and Cedar) have exactly as much memory as needed for enabling all the features and optimal performance. Or in other words, the kernel parts releated to 3D graphics and hardware video decoding just work out of the box and do not require any error prone kernel cmdline parameters selection for memory reservation or tweaking FEX files. Also ROOT_NFS is enabled and the cpufreq settings are unified for sun4i/sun5i/sun7i. These are the old patches that I have been using for ages. They serve exactly the same purpose: make things work out of the box in a reasonable way. These patches are also available in the following git branch: https://github.com/ssvb/linux-sunxi/commits/20151202-more-cma-for-sunxi-3.4 Siarhei Siamashka (9): sunxi: defconfig: Use performance cpufreq governor by default sunxi: defconfig: Enable ROOT_NFS support sunxi: disp: Allocate framebuffers from the CMA area sunxi: mali: Handle both framebuffers in the Mali validation code sunxi: disp: Tweak framebuffer size for best X11 GLES/DRI2 performance sunxi: mali: Fix problems with a static build of the Mali driver sunxi: defconfig: Build the Mali driver statically sunxi: cedar: Allow only one /dev/cedar_dev user at a time sunxi: cedar: Allocate memory buffer only when /dev/cedar_dev is open arch/arm/configs/sun4i_defconfig | 18 +++-- arch/arm/configs/sun5i_defconfig | 17 - arch/arm/configs/sun7i_defconfig | 20 +++--- arch/arm/plat-sunxi/core.c | 12 drivers/gpu/mali/Kconfig | 2 +- drivers/gpu/mali/mali/common/mali_mem_validation.c | 22 ++- drivers/gpu/mali/mali/linux/mali_osk_atomics.c | 14 ++-- drivers/gpu/mali/mali/linux/mali_osk_locks.c | 14 ++-- drivers/gpu/mali/mali/linux/mali_osk_math.c| 2 +- drivers/gpu/mali/mali/linux/mali_osk_memory.c | 16 ++--- drivers/gpu/mali/mali/linux/mali_osk_misc.c| 12 ++-- .../mali/mali/platform/mali400-pmu/mali_platform.c | 25 --- drivers/gpu/mali/ump/linux/ump_kernel_linux.c | 2 +- drivers/media/video/sunxi/sunxi_cedar.c| 70 +--- drivers/video/Kconfig | 3 +- drivers/video/sunxi/disp/dev_fb.c | 76 ++ 16 files changed, 209 insertions(+), 116 deletions(-) -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 4/9] sunxi: mali: Handle both framebuffers in the Mali validation code
The Mali kernel driver allows the userland code to map a buffer in physical memory (via the MALI_IOC_MEM_MAP_EXT ioctl). This is normally used for mapping the framebuffer in the userland Mali blob and directly accessing it for rendering graphics. Because of security reasons, the kernel driver has a validation check, which only permits one chunk of physical memory to be mapped this way. And the Mali driver initialization code configures the address and the size of this chunk. Now the problem is that the sunxi hardware has not just one, but up to two framebuffers (for example, one VGA and one HDMI monitor). Previously both framebuffers were allocated from the disp reservation area. So the Mali validation code was just allowing access to the whole disp reservation area. But with CMA support, the framebuffers may be allocated anywhere in the CMA area. And now we have two disconnected chunks of physical memory, which should be both supported by the MALI_IOC_MEM_MAP_EXT ioctl. This patch modifies the MALI_IOC_MEM_MAP_EXT validation code to support both of the sunxi disp framebuffers. PS. If the kernel driver does not allow to map physical memory via the MALI_IOC_MEM_MAP_EXT ioctl at all, then the Mali userland blob still can work and is able to render 3D graphics. However this is done by using memcpy to copy data into the framebuffer for each frame and the performance becomes ridiculously bad. Signed-off-by: Siarhei Siamashka --- arch/arm/plat-sunxi/core.c | 12 +++ drivers/gpu/mali/mali/common/mali_mem_validation.c | 22 +-- .../mali/mali/platform/mali400-pmu/mali_platform.c | 25 -- drivers/video/sunxi/disp/dev_fb.c | 22 +++ 4 files changed, 54 insertions(+), 27 deletions(-) diff --git a/arch/arm/plat-sunxi/core.c b/arch/arm/plat-sunxi/core.c index e7da395..89f3187 100644 --- a/arch/arm/plat-sunxi/core.c +++ b/arch/arm/plat-sunxi/core.c @@ -135,6 +135,18 @@ static int __init reserve_fb_param(char *s) early_param("sunxi_fb_mem_reserve", reserve_fb_param); #endif +/* + * Physical addresses and sizes of two framebuffers. + */ +unsigned long fb0_start; +unsigned long fb0_size; +unsigned long fb1_start; +unsigned long fb1_size; +EXPORT_SYMBOL(fb0_start); +EXPORT_SYMBOL(fb0_size); +EXPORT_SYMBOL(fb1_start); +EXPORT_SYMBOL(fb1_size); + #if IS_ENABLED(CONFIG_SUNXI_G2D) /* The G2D block is used by: * diff --git a/drivers/gpu/mali/mali/common/mali_mem_validation.c b/drivers/gpu/mali/mali/common/mali_mem_validation.c index 2f57459..4a5b88c 100644 --- a/drivers/gpu/mali/mali/common/mali_mem_validation.c +++ b/drivers/gpu/mali/mali/common/mali_mem_validation.c @@ -14,6 +14,11 @@ #define MALI_INVALID_MEM_ADDR 0x +extern unsigned long fb0_start; +extern unsigned long fb0_size; +extern unsigned long fb1_start; +extern unsigned long fb1_size; + typedef struct { u32 phys_base;/**< Mali physical base of the memory, page aligned */ @@ -47,7 +52,8 @@ _mali_osk_errcode_t mali_mem_validation_add_range(const _mali_osk_resource_t *re return _MALI_OSK_ERR_OK; } -_mali_osk_errcode_t mali_mem_validation_check(u32 phys_addr, u32 size) +static _mali_osk_errcode_t validation_check_helper(u32 phys_addr, u32 size, + _mali_mem_validation_t mali_mem_validator) { if (phys_addr < (phys_addr + size)) /* Don't allow overflow (or zero size) */ { @@ -65,7 +71,19 @@ _mali_osk_errcode_t mali_mem_validation_check(u32 phys_addr, u32 size) } } - MALI_PRINT_ERROR(("MALI PHYSICAL RANGE VALIDATION ERROR: The range supplied was: phys_base=0x%08X, size=0x%08X\n", phys_addr, size)); + return _MALI_OSK_ERR_FAULT; +} +_mali_osk_errcode_t mali_mem_validation_check(u32 phys_addr, u32 size) +{ + _mali_mem_validation_t fb0 = { fb0_start, fb0_size }; + _mali_mem_validation_t fb1 = { fb1_start, fb1_size }; + + if (validation_check_helper(phys_addr, size, fb0) == _MALI_OSK_ERR_OK || + validation_check_helper(phys_addr, size, fb1) == _MALI_OSK_ERR_OK || + validation_check_helper(phys_addr, size, mali_mem_validator) == _MALI_OSK_ERR_OK) + return _MALI_OSK_ERR_OK; + + MALI_PRINT_ERROR(("MALI PHYSICAL RANGE VALIDATION ERROR: The range supplied was: phys_base=0x%08X, size=0x%08X\n", phys_addr, size)); return _MALI_OSK_ERR_FAULT; } diff --git a/drivers/gpu/mali/mali/platform/mali400-pmu/mali_platform.c b/drivers/gpu/mali/mali/platform/mali400-pmu/mali_platform.c index 290c1f9..d43bde0 100644 --- a/drivers/gpu/mali/mali/platform/mali400-pmu/mali_platform.c +++ b/drivers/gpu/mali/mali/platform/mali400-pmu/mali_platform.c @@ -24,13 +24,6 @@ #include #include -#ifdef CONFIG_FB_SUNXI_RESERVED_MEM -extern unsigned long fb_start; -extern unsigned long fb_size; -static int fb_validation_range
[linux-sunxi] [PATCH 3.4 1/9] sunxi: defconfig: Use performance cpufreq governor by default
A rather popular problem reported by new users on irc is very laggy performance out of the box. The default ondemand governor is too slow to react on increased demand for processing power without extra tuning. This extra tuning needs extra efforts from the users and prior knowledge that such tuning might be necessary. The most important defconfigs are sun4i_defconfig, sun5i_defconfig and sun7i_defconfig because they are mentioned in http://linux-sunxi.org/Linux_Kernel#Compilation This patch changes defconfigs to have the following set of governors: 1. 'performance' (default) 2. 'userspace' (for benchmarking purposes) 3. 'interactive' (a replacement for 'ondemand' with more sane default behavior) One more reason not to use the 'ondemand' governor by default is that the power saving provided by it is not particularly good: https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00492.html https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg00678.html http://www.cubieforums.com/index.php/topic,1413.msg8745.html#msg8745 It basically wastes a lot of performance for almost nothing. Signed-off-by: Siarhei Siamashka --- arch/arm/configs/sun4i_defconfig | 4 ++-- arch/arm/configs/sun5i_defconfig | 4 arch/arm/configs/sun7i_defconfig | 4 ++-- 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/sun4i_defconfig b/arch/arm/configs/sun4i_defconfig index feef899..dcd586d 100644 --- a/arch/arm/configs/sun4i_defconfig +++ b/arch/arm/configs/sun4i_defconfig @@ -53,8 +53,8 @@ CONFIG_COMPACTION=y CONFIG_KSM=y CONFIG_CMDLINE="mem=448M@0x4000 console=ttyS0,115200" CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_STAT=m -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_INTERACTIVE=y CONFIG_CPU_FREQ_DVFS=y CONFIG_CPU_IDLE=y CONFIG_VFP=y diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig index 18845db..7b0d01d 100644 --- a/arch/arm/configs/sun5i_defconfig +++ b/arch/arm/configs/sun5i_defconfig @@ -51,6 +51,10 @@ CONFIG_HIGHMEM=y CONFIG_COMPACTION=y CONFIG_KSM=y CONFIG_CMDLINE="mem=448M@0x4000 console=ttyS0,115200" +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_INTERACTIVE=y +CONFIG_CPU_FREQ_DVFS=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_BINFMT_MISC=y diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig index 0bf0811..b463645 100644 --- a/arch/arm/configs/sun7i_defconfig +++ b/arch/arm/configs/sun7i_defconfig @@ -54,8 +54,8 @@ CONFIG_COMPACTION=y CONFIG_KSM=y CONFIG_CMDLINE="mem=448M@0x4000 console=ttyS0,115200" CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_STAT=m -CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_INTERACTIVE=y CONFIG_CPU_FREQ_DVFS=y CONFIG_CPU_IDLE=y CONFIG_VFP=y -- 2.4.10 -- 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.