[linux-sunxi] Re: [RFC PATCH 1/3] sunxi: Extend SPL header versioning

[Siarhei Siamashka]

nse to
do this, but it is technically possible.

>   /* 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

[Siarhei Siamashka]

On Tue, 3 Apr 2018 13:43:43 +0100
Andre Przywara <andre.przyw...@arm.com> wrote:

> Hi Icenowy,
> 
> On 03/04/18 12:51, Icenowy Zheng wrote:
> > 
> > 
> > 于 2018年4月3日 GMT+08:00 下午7:34:55, Maxime Ripard <maxime.rip...@bootlin.com> 
> > 写到:  
> >> 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

[Siarhei Siamashka]

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

[Siarhei Siamashka]

ffset,
> -"allwinner,simple-framebuffer");
> - }
> + offset = sunxi_simplefb_fdt_match(blob, pipeline);
>   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 <siarhei.siamas...@gmail.com>

-- 
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?

[Siarhei Siamashka]

On Tue, 18 Jul 2017 13:28:40 -0700 (PDT)
mehdi soheili <m.soheilip...@gmail.com> 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

[Siarhei Siamashka]

On Sat,  3 Jun 2017 17:10:13 +0800
Icenowy Zheng <icen...@aosc.io> 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

[Siarhei Siamashka]

On Sun, 26 Feb 2017 06:10:50 -0800 (PST)
Vinicius Maciel <vinicius...@gmail.com> 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

[Siarhei Siamashka]

On Tue, 28 Feb 2017 09:16:11 +
Andre Przywara <andre.przyw...@arm.com> wrote:

> Hi,
> 
> On 28/02/17 03:08, Siarhei Siamashka wrote:
> > On Mon, 27 Feb 2017 20:55:53 +
> > Andre Przywara <o...@andrep.de> wrote:
> >   
> >> On Mon, 27 Feb 2017 05:48:48 +0200
> >> Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> >>  
> >>> On Mon, 27 Feb 2017 02:22:08 +
> >>> André Przywara <andre.przyw...@arm.com> wrote:
> >>> 
> >>>> On 27/02/17 01:20, Siarhei Siamashka wrote:
> >>>>> On Wed, 22 Feb 2017 17:08:47 +
> >>>>> Andre Przywara <o...@andrep.de> 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 <o...@andrep.de>
> >>>>>>
> >>>>>> ---
> >>>>>> 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 

Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command

[Siarhei Siamashka]

On Tue, 28 Feb 2017 05:14:27 +0800
Icenowy Zheng <icen...@aosc.xyz> wrote:

> 2017年2月28日 04:55于 Andre Przywara <o...@andrep.de>写道：
> >
> > On Mon, 27 Feb 2017 05:48:48 +0200 
> > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: 
> >  
> > > On Mon, 27 Feb 2017 02:22:08 + 
> > > André Przywara <andre.przyw...@arm.com> wrote: 
> > >   
> > > > On 27/02/17 01:20, Siarhei Siamashka wrote:   
> > > > > On Wed, 22 Feb 2017 17:08:47 + 
> > > > > Andre Przywara <o...@andrep.de> 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 <o...@andrep.de> 
> > > > >> 
> > > > >> --- 
> > > > >> 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 optio

Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command

[Siarhei Siamashka]

On Mon, 27 Feb 2017 20:55:53 +
Andre Przywara <o...@andrep.de> wrote:

> On Mon, 27 Feb 2017 05:48:48 +0200
> Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> 
> > On Mon, 27 Feb 2017 02:22:08 +
> > André Przywara <andre.przyw...@arm.com> wrote:
> >   
> > > On 27/02/17 01:20, Siarhei Siamashka wrote:  
> > > > On Wed, 22 Feb 2017 17:08:47 +
> > > > Andre Przywara <o...@andrep.de> 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 <o...@andrep.de>
> > > >>
> > > >> ---
> > > >> 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
> > 
>

Re: [linux-sunxi] Re: [sunxi-tools PATCH] fel: add smc command

[Siarhei Siamashka]

On Mon, 27 Feb 2017 02:22:08 +
André Przywara <andre.przyw...@arm.com> wrote:

> On 27/02/17 01:20, Siarhei Siamashka wrote:
> > On Wed, 22 Feb 2017 17:08:47 +
> > Andre Przywara <o...@andrep.de> 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 <o...@andrep.de>
> >>
> >> ---
> >> 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

[Siarhei Siamashka]

On Wed, 22 Feb 2017 17:08:47 +
Andre Przywara <o...@andrep.de> 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 <o...@andrep.de>
>
> ---
> 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

[Siarhei Siamashka]

On Sat, 11 Feb 2017 00:05:42 -0300
Vinicius Maciel <vinicius...@gmail.com> wrote:

> Em 10 de fev de 2017 23:53, "Siarhei Siamashka" <siarhei.siamas...@gmail.com>
> escreveu:
> 
> > On Fri, 10 Feb 2017 19:02:47 -0300
> > Vinicius Maciel <vinicius...@gmail.com> 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 <vinicius...@gmail.com>
> > > ---
> > >  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 <siarhei.siamas...@gmail.com>

> 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

[Siarhei Siamashka]

On Fri, 10 Feb 2017 19:02:47 -0300
Vinicius Maciel <vinicius...@gmail.com> 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 <vinicius...@gmail.com>
> ---
>  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 <siarhei.siamas...@gmail.com>

-- 
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

[Siarhei Siamashka]

  fd_out = STDOUT_FILENO;
> + } else {
> + fd_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

[Siarhei Siamashka]

On Fri, 20 Jan 2017 21:55:53 +
André Przywara <andre.przyw...@arm.com> 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 <andre.przyw...@arm.com>
> >> ---
> >>  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

[Siarhei Siamashka]

On Tue, 20 Dec 2016 02:03:36 +0800
Icenowy Zheng <icen...@aosc.xyz> 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 <icen...@aosc.xyz>
> ---
>  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

[Siarhei Siamashka]

On Thu, 13 Oct 2016 22:08:15 +0200
Paolo De Luca Bosso <paolo.delucabo...@gmail.com> 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 <paolo.delucabo...@gmail.com>
> :
> 
> > 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 <siarhei.siamas...@gmail.com  
> >> >:  
> >>  
> >>> On Wed, 12 Oct 2016 14:45:01 -0700 (PDT)
> >>> dlbp <paolo.delucabo...@gmail.com> 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

[Siarhei Siamashka]

On Wed, 12 Oct 2016 14:45:01 -0700 (PDT)
dlbp <paolo.delucabo...@gmail.com> 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

[Siarhei Siamashka]

On Sun, 25 Sep 2016 10:19:55 +0200
Danny Milosavljevic <dan...@scratchpost.org> wrote:

> On Fri, 23 Sep 2016 04:03:57 +0300
> Siarhei Siamashka <siarhei.siamas...@gmail.com> 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

[Siarhei Siamashka]

On Fri, 23 Sep 2016 10:48:11 +0300
Maxime Ripard <maxime.rip...@free-electrons.com> 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 <dan...@scratchpost.org> 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

[Siarhei Siamashka]

Hello Karsten,

On Sun,  4 Sep 2016 18:53:13 +0200
Karsten Merker <mer...@debian.org> 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

[Siarhei Siamashka]

On Thu, 22 Sep 2016 23:52:52 +0200
Danny Milosavljevic <dan...@scratchpost.org> 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

[Siarhei Siamashka]

On Mon, 19 Sep 2016 09:07:39 -0700 (PDT)
TsvetanUsunov <tsvetanusu...@gmail.com> 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

[Siarhei Siamashka]

On Thu, 8 Sep 2016 03:06:55 -0700 (PDT)
Ciprian Manea <ciprian.manea...@gmail.com> 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

[Siarhei Siamashka]

On Tue, 6 Sep 2016 18:24:28 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Tue, Sep 6, 2016 at 6:20 PM, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > Hi,
> >
> > On Tue, 6 Sep 2016 02:51:29 -0700 (PDT)
> > Ciprian Manea <ciprian.manea...@gmail.com> 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_ad

Re: [linux-sunxi] Flashing NAND on SinA33

[Siarhei Siamashka]

On Tue, 6 Sep 2016 06:09:13 -0700 (PDT)
Ciprian Manea <ciprian.manea...@gmail.com> 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

[Siarhei Siamashka]

cache.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

[Siarhei Siamashka]

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 @@
> > };
> >  };
> >
> > + {
> > +   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=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

[Siarhei Siamashka]

On Thu, 9 Jun 2016 19:42:55 -0700
Simon Glass <s...@chromium.org> wrote:

> Hi,
> 
> On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamas...@gmail.com> 
> wrote:
> > Hi Simon,
> >
> > On Thu, 9 Jun 2016 17:36:10 -0700
> > Simon Glass <s...@chromium.org> wrote:
> >  
> >> Hi,
> >>
> >> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamas...@gmail.com> 
> >> 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 <siarhei.siamas...@gmail.com>
> >> > ---
> >> >
> >> > 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
&

[linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash

[Siarhei Siamashka]

Hi Simon,

On Thu, 9 Jun 2016 17:36:10 -0700
Simon Glass <s...@chromium.org> wrote:

> Hi,
> 
> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamas...@gmail.com> 
> 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 <siarhei.siamas...@gmail.com>
> > ---
> >
> > 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

[Siarhei Siamashka]

On Wed, 1 Jun 2016 14:54:24 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> On Wed, 1 Jun 2016 14:41:36 +0300
> Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> 
> > On Mon, 30 May 2016 19:02:13 +0200
> > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> >   
> > > On Mon, 30 May 2016 19:46:17 +0300
> > > Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> > > 
> > > > On Mon, 30 May 2016 17:24:16 +0200
> > > > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> > > >   
> > > > > Hi Hans,
> > > > > 
> > > > > On Mon, 30 May 2016 17:12:53 +0200
> > > > > Boris Brezillon <boris.brezil...@free-electrons.com> 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
> &

Re: [linux-sunxi] Re: [PATCH v2] sunxi: Support booting from SPI flash

[Siarhei Siamashka]

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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---

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 @@ 

Re: [linux-sunxi] [PATCH v2 7/7] spl: nand: sunxi: add support for NAND config auto-detection

[Siarhei Siamashka]

On Wed,  1 Jun 2016 13:23:24 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> 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 <boris.brezil...@free-electrons.com>
> Acked-by: Hans de Goede <hdego...@redhat.com>

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

[Siarhei Siamashka]

On Mon, 30 May 2016 19:02:13 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> On Mon, 30 May 2016 19:46:17 +0300
> Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> 
> > On Mon, 30 May 2016 17:24:16 +0200
> > Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
> >   
> > > Hi Hans,
> > > 
> > > On Mon, 30 May 2016 17:12:53 +0200
> > > Boris Brezillon <boris.brezil...@free-electrons.com> 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 late

[linux-sunxi] Re: [PATCH sunxi-tools] Add a tool to generate raw NAND images

[Siarhei Siamashka]

On Mon, 30 May 2016 17:24:16 +0200
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> Hi Hans,
> 
> On Mon, 30 May 2016 17:12:53 +0200
> Boris Brezillon <boris.brezil...@free-electrons.com> 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

[Siarhei Siamashka]

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 

Re: [linux-sunxi] Pine64 unreview

[Siarhei Siamashka]

On Thu, 21 Apr 2016 20:50:23 +0200
Benjamin Henrion <zoo...@gmail.com> 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

[Siarhei Siamashka]

On Thu, 21 Apr 2016 19:56:10 -0400
"jonsm...@gmail.com" <jonsm...@gmail.com> wrote:

> On Thu, Apr 21, 2016 at 7:45 PM, jonsm...@gmail.com <jonsm...@gmail.com> 
> wrote:
> > On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com> 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

[Siarhei Siamashka]

On Thu, 21 Apr 2016 16:14:13 -0400
"jonsm...@gmail.com" <jonsm...@gmail.com> wrote:

> On Thu, Apr 21, 2016 at 4:09 PM, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > On Thu, 21 Apr 2016 13:38:19 -0400
> > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote:
> >  
> >> On Thu, Apr 21, 2016 at 1:17 PM, Siarhei Siamashka
> >> <siarhei.siamas...@gmail.com> wrote:  
> >> > Hello,
> >> >
> >> > On Thu, 21 Apr 2016 11:24:56 -0400
> >> > "jonsm...@gmail.com" <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

[Siarhei Siamashka]

Hello,

On Thu, 21 Apr 2016 11:24:56 -0400
"jonsm...@gmail.com" <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

[Siarhei Siamashka]

 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

[Siarhei Siamashka]

On Mon, 21 Mar 2016 14:24:15 +0100
Jens Kuske <jensku...@gmail.com> 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 <jensku...@gmail.com>

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 <siarhei.siamas...@gmail.com>

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

[Siarhei Siamashka]

On Mon, 21 Mar 2016 14:24:14 +0100
Jens Kuske <jensku...@gmail.com> wrote:

> This workaround is necessary for A80, which sometimes
> fails at reading DACR.
> 
> Signed-off-by: Jens Kuske <jensku...@gmail.com>
> ---
>  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 <siarhei.siamas...@gmail.com>

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

[Siarhei Siamashka]

On Sun, 20 Mar 2016 16:09:40 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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

[Siarhei Siamashka]

On Sun, 20 Mar 2016 15:18:10 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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 <bernhard.nortm...@web.de>

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

[Siarhei Siamashka]

On Sun, 20 Mar 2016 14:03:24 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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

[Siarhei Siamashka]

On Sat, 19 Mar 2016 18:29:40 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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.

[Siarhei Siamashka]

On Thu, 17 Mar 2016 19:38:54 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> wrote:

> From: Lourens Rozema <lroz...@embed.nl>
> 
> Tested-by: Bernhard Nortmann <bernhard.nortm...@web.de>
> ---

> 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 <siarhei.siamas...@gmail.com>

-- 
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

[Siarhei Siamashka]

On Thu, 17 Mar 2016 18:31:42 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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 <siarhei.siamas...@gmail.com>
> > ---
> >  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_i

[linux-sunxi] Re: [PATCH sunxi-tools v5] fel: support selection of specific USB bus and device number

[Siarhei Siamashka]

uboot" command = U-Boot 
> autostart */
>   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", , ) != 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 <siarhei.siamas...@gmail.com>

