[U-Boot] [PATCH v4 3/8] mips: add base support for atheros ath79 based SOCs

[Marek Vasut <marex@denx.de>]

On Saturday, December 26, 2015 at 06:01:36 PM, Daniel Schwierzeck wrote:

[...]

> >> This should be C code, pretty please.
> > 
> > Must this be change to c code?
> > I think there should be no problem.
> 
> this function is only called from init_dram() which already runs in a
> full C environment. The conversion to C should be simple. But I would
> accept the current patch for the initial merge if you do the conversion
> later.

I'm quite opposed to that, we should keep the code out of tree until it's
in sensible state, otherwise it'd only set a bad example. Especially if the
conversion is easy and it has full C env, we should just do that.

> >> [...]
> >> 
> >>> diff --git a/arch/mips/mach-ath79/ar933x/lowlevel_init.S
> >>> b/arch/mips/mach-ath79/ar933x/lowlevel_init.S new file mode 100644
> >>> index 0000000..72509ca
> >>> --- /dev/null
> >>> +++ b/arch/mips/mach-ath79/ar933x/lowlevel_init.S
> >> 
> >> lowlevel_init.S should be C code too, I don't see anything which would
> >> require this to be ASM .
> > 
> > I don't find SRAM in this chip, we need DDR memory to handle C runtime
> > statck.
> 
> currently lowlevel_init() must be coded in assembly because it runs
> before RAM and caches are initialized. This function only exists to do
> that initialization. MIPS did this from the beginning. Maybe I will send
> some patches to use locked cache lines, but that should not be a hard
> requirement for adding new SoC's. Actually all modern MIPS based SoC's
> have some type of SRAM or first-stage bootloaders, thus adding the cache
> line lock feature was not really necessary. I would accept the current
> patch for the initial merge.

I believe the AR9331 has SRAM , at least according to the datasheet I have.
We should therefore use it.

[...]

Best regards,
Marek Vasut