[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

Store the 'compatibility revision' number in the top 4 bits of the
machine id and pass it to the kernel. The old buggy kernels will
fail to load with a very much googlable error message on the serial
console:

  "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"

This error message can be documented in the linux-sunxi wiki with
proper explanations about how to resolve this situation and where
to get the necessary bugfixes for the sunxi-3.4 kernel.

The fixed sunxi-3.4 kernels can implement a revision compatibility
check and clear the top 4 bits of the machine id if everything is
alright.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
---

To be used together with:
    https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8

 include/configs/sun4i.h        | 4 ++--
 include/configs/sun5i.h        | 4 ++--
 include/configs/sun7i.h        | 4 ++--
 include/configs/sunxi-common.h | 7 +++++++
 4 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h
index 87d269b..1537e53 100644
--- a/include/configs/sun4i.h
+++ b/include/configs/sun4i.h
@@ -13,8 +13,6 @@
  */
 #define CONFIG_CLK_FULL_SPEED		1008000000
 
-#define CONFIG_MACH_TYPE		4104
-
 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
 #define CONFIG_USB_MAX_CONTROLLER_COUNT	2
@@ -25,4 +23,6 @@
  */
 #include <configs/sunxi-common.h>
 
+#define CONFIG_MACH_TYPE	(4104 | ((CONFIG_MACH_TYPE_COMPAT_REV) << 28))
+
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h
index 52e3a6f..e755531 100644
--- a/include/configs/sun5i.h
+++ b/include/configs/sun5i.h
@@ -13,8 +13,6 @@
  */
 #define CONFIG_CLK_FULL_SPEED		1008000000
 
-#define CONFIG_MACH_TYPE		4138
-
 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
 #define CONFIG_USB_MAX_CONTROLLER_COUNT	1
@@ -25,4 +23,6 @@
  */
 #include <configs/sunxi-common.h>
 
+#define CONFIG_MACH_TYPE	(4138 | ((CONFIG_MACH_TYPE_COMPAT_REV) << 28))
+
 #endif /* __CONFIG_H */
diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
index 7cd7890..f817f73 100644
--- a/include/configs/sun7i.h
+++ b/include/configs/sun7i.h
@@ -14,8 +14,6 @@
  */
 #define CONFIG_CLK_FULL_SPEED		912000000
 
-#define CONFIG_MACH_TYPE		4283
-
 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
 #define CONFIG_USB_MAX_CONTROLLER_COUNT	2
@@ -31,4 +29,6 @@
  */
 #include <configs/sunxi-common.h>
 
+#define CONFIG_MACH_TYPE	(4283 | ((CONFIG_MACH_TYPE_COMPAT_REV) << 28))
+
 #endif /* __CONFIG_H */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 5ece020..f3e764a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -14,6 +14,13 @@
 #define _SUNXI_COMMON_CONFIG_H
 
 /*
+ * Compatibility guard to prevent loading old buggy sunxi-3.4 kernels.
+ * Only sunxi-3.4 kernels with appropriate fixes applied are able to
+ * pass beyond the machine id check.
+ */
+#define CONFIG_MACH_TYPE_COMPAT_REV	1
+
+/*
  * High Level Configuration Options
  */
 #define CONFIG_SUNXI		/* sunxi family */
-- 
2.0.5

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 20-02-15 09:08, Siarhei Siamashka wrote:
> Store the 'compatibility revision' number in the top 4 bits of the
> machine id and pass it to the kernel. The old buggy kernels will
> fail to load with a very much googlable error message on the serial
> console:
>
>    "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
>
> This error message can be documented in the linux-sunxi wiki with
> proper explanations about how to resolve this situation and where
> to get the necessary bugfixes for the sunxi-3.4 kernel.
>
> The fixed sunxi-3.4 kernels can implement a revision compatibility
> check and clear the top 4 bits of the machine id if everything is
> alright.
>
> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

TBH I'm not a big fan if this.

> ---
>
> To be used together with:
>      https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8

Nor of this one.

What I would prefer is for CONFIG_OLD_SUNXI_KERNEL_COMPAT to go away
and for u-boot to automatically do the right thing when booting an old
kernel.

Recently some patches where merged to make "bootm" work without an
fdt even when build with fdt support.

Specifically in common/image-fdt.c line 437 there is:

         if (!select && ok_no_fdt) {
                 debug("Continuing to boot without FDT\n");
                 return 0;
         }

So we known when executing the bootm command that we do not have an fdt.

If this is the case, and only when this (no fdt) is the case then in
arch/arm/lib/bootm.c: boot_prep_linux()

The board specific setup_board_tags() function gets called, we could
define our own version of this (it has an empty weak default), and in
our own version fixup things for the old kernel to just work.

That means:

Halving PLL5, then waiting for it to settle, then reprogramming the
DRAM clk divider, I'm assuming that this will work if done in this
order, but we obviously need to test this thoroughly.

Halving PLL6, then waiting for it to settle, then reprogram the MBUS
divider, and check and update mmc mod clock dividers.

Modifying armv7_boot_nonsec so that we can override the default. We
can do this e.g. by adding a global armv7_boot_nonsec_default variable
and setting that from setup_board_tags().

This way we can just do the right thing automatically, and this has
the added advantage that if we later find out that we're doing
something in u-boot which is not good for the older kernels we can
fix it in u-boot without needing to coordinate with the sunxi-3.4
kernels. In my experience the version check for compatibility style
solution you are proposing brings a large maintenance burden, and
it does not actually help the user, as the users wants something
which just works.

Ian, would something like the above be acceptable to you ?

Regards,

Hans

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

On Fri, 20 Feb 2015 10:19:51 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 20-02-15 09:08, Siarhei Siamashka wrote:
> > Store the 'compatibility revision' number in the top 4 bits of the
> > machine id and pass it to the kernel. The old buggy kernels will
> > fail to load with a very much googlable error message on the serial
> > console:
> >
> >    "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
> >
> > This error message can be documented in the linux-sunxi wiki with
> > proper explanations about how to resolve this situation and where
> > to get the necessary bugfixes for the sunxi-3.4 kernel.
> >
> > The fixed sunxi-3.4 kernels can implement a revision compatibility
> > check and clear the top 4 bits of the machine id if everything is
> > alright.
> >
> > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> 
> TBH I'm not a big fan if this.
> 
> > ---
> >
> > To be used together with:
> >      https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8
> 
> Nor of this one.
> 
> What I would prefer is for CONFIG_OLD_SUNXI_KERNEL_COMPAT to go away

Yes, the CONFIG_OLD_SUNXI_KERNEL_COMPAT option is barely useful for
anything right now. And it would be great to get rid of it.

> and for u-boot to automatically do the right thing when booting an old
> kernel.

Sure, but first we need to define what is the "right thing".

> Recently some patches where merged to make "bootm" work without an
> fdt even when build with fdt support.
> 
> Specifically in common/image-fdt.c line 437 there is:
> 
>          if (!select && ok_no_fdt) {
>                  debug("Continuing to boot without FDT\n");
>                  return 0;
>          }
> 
> So we known when executing the bootm command that we do not have an fdt.
> 
> If this is the case, and only when this (no fdt) is the case then in
> arch/arm/lib/bootm.c: boot_prep_linux()
> 
> The board specific setup_board_tags() function gets called, we could
> define our own version of this (it has an empty weak default), and in
> our own version fixup things for the old kernel to just work.

Sounds like we are coming back to

    http://lists.denx.de/pipermail/u-boot/2014-October/191697.html

As you may guess, I'm in favour of having everything working
automatically without the need to set extra Kconfig options or
environment variables :-)