-- 
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

[Siarhei Siamashka]

 argc -= 1;
> + argv += 1;
>   }
> +
> + request_libusb_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

[Siarhei Siamashka]

On Wed, 16 Mar 2016 20:06:00 -0700 (PDT)
kimdou <rainboy...@gmail.com> 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?

[Siarhei Siamashka]

On Wed, 2 Mar 2016 08:31:03 -0800 (PST)
alexey_11 via linux-sunxi <linux-sunxi@googlegroups.com> 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

[Siarhei Siamashka]

On Mon, 1 Feb 2016 22:49:16 +
André Przywara <andre.przyw...@arm.com> 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 <andre.przyw...@arm.com>
> >> ---
> >>  .../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?

[Siarhei Siamashka]

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

[Siarhei Siamashka]

On Mon, 25 Jan 2016 06:50:54 +0200
Siarhei Siamashka <siarhei.siamas...@gmail.com> 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 <siarhei.siamas...@gmail.com>
> ---
>  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 3/7] fel: Move the backup storage to the SRAM B on A31

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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 7/7] fel: Add fel spl command support for Allwinner A64

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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 5/7] fel: Move the temporary scratch buffer under the IRQ stack

[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
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 <siarhei.siamas...@gmail.com>
---
 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,
 

[linux-sunxi] [PATCH sunxi-tools 0/7] fel: OpenRISC preparations and A64 support

[Siarhei Siamashka]

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.

[linux-sunxi] [PATCH sunxi-tools 6/7] fel: Add "readl" and "writel" commands

[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 <siarhei.siamas...@gmail.com>
---
 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, , 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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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.

Re: [linux-sunxi] A64, arisc, SCPI and regulator handling

[Siarhei Siamashka]

ctly 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] Another take on sunxi-tools.

[Siarhei Siamashka]

Hello Eddy,

On Tue, 5 Jan 2016 22:55:40 -0500
Eddy Beaupré <hyw...@gmail.com> 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 experimentation.

-- 
Best regards,
Siarhei Siamashka

-- 
You re

Re: [linux-sunxi] [PATCH] Add FEX file for Foxconn Super Pi

[Siarhei Siamashka]

On Wed, 6 Jan 2016 00:45:00 -0800 (PST)
Hsüan-Ming Ko(vickycq) <kohsuanm...@gmail.com> 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

[Siarhei Siamashka]

On Fri, 1 Jan 2016 12:38:53 +0900
Naoki FUKAUMI <nao...@gmail.com> 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] Re: fel-sdboot.sunxi problems on Cubietruck and A20-OLinuXino-MICRO

