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

[Chen-Yu Tsai]

On Sun, Oct 30, 2016 at 4:15 PM, Hans de Goede <hdegoede at redhat.com> wrote:
> 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).

Some follow up:

Benoit (CC-ed) reported that GMAC with mainline kernel (a topic
branch in my github repo) no longer works. This seems to be because
we are no longer configuring the I/O voltages for the pins in the
PIO.

We'll need some sort of IO domain driver like Rockchip's [1] in the
kernel, in U-boot, or both to configure the voltage levels to match
the regulators.

Regards
ChenYu

[1] http://lxr.free-electrons.com/source/drivers/power/avs/rockchip-io-domain.c