11:46 <mtrbot-ml> [mattermost] <lho2> lho2 joined the team.

11:52 <mtrbot-ml> [mattermost] <lho2> Hi all, first of all I would like to congrate you for your impressive job on Migen/Misoc and MilkyMist.

11:52 <mtrbot-ml> [mattermost] <lho2> By the past, I have spent some time looking to milkyMist internals and from what I remember, LM32 softcore was used internally right?

11:52 <mtrbot-ml> [mattermost] <lho2> For the OS, you were using RTEMS as far as I get. So could you tell me if toolchain for LM32 is still functionnal?

11:52 <mtrbot-ml> [mattermost] <lho2> Are you using same Softcore as a base for Misoc? Or this is something else? it's not really clear for me

12:00 <mtrbot-ml> [mattermost] <sb10q> hi @lho2

12:00 <mtrbot-ml> [mattermost] <sb10q> thanks :)

12:01 <mtrbot-ml> [mattermost] <sb10q> the toolchain for lm32 is rather bitrotten. if you compile the old gcc/binutils versions it might still work. I have little hope in the newer versions which are probably broken for lm32

12:01 <mtrbot-ml> [mattermost] <sb10q> misoc still has lm32 but also supports mor1kx (which is what we are mostly using these days due to the better compiler toolchain) and vexriscv

12:02 <mtrbot-ml> [mattermost] <lho2> old? how old ? do you have an idea ?

12:02 <mtrbot-ml> [mattermost] <lho2> So how did you manage to use lm32 on misoc in this case? I'm lost

12:03 <mtrbot-ml> [mattermost] <sb10q> about 8 to 10 years old. iirc gcc 4.9

12:03 <mtrbot-ml> [mattermost] <sb10q> there some lm32 patches around. but they have not been adapted to newer gcc versions, and since those things have gotten systematically broken it is safe to assume they don't work anymore

12:04 <mtrbot-ml> [mattermost] <sb10q> there are some lm32 patches around. but they have not been adapted to newer gcc versions, and since those things have gotten systematically broken it is safe to assume they don't work anymore

12:04 <mtrbot-ml> [mattermost] <lho2> too bad, so lm32 is not a real option anymore if I want opened softcore right ?

12:04 <mtrbot-ml> [mattermost] <sb10q> I suggest minerva or vexriscv

12:05 <mtrbot-ml> [mattermost] <sb10q> they're basically like lm32 but due to the risc-v hype people have been maintaining the toolchain

12:05 <mtrbot-ml> [mattermost] <sb10q> there's little difference otherwise

12:05 <mtrbot-ml> [mattermost] <lho2> risc V is royalty free ?

12:05 <mtrbot-ml> [mattermost] <sb10q> yes

12:05 <mtrbot-ml> [mattermost] <lho2> hum nice

12:06 <mtrbot-ml> [mattermost] <lho2> and if I would like to bring back to life lm32, do you know some company/people that could help me ?

12:07 <mtrbot-ml> [mattermost] <sb10q> yeah, but this is likely going to be very expensive. i tried going that route before

12:07 <mtrbot-ml> [mattermost] <sb10q> or you can just compile the old gcc versions...

12:09 <mtrbot-ml> [mattermost] <lho2> ok thank you for sharing your experience. So If I'm summing up : Lm32 "could" be used only If I'm using old version (4.9) that will support C/C++ right? Otherwise your advice is to go for minerva or vexriscV (I suppose there, they are supported recent version and recent C++ standard right ?)

12:09 <mtrbot-ml> [mattermost] <sb10q> yes

12:09 <mtrbot-ml> [mattermost] <sb10q> risc-v has recent gcc and llvm support

12:10 <mtrbot-ml> [mattermost] <lho2> and if I would like to give a try to gcc4.9, on your past experience, did it support C++ or only C? Did you notice some incompatibility? (like I don't know no support for virtual function, stack alignment issue ...) ?

12:11 <mtrbot-ml> [mattermost] <sb10q> it supports C++

12:11 <mtrbot-ml> [mattermost] <sb10q> haven't used it much but I have not seen any particular issues

12:12 <mtrbot-ml> [mattermost] <lho2> to be honest, why I'm asking => I did a try a recent gcc version with lm32, and simple class inheritance with virtual gets crazy

12:12 <mtrbot-ml> [mattermost] <sb10q> I'm surprised you managed to compile that gcc at all

12:13 <mtrbot-ml> [mattermost] <lho2> I would not lie : it was really tough for me:)

12:13 <mtrbot-ml> [mattermost] <sb10q> but yes, this sort of bug festival is what is to be expected. I did try to upgrade gcc myself and it was always a mess

12:14 <mtrbot-ml> [mattermost] <sb10q> the LLVM stuff is somewhat better, though there is a lot of constant internal API breakage there as well

12:14 <mtrbot-ml> [mattermost] <lho2> I'm not an expert in such area so at least it's relief for me to heard that it's normal

12:16 <mtrbot-ml> [mattermost] <lho2> I never dig to LLVM direction sorry

12:16 <mtrbot-ml> [mattermost] <sb10q> well the LLVM LM32 port is very crappy (worse than gcc 4.9) so you'll have a lot of homework if you want to use it with LM32

12:16 <mtrbot-ml> [mattermost] <sb10q> I was saying that LLVM is generally more maintainable than GCC

12:17 <mtrbot-ml> [mattermost] <sb10q> (IMHO)

12:17 <mtrbot-ml> [mattermost] <lho2> :) too bad. I do not intend to be an expert in creating toolchain and maintaining them. I'm just looking for a good ready to play open softcore with ideally OS support

