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

["Heiko Stübner" <heiko@sntech.de>]

Hi Simon,

Am Montag, 18. Juli 2016, 06:16:33 schrieb Simon Glass:
> On 17 July 2016 at 09:27, Simon Glass <sjg@chromium.org> wrote:
> > On 17 July 2016 at 09:20, Heiko St?bner <heiko@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@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.


Heiko