Use this thread to discuss what you have done recently and are working on this week with a vague relation to lowRISC, RISC-V, open-source hardware etc. Please be descriptive and don’t hesitate to champion your accomplishments or ask for help, advice or other guidance.

I've seen this kind of weekly update thread work well in other communities (notably lobste.rs [1] and the rust community [2]) so thought it would be worth trialling it on lowrisc-dev, particularly with all the activity that is going on around GSoC. Use this thread to discuss what you have done recently and are working on this week with a vague relation to lowRISC, RISC-V, open-source hardware etc. Please be descriptive and don’t hesitate to champion your accomplishments or ask for help, advice or other guidance. [1]: https://lobste.rs/s/nfh5nd/what_are_you_working_on_this_week [2]: https://www.reddit.com/r/rust/comments/4nu1ag/whats_everyone_working_on_t...

:

Hi everyone, As part of GSoC I'm continuing to work on porting the xv6 teaching operating system to RISC-V. Last week I finished up reorganizing the codebase to separate out the machine dependent and machine independent code and used Jonathan Neuschäfer's UART patch to spike to get output working in my kernel. This week I'll continue bringing up the kernel and adding more functionality into it, starting with trying to get a console up and running. Best, Jeff On 6/20/16 08:40, Alex Bradbury wrote: > On 13 June 2016 at 15:41, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: > >> I've seen this kind of weekly update thread work well in other >> communities (notably lobste.rs [1] and the rust community [2]) so >> thought it would be worth trialling it on lowrisc-dev, particularly >> with all the activity that is going on around GSoC. >> >> Use this thread to discuss what you have done recently and are working >> on this week with a vague relation to lowRISC, RISC-V, open-source >> hardware etc. Please be descriptive and don’t hesitate to champion >> your accomplishments or ask for help, advice or other guidance. >> >> [1]: https://lobste.rs/s/nfh5nd/what_are_you_working_on_this_week >> [2]: >> https://www.reddit.com/r/rust/comments/4nu1ag/whats_everyone_working_on_t... >> > > It's a new week, and there seemed to be some positive feedback so lets > give "what are you working on this week" another go. I'll keep it > under the same thread for now. A few people dropped me an email to say > they'd wanted to take part but the week was almost over by the time > they got round to it. Well, here's another chance :) > > Last week, I spent some time getting up to speed on Linux kernel > hacking. I believe I've got a test kernel that should properly > initialise the Xilinx Quad SPI device, but there is an outstanding bug > with program loading for the next major lowRISC code release that > needs to be resolved before I can properly test that. For now, > printk() is my debugger. Debugging the program loading issue is the > main blocker now I believe. > > We have a group of four local interns starting here at the lab next > week so there has been some miscellaneous work in getting things set > up for them, and there's still some more to do - setting up tool > install on shared filespace etc. I hope later in the summer they'll be > introducing themselves on the list and once they start having results, > blogging about what they're working on. One of the products of the > internship should be more documentation about how to design, implement > and test custom accelerators (including the necessary hardware and > software support). > > That's my bit, now your turn - what are you working on this week? > > See also recent updates from some of our GSoC students: > * > http://mahadevrahul.blogspot.co.uk/2016/06/trusted-execution-environment-... > * > https://listmaster.pepperfish.net/pipermail/lowrisc-dev-lists.lowrisc.org... > > Best, > > Alex > >

On 13 June 2016 at 15:41, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: > I've seen this kind of weekly update thread work well in other > communities (notably lobste.rs [1] and the rust community [2]) so > thought it would be worth trialling it on lowrisc-dev, particularly > with all the activity that is going on around GSoC. > > Use this thread to discuss what you have done recently and are working > on this week with a vague relation to lowRISC, RISC-V, open-source > hardware etc. Please be descriptive and don’t hesitate to champion > your accomplishments or ask for help, advice or other guidance. > > [1]: https://lobste.rs/s/nfh5nd/what_are_you_working_on_this_week > [2]: https://www.reddit.com/r/rust/comments/4nu1ag/whats_everyone_working_on_t... It's a new week, and there seemed to be some positive feedback so lets give "what are you working on this week" another go. I'll keep it under the same thread for now. A few people dropped me an email to say they'd wanted to take part but the week was almost over by the time they got round to it. Well, here's another chance :)

