[U-Boot] [linux-sunxi] Re: [PATCH 00/11] sunxi: Add full SPL support for sun9i (A80)

[Hans de Goede]

Hi,

On 30-10-16 06:30, Chen-Yu Tsai wrote:
> On Sat, Oct 29, 2016 at 8:06 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>>
>> On 28-10-16 19:30, Hans de Goede wrote:
>>>
>>> Hi Chen-Yu,
>>>
>>> On 28-10-16 12:21, Chen-Yu Tsai wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> This series adds full SPL with DRAM initialization for sun9i (A80).
>>>> The bulk of the work was done by the people at Theobroma Systems.
>>>> Their work can be found here:
>>>>
>>>>     https://git.theobroma-systems.com/armadillo-u-boot.git/
>>>>
>>>> I picked the essential patches and cleaned them up a bit more,
>>>> and added commit messages if they were missing.
>>>>
>>>> As the DRAM bits are essentially a code dump with some cleanups and
>>>> some bits disabled, expect many warnings. Checkpatch is still not
>>>> happy with it.
>>>>
>>>> I've tested the series on both my A80 boards, which I've added
>>>> defconfigs for in the last 2 patches. My A80 Optimus does not
>>>> boot from micro SD, so I'm still FEL booting that one. But my
>>>> Cubieboard 4 is now standalone.
>>>>
>>>> As usual, please have a look, test if possible.
>>>
>>>
>>> Awesome, thanks for doing this and it was good to have
>>> some face2face time at ELCE.
>>>
>>> I've merged this into my personal sunxi-wip u-boot branch,
>>> I've made 2 changes:
>>>
>>> 1) in : ¨sunxi: DRAM initialisation for sun9i" there are a
>>> lot of #if 0 #endif blocks, most of these document some features
>>> which we may want to enable in the future, but a few were just
>>> dead weight IMHO, so I've pruned a few
>>>
>>> 2) in : "sunxi: Add support for A80 Optimus board", we already
>>> have a configs/Merrii_A80_Optimus_defconfig, so I've made the patch
>>> update that instead of adding a new defconfig
>>>
>>> I have not tested this yet, I will do tomorrow, assuming it
>>> works for me too I will include it in my next pull-req (*)
>>
>>
>> Ok, just finished testing, u-boot seems to work well. I do
>> seem to have one kernel issue (with the last 4.8 based
>> sunxi-next kernel, I still need to upgrade that) :
>>
>> [    1.137105] Division by zero in kernel.
>> [    1.140988] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0+ #475
>> [    1.147089] Hardware name: Allwinner sun9i Family
>> [    1.151830] [<c0310f74>] (unwind_backtrace) from [<c030bed0>]
>> (show_stack+0x18/0x1c)
>> [    1.159596] [<c030bed0>] (show_stack) from [<c068ee30>]
>> (dump_stack+0x80/0x9c)
>> [    1.166839] [<c068ee30>] (dump_stack) from [<c068dac0>] (Ldiv0+0x8/0x10)
>> [    1.173558] [<c068dac0>] (Ldiv0) from [<c09de7e4>]
>> (sun4i_a10_get_mod0_factors+0x2c/0x8c)
>> [    1.181758] [<c09de7e4>] (sun4i_a10_get_mod0_factors) from [<c09de480>]
>> (clk_factors_determine_rate+0xb8/0xf8)
>> [    1.191781] [<c09de480>] (clk_factors_determine_rate) from [<c09d6054>]
>> (clk_composite_determine_rate+0x58/0x1cc)
>> [    1.202062] [<c09d6054>] (clk_composite_determine_rate) from [<c09d1b3c>]
>> (clk_calc_new_rates+0xa0/0x240)
>> [    1.211647] [<c09d1b3c>] (clk_calc_new_rates) from [<c09d34f8>]
>> (clk_core_set_rate_nolock+0x4c/0xbc)
>> [    1.220798] [<c09d34f8>] (clk_core_set_rate_nolock) from [<c09d3590>]
>> (clk_set_rate+0x28/0x38)
>> [    1.229432] [<c09d3590>] (clk_set_rate) from [<c0942bd4>]
>> (sunxi_ir_probe+0xfc/0x480)
>> [    1.420454] [<c0942bd4>] (sunxi_ir_probe) from [<c07a6784>]
>> (platform_drv_pro
>> be+0x58/0xa4)
>>
>> ...
>>
>> And it fails to find any mmc controllers, but that might be related to
>> the above oops (maybe it stops probing after that due to a stuck lock).
>
> This is related to the regulators, specifically cold boot default
> values for ldo_ios causing the regulators to fail to register. You
> actually fixed this for the axp22x's before.
>
> There's also the addressing issue for the axp806.
>
> See the top of https://github.com/wens/linux/commits/sun9i-gmac-wifi
> for the bunch of fixes I need to send.
>
>> Anyways the u-boot side looks good. One issue I see is that your
>> optimus has an emmc, where as mine has a nand. We may want to
>> gave 2 optimus defconfigs for this once we've nand support.
>
> Hmm... This implies the need for 2 versions of dts files as well.
> Any ideas on probing for nand/emmc during boot?

If we want to use a single devicetree and use something like quirks
or some such, I'm sure we can up with some way to find out whether
there is an emmc or nand connected during boot (in u-boot), but
this requires a mechanism like dt-quirks to first get merged
upstream. Anyways NAND support is still not here, lets just go
with eMMC support in u-boot + the dts and we can worry about NAND
support later (this will likely cause some kernel errors on optimus
boards with NAND, but I live with that).

Regards,

Hans