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