> That means:
> 
> Halving PLL5, then waiting for it to settle, then reprogramming the
> DRAM clk divider, I'm assuming that this will work if done in this
> order, but we obviously need to test this thoroughly.
> 
> Halving PLL6, then waiting for it to settle, then reprogram the MBUS
> divider, and check and update mmc mod clock dividers.

This already looks somewhat more complicated than necessary...

> Modifying armv7_boot_nonsec so that we can override the default. We
> can do this e.g. by adding a global armv7_boot_nonsec_default variable
> and setting that from setup_board_tags().
> 
> This way we can just do the right thing automatically,

By the "right thing", do you mean booting the sunxi-3.4 kernel with
weird PLL5 and PLL6 settings just because some *older* versions of
this kernel used to have bugs in the past?

> and this has
> the added advantage that if we later find out that we're doing
> something in u-boot which is not good for the older kernels we can
> fix it in u-boot without needing to coordinate with the sunxi-3.4
> kernels. In my experience the version check for compatibility style
> solution you are proposing brings a large maintenance burden,

I don't expect any maintenance burden at all. We only ever need this
coordination to take care of very serious showstopper bugs. And such
bugs have been already fixed.

We probably might only need an update for this version check if we try
to adjust AXP152 DCDC4 voltage on A10s (and the sunxi-3.4 kernel would
need to be patched in order not to touch DCDC4). Or if some other
critical compatibility problem gets reported.

Please note that the newly discovered PLL6 issue is not a critical
one and does not even deserve any coordination or version bump at all.
It only causes some performance drop (MBUS clock speed reduction from
204 MHz to 150 MHz) and is easy to workaround in other ways.

> and it does not actually help the user, as the users wants something
> which just works.

And the users do have something that just works.

The only problem here is poor errors reporting. Tsvetan and Lars wasted
some of their time doing debugging simply because they picked a wrong
kernel. If they had a sane error message right from the start, then
they would have just switched to a different kernel and be good.
Or cherry picked the important fixes in the case of working with a
heavily diverged sunxi-3.4 fork.

Tsvetan, Lars: do you have any comments on this?

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 20-02-15 11:36, Siarhei Siamashka wrote:
> On Fri, 20 Feb 2015 10:19:51 +0100
> Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Hi,
>>
>> On 20-02-15 09:08, Siarhei Siamashka wrote:
>>> Store the 'compatibility revision' number in the top 4 bits of the
>>> machine id and pass it to the kernel. The old buggy kernels will
>>> fail to load with a very much googlable error message on the serial
>>> console:
>>>
>>>     "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
>>>
>>> This error message can be documented in the linux-sunxi wiki with
>>> proper explanations about how to resolve this situation and where
>>> to get the necessary bugfixes for the sunxi-3.4 kernel.
>>>
>>> The fixed sunxi-3.4 kernels can implement a revision compatibility
>>> check and clear the top 4 bits of the machine id if everything is
>>> alright.
>>>
>>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
>>
>> TBH I'm not a big fan if this.
>>
>>> ---
>>>
>>> To be used together with:
>>>       https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8
>>
>> Nor of this one.
>>
>> What I would prefer is for CONFIG_OLD_SUNXI_KERNEL_COMPAT to go away
>
> Yes, the CONFIG_OLD_SUNXI_KERNEL_COMPAT option is barely useful for
> anything right now. And it would be great to get rid of it.
>
>> and for u-boot to automatically do the right thing when booting an old
>> kernel.
>
> Sure, but first we need to define what is the "right thing".
>
>> Recently some patches where merged to make "bootm" work without an
>> fdt even when build with fdt support.
>>
>> Specifically in common/image-fdt.c line 437 there is:
>>
>>           if (!select && ok_no_fdt) {
>>                   debug("Continuing to boot without FDT\n");
>>                   return 0;
>>           }
>>
>> So we known when executing the bootm command that we do not have an fdt.
>>
>> If this is the case, and only when this (no fdt) is the case then in
>> arch/arm/lib/bootm.c: boot_prep_linux()
>>
>> The board specific setup_board_tags() function gets called, we could
>> define our own version of this (it has an empty weak default), and in
>> our own version fixup things for the old kernel to just work.
>
> Sounds like we are coming back to
>
>      http://lists.denx.de/pipermail/u-boot/2014-October/191697.html

Yes.

> As you may guess, I'm in favour of having everything working
> automatically without the need to set extra Kconfig options or
> environment variables :-)

So am I.

>
>> That means:
>>
>> Halving PLL5, then waiting for it to settle, then reprogramming the
>> DRAM clk divider, I'm assuming that this will work if done in this
>> order, but we obviously need to test this thoroughly.
>>
>> Halving PLL6, then waiting for it to settle, then reprogram the MBUS
>> divider, and check and update mmc mod clock dividers.
>
> This already looks somewhat more complicated than necessary...

So how about we just halve the frequency of the 2 PLL-s
(PLL6 only on sun5i) everywhere and be done with it?

It seems to me that the advantage of having them doubled so that we
can get more clocks is mostly theoretical in both cases anyways.

I'm fine with halving PLL6 on sun5i, but I believe we should then really
also have PLL5 everywhere, taking us back to the original allwinner /
u-boot-sunxi settings.

I seriously wonder what exactly, concretely having PLL5 doubled gains
us. Yes we could run MBUS on 2/3th of the DRAM speed which we cannot
do otherwise, but AFAIK we want MBUS at 300 for optimal perfomance,
and we can get MBUS at exactly 300 by using pll6 as its parent
(even if we halve PLL6).

Do you have any non theoritical example where having PLL5 doubled helps?
Because if not then I'm becoming more and more in favor of just halving
it leaving us with only the A20 sec vs nonsec boot thing for which the
solution which I've outlined in my previous mail should work nicely.

>> Modifying armv7_boot_nonsec so that we can override the default. We
>> can do this e.g. by adding a global armv7_boot_nonsec_default variable
>> and setting that from setup_board_tags().
>>
>> This way we can just do the right thing automatically,
>
> By the "right thing", do you mean booting the sunxi-3.4 kernel with
> weird PLL5 and PLL6 settings just because some *older* versions of
> this kernel used to have bugs in the past?
>
>> and this has
>> the added advantage that if we later find out that we're doing
>> something in u-boot which is not good for the older kernels we can
>> fix it in u-boot without needing to coordinate with the sunxi-3.4
>> kernels. In my experience the version check for compatibility style
>> solution you are proposing brings a large maintenance burden,
>
> I don't expect any maintenance burden at all. We only ever need this
> coordination to take care of very serious showstopper bugs. And such
> bugs have been already fixed.

Been there done that did not like it, this is going to suck big time,
trust me I've done enough of this kinda stuff to know.

Regards,

Hans

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

