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