12:17 <mtrbot-ml> [mattermost] <sb10q> which OS?

12:18 <mtrbot-ml> [mattermost] <sb10q> I would suggest RISC-V then, since people have been porting a lot of software to it recently

12:18 <mtrbot-ml> [mattermost] <lho2> anyone that could be more or less branded RealTime

12:18 <mtrbot-ml> [mattermost] <sb10q> try this

12:19 <mtrbot-ml> [mattermost] <sb10q> https://docs.rs/cortex-m-rtfm/0.4.0/rtfm/

12:19 <mtrbot-ml> [mattermost] <lho2> I do not plan really complicated task but a scheduler + synchronization primitive this is minimum

12:19 <mtrbot-ml> [mattermost] <sb10q> imo all the other realtime stuff sucks

12:19 <mtrbot-ml> [mattermost] <sb10q> there's more info https://blog.japaric.io/rtfm-v2/ after github gets their act together

12:20 <mtrbot-ml> [mattermost] <lho2> interesting link thank you.Until now I was considering RTEMS (but so heavy !) or freertos (but I'm not sure about licence with Amazon behind)

12:20 <mtrbot-ml> [mattermost] <sb10q> RTEMS isn't that heavy, the main issue is it's buggy

12:20 <mtrbot-ml> [mattermost] <sb10q> and very old-school

12:21 <mtrbot-ml> [mattermost] <sb10q> it's nice if you want to run POSIX libs

12:21 <mtrbot-ml> [mattermost] <sb10q> for the rest, meh

12:21 <mtrbot-ml> [mattermost] <lho2> really? I saw article saying it was use on spatial application so for me it was synomym of bullet proof

12:21 <mtrbot-ml> [mattermost] <sb10q> :) you'd be surprised with the bugs we found

12:21 <mtrbot-ml> [mattermost] <lho2> ok thank you. Nice to know

12:22 <mtrbot-ml> [mattermost] <sb10q> like a race condition in the queue implementation that would randomly lock up the whole system

12:22 <mtrbot-ml> [mattermost] <lho2> holly cr** not serious for spatial stuff

12:23 <mtrbot-ml> [mattermost] <sb10q> anyway, for a modern softcore with a realtime scheduler I would recommend risc-v + rtfm

12:23 <mtrbot-ml> [mattermost] <lho2> I never heard about the OS you send to me (https://docs.rs/cortex-m-rtfm/0.4.0/rtfm/) . This is for ARM Cortex only nope ?

12:23 <mtrbot-ml> [mattermost] <sb10q> it's not really a OS

12:24 <mtrbot-ml> [mattermost] <sb10q> it's likely portable; and rust runs on risc-v just fine

12:25 <mtrbot-ml> [mattermost] <lho2> I don't need really full OS => just a scheduler (context switch) to run task in parallel and being able to put task in sleep mode when waiting for instance to get some shared HW resources

12:25 <mtrbot-ml> [mattermost] <lho2> so I need primitive (mutex and semaphore) to synchronize them

12:25 <mtrbot-ml> [mattermost] <sb10q> there's also this https://github.com/ferrous-systems/async-on-embedded/ but not real-time

12:26 <mtrbot-ml> [mattermost] <lho2> I don't need (at least for the time being) filesystem, network stack etc that could be part of bigger OS

12:27 <mtrbot-ml> [mattermost] <lho2> I was considering baremetal code too....sounds ok for the beginning...but experience is showing that you always to add more and more...and it will be a nightmare at the end

12:28 <mtrbot-ml> [mattermost] <sb10q> why would it be a nightmare?

12:29 <mtrbot-ml> [mattermost] <lho2> Because I will probably have some shared HW resource (typically I2C bus) and I'm targeting real time processing, so I cannot just do active polling to wait to get my answer

12:29 <mtrbot-ml> [mattermost] <sb10q> ok but things like RTFM deal with this sort of stuff

12:29 <mtrbot-ml> [mattermost] <lho2> So I need to release current task to process urgent task

12:30 <mtrbot-ml> [mattermost] <lho2> and why you had choose mor1kx and not Risc-V ? maybe it was not existing yet right ?

12:30 <mtrbot-ml> [mattermost] <sb10q> operating systems, well... they deal with it poorly if at all, and bring a lot of problems on their own

12:31 <mtrbot-ml> [mattermost] <sb10q> back then, all mor1kx implementations and the toolchains sucked

12:31 <mtrbot-ml> [mattermost] <sb10q> back then, all risc-v implementations and the toolchains sucked

12:31 <mtrbot-ml> [mattermost] <sb10q> this has changed a lot, people started making nice implementations and the llvm and gcc toolchains have been fixed

12:32 <mtrbot-ml> [mattermost] <lho2> still the case or not ? I mean should I consider mor1kx instead of risc-V ?

12:32 <mtrbot-ml> [mattermost] <sb10q> no, go for risc-v for new designs

12:32 <mtrbot-ml> [mattermost] <lho2> ok thank you very much for these advices and experience sharings

12:34 <mtrbot-ml> [mattermost] <lho2> It's funny to discuss with you whereas you are in HK because we have met in paris few years ago around Paris when you were teaching VHDL (and working on MilkyMist at that time)

12:35 <mtrbot-ml> [mattermost] <lho2> (and no problem, i'm quite sure you do not remember me :) )

12:37 <mtrbot-ml> [mattermost] <lho2> Congrats again for your trajectory, I'm still impressed by your skills and your motivation to share experience and knowledge

12:39 <mtrbot-ml> [mattermost] <lho2> Take care during this complicated period with Coronavirus. thank again for advices.