On Fri, 20 Feb 2015 15:11:04 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 20-02-15 11:36, Siarhei Siamashka wrote:
> > On Fri, 20 Feb 2015 10:19:51 +0100
> > Hans de Goede <hdegoede@redhat.com> wrote:
> >
> >> Hi,
> >>
> >> On 20-02-15 09:08, Siarhei Siamashka wrote:
> >>> Store the 'compatibility revision' number in the top 4 bits of the
> >>> machine id and pass it to the kernel. The old buggy kernels will
> >>> fail to load with a very much googlable error message on the serial
> >>> console:
> >>>
> >>>     "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
> >>>
> >>> This error message can be documented in the linux-sunxi wiki with
> >>> proper explanations about how to resolve this situation and where
> >>> to get the necessary bugfixes for the sunxi-3.4 kernel.
> >>>
> >>> The fixed sunxi-3.4 kernels can implement a revision compatibility
> >>> check and clear the top 4 bits of the machine id if everything is
> >>> alright.
> >>>
> >>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
> >>
> >> TBH I'm not a big fan if this.
> >>
> >>> ---
> >>>
> >>> To be used together with:
> >>>       https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8
> >>
> >> Nor of this one.
> >>
> >> What I would prefer is for CONFIG_OLD_SUNXI_KERNEL_COMPAT to go away
> >
> > Yes, the CONFIG_OLD_SUNXI_KERNEL_COMPAT option is barely useful for
> > anything right now. And it would be great to get rid of it.
> >
> >> and for u-boot to automatically do the right thing when booting an old
> >> kernel.
> >
> > Sure, but first we need to define what is the "right thing".
> >
> >> Recently some patches where merged to make "bootm" work without an
> >> fdt even when build with fdt support.
> >>
> >> Specifically in common/image-fdt.c line 437 there is:
> >>
> >>           if (!select && ok_no_fdt) {
> >>                   debug("Continuing to boot without FDT\n");
> >>                   return 0;
> >>           }
> >>
> >> So we known when executing the bootm command that we do not have an fdt.
> >>
> >> If this is the case, and only when this (no fdt) is the case then in
> >> arch/arm/lib/bootm.c: boot_prep_linux()
> >>
> >> The board specific setup_board_tags() function gets called, we could
> >> define our own version of this (it has an empty weak default), and in
> >> our own version fixup things for the old kernel to just work.
> >
> > Sounds like we are coming back to
> >
> >      http://lists.denx.de/pipermail/u-boot/2014-October/191697.html
> 
> Yes.
> 
> > As you may guess, I'm in favour of having everything working
> > automatically without the need to set extra Kconfig options or
> > environment variables :-)
> 
> So am I.
> 
> >
> >> That means:
> >>
> >> Halving PLL5, then waiting for it to settle, then reprogramming the
> >> DRAM clk divider, I'm assuming that this will work if done in this
> >> order, but we obviously need to test this thoroughly.
> >>
> >> Halving PLL6, then waiting for it to settle, then reprogram the MBUS
> >> divider, and check and update mmc mod clock dividers.
> >
> > This already looks somewhat more complicated than necessary...
> 
> So how about we just halve the frequency of the 2 PLL-s
> (PLL6 only on sun5i) everywhere and be done with it?

Yes, that's what I also asked in

    http://lists.denx.de/pipermail/u-boot/2015-February/205637.html

> It seems to me that the advantage of having them doubled so that we
> can get more clocks is mostly theoretical in both cases anyways.

It is not so theoretical for PLL5P though.

> I'm fine with halving PLL6 on sun5i, but I believe we should then really
> also have PLL5 everywhere, taking us back to the original allwinner /
> u-boot-sunxi settings.
> 
> I seriously wonder what exactly, concretely having PLL5 doubled gains
> us. Yes we could run MBUS on 2/3th of the DRAM speed which we cannot
> do otherwise, but AFAIK we want MBUS at 300 for optimal perfomance,
> and we can get MBUS at exactly 300 by using pll6 as its parent
> (even if we halve PLL6).

We might potentially want to set MBUS higher than 300. Yes, the
A13 manual says that 300MHz is the limit. But in practice it can be
increased as high as 576MHz on more than one board (with some VDD-DLL
voltage increase). There seems to be really a lot of headroom and going
slightly beyond 300MHz might be OK.

> Do you have any non theoritical example where having PLL5 doubled helps?

Sigh. I believe, that I had already explained it multiple times in
various e-mail posts. But here we go again:

1. The G2D (Mixer Processor) clock speed has a certain limit. We don't
know what it is exactly, but the sunxi-3.4 kernel used to hardcode it
to 1/2 of the PLL5P speed, which means that we can assume at least
240MHz for the boards with 480MHz DRAM clock speed.

Now let's see what happens if we try to increase the DRAM clock speed
to 504MHz. In the case of the doubled PLL5P and divisor 5, we can get
1008MHz / 5 = 201.6 MHz clock speed for the G2D. But in the case
of the same PLL5P as the DRAM clock speed, we have to use the divisor
3 and only get 504MHz / 3 = 168MHz. Obviously, 201.6MHz is faster than
168MHz.

The erratic G2D clock speed drops when gradually increasing the DRAM
clock speed are not very nice. People are going to have a lot of
headache finding a reasonable compromise between the DRAM and G2D
performance. Doubling PLL5 reduces the performance penalties.

And yes, G2D is used today in the sunxi-3.4 kernel. Hopefully it
will be also supported in the mainline kernel soon.

2. If we configure the DRAM clock speed as 648MHz, then the PLL5
clock speed already becomes rather high. IMHO, it is not healthy
for the peripherals even without further doubling it. Tsvetan
reported LCD flicker problems at 768MHz, which is not terribly 
far away from 648MHz. The real solution is to use the bugfixed
sunxi-3.4 kernels, and the fixes are not very invasive (which
means that they can be cherry picked to any potential fork).

3. Not quite related to PLL5, but we have to deal with the voltage
regulators too. Old buggy kernels are also trying to change the DCDC3
voltage in the case of AXP209 and DCDC4 voltage in the case of AXP152.
Which means that u-boot can't safely change these voltages if the
compatibility with old buggy kernels is desired. Without increasing
the VDD-DLL voltage, we can't reach very high MBUS and DRAM clock
speeds. This is yet another PITA, which holds us back.

4. Currently running DRAM reliability tests requires the sunxi-3.4
kernel (see https://github.com/ssvb/lima-memtester/ for more details).
I don't really like having different DRAM clock speed setup for the
mainline kernel and for the sunxi-3.4 kernel, that's why using the
CONFIG_OLD_SUNXI_KERNEL_COMPAT option is not a very good idea in
general. It's much better to use the bugfixed sunxi-3.4 kernel
without CONFIG_OLD_SUNXI_KERNEL_COMPAT.

> Because if not then I'm becoming more and more in favor of just halving
> it 

The sun4i/sun5i/sun7i DRAM controller code in u-boot is ready for much
faster DRAM clock speeds since the v2014.10 release. We are only
missing the appropriate 'dram_para' settings for the boards, which can
be prepared/verified according to the instructions from the linux-sunxi
wiki. But there does not seem to be much interest in the performance
and reliability for the sunxi boards yet. And participation of the
hardware vendors (for doing large scale tests on many boards) is
missing too.

Maybe now after the introduction of the Raspberry Pi 2, the Allwinner
based devboard manufacturers might become a bit more interested in
tweaking the performance in order to remain competitive.

I believe that every Cubietruck user had more than enough time to
try my 'highspeedtruck' branches posted at

    http://lists.denx.de/pipermail/u-boot/2014-July/183981.html

That's "the proof of the pudding", which demonstrates what is
possible with this hardware :-)

But now you are telling me that you are in favour of crippling it
before it really takes off the ground...

> leaving us with only the A20 sec vs nonsec boot thing for which the
> solution which I've outlined in my previous mail should work nicely.

Well, this is not really a news. We could have fixed the sec vs nonsec
boot thing months ago (if there only was a consensus about it). But
better late than never.

> >> Modifying armv7_boot_nonsec so that we can override the default. We
> >> can do this e.g. by adding a global armv7_boot_nonsec_default variable
> >> and setting that from setup_board_tags().
> >>
> >> This way we can just do the right thing automatically,
> >
> > By the "right thing", do you mean booting the sunxi-3.4 kernel with
> > weird PLL5 and PLL6 settings just because some *older* versions of
> > this kernel used to have bugs in the past?
> >
> >> and this has
> >> the added advantage that if we later find out that we're doing
> >> something in u-boot which is not good for the older kernels we can
> >> fix it in u-boot without needing to coordinate with the sunxi-3.4
> >> kernels. In my experience the version check for compatibility style
> >> solution you are proposing brings a large maintenance burden,
> >
> > I don't expect any maintenance burden at all. We only ever need this
> > coordination to take care of very serious showstopper bugs. And such
> > bugs have been already fixed.
> 
> Been there done that did not like it, this is going to suck big time,
> trust me I've done enough of this kinda stuff to know.

