[U-Boot] [PATCH 0/9] rockchip: cosmetics, a fix and first steps on the rk3188

[Simon Glass]

Hi Heiko,

On 18 July 2016 at 07:42, Heiko Stübner <heiko at sntech.de> wrote:
> Hi Simon,
>
> Am Montag, 18. Juli 2016, 06:16:33 schrieb Simon Glass:
>> On 17 July 2016 at 09:27, Simon Glass <sjg at chromium.org> wrote:
>> > On 17 July 2016 at 09:20, Heiko Stübner <heiko at sntech.de> wrote:
>> >> Am Sonntag, 17. Juli 2016, 08:14:06 schrieb Simon Glass:
>> >>> Hi Heiko,
>> >>>
>> >>> On 15 July 2016 at 16:17, Heiko Stuebner <heiko at sntech.de> wrote:
>> >>> > I've made some nice progress on using mainline uboot on the rk3188
>> >>> > and would like to dump some first results.
>> >>> >
>> >>> > Right now I can use uboot on the rk3188 with the Rockchip binary ddr
>> >>> > init,
>> >>> > similar to what barebox does and can even netboot a kernel image using
>> >>> > a usb ethernet adapter [0] .
>> >>> >
>> >>> > While working on this I found quite some cosmetic stuff that shouldn't
>> >>> > persist to make extending easier. So while I don't know what the
>> >>> > policy
>> >>> > is for my standalone pinctrl and clock drivers (without the actual
>> >>> > board)
>> >>> > at least the cosmetics + fix might get in at least.
>> >>>
>> >>> Nice work!
>> >>>
>> >>> It would be best to add the drivers with the board - otherwise they
>> >>> are just dead code. How far away is it?
>> >>
>> >> The big issue is the SPL. Right now I'm using Rockchip's ddr-init as spl-
>> >> replacement, and I'd say this second part is nearly ready - only minor
>> >> cleanups.
>> >>
>> >> The memory-setup is supposed to be very much similar to the rk3288 (same
>> >> dw_upctl and ddr-phy), but it looks like the very first steps are
>> >> somewhat
>> >> different and I haven't been able to make the spl output anything on the
>> >> serial console yet ... which could stem from some difference in what the
>> >> soc expects or just some dumb mistake on my part :-)
>> >
>> > That's always tricky.
>> >
>> > You may already know this, but the EARLY_UART setting is used on
>> > rk3288 to display a character as soon as SPL starts. You might be able
>> > to do something similar. The main issue I had was getting the pinmux
>> > setting right.
>> >
>> > As a test, you can start with booting SPL from the ddr-init binary I
>> > suspect. I have not tried it but it should work. Then the pinmux
>> > should already be set up (since ddr-init outputs to serial).
>
> yep, changing the SPL_TEXT_BASE to the ram address and using the spl as 2nd
> stage brings me the expected
>         earlyuart running
> message.
>
> I've also dumped the sram contents after a sucessful boot using the rk ddr-
> init + uboot and can see that the ddr-init is sitting at the 0x800 offset in
> sram - including the rk31 header, so I'm pretty sure the sram-based
> SPL_TEXT_BASE should be 0x10080804 - yet no lifesign.
>
> Judging by how the rk3036 declares its SPL_STACK, I guess 0x10087fff should
> also be right.
>
>> I'm going to apply the earlier patches in your series. Once you have a
>> working board we can apply the rest (to avoid adding dead code).
>
> great ... everything I don't need to carry over helps ;-) .
>
>
> Going forward, I see both the rk3368 and rk3399 support initially not
> providing a spl but sitting on top of the binary ddr init + ATF.
> Is that also something doable for my rk3188 or do you _require_ the spl there?
>
> I.e. bringing the support without spl forward should be fairly easy, so doing
> that first sounds nice, before worrying about the strange things the SPL needs.

That it because we don't have a good story for how to integrate ATF
with SPL at present (on ARMv8). I would much prefer to avoid this on
rk3188. Can you perhaps ask the Rockchip people on the list for help?

Regards,
Simon