
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