Hi,

On 30-10-16 06:30, Chen-Yu Tsai wrote:
On Sat, Oct 29, 2016 at 8:06 PM, Hans de Goede <hdego...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to