[U-Boot] [Patch v4 2/5] ARMv8: Adjust MMU setup

[Tom Rini <trini@ti.com>]

On Fri, Jun 06, 2014 at 07:52:44AM -0700, York Sun wrote:
> On 06/06/2014 06:34 AM, Rob Herring wrote:
> > On Thu, Jun 5, 2014 at 1:34 PM, York Sun <yorksun@freescale.com> wrote:
> >> On 06/05/2014 10:41 AM, Mark Rutland wrote:
> >>> On Thu, Jun 05, 2014 at 04:07:17PM +0100, York Sun wrote:
> >>>> On 06/05/2014 03:09 AM, Mark Rutland wrote:
> > 
> > [...]
> > 
> >>>> No objection here on the idea. But again this is not the case. My first MMU
> >>>> table is in SRAM, which is small and will be used for other purpose. The 2nd MMU
> >>>> table is in DDR. I could copy the table and do the maintenance as you said. For
> >>>> now, I want to stick with the static table and only create the API when I have to.
> >>>
> >>> Sure, if your tables are in SRAM then trying to do a load of dynamic
> >>> allocation isn't going to work.
> > 
> > Why do you need to turn on the MMU early using SRAM in the first
> > place? Can't you delay that until after DDR setup?
> 
> Logically yes. But it runs too slow without cache on emulator.
> 
> > 
> >>> My fear is that while that sounds OK with a single user to do a quick
> >>> havk and poke the tables directly, we'll end up with everyone doing
> >>> that, and no-one will try to unify things. It is very diffifcult to
> >>> unify such variation after the fact.
> >>
> >> That's a good reason. Let me start to code the API. It will take a while to
> >> cover the complexity of the multilevel tables and sizes. It will be a separated
> >> patch for later review. I don't want that to delay this patch set. I am hoping
> >> to get this set in for 2014.07 release.
> > 
> > If I was maintainer I would say no because few people come back later
> > to clean-up their mess. If you want to get platform support in now,
> > perhaps you should just add the base platform first and add mmu setup
> > later. Surely you don't need the MMU to just boot to u-boot shell.
> > 
> 
> My plan is to get the first platform in, then I will maintain
> Freescale stuff.  So you can be sure I will continue to improve it.
> One reason to get these code in early is to enable our partners and
> early adopters to use u-boot. After all, this is the second ARMv8
> platform. The first one vexpress_aemv8a doesn't even support cache.

For the record, I'm OK with this plan given York's track record in the
U-Boot community.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140606/c368254a/attachment.pgp>