[Siarhei Siamashka]

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}
   0x00000022    014b 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

[Siarhei Siamashka]

5474f4e 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

[Siarhei Siamashka]

On Tue, 17 Nov 2015 15:32:30 +0100
Jens Kuske <jensku...@gmail.com> 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: PSCI for H3

[Siarhei Siamashka]

On Wed, 23 Dec 2015 22:36:19 +0800
Chen-Yu Tsai <w...@csie.org> wrote:

> On Wed, Dec 23, 2015 at 6:14 PM, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > On Tue, 17 Nov 2015 15:32:30 +0100
> > Jens Kuske <jensku...@gmail.com> 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: [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[Siarhei Siamashka]

On Sat, 19 Dec 2015 22:18:28 +0100
Thomas Kaiser <thomas.kai...@phg-online.de> 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 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Siarhei Siamashka]

Hi,

On Wed, 16 Dec 2015 10:11:38 +0100
Hans de Goede <hdego...@redhat.com> wrote:

> Hi,
> 
> On 16-12-15 08:35, Siarhei Siamashka wrote:
> > On Thu, 10 Dec 2015 04:31:05 -0800 (PST)
> > Thomas Kaiser <thomas.kai...@phg-online.de> 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=findpost=257=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

[Siarhei Siamashka]

On Wed, 9 Dec 2015 00:40:18 -0800 (PST)
Thomas Kaiser <thomas.kai...@phg-online.de> 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

