On Tue, Nov 17, 2020 at 3:47 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> On Tue, Nov 17, 2020 at 3:39 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > On Tue, Nov 17, 2020 at 3:19 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > > On Tue, Nov 17, 2020 at 1:25 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> > > > On Tue, Nov 17, 2020 at 11:30 AM Geert Uytterhoeven
> > > > <geert+renesas@xxxxxxxxx> wrote:
> > > > > Replace using the legacy IOMEM() macro to map various registers related
> > > > > to INTC2 configuration by ioremap().
> > > > >
> > > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> > > >
> > > > The patch looks good, but since you are already touching these __raw_writel(),
> > > > could you turn them into normal writel() to have a chance that this works
> > > > on big-endian? It could be either a follow-up or merged into the same patch.
> > >
> > > (Do you want us to support big-endian on these old platforms? ;-)
> > >
> > > At your service. Seems to work well.
> >
> > In general, my preference is that code is written in a portable way, to make
> > it at least plausible that it works. I don't expect anyone to actually run
> > big-endian code on it, but if you can confirm that it boots all the way
> > to not finding a compatible /sbin/init, that would be awesome.
>
> With "work well", I meant no regressions after converting from _raw_*()
> to normal accessors. No idea how to boot big-endian kernels on this
> hardware ;-)
There is no change when booting them, you just enable
CONFIG_CPU_BIG_ENDIAN and recompile the kernel.
The bootloader remains little-endian and the first instruction in
the image then changes into big-endian mode. The expected
behavior is that it crashes as soon as it tries to get into user
space. Recompiling that is significantly more work.
Arnd
