Patches (was Re: Problem with L4Linux accessing ethernet clocks)
adam at os.inf.tu-dresden.de
Mon Oct 23 00:55:53 CEST 2017
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
> You also mentioned the following patch when I experienced problems that had
> something to do with variable or member initialisation:
> Was this merged upstream in the end?
> 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
More information about the l4-hackers