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

[Adam Lackorzynski]

On Mon Oct 16, 2017 at 15:35:22 +0200, Paul Boddie wrote:
> On Monday 16. October 2017 00.48.38 Adam Lackorzynski wrote:
> > On Sat Oct 14, 2017 at 17:09:46 +0200, Paul Boddie wrote:
> > > On Wednesday 11. October 2017 15.33.58 Manolis Ragkousis wrote:
> > > > Finally I have a question, Are you accepting patches for L4 and
> > > > L4Linux? I could make my git patches more presentable and send them
> > > > here if you want, to be added to your upstream repo.
> > > 
> > > I would be interested to know about this as well. I sent some patches to
> > > the list a while back, but nothing was really said about whether there
> > > was any interest in incorporating them upstream.
> > 
> > Principally yes but this also depends on time etc., see other mail.
> 
> Yes, from my own perspective I understand this well. :-)
> 
> > > One of the patches made the stated CI20 support actually work, thanks to
> > > Sarah's guidance, so it must surely be of interest to more than just me.
> > > The
> > 
> > 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.

> support floating point instructions natively, and where L4Re/Fiasco.OC might 
> not be buildable using "soft float" instructions (advice welcome!), but this 
> is a different topic altogether (and one that I am not likely to explore in 
> the near future).

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

> > > other patches attempted to support gcc instead of the vendor compiler,
> > > which I would also think would be desirable (especially given the
> > > corporate "pass the parcel" game going on with the vendor in question at
> > > the moment).
> > 
> > Well, then lets discuss those changes.
> 
> 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?

> 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.

> 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.

> 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.


Adam