I would say, that it would be a good idea to trust me this time for a
change :-) You were given a chance to enforce your own solution, and
it quite predictably sucks. Too bad that Tsvetan and Lars had to
encounter problems in order to (hopefully) make this clear for everyone.

In fact, I have a better suggestion. We can have this versioned
machine id hack active only when CONFIG_OLD_SUNXI_KERNEL_COMPAT
is not defined. So that the normal build does not have non-obvious
runtime failures with unpatched sunxi-3.4 kernels anymore. And the
CONFIG_OLD_SUNXI_KERNEL_COMPAT still works just like before. I'll
send a v2 patch shortly.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 20-02-15 19:33, Siarhei Siamashka wrote:
> On Fri, 20 Feb 2015 15:11:04 +0100
> Hans de Goede <hdegoede@redhat.com> wrote:
>
>> Hi,
>>
>> On 20-02-15 11:36, Siarhei Siamashka wrote:
>>> On Fri, 20 Feb 2015 10:19:51 +0100
>>> Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 20-02-15 09:08, Siarhei Siamashka wrote:
>>>>> Store the 'compatibility revision' number in the top 4 bits of the
>>>>> machine id and pass it to the kernel. The old buggy kernels will
>>>>> fail to load with a very much googlable error message on the serial
>>>>> console:
>>>>>
>>>>>      "Error: unrecognized/unsupported machine ID (r1 = 0x100010bb)"
>>>>>
>>>>> This error message can be documented in the linux-sunxi wiki with
>>>>> proper explanations about how to resolve this situation and where
>>>>> to get the necessary bugfixes for the sunxi-3.4 kernel.
>>>>>
>>>>> The fixed sunxi-3.4 kernels can implement a revision compatibility
>>>>> check and clear the top 4 bits of the machine id if everything is
>>>>> alright.
>>>>>
>>>>> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
>>>>
>>>> TBH I'm not a big fan if this.
>>>>
>>>>> ---
>>>>>
>>>>> To be used together with:
>>>>>        https://groups.google.com/forum/#!topic/linux-sunxi/LOAxP3kAYs8
>>>>
>>>> Nor of this one.
>>>>
>>>> What I would prefer is for CONFIG_OLD_SUNXI_KERNEL_COMPAT to go away
>>>
>>> Yes, the CONFIG_OLD_SUNXI_KERNEL_COMPAT option is barely useful for
>>> anything right now. And it would be great to get rid of it.
>>>
>>>> and for u-boot to automatically do the right thing when booting an old
>>>> kernel.
>>>
>>> Sure, but first we need to define what is the "right thing".
>>>
>>>> Recently some patches where merged to make "bootm" work without an
>>>> fdt even when build with fdt support.
>>>>
>>>> Specifically in common/image-fdt.c line 437 there is:
>>>>
>>>>            if (!select && ok_no_fdt) {
>>>>                    debug("Continuing to boot without FDT\n");
>>>>                    return 0;
>>>>            }
>>>>
>>>> So we known when executing the bootm command that we do not have an fdt.
>>>>
>>>> If this is the case, and only when this (no fdt) is the case then in
>>>> arch/arm/lib/bootm.c: boot_prep_linux()
>>>>
>>>> The board specific setup_board_tags() function gets called, we could
>>>> define our own version of this (it has an empty weak default), and in
>>>> our own version fixup things for the old kernel to just work.
>>>
>>> Sounds like we are coming back to
>>>
>>>       http://lists.denx.de/pipermail/u-boot/2014-October/191697.html
>>
>> Yes.
>>
>>> As you may guess, I'm in favour of having everything working
>>> automatically without the need to set extra Kconfig options or
>>> environment variables :-)
>>
>> So am I.
>>
>>>
>>>> That means:
>>>>
>>>> Halving PLL5, then waiting for it to settle, then reprogramming the
>>>> DRAM clk divider, I'm assuming that this will work if done in this
>>>> order, but we obviously need to test this thoroughly.
>>>>
>>>> Halving PLL6, then waiting for it to settle, then reprogram the MBUS
>>>> divider, and check and update mmc mod clock dividers.
>>>
>>> This already looks somewhat more complicated than necessary...
>>
>> So how about we just halve the frequency of the 2 PLL-s
>> (PLL6 only on sun5i) everywhere and be done with it?
>
> Yes, that's what I also asked in
>
>      http://lists.denx.de/pipermail/u-boot/2015-February/205637.html
>
>> It seems to me that the advantage of having them doubled so that we
>> can get more clocks is mostly theoretical in both cases anyways.
>
> It is not so theoretical for PLL5P though.
>
>> I'm fine with halving PLL6 on sun5i, but I believe we should then really
>> also have PLL5 everywhere, taking us back to the original allwinner /
>> u-boot-sunxi settings.
>>
>> I seriously wonder what exactly, concretely having PLL5 doubled gains
>> us. Yes we could run MBUS on 2/3th of the DRAM speed which we cannot
>> do otherwise, but AFAIK we want MBUS at 300 for optimal perfomance,
>> and we can get MBUS at exactly 300 by using pll6 as its parent
>> (even if we halve PLL6).
>
> We might potentially want to set MBUS higher than 300. Yes, the
> A13 manual says that 300MHz is the limit. But in practice it can be
> increased as high as 576MHz on more than one board (with some VDD-DLL
> voltage increase). There seems to be really a lot of headroom and going
> slightly beyond 300MHz might be OK.
>
>> Do you have any non theoritical example where having PLL5 doubled helps?
>
> Sigh. I believe, that I had already explained it multiple times in
> various e-mail posts. But here we go again:
>
> 1. The G2D (Mixer Processor) clock speed has a certain limit. We don't
> know what it is exactly, but the sunxi-3.4 kernel used to hardcode it
> to 1/2 of the PLL5P speed, which means that we can assume at least
> 240MHz for the boards with 480MHz DRAM clock speed.
>
> Now let's see what happens if we try to increase the DRAM clock speed
> to 504MHz. In the case of the doubled PLL5P and divisor 5, we can get
> 1008MHz / 5 = 201.6 MHz clock speed for the G2D. But in the case
> of the same PLL5P as the DRAM clock speed, we have to use the divisor
> 3 and only get 504MHz / 3 = 168MHz. Obviously, 201.6MHz is faster than
> 168MHz.
>
> The erratic G2D clock speed drops when gradually increasing the DRAM
> clock speed are not very nice. People are going to have a lot of
> headache finding a reasonable compromise between the DRAM and G2D
> performance. Doubling PLL5 reduces the performance penalties.

Hmm, I see that is a nasty problem, esp. with the older kernels
not dealing well with the doubled pll.

> And yes, G2D is used today in the sunxi-3.4 kernel. Hopefully it
> will be also supported in the mainline kernel soon.
>
> 2. If we configure the DRAM clock speed as 648MHz, then the PLL5
> clock speed already becomes rather high. IMHO, it is not healthy
> for the peripherals even without further doubling it. Tsvetan
> reported LCD flicker problems at 768MHz, which is not terribly
> far away from 648MHz. The real solution is to use the bugfixed
> sunxi-3.4 kernels, and the fixes are not very invasive (which
> means that they can be cherry picked to any potential fork).

Ok, but then we should really also fix the PLL6 issue on sun5i in
the older kernels, that should be as simple as simply removing the
call setting the PLL6 speed from the code you pointed too, everything
else can pretty much be kept as is. But I'm afraid I've other priorities
then fixing this.