[Siarhei Siamashka]

On Wed, 16 Dec 2015 12:14:10 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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

[Siarhei Siamashka]

On Thu, 10 Dec 2015 10:29:52 +0100
Jens Kuske <jensku...@gmail.com> wrote:

> On 10/12/15 03:13, Siarhei Siamashka wrote:
> > Hello,
> > 
> > On Wed, 9 Dec 2015 19:29:49 +0100
> > Jens Kuske <jensku...@gmail.com> 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 <siarhei.siamas...@gmail.com>  
> 
> 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 differenc

Re: [linux-sunxi] [PATCH 1/3] sunxi-tools: script_extractor: bug fixes

[Siarhei Siamashka]

Hello Justin,

On Wed,  2 Dec 2015 01:45:30 +0200
Justin Swartz <justin.swa...@risingedge.co.za> 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 <justin.swa...@risingedge.co.za>
> ---
>  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.

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Siarhei Siamashka]

On Thu, 10 Dec 2015 04:31:05 -0800 (PST)
Thomas Kaiser <thomas.kai...@phg-online.de> 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=findpost=257=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 v5 6/9] sunxi-tools: Add file_size() and factor out a reusable file_upload()

[Siarhei Siamashka]

On Mon, 7 Dec 2015 12:03:41 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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.

