On Fri, 20 Mar 2015 18:32:07 +0100 Paul Kocialkowski <[email protected]> wrote:
> Le vendredi 20 mars 2015 à 19:21 +0200, Siarhei Siamashka a écrit : > > On Fri, 20 Mar 2015 17:51:03 +0100 > > Paul Kocialkowski <[email protected]> wrote: > > > > > After investigating a bit, I found out that I was unable to boot > > > sunxi-3.4 on A20 devices because I wasn't setting > > > CONFIG_OLD_SUNXI_KERNEL_COMPAT the right way. > > > > > > What I did initially was to add it to sunxi-common.h (before any other > > > define), but it apparently didn't get taken in account in the SPL > > > context. Setting it in the device defconfig works for both the main > > > U-Boot binary and SPL. This seems like a very strange behaviour to me. > > > Would someone care to weigh-in and provide an explanation for this? I > > > thought that sunxi-common.h was supposed to be used in both contexts. > > > > > > I am now looking for a way to enable it at build time, that is, through > > > some equivalent of menuconfig, that wouldn't require any interaction (so > > > that I can have it all scriptable). > > > > U-Boot uses to have separate menuconfig invocations for the SPL and the > > main binary for a while. This turned out to be very user unfriendly and > > confusing, but now this mishap should be already resolved: > > > > http://lists.denx.de/pipermail/u-boot/2015-February/205512.html > > > > Try to upgrade to the latest U-Boot git master branch and check if it > > works better. > > I'm working off v2015.04-rc4, which is recent enough. > > Having this diff: > diff --git a/include/configs/sunxi-common.h > b/include/configs/sunxi-common.h > index 61a45e1..14ac9db 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -13,6 +13,8 @@ > #ifndef _SUNXI_COMMON_CONFIG_H > #define _SUNXI_COMMON_CONFIG_H > > +#define CONFIG_OLD_SUNXI_KERNEL_COMPAT 1 > + > #ifdef CONFIG_OLD_SUNXI_KERNEL_COMPAT > /* > * The U-Boot workarounds bugs in the outdated buggy sunxi-3.4 kernels > at the > > Results in this .config: > > grep CONFIG_OLD_SUNXI_KERNEL_COMPAT u-boot-out/.config > # CONFIG_OLD_SUNXI_KERNEL_COMPAT is not set > > So this is not, in fact, specific to the SPL. Still, why does it happen? > Perhaps the fact that OLD_SUNXI_KERNEL_COMPAT is defined as a Kconfig > option, defaulted to n, implies that a define in the config header is > not sufficient to enable it in Kconfig? I'm not that familiar with the Kconfig machinery, but suspect that the .config file might be generated independently from the sunxi-common.h file. And this could be a duplicated functionality. It might be enough to just verify that the the ifdef checks all over the u-boot code are handled correctly by inserting some #error directives to the undesired code paths. I'm not sure if using CONFIG_OLD_SUNXI_KERNEL_COMPAT is a good idea in the long run, because it does not protect us against the legacy kernels which incorrectly re-configure dcdc3 voltage. For example, this is the case for the A13-OLinuXino board (the sunxi-3.4 kernel drops the dcdc3 voltage from 1.25V to 1.2V): http://lists.denx.de/pipermail/u-boot/2015-March/207510.html That is, unless this particular problem has been already resolved by Olimex. Furthermore, we probably don't want to keep dcdc3 at 1.25V forever. There is a (non-urgent) patch to make it configurable: https://patchwork.ozlabs.org/patch/435193/ I'm not rushing with it because the legacy kernels situation needs to be sorted out first. But more importantly, we first need more sets of tested DRAM settings, which make use of the increased voltage. This is progressing rather slowly because of low interest and poor participation, but we are gradually getting there. So I would suggest to try the stage/sunxi-3.4 kernel without CONFIG_OLD_SUNXI_KERNEL_COMPAT as instructed at: http://linux-sunxi.org/Mainline_U-boot#Boot -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