> 3. Not quite related to PLL5, but we have to deal with the voltage
> regulators too. Old buggy kernels are also trying to change the DCDC3
> voltage in the case of AXP209 and DCDC4 voltage in the case of AXP152.
> Which means that u-boot can't safely change these voltages if the
> compatibility with old buggy kernels is desired. Without increasing
> the VDD-DLL voltage, we can't reach very high MBUS and DRAM clock
> speeds. This is yet another PITA, which holds us back.

And something which we could fix by increasing the number you want to
store in the high bits of the machine id and then too old kernels would
simply not work rather then be unreliable. So yes I can see why you want
what you want.

> 4. Currently running DRAM reliability tests requires the sunxi-3.4
> kernel (see https://github.com/ssvb/lima-memtester/ for more details).
> I don't really like having different DRAM clock speed setup for the
> mainline kernel and for the sunxi-3.4 kernel, that's why using the
> CONFIG_OLD_SUNXI_KERNEL_COMPAT option is not a very good idea in
> general. It's much better to use the bugfixed sunxi-3.4 kernel
> without CONFIG_OLD_SUNXI_KERNEL_COMPAT.
>
>> Because if not then I'm becoming more and more in favor of just halving
>> it
>
> The sun4i/sun5i/sun7i DRAM controller code in u-boot is ready for much
> faster DRAM clock speeds since the v2014.10 release. We are only
> missing the appropriate 'dram_para' settings for the boards, which can
> be prepared/verified according to the instructions from the linux-sunxi
> wiki. But there does not seem to be much interest in the performance
> and reliability for the sunxi boards yet. And participation of the
> hardware vendors (for doing large scale tests on many boards) is
> missing too.
>
> Maybe now after the introduction of the Raspberry Pi 2, the Allwinner
> based devboard manufacturers might become a bit more interested in
> tweaking the performance in order to remain competitive.
>
> I believe that every Cubietruck user had more than enough time to
> try my 'highspeedtruck' branches posted at
>
>      http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
>
> That's "the proof of the pudding", which demonstrates what is
> possible with this hardware :-)

I still believe that the only way to get anywhere wrt getting better
DRAM speeds is to just make the change. As said before if you submit
patches to increase DRAM speed on some boards I'll put them in
my personal sunxi-wip and the official u-boot-sunxi/next asap, and
then we can ask people to test that, and once the merge window for
v2015.07 opens we can land those changes and see from there.

What would also be welcome is a wiki page for reading DRAM chip
markings, so that people can figure out what their board should
be able to handle theoretically (assuming the pcb is not holding
things back).

> But now you are telling me that you are in favour of crippling it
> before it really takes off the ground...

When I was asking why not just halve pll5 I was sincerely asking, and
your g2d story is a compeling reason not to do that, if only the g2d could
use pll6 as a parent, then we could just run it as 300MHz (which I
believe should be a safe speed, as that is what the limit seems to
be for the backend and frontend bits), but alas like the backend /
frontend it has an IMHO weird set of parent choices. Given that
weird set of parent choices I see the logic in not wanting to halve
pll5, so lets try to find another solution for this.

>> leaving us with only the A20 sec vs nonsec boot thing for which the
>> solution which I've outlined in my previous mail should work nicely.
>
> Well, this is not really a news. We could have fixed the sec vs nonsec
> boot thing months ago (if there only was a consensus about it). But
> better late than never.

Fixing this only becomes interesting IMHO once we've the other bits sorted
out. Also I know the involved code a lot better know then back then which
has resulted in me seeing a possible way to fix this relatively cleanly.

>>>> Modifying armv7_boot_nonsec so that we can override the default. We
>>>> can do this e.g. by adding a global armv7_boot_nonsec_default variable
>>>> and setting that from setup_board_tags().
>>>>
>>>> This way we can just do the right thing automatically,
>>>
>>> By the "right thing", do you mean booting the sunxi-3.4 kernel with
>>> weird PLL5 and PLL6 settings just because some *older* versions of
>>> this kernel used to have bugs in the past?

By the right thing I mean having things just work for the end user,
whatever I'm doing having things just work is always my end goal.
This is also why I'm mostly focussing upstream, which has resulted in
Fedora 21 and the upcoming Debian release supporting allwinner devices
ootb (albeit only headless) and the upcoming F-22 release will have
much improved allwinner device support, supporting more devices, and
supporting video output, etc.

>>>> and this has
>>>> the added advantage that if we later find out that we're doing
>>>> something in u-boot which is not good for the older kernels we can
>>>> fix it in u-boot without needing to coordinate with the sunxi-3.4
>>>> kernels. In my experience the version check for compatibility style
>>>> solution you are proposing brings a large maintenance burden,
>>>
>>> I don't expect any maintenance burden at all. We only ever need this
>>> coordination to take care of very serious showstopper bugs. And such
>>> bugs have been already fixed.
>>
>> Been there done that did not like it, this is going to suck big time,
>> trust me I've done enough of this kinda stuff to know.
>
> I would say, that it would be a good idea to trust me this time for a
> change :-)  You were given a chance to enforce your own solution, and
> it quite predictably sucks. Too bad that Tsvetan and Lars had to
> encounter problems in order to (hopefully) make this clear for everyone.
>
> In fact, I have a better suggestion. We can have this versioned
> machine id hack active only when CONFIG_OLD_SUNXI_KERNEL_COMPAT
> is not defined. So that the normal build does not have non-obvious
> runtime failures with unpatched sunxi-3.4 kernels anymore. And the
> CONFIG_OLD_SUNXI_KERNEL_COMPAT still works just like before. I'll
> send a v2 patch shortly.

Ok, I think I can live with that as solution, esp. since it will also
work to ensure that we don't run old kernels which muck with voltages
making things run unreliable in an unpredictable manner.

I'm not 100% happy about overloading the upper id bits though, that
is not how machine ids are supposed to work officially, I guess we can
get away with this since we are keeping all related changes confined
to sunxi code only. But I'm not 100% enthusiastic about this.

Ian, can you live with overloading the high machine-id bits to
deliberately break old kernels when not compiled with old kernel
compatibility?

Regards,

Hans

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Ian Campbell]

On Sat, 2015-02-21 at 10:41 +0100, Hans de Goede wrote:
> By the right thing I mean having things just work for the end user,
> whatever I'm doing having things just work is always my end goal.
> This is also why I'm mostly focussing upstream, which has resulted in
> Fedora 21 and the upcoming Debian release supporting allwinner devices
> ootb (albeit only headless) and the upcoming F-22 release will have
> much improved allwinner device support, supporting more devices, and
> supporting video output, etc.

Speaking of which, if someone were to identify a suitable set of
simple-fb backports for 3.16 and they are reasonably self contained I'd
happily backport them to the kenrel which is going to be in the next
Debian release too...

> Ian, can you live with overloading the high machine-id bits to
> deliberately break old kernels when not compiled with old kernel
> compatibility?

It kind of sucks, but so do all the options it seems, I guess we can
live with it...

Ian.

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 21-02-15 11:26, Ian Campbell wrote:
> On Sat, 2015-02-21 at 10:41 +0100, Hans de Goede wrote:
>> By the right thing I mean having things just work for the end user,
>> whatever I'm doing having things just work is always my end goal.
>> This is also why I'm mostly focussing upstream, which has resulted in
>> Fedora 21 and the upcoming Debian release supporting allwinner devices
>> ootb (albeit only headless) and the upcoming F-22 release will have
>> much improved allwinner device support, supporting more devices, and
>> supporting video output, etc.
>
> Speaking of which, if someone were to identify a suitable set of
> simple-fb backports for 3.16 and they are reasonably self contained I'd
> happily backport them to the kenrel which is going to be in the next
> Debian release too...

You will need all patches by me and by "Luc Verhaegen" from here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/simplefb.c