Re: [linux-sunxi] [PATCH 3/3] sunxi-tools: README: Cross-compilation examples

[Siarhei Siamashka]

On Wed,  2 Dec 2015 01:45:32 +0200
Justin Swartz <justin.swa...@risingedge.co.za> 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 <justin.swa...@risingedge.co.za>
> ---
>  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.

[linux-sunxi] Re: [PATCH 1/2] sunxi-tools: some trivial fixes

[Siarhei Siamashka]

On Thu, 19 Nov 2015 16:01:37 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> wrote:

> - get rid of double includes
> - fix U-Boot source reference
> - get rid of "uboot_autostart" variable
> 
> Signed-off-by: Bernhard Nortmann <bernhard.nortm...@web.de>
> ---
>  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.

[linux-sunxi] Re: [PATCH v5 0/8] sunxi-tools: support progress display for FEL utility

[Siarhei Siamashka]

On Mon, 7 Dec 2015 12:17:04 +0100
Bernhard Nortmann <bernhard.nortm...@web.de> 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] [PATCH 2/3] sunxi-tools: Makefile: Add sunxi-script_extractor target

[Siarhei Siamashka]

On Wed,  2 Dec 2015 01:45:31 +0200
Justin Swartz <justin.swa...@risingedge.co.za> wrote:

