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

Adam Lackorzynski <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.