As well as these dts patches:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5790d4ee1e425fefef0e012d1415c25baeb9dae8
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=d501841fc42a97a8b69449135eadf6e9c4589a87
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e53a8b2201384ee1a2cfd1609c9ffdf951b041a1
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8efc5c2be5b29f7ceec83bb471da81690273e141
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a9f8cda32a3acc3150755fe973f7fa1867a7a5d6
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8cedd6628472aa2d8f2f54dfcc36633e46a59db8
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=fd18c7eac03540654abdbfedd52e6dfb3718b489

Those combined with a new enough u-boot should get you video output on most devices
supported in upstream u-boot.

>> Ian, can you live with overloading the high machine-id bits to
>> deliberately break old kernels when not compiled with old kernel
>> compatibility?
>
> It kind of sucks, but so do all the options it seems, I guess we can
> live with it...

Ok, I'll go and merge the v2 patch then. Siarhei, I'm working on a
linux-sunxi-3.4 fix for the sun5i PLL6 issue, please do not add a
patch to the linux-sunxi-3.4 kernels claiming "COMPAT_REV 1" compatibility
until that patch is done and merged.

Thanks & Regards,

Hans

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

On Sat, 21 Feb 2015 11:49:22 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> On 21-02-15 11:26, Ian Campbell wrote:
> > On Sat, 2015-02-21 at 10:41 +0100, Hans de Goede wrote:
> >> Ian, can you live with overloading the high machine-id bits to
> >> deliberately break old kernels when not compiled with old kernel
> >> compatibility?
> >
> > It kind of sucks, but so do all the options it seems, I guess we can
> > live with it...
> 
> Ok, I'll go and merge the v2 patch then. Siarhei, I'm working on a
> linux-sunxi-3.4 fix for the sun5i PLL6 issue, please do not add a
> patch to the linux-sunxi-3.4 kernels claiming "COMPAT_REV 1" compatibility
> until that patch is done and merged.

Thanks!

While we are at it, could linux-sunxi-3.4 be also patched to not touch
DCDC4 on AXP152? It serves the same role as DCDC3 on AXP209 and is
connected to VDD-INT/VDD-DLL. I don't have A10s hardware myself.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 21-02-15 14:11, Siarhei Siamashka wrote:
> On Sat, 21 Feb 2015 11:49:22 +0100
> Hans de Goede <hdegoede@redhat.com> wrote:
>
>> On 21-02-15 11:26, Ian Campbell wrote:
>>> On Sat, 2015-02-21 at 10:41 +0100, Hans de Goede wrote:
>>>> Ian, can you live with overloading the high machine-id bits to
>>>> deliberately break old kernels when not compiled with old kernel
>>>> compatibility?
>>>
>>> It kind of sucks, but so do all the options it seems, I guess we can
>>> live with it...
>>
>> Ok, I'll go and merge the v2 patch then. Siarhei, I'm working on a
>> linux-sunxi-3.4 fix for the sun5i PLL6 issue, please do not add a
>> patch to the linux-sunxi-3.4 kernels claiming "COMPAT_REV 1" compatibility
>> until that patch is done and merged.
>
> Thanks!
>
> While we are at it, could linux-sunxi-3.4 be also patched to not touch
> DCDC4 on AXP152? It serves the same role as DCDC3 on AXP209 and is
> connected to VDD-INT/VDD-DLL. I don't have A10s hardware myself.

Since I'm working on this now anyways I'll whip up a patch for this.

Regards,

Hans

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Ian Campbell]

On Sat, 2015-02-21 at 11:49 +0100, Hans de Goede wrote:
> On 21-02-15 11:26, Ian Campbell wrote:
> > Speaking of which, if someone were to identify a suitable set of
> > simple-fb backports for 3.16 and they are reasonably self contained I'd
> > happily backport them to the kenrel which is going to be in the next
> > Debian release too...
> 
> You will need all patches by me and by "Luc Verhaegen" from here:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/simplefb.c
> 
> As well as these dts patches:
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5790d4ee1e425fefef0e012d1415c25baeb9dae8
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=d501841fc42a97a8b69449135eadf6e9c4589a87
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e53a8b2201384ee1a2cfd1609c9ffdf951b041a1
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8efc5c2be5b29f7ceec83bb471da81690273e141

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=678e75d

I inserted this one here so the following stuff would cherry-pick ok, I
think that was the right thing to do.

> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a9f8cda32a3acc3150755fe973f7fa1867a7a5d6
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8cedd6628472aa2d8f2f54dfcc36633e46a59db8
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=fd18c7eac03540654abdbfedd52e6dfb3718b489
> 
> Those combined with a new enough u-boot should get you video output on most devices
> supported in upstream u-boot.

Indeed, this gets me graphics on my Cubietruck at least.

Thanks!

Ian.

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

On Sat, 28 Feb 2015 16:18:16 +0000
Ian Campbell <ijc+uboot@hellion.org.uk> wrote:

> On Sat, 2015-02-21 at 11:49 +0100, Hans de Goede wrote:
> > On 21-02-15 11:26, Ian Campbell wrote:
> > > Speaking of which, if someone were to identify a suitable set of
> > > simple-fb backports for 3.16 and they are reasonably self contained I'd
> > > happily backport them to the kenrel which is going to be in the next
> > > Debian release too...
> > 
> > You will need all patches by me and by "Luc Verhaegen" from here:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/simplefb.c
> > 
> > As well as these dts patches:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5790d4ee1e425fefef0e012d1415c25baeb9dae8
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=d501841fc42a97a8b69449135eadf6e9c4589a87
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e53a8b2201384ee1a2cfd1609c9ffdf951b041a1
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8efc5c2be5b29f7ceec83bb471da81690273e141
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=678e75d
> 
> I inserted this one here so the following stuff would cherry-pick ok, I
> think that was the right thing to do.
> 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a9f8cda32a3acc3150755fe973f7fa1867a7a5d6
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8cedd6628472aa2d8f2f54dfcc36633e46a59db8
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=fd18c7eac03540654abdbfedd52e6dfb3718b489
> > 
> > Those combined with a new enough u-boot should get you video output on most devices
> > supported in upstream u-boot.
> 
> Indeed, this gets me graphics on my Cubietruck at least.
> 
> Thanks!

This looks great, thanks. The video output support in Debian is going
to be very much appreciated. It looks like I don't really need to do
anything other than just installing the U-Boot bootloader by
    
    http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
    https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype

And can simply delegate everything else to the Debian installer :-)

Just one suggestion. It would be really nice if the Debian installer
could present itself on all the available consoles, so that the user
can use any of them for providing input to the installer.

Otherwise there will be a need to provide separate SD card images for
the HDMI console (for the Raspberry Pi wannable competitors), the UART
serial console (A10/A20 development boards without HDMI) and the USB OTG
serial gadget console (for the tablets without HDMI). Instead of just
having only a single SD card image to handle everything automatically.

Oh, and one more suggestion. The SD card partitioning could be also
improved in order to make it more user friendly. Right now the user may
be confused by the Debian installer regarding what to do with the
existing partition on the SD card (yes, it can be safely erased since
the installer is running from RAM and does not rely on the data from
that partition anymore).

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Ian Campbell]

On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote:
> Just one suggestion. It would be really nice if the Debian installer
> could present itself on all the available consoles, so that the user
> can use any of them for providing input to the installer.

There is some reason why d-i doesn't do this by default. I think it's to
do with bricking or otherwise interfering with devices attached to
serial ports e.g I think Braille terminals were mentioned, but I suppose
any random device might not like getting random strings of characters.

> Otherwise there will be a need to provide separate SD card images for
> the HDMI console (for the Raspberry Pi wannable competitors), the UART
> serial console (A10/A20 development boards without HDMI) and the USB OTG
> serial gadget console (for the tablets without HDMI). Instead of just
> having only a single SD card image to handle everything automatically.