> Signed-off-by: Justin Swartz <justin.swa...@risingedge.co.za>
> ---
>  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] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Siarhei Siamashka]

Hello,

On Wed, 9 Dec 2015 19:29:49 +0100
Jens Kuske <jensku...@gmail.com> 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 <siarhei.siamas...@gmail.com>

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(_ctl->datx[i].iocr[j], val);
> +   writel(val, _ctl->datx[i].iocr[j]);
> }
>  
> clrbits_le32(_ctl->pgcr[0], 1 << 26);
> @@ -85,8 +85,8 @@ static void mctl_dq_delay(u32 read, 

[linux-sunxi] [PATCH sunxi-boards 3/3] h3: Update cpufreq and cooling state tables on Orange Pi PC

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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
 

[linux-sunxi] [PATCH sunxi-boards 1/3] h3: Add fex file for Orange Pi PC

[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, 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 <siarhei.siamas...@gmail.com>
---
 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:P

[linux-sunxi] [PATCH sunxi-boards 2/3] h3: Make LEDs available in /sys/class/leds on Orange Pi PC

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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 3.4 4/9] sunxi: mali: Handle both framebuffers in the Mali validation code

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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;
-sta

[linux-sunxi] [PATCH 3.4 1/9] sunxi: defconfig: Use performance cpufreq governor by default

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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.

[linux-sunxi] [PATCH 3.4 0/9] Better out of the box behavior for sunxi-3.4

[Siarhei Siamashka]

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 2/9] sunxi: defconfig: Enable ROOT_NFS support

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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, ,
+   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 9/9] sunxi: cedar: Allocate memory buffer only when /dev/cedar_dev is open

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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, ,
+   GFP_KERNEL | GFP_DMA);
+   if (!ve_start_virt) {
+   printk(KERN_NOTICE "cedar: failed to allocate memory buffer\n");
+   up(>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(>sem);
+   return -ENOMEM;
+   }
+#else
+   if (ve_size == 0) {
+   printk("[cedar dev]: not installed! ve_mem_reserve=0\n");
+   up(>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(>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, ,
-   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(_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 8/9] sunxi: cedar: Allow only one /dev/cedar_dev user at a time

[Siarhei Siamashka]

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 <siarhei.siamas...@gmail.com>
---
 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(>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(>sem)) {
-   return -ERESTARTSYS;
-   }
+
/* release other resource here */
-devp->irq_flag = 1;
+   devp->irq_flag = 1;
up(>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 6/9] sunxi: mali: Fix problems with a static build of the Mali driver

[Siarhei Siamashka]

There are a bunch of common functions used in the 'mali' and
'ump' modules. In fact, the the source files with these functions
are even symlinked between 'ump' and 'mali' directories since
commit 08084c4f2351a190b53f3f39f5b35b8821cc11e4 ("sunxi: prevent
mali drivers from building every time").

But if we try to build both 'mali' and 'ump' modules statically,
then the linker complains about duplicated functions. In order
to resolve this problem, just mark the problematic functions
as 'weak'.

Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
 drivers/gpu/mali/Kconfig   |  2 +-
 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 ++--
 drivers/gpu/mali/ump/linux/ump_kernel_linux.c  |  2 +-
 7 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/mali/Kconfig b/drivers/gpu/mali/Kconfig
index 2c7f9b6..32d1e91 100644
--- a/drivers/gpu/mali/Kconfig
+++ b/drivers/gpu/mali/Kconfig
@@ -1,6 +1,6 @@
 config MALI
tristate "ARM Mali GPU modules"
-   depends on ARM && m
+   depends on ARM
 select UMP
 select MALI400
default n
diff --git a/drivers/gpu/mali/mali/linux/mali_osk_atomics.c 
b/drivers/gpu/mali/mali/linux/mali_osk_atomics.c
index 846fd3b..9dad2e7 100644
--- a/drivers/gpu/mali/mali/linux/mali_osk_atomics.c
+++ b/drivers/gpu/mali/mali/linux/mali_osk_atomics.c
@@ -17,39 +17,39 @@
 #include 
 #include "mali_kernel_common.h"
 
-void _mali_osk_atomic_dec( _mali_osk_atomic_t *atom )
+__weak void _mali_osk_atomic_dec( _mali_osk_atomic_t *atom )
 {
 atomic_dec((atomic_t *)>u.val);
 }
 
-u32 _mali_osk_atomic_dec_return( _mali_osk_atomic_t *atom )
+__weak u32 _mali_osk_atomic_dec_return( _mali_osk_atomic_t *atom )
 {
 return atomic_dec_return((atomic_t *)>u.val);
 }
 
-void _mali_osk_atomic_inc( _mali_osk_atomic_t *atom )
+__weak void _mali_osk_atomic_inc( _mali_osk_atomic_t *atom )
 {
 atomic_inc((atomic_t *)>u.val);
 }
 
-u32 _mali_osk_atomic_inc_return( _mali_osk_atomic_t *atom )
+__weak u32 _mali_osk_atomic_inc_return( _mali_osk_atomic_t *atom )
 {
 return atomic_inc_return((atomic_t *)>u.val);
 }
 
-_mali_osk_errcode_t _mali_osk_atomic_init( _mali_osk_atomic_t *atom, u32 val )
+__weak _mali_osk_errcode_t _mali_osk_atomic_init( _mali_osk_atomic_t *atom, 
u32 val )
 {
 MALI_CHECK_NON_NULL(atom, _MALI_OSK_ERR_INVALID_ARGS);
 atomic_set((atomic_t *)>u.val, val);
 return _MALI_OSK_ERR_OK;
 }
 
-u32 _mali_osk_atomic_read( _mali_osk_atomic_t *atom )
+__weak u32 _mali_osk_atomic_read( _mali_osk_atomic_t *atom )
 {
 return atomic_read((atomic_t *)>u.val);
 }
 
-void _mali_osk_atomic_term( _mali_osk_atomic_t *atom )
+__weak void _mali_osk_atomic_term( _mali_osk_atomic_t *atom )
 {
 MALI_IGNORE(atom);
 }
diff --git a/drivers/gpu/mali/mali/linux/mali_osk_locks.c 
b/drivers/gpu/mali/mali/linux/mali_osk_locks.c
index c3c8d09..34e05ee 100644
--- a/drivers/gpu/mali/mali/linux/mali_osk_locks.c
+++ b/drivers/gpu/mali/mali/linux/mali_osk_locks.c
@@ -73,7 +73,7 @@ struct _mali_osk_lock_t_struct
); /* MALI_DEBUG_CODE */
 };
 
-_mali_osk_lock_t *_mali_osk_lock_init( _mali_osk_lock_flags_t flags, u32 
initial, u32 order )
+__weak _mali_osk_lock_t *_mali_osk_lock_init( _mali_osk_lock_flags_t flags, 
u32 initial, u32 order )
 {
 _mali_osk_lock_t *lock = NULL;
 
@@ -148,23 +148,23 @@ _mali_osk_lock_t *_mali_osk_lock_init( 
_mali_osk_lock_flags_t flags, u32 initial
 }
 
 #ifdef DEBUG
-u32 _mali_osk_lock_get_owner( _mali_osk_lock_t *lock )
+__weak u32 _mali_osk_lock_get_owner( _mali_osk_lock_t *lock )
 {
return lock->owner;
 }
 
-u32 _mali_osk_lock_get_number_owners( _mali_osk_lock_t *lock )
+__weak u32 _mali_osk_lock_get_number_owners( _mali_osk_lock_t *lock )
 {
return lock->nOwners;
 }
 
-u32 _mali_osk_lock_get_mode( _mali_osk_lock_t *lock )
+__weak u32 _mali_osk_lock_get_mode( _mali_osk_lock_t *lock )
 {
return lock->mode;
 }
 #endif /* DEBUG */
 
-_mali_osk_errcode_t _mali_osk_lock_wait( _mali_osk_lock_t *lock, 
_mali_osk_lock_mode_t mode)
+__weak _mali_osk_errcode_t _mali_osk_lock_wait( _mali_osk_lock_t *lock, 
_mali_osk_lock_mode_t mode)
 {
 _mali_osk_errcode_t err = _MALI_OSK_ERR_OK;
 
@@ -247,7 +247,7 @@ _mali_osk_errcode_t _mali_osk_lock_wait( _mali_osk_lock_t 
*lock, _mali_osk_lock_
 return err;
 }
 
-void _mali_osk_lock_signal( _mali_osk_lock_t *lock, _mali_osk_lock_mode_t mode 
)
+__weak void _mali_osk_lock_signal( _mali_osk_lock_t *lock, 
_mali_osk_lock_mode_t mode )
 {
/* Parameter validation */
MALI_DEBUG_ASSERT_POINTER( lock );
@@ -326,7 +326,7 @@ void _mali_osk_lock_signal( _mali_osk_lock_t *lock,

[linux-sunxi] [PATCH 3.4 7/9] sunxi: defconfig: Build the Mali driver statically

[Siarhei Siamashka]

Sometimes people are just forgetting to copy their kernel modules
to the device. Building the Mali kernel driver statically ensures
that people can't make this mistake anymore and removes one of the
potential obstacles on the way to getting 3D accelatation up and
running.

It is also convenient to be able to include the lima-memtester
test program into an initrd image without bothering about adding
kernel modules to the initrd image too.

Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
 arch/arm/configs/sun4i_defconfig | 8 +++-
 arch/arm/configs/sun5i_defconfig | 6 +++---
 arch/arm/configs/sun7i_defconfig | 8 +++-
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/arch/arm/configs/sun4i_defconfig b/arch/arm/configs/sun4i_defconfig
index 38a6073..0679d44 100644
--- a/arch/arm/configs/sun4i_defconfig
+++ b/arch/arm/configs/sun4i_defconfig
@@ -156,7 +156,6 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
 CONFIG_SERIAL_8250_RUNTIME_UARTS=8
 # CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -206,10 +205,9 @@ CONFIG_CSI_OV5640=m
 # CONFIG_RADIO_ADAPTERS is not set
 CONFIG_AUDIO_ENGINE=y
 CONFIG_PA_CONTROL=y
-CONFIG_DRM=m
-CONFIG_DRM_MALI=m
-CONFIG_MALI=m
-CONFIG_FB=y
+CONFIG_DRM=y
+CONFIG_DRM_MALI=y
+CONFIG_MALI=y
 CONFIG_FB_SUNXI=y
 CONFIG_FB_SUNXI_LCD=y
 CONFIG_FB_SUNXI_HDMI=y
diff --git a/arch/arm/configs/sun5i_defconfig b/arch/arm/configs/sun5i_defconfig
index c01d2f4..1eee7d0 100644
--- a/arch/arm/configs/sun5i_defconfig
+++ b/arch/arm/configs/sun5i_defconfig
@@ -135,7 +135,6 @@ CONFIG_SERIAL_NONSTANDARD=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_SPI=y
 CONFIG_GPIOLIB=y
@@ -150,9 +149,10 @@ CONFIG_AXP152=y
 CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_PA_CONTROL=y
-CONFIG_MALI=m
+CONFIG_DRM=y
+CONFIG_DRM_MALI=y
+CONFIG_MALI=y
 # CONFIG_UMP_DEBUG is not set
-CONFIG_FB=y
 CONFIG_FB_SUNXI=y
 CONFIG_FB_SUNXI_LCD=y
 CONFIG_FB_SUNXI_HDMI=y
diff --git a/arch/arm/configs/sun7i_defconfig b/arch/arm/configs/sun7i_defconfig
index a7c8d94..f743b66f 100644
--- a/arch/arm/configs/sun7i_defconfig
+++ b/arch/arm/configs/sun7i_defconfig
@@ -156,7 +156,6 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
 CONFIG_SERIAL_8250_RUNTIME_UARTS=8
 # CONFIG_HW_RANDOM is not set
-CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_SYSFS=y
@@ -206,10 +205,9 @@ CONFIG_CSI_OV5640=m
 # CONFIG_RADIO_ADAPTERS is not set
 CONFIG_AUDIO_ENGINE=y
 CONFIG_PA_CONTROL=y
-CONFIG_DRM=m
-CONFIG_DRM_MALI=m
-CONFIG_MALI=m
-CONFIG_FB=y
+CONFIG_DRM=y
+CONFIG_DRM_MALI=y
+CONFIG_MALI=y
 CONFIG_FB_SUNXI=y
 CONFIG_FB_SUNXI_LCD=y
 CONFIG_FB_SUNXI_HDMI=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.