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