I've backported DT the /chosen/stdout-path support to the kernel a while
ago and I thought together with Hans' u-boot patches to populate this
field with the right thing then console selection would Just Work(tm).

At least for HDMI vs. UART since I'm not quite sure how the OTG gadget
console is presented to Linux and whether it falls into this stuff
correctly.

> Oh, and one more suggestion. The SD card partitioning could be also
> improved in order to make it more user friendly. Right now the user may
> be confused by the Debian installer regarding what to do with the
> existing partition on the SD card (yes, it can be safely erased since
> the installer is running from RAM and does not rely on the data from
> that partition anymore).

I leave this one to Karsten who looks after the SD card images.

Ian.

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Siarhei Siamashka]

On Tue, 03 Mar 2015 08:17:56 +0000
Ian Campbell <ijc+uboot@hellion.org.uk> wrote:

> On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote:
> > Just one suggestion. It would be really nice if the Debian installer
> > could present itself on all the available consoles, so that the user
> > can use any of them for providing input to the installer.
> 
> There is some reason why d-i doesn't do this by default. I think it's to
> do with bricking or otherwise interfering with devices attached to
> serial ports e.g I think Braille terminals were mentioned, but I suppose
> any random device might not like getting random strings of characters.

There could be perhaps a fake kernel cmdline option to specify the
exact list of consoles to be used by the Debian installer?

> > Otherwise there will be a need to provide separate SD card images for
> > the HDMI console (for the Raspberry Pi wannable competitors), the UART
> > serial console (A10/A20 development boards without HDMI) and the USB OTG
> > serial gadget console (for the tablets without HDMI). Instead of just
> > having only a single SD card image to handle everything automatically.
> 
> I've backported DT the /chosen/stdout-path support to the kernel a while
> ago and I thought together with Hans' u-boot patches to populate this
> field with the right thing then console selection would Just Work(tm).

I need to check this new feature myself, especially whether it can do
user input handling.

> At least for HDMI vs. UART since I'm not quite sure how the OTG gadget
> console is presented to Linux and whether it falls into this stuff
> correctly.

It should be seen as just one more /dev/tty* entry (maybe USB or ACM).

My original plan from

    http://lists.denx.de/pipermail/u-boot/2015-January/202306.html

was to make the bootable SD card just drop into the FEL mode in the
case if an A13/A23 SoC is detected or if there is no HDMI monitor
connected. Then a custom application running on a desktop PC could
upload a custom SPL for the only purpose of identifying the DRAM size
and bus width. Then present a choice of the possibly matching devices
to the user, boot the system via FEL, run hardware reliability tests
and move on to preparing the rootfs.

But with the Debian installer, this becomes somewhat more difficult.
Because we need a way of handling user input during the installation
(for the language selection, time zone, and other things).

However with the new USB OTG code from Hans hopefully coming into the
Linux kernel, we can have everything much easier and more unified :-)
Basically, the serial port over USB should work fine even in Windows
(at least it works for the Arduino people):

    http://arduino.cc/en/Guide/Windows

And because the BROM is able to use USB OTG for the FEL mode on all
sunxi devices, the serial console over USB should also work in a
generic image without any special device dependent configuration.

> > Oh, and one more suggestion. The SD card partitioning could be also
> > improved in order to make it more user friendly. Right now the user may
> > be confused by the Debian installer regarding what to do with the
> > existing partition on the SD card (yes, it can be safely erased since
> > the installer is running from RAM and does not rely on the data from
> > that partition anymore).
> 
> I leave this one to Karsten who looks after the SD card images.

I just mean that the Debian installer could be a little bit more aware
of the target platform and guide the user appropriately without leading
to any surprises.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [linux-sunxi] Re: [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Michal Suchanek]

On 4 March 2015 at 16:17, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> On Tue, 03 Mar 2015 08:17:56 +0000
> Ian Campbell <ijc+uboot@hellion.org.uk> wrote:
>
>> On Mon, 2015-03-02 at 00:07 +0200, Siarhei Siamashka wrote:
>> > Just one suggestion. It would be really nice if the Debian installer
>> > could present itself on all the available consoles, so that the user
>> > can use any of them for providing input to the installer.
>>
>> There is some reason why d-i doesn't do this by default. I think it's to
>> do with bricking or otherwise interfering with devices attached to
>> serial ports e.g I think Braille terminals were mentioned, but I suppose
>> any random device might not like getting random strings of characters.
>
> There could be perhaps a fake kernel cmdline option to specify the
> exact list of consoles to be used by the Debian installer?
>
>> > Otherwise there will be a need to provide separate SD card images for
>> > the HDMI console (for the Raspberry Pi wannable competitors), the UART
>> > serial console (A10/A20 development boards without HDMI) and the USB OTG
>> > serial gadget console (for the tablets without HDMI). Instead of just
>> > having only a single SD card image to handle everything automatically.
>>
>> I've backported DT the /chosen/stdout-path support to the kernel a while
>> ago and I thought together with Hans' u-boot patches to populate this
>> field with the right thing then console selection would Just Work(tm).
>
> I need to check this new feature myself, especially whether it can do
> user input handling.
>
>> At least for HDMI vs. UART since I'm not quite sure how the OTG gadget
>> console is presented to Linux and whether it falls into this stuff
>> correctly.
>
> It should be seen as just one more /dev/tty* entry (maybe USB or ACM).
>
> My original plan from
>
>     http://lists.denx.de/pipermail/u-boot/2015-January/202306.html
>
> was to make the bootable SD card just drop into the FEL mode in the
> case if an A13/A23 SoC is detected or if there is no HDMI monitor
> connected. Then a custom application running on a desktop PC could
> upload a custom SPL for the only purpose of identifying the DRAM size
> and bus width. Then present a choice of the possibly matching devices
> to the user, boot the system via FEL, run hardware reliability tests
> and move on to preparing the rootfs.
>
> But with the Debian installer, this becomes somewhat more difficult.
> Because we need a way of handling user input during the installation
> (for the language selection, time zone, and other things).

For things selectable from a menu it might be possible to use the
volume and power keys as the Android recovery does.

Driver for the power key is already in u-boot. It's just not hooked up
to provide input.

>
> However with the new USB OTG code from Hans hopefully coming into the
> Linux kernel, we can have everything much easier and more unified :-)
> Basically, the serial port over USB should work fine even in Windows
> (at least it works for the Arduino people):
>
>     http://arduino.cc/en/Guide/Windows
>
> And because the BROM is able to use USB OTG for the FEL mode on all
> sunxi devices, the serial console over USB should also work in a
> generic image without any special device dependent configuration.

I pretty much use only the OTG port when I boot GNU/Linux on a tablet.
yes, I can get display output but any input has to  come over OTG so I
use ethernet gadget and ssh.

That also happens to cover downloading stuff in case the WiFi chipset
is not supported. I have yet to see an Allwinner tablet with supported
touchscreen.

Thanks

Michal

[U-Boot] [PATCH] sunxi: Machine id hack to prevent loading buggy sunxi-3.4 kernels

[Hans de Goede]

Hi,

On 28-02-15 17:18, Ian Campbell wrote:
> On Sat, 2015-02-21 at 11:49 +0100, Hans de Goede wrote:
>> On 21-02-15 11:26, Ian Campbell wrote:
>>> Speaking of which, if someone were to identify a suitable set of
>>> simple-fb backports for 3.16 and they are reasonably self contained I'd
>>> happily backport them to the kenrel which is going to be in the next
>>> Debian release too...
>>
>> You will need all patches by me and by "Luc Verhaegen" from here:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/video/fbdev/simplefb.c
>>
>> As well as these dts patches:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=5790d4ee1e425fefef0e012d1415c25baeb9dae8
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=d501841fc42a97a8b69449135eadf6e9c4589a87
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=e53a8b2201384ee1a2cfd1609c9ffdf951b041a1
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8efc5c2be5b29f7ceec83bb471da81690273e141
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=678e75d
>
> I inserted this one here so the following stuff would cherry-pick ok, I
> think that was the right thing to do.

