[U-Boot] [PATCH v3 00/16] rk3188 uboot support

[Heiko Stuebner]

Am Freitag, 17. Februar 2017, 01:41:27 CET schrieb Heiko Stübner:
> Hi Simon,
> 
> Am Donnerstag, 16. Februar 2017, 13:43:45 CET schrieb Simon Glass:
> > On 3 February 2017 at 09:09, Heiko Stuebner <heiko at sntech.de> wrote:
> > > this is meant as a status update and possible discussion for
> > > the core parts if needed.
> > > 
> > > After talking with Simon and Tom the order is now also correct
> > > with tpl -> spl -> uboot.
> > > 
> > > 
> > > Status right now is:
> > > - the full uboot still works
> > > - the tpl/spl does start and is able to configure the ddr
> > > 
> > >   into a working state
> > > 
> > > - The jump spl -> bootrom -> uboot doesn't work though
> > > 
> > > On the other hand, Kever was able to make this work, booting
> > > from nand when building the image with a very ancient tool.
> > > 
> > > All newer tools (including boot_merger.c from Rockchip's uboot)
> > > do not produce working images. But it is possible to produce
> > > a working sd-boot image using the proprietary 1st-stage loader.
> > > 
> > > See the temporary mkuboot script in the last patch, which can
> > > create both types of images now (especially wrt. the needed
> > > rc4 encryption of everything).
> > > 
> > > Combining this (it does work using some special tool), it looks
> > > like there is still some minor glitch in the way we build the
> > > spl image somewhere.
> > 
> > What should we do with this series? There are a few minor things to
> > resolve but other than that, do you think it is ready to apply?
> 
> It's somehow always on the backburner, but I already started fixing the
> things you pointed out. Though I'll be in Portland, Mountain View and San
> Francisco for the next two weeks, so will only be able to resend the fixes
> after that.
> > The above problem could perhaps be resolved later if there is a
> > suitable README describing it?
> 
> Kever  already found out, that the sd read the bootrom does fails when
> trying to load the uboot from the spl. I'm still trying to investigate this
> [same Portland remark applies], but if you're ok with stuff going in in
> this state, that is definitly fine by me, as it spares me from sending the
> full series all the time ;-)

schedule update :-)

Kever is the hero of the day, as he found out what was causing the load 
failure (reset in sdram driver did actually reset the sdmmc controller). So 
now the real uboot does load finally from spl.

So with the technical issues solved, I'm hoping to just get the review commens 
finalized tomorrow on my flight over the atlantic and plane-wifi permitting may 
even resend from there ;-) .


Heiko