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