Patches (was Re: Problem with L4Linux accessing ethernet clocks)

[Paul Boddie]

Hello,

A quick reply as it is rather late...

On Monday 23. October 2017 00.55.53 Adam Lackorzynski wrote:
> On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
> > On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
> > > 
> > > You're talking about the cache instruction issue?
> > 
> > Yes (ci20-rdhwr.diff). I was also potentially interested in supporting
> > other instructions that related SoCs do not support, at least where
> > those do not
> 
> What I don't understand is why this needs to be done in asm. I'd favor
> something in C.

I haven't looked at how the floating point emulation is done in the Linux 
kernel, as another example of this kind of thing, but I imagine that you have 
to do some assembly language programming here just to recover from the 
exception. In this case, however, the emulated instruction is very simple, 
although I did take the liberty of rearranging the emulation mechanism 
slightly.

In fact, someone with more familiarity than me with low-level MIPS programming 
could probably reproduce my patch with little effort, but I imagine that it 
isn't of significant interest any more.

[MIPS systems without floating point support]

> Fiasco is typically built not using floating point, as most kernels.
> Which problem are you hinting at?

I was just wondering about use of floating point. If I can build user space 
programs that also don't need floating point then I save myself some work, 
potentially.

[...]

> > Thinking back, there was some uncertainty about whether it was
> > appropriate to generate position-independent code when building
> > Fiasco.OC, where I had introduced initialisation of t9 so that global
> > offset table lookups functioned correctly (ci20-gcc-cpload.diff).
> 
> This diff addresses user-level programs, and are meant to have them
> being able to be compiled as PIC?

Yes. Various L4Re components do not work when compiled with gcc unless I 
introduce these changes. It was suggested that I do not compile such things as 
position-independent code, but I don't remember any further explanation.

> > There was also a trivial patch changing the
> > compiler prefix for Debian (ci20-gcc-debian.diff).
> 
> It is debatable which prefix shall be preferred. In any case
> CROSS_COMPILE can be set on the command line and in files such as
> Makeconf.local.

OK.

> > You also mentioned the following patch when I experienced problems that
> > had something to do with variable or member initialisation:
> > 
> > http://os.inf.tu-dresden.de/pipermail/l4-hackers/2017/008005.html
> > 
> > Was this merged upstream in the end?
> 
> Yes.

OK.

> > I was rebasing my own large patch against an updated upstream repository,
> > but other matters took priority and I haven't looked at it again. I had
> > been trying to write a few device drivers for the CI20, specifically for
> > GPIO, CPM and I2C, with the latter being unreliable and rather annoying.
> 
> I don't know but maybe the Ci40 is a better board, having interAptiv
> cores.

The CI40 is aimed at a different sector, being IoT-related rather than a 
desktop-style single-board computer. Indeed, the CI20 has 1GB RAM - far more 
than the CI40 - but some trickery appears necessary to make more than 256MB 
visible to Fiasco due to the physical memory map layout, but I haven't looked 
into this yet. Obviously, Linux can make use of all of the RAM.

For me, my interest in the CI20 is driven by its choice of SoC which is in the 
same family as various other products I have access to. I don't think I'll be 
buying another board for the time being: the CI20 is tangential enough to my 
core interests as it is.

Paul