Yes it was, sorry for overlooking that one.

>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a9f8cda32a3acc3150755fe973f7fa1867a7a5d6
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=8cedd6628472aa2d8f2f54dfcc36633e46a59db8
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=fd18c7eac03540654abdbfedd52e6dfb3718b489
>>
>> Those combined with a new enough u-boot should get you video output on most devices
>> supported in upstream u-boot.
>
> Indeed, this gets me graphics on my Cubietruck at least.

Cool.

Regards,

Hans

[U-Boot] Improving DRAM settings for Allwinner A10/A13/A20 devices

[Siarhei Siamashka]

Hello,

This is a reply to an old thread
    http://lists.denx.de/pipermail/u-boot/2015-February/205761.html

On Sat, 21 Feb 2015 10:41:48 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> On 20-02-15 19:33, Siarhei Siamashka wrote:
> > On Fri, 20 Feb 2015 15:11:04 +0100
> >
> > The sun4i/sun5i/sun7i DRAM controller code in u-boot is ready for much
> > faster DRAM clock speeds since the v2014.10 release. We are only
> > missing the appropriate 'dram_para' settings for the boards, which can
> > be prepared/verified according to the instructions from the linux-sunxi
> > wiki. But there does not seem to be much interest in the performance
> > and reliability for the sunxi boards yet. And participation of the
> > hardware vendors (for doing large scale tests on many boards) is
> > missing too.
> >
> > Maybe now after the introduction of the Raspberry Pi 2, the Allwinner
> > based devboard manufacturers might become a bit more interested in
> > tweaking the performance in order to remain competitive.
> >
> > I believe that every Cubietruck user had more than enough time to
> > try my 'highspeedtruck' branches posted at
> >
> >      http://lists.denx.de/pipermail/u-boot/2014-July/183981.html
> >
> > That's "the proof of the pudding", which demonstrates what is
> > possible with this hardware :-)
> 
> I still believe that the only way to get anywhere wrt getting better
> DRAM speeds is to just make the change. As said before if you submit
> patches to increase DRAM speed on some boards I'll put them in
> my personal sunxi-wip and the official u-boot-sunxi/next asap,

Just to make it clear. I'm still not in favour of pushing potentially
reliability degrading changes to any repository, where they can be
picked up by unsuspecting users. And I'm going to be strict about
it, so no compromise is possible. Sorry about this.

The users must be well aware of what they are trying, which tests to
run and what kind of feedback is expected from them. Otherwise very
few will notice anything even if they get unreliable DRAM setup.
A good example is the unstable "1008MHz, 1.4V" CPU voltage/frequency
configuration on the A10-Lime board. Only a small fraction of
boards was affected, and the symptoms were not very obvious (it
is not like the board fails to boot). And the users had to
unnecessarily play the "guinea pig" role for a very long time.

As I said, the best possible scenario would be a participation
of the board manufacturers (OLIMEX, CubieTech, LeMaker, ...). So
that we could collect sufficient statistics from multiple board
samples (preferably from different batches) and check whether we
can select the settings, which work fine on all of them. But if
there is no interested board manufacturer, then the only option
is to ask users for help. Unfortunately the users are not always
cooperative and disciplined. So it becomes a real hassle in
practice.

We already got some interesting results though. For example, Adam
Sampson tried to follow the guide from the linux-sunxi wiki and run
my DRAM settings bruteforcing scripts on two pcDuino3 Nano boards. He
also managed to reach 648MHz DRAM clock speed (though increasing MBUS
to anything higher than 300MHz resulted in stability problems). It's
surely good that we can potentially get into the 600MHz DRAM clock
speed range on one more board model in addition to Cubietruck and
A13-OLinuXino-Micro. But the most interesting part is that he had
the results updated in real time on a web server as the scripts
were progressing (now this link contains the final report):
    http://stuff.offog.org/tpr3.html

The Adam's work also demonstrated that the current scripts do
not support efficient handling of multiple boards at one. The
html report is a bit messy when there is more than one board.
I could try to introduce some improvements in this area. And
inspired by Adam's web server usage for real-time progress
tracking, in fact it may be beneficial to move from the current
NFS based setup to a server in the Internet, which could show
statistics in realtime, implement a simple communication protocol
and coordinate the DRAM settings bruteforcing process by issuing
commands to the connected "slave" devices. Anyone who is interested
in participating, would only need to use a special bootable SD
card and just let the device out in the Internet...

However now I'm really disappointed in the whole idea of relying on
anyone else, because this proved to be really inefficient. So I have
bought 5 pcDuino V2 boards myself from
    http://www.exp-tech.de/pcduino-v2-linux-android-arduino-dev-board
They are currently available at a discounted price 22.5 euro,
which seemed to be a reasonably good deal for me :-)

I'm just going to take care of tuning the DRAM settings for
pcDuino V2. But I'm not setting any deadline and will do it
as time permits. And then we can see what happens.  After I'm
done experimenting with the DRAM settings, I will probably
donate extra boards to other people.

And we still do have preliminary DRAM settings for Cubietruck,
which had been tested on my Cubietruck board:
    http://linux-sunxi.org/User:Ssvb/Cubietruck_DRAM_Calibration
But Cubietruck is relatively expensive and I can't afford to buy
many boards. I only initially selected Cubietruck because this
was the first sunxi board added to the mainline U-Boot. Also both
Hans de Goede and Ian Campbell own Cubietruck boards, so there
was a hope that they could help by running some simple quick tests.
But as we can see, no progress can be realistically made on the
Cubietruck front, so the only choice is to focus on pcDuino V2
for now.

Again, I'm not suggesting to use ~600MHz DRAM clock speed settings
by default. They are just good for exploring the limits of hardware
capabilities and demonstrate that the ZQ calibration and carefully
selected delay settings improve reliability if done right. What is
a reasonable default DRAM clock speed is yet to be decided though.

PS. Raspberry Pi supports DRAM overclocking up to 600MHz as an option,
    so it is not something really extraordinary. 

> and then we can ask people to test that, and once the merge window for
> v2015.07 opens we can land those changes and see from there.

How is it really different from my announcement of the Cubietruck test
branch and the request to try it?

> What would also be welcome is a wiki page for reading DRAM chip
> markings, so that people can figure out what their board should
> be able to handle theoretically (assuming the pcb is not holding
> things back).

All the DRAM chips appear to be at least DDR3-1333 in practice.
There are also DRAM chip compatibility lists from Allwinner available
on the Internet. We have not seen any exception from this pattern so
far. And newer devices tend to use DDR3-1600 chips.

Moreover, reading the markings would not help anyone. Not every
person would want to open their device. And not every person
would be able to read and correctly interpret the markings, no
matter how good is the documentation. Also unlike robots, humans
tend to make silly mistakes occasionally :-)

It is much better to just run a quick DRAM reliability test as a
part of the Linux distribution installation procedure [1]. Finding
good DRAM settings is a difficult and slow process. But verifying
them is relatively simple and fast (while also ensuring some safety
headroom). In a way, it's very similar to passwords bruteforcing.
Bruteforcing a password is difficult, slow and needs special tools.
However it is trivially simple to verify whether a password is
good.

[1] http://lists.denx.de/pipermail/u-boot/2015-January/202306.html

-- 
Best regards,
Siarhei Siamashka