On 20 June 2016 at 13:40, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: > On 13 June 2016 at 15:41, Alex Bradbury <asb(a)asbradbury.org&gt; wrote: >> I've seen this kind of weekly update thread work well in other >> communities (notably lobste.rs [1] and the rust community [2]) so >> thought it would be worth trialling it on lowrisc-dev, particularly >> with all the activity that is going on around GSoC. >> >> Use this thread to discuss what you have done recently and are working >> on this week with a vague relation to lowRISC, RISC-V, open-source >> hardware etc. Please be descriptive and don’t hesitate to champion >> your accomplishments or ask for help, advice or other guidance. >> >> [1]: https://lobste.rs/s/nfh5nd/what_are_you_working_on_this_week >> [2]: https://www.reddit.com/r/rust/comments/4nu1ag/whats_everyone_working_on_t... > > It's a new week, and there seemed to be some positive feedback so lets > give "what are you working on this week" another go. I'll keep it > under the same thread for now. A few people dropped me an email to say > they'd wanted to take part but the week was almost over by the time > they got round to it. Well, here's another chance :) Happy Monday everyone. The GSoC mid-term evaluations were due in today (both from mentors and from students). Thank you to everyone for taking the time to fill these out. The main thing happening this week is we have four interns (kindly funded by IMC Financial Markets) starting today. I'll start a new thread for them to introduce themselves later this evening or this morning. A fair bit of time was spent on administrative tasks getting things ready for the interns arrival and so we remain blocked on a program loading issue for the next release (which includes trace debug). Your turn - what are you up to this week? Best, Alex

Thanks for reviving the thread Stefan. I've been working towards putting out an initial set of LLVM RISC-V patches up for comment at reviews.llvm.org. I thought I might get it done today, but it's looking like tomorrow now. I've gone through 35 of my ~44 patches for MC support. I just need to merge or otherwise fix up the remaining ones. I expect the initial patch series will be about ~10-12 patches long. Best, Alex On 15 August 2016 at 07:29, Stefan Wallentowitz <stefan(a)wallentowitz.de&gt; wrote: > Hi all, > > I am reviving this thread as I liked it a lot. > > I got back to do some lowRISC stuff over the weekend, but I am still > stuck with a hard bug on the debug interface transport. Hope to fix is > this week. Beside this we have been working to integrate the updated > debug infrastructure in my other project (OpTiMSoC) and will present the > overall state and roadmap of "Open SoC Debug" at this years' ORCONF. I > hope you all registered already at orconf.org. > > Cheers, > Stefan >

Another week already! I did manage to get my LLVM RISC-V MC layer patches up for review last week * RFC: http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html * Patches: https://reviews.llvm.org/differential/?authors=asb

Please do share what you're working on this week.

On 22 August 2016 at 15:20, Manuel A. Fernandez Montecelo > > As for what's next... Having the changes upstreamed in the GNU toolchain > would be very nice, to be able to put all that work in the Debian > infrastructure. I am not sure that it could be made to work with LLVM, > but even in that case GNU libc is needed even for the non-Linux Debian > ports (FreeBSD and Hurd), so at least that and probably GNU binutils > would be necessary. I'm not sure if the upstreaming of those components > would happen during this year, but let's hope for the best :-) Yes, Sylvestre Ledru has I think done a lot of work using Clang to build Debian but it's still easier to just use gcc as that's what the packages are built with on other architectures. Plus as you suggest, we'd still want GNU binutils as LLD isn't really mature yet.

> My other goal is to make the building process self-hosting and (more, > mostly) automatic, and keep things up-to-date with the updated packages > as they enter the archive. I'm almost there, but the unreliability [1] > and shortcomings [2] of Spike and Qemu (and lack of alternatives) are > blocking this at the moment. More automation definitely sounds like the way to go. It seems as though the QEMU work is getting increased attention, probably even more so after Sagar's talk at the QEMU/KVM forum (this week?)

Hi, Last week, I helped Rahul getting OP-TEE working on seL4/ARM, and tested it on seL4/RISC-V64. Also, I started adding CHERI ISA to RISC-V binutils. CHERI registers are added, and I spent sometime figuring out what bits/values I can use to integrate CHERI ISA into RISC-V ISA. Eventually decided to add CHERI as a RISC-V extension (like "Rocket Custom Coprocessor extension"), and used one of the reserved RISC-V opcode slots. As a start I got ccall instruction added and the assembler/objdump produce the correct opcode/instruction. On Spike, I just added a new letter extension (C) to support running CHERI-based programs, later. This week I'll continue adding more instructions, and maybe try simulating ccall on Spike. Cheers, Hesham On Tue, Aug 23, 2016 at 6:08 AM, Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com&gt; wrote: > 2016-08-22 17:59 GMT+01:00 Alex Bradbury <asb(a)asbradbury.org&gt;: >> On 22 August 2016 at 15:20, Manuel A. Fernandez Montecelo >>> As for what's next... Having the changes upstreamed in the GNU toolchain >>> would be very nice, to be able to put all that work in the Debian >>> infrastructure. I am not sure that it could be made to work with LLVM, >>> but even in that case GNU libc is needed even for the non-Linux Debian >>> ports (FreeBSD and Hurd), so at least that and probably GNU binutils >>> would be necessary. I'm not sure if the upstreaming of those components >>> would happen during this year, but let's hope for the best :-) >> Yes, Sylvestre Ledru has I think done a lot of work using Clang to >> build Debian but it's still easier to just use gcc as that's what the >> packages are built with on other architectures. Plus as you suggest, >> we'd still want GNU binutils as LLD isn't really mature yet. > The last rebuild from Sylvestre was back in March 2015, according to > [1], last blog entry in 2014. I knew that I hadn't heard about him in > a while, just didn't remember exactly how long. > > The results are quite good, ~6% instead of 10~12% or so in the > previous runs that I remembered [2]. The key is if the packages that > fail are unimportant (e.g. games) and fixable, or if upstream refuses > or is highly uninterested to fix them, as it is the case e.g. with the > Linux kernel (AFAIK). > > Even if the software itself can be compiled with LLVM, perhaps the > problem lies in some characteristics of the Debian packaging, and > getting changes to 1300 packages (or even 10% of that) is a lot of > effort. > > > [1] http://clang.debian.net/ > > [2] I am not sure how the statistics were gathered, though. 22k is > about the total number of packages in the whole archive, and vasts > amounts of packages do not depend on a C/C++/Fortran/etc compiler at > all -- hundreds of packages for Ruby, Haskell, Java, Python, Perl... > and about 50% of the whole set are not binaries (data and similar). > So 1320 packages is a quite higher percentage if we only take into > account the ones that need "GCC", probably 6k or 8k. > > >>> My other goal is to make the building process self-hosting and (more, >>> mostly) automatic, and keep things up-to-date with the updated packages >>> as they enter the archive. I'm almost there, but the unreliability [1] >>> and shortcomings [2] of Spike and Qemu (and lack of alternatives) are >>> blocking this at the moment. >> More automation definitely sounds like the way to go. It seems as >> though the QEMU work is getting increased attention, probably even >> more so after Sagar's talk at the QEMU/KVM forum (this week?) > Yep, fingers crossed! > > -- > Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com&gt; >

Another week already! I did manage to get my LLVM RISC-V MC layer patches up for review last week * RFC: http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html * Patches: https://reviews.llvm.org/differential/?authors=asb I've had a number of useful review comments, so am currently working through addressing them all. As requested, people have scrutinised every possible implementation detail - this is great, as we should end up with a really solid, easy to read base for further work. My main focus this week is refreshing this patchset to address all review comments and to continue work on the RISC-V LLVM backend. The lowrisc.org website is in desperate need of a refresh to make it easier for people who aren't already familiar with lowRISC to find out more about our mission, and I hope to spend a bit of time planning that work too. Please do share what you're working on this week. Alex On 16 August 2016 at 10:09, Nathanael Davison <nd359(a)cam.ac.uk&gt; wrote: > I and the other lowRISC interns have produced a few hardware accelerators > for elements of the MPEG-2 decode operation, and are now working on > integrating these into our fork of the lowRISC architecture. We're also > starting to plan the documentation we will deliver at the end of our > internship (2nd September). > > Best, > Nathanael > > > On 15/08/16 19:54, Alex Bradbury wrote: >> >> Thanks for reviving the thread Stefan. >> >> I've been working towards putting out an initial set of LLVM RISC-V >> patches up for comment at reviews.llvm.org. I thought I might get it >> done today, but it's looking like tomorrow now. I've gone through 35 >> of my ~44 patches for MC support. I just need to merge or otherwise >> fix up the remaining ones. I expect the initial patch series will be >> about ~10-12 patches long. >> >> Best, >> >> Alex >> >> >> >> On 15 August 2016 at 07:29, Stefan Wallentowitz <stefan(a)wallentowitz.de > >> wrote: >>> >>> Hi all, >>> >>> I am reviving this thread as I liked it a lot. >>> >>> I got back to do some lowRISC stuff over the weekend, but I am still >>> stuck with a hard bug on the debug interface transport. Hope to fix is >>> this week. Beside this we have been working to integrate the updated >>> debug infrastructure in my other project (OpTiMSoC) and will present the >>> overall state and roadmap of "Open SoC Debug" at this years' ORCONF. I >>> hope you all registered already at orconf.org. >>> >>> Cheers, >>> Stefan >>> > >

One minor suggestion - it may also be worth putting a screenshot in the README.

Another waveform viewer I haven't tried but rather like the idea of is waveterm https://github.com/ujamjar/hardcaml-waveterm, which as the name suggests supports outputting the waveform to terminal. Perhaps not as practical as a GUI tool, but definitely a fun idea.