4 ms·

They're replacing openbmc, thankfully - the build system is absolutely ridiculous. The motivation is to escape binary blob ARM world. You know that POWER and RI

They're replacing openbmc, thankfully - the build system is absolutely ridiculous. The motivation is to escape binary blob ARM world. You know that POWER and RISC-V are competing solutions, right?

jhallenworld 5y ago
Which soft-core Power are they using? They mention Lattice ECP5, so a fairly small one I assume.
- sennight 5y ago
  An OpenPOWER one, likely this with modification: https://github.com/antonblanchard/microwatt https://github.com/antonblanchard/microwatt
  - jhallenworld 5y ago
    Microwatt looks nice (though I wish it was Verilog), it has a floating point unit which most of the low-end RISC-Vs do not. Also: "Anton Blanchard", Distinguished Engineer: IBM Total Duration 20 yrs 3 mos
    - sennight 5y ago
      Well the same guy (yes, he is a madman) did another one in Chisel, which is one step removed from Verilog: https://github.com/antonblanchard/chiselwatt https://github.com/antonblanchard/chiselwatt I don't spend enough time with FPGAs to even pretend to have an educated opinion on HDLs.
      - jhallenworld 5y ago
        Yeah, they are semantically equivalent, but I'm more comfortable in Verilog. It used to be that the open source situation for VHDL was not as good, but it's clearly improving.
      - deleted 5y ago
        [deleted]
jabl 5y ago
> They're replacing openbmc The press release says they're planning to use openbmc. The "LibreBMC" part seems to be about an open HW platform (incl. created with FOSS tools) for running openbmc. Or are you saying openbmc is planning on some major refactoring?
- sennight 5y ago
  The statement was "run software from OpenBMC"... so that could mean almost anything - anything except the conclusion to seem to have drawn. My guess would be that it means they'll grab some of the python code and carve up the systemd scripts. I've been living with an openbmc equipped system for a year or so - there is a lot about it that I won't miss, especially the way it handles serial communication.
  - amboar 5y ago
    > there is a lot about it that I won't miss, especially the way it handles serial communication Out of curiosity, what were the issues you had with OpenBMC's serial communication?
    - sennight 5y ago
      It was eating characters, which is the second worst thing it could do. Digging into the source, I found a really wonky software buffer... which kind of blew my mind - since hardware buffers and flow control exist. I don't remember if that was a case where python was somehow in the pipeline, but that was unfortunately very common in OpenBMC. I also had a lot of trouble getting the thing to honor the most basic settings, like baud rate. But it is harder to confidently place the blame on that one. Is it OpenBMC's fault that the software provides no clue as to where things are going wrong in the serial plumbing? Is it the AST2500's fault that designers are routing every serial line through it and making it impossible to eliminate as the cause while troubleshooting? Is it IBM's fault, because the design of OPAL (OpenPower Abstraction Layer) encourages construction of this kind of Rube Goldberg machine? If anyone from IBM is listening: don't route all your serial lines through the BMC on your reference designs... system implementers will just copy it.
Teknoman117 5y ago
All I remember about OpenEmbedded/Yocto was trying to wrap my then teenage brain around it a decade or so ago when it was the build system / distribution of choice for Beagleboards (via Angstrom). Ended up going with buildroot instead at the time...
- bfrog 5y ago
  Seriously, nothing like spending a day building an image in a way documented only to see it blow up and fail, resulting in having to redo the whole thing. Wish Nix were more popular building embedded system images, the tooling is capable of doing everything bitbake and yocto do, with far saner usage.

They're replacing openbmc, thankfully - the build system is absolutely ridiculous. The motivation is to escape binary blob ARM world. You know that POWER and RISC-V are competing solutions, right?

jhallenworld 5y ago

Which soft-core Power are they using? They mention Lattice ECP5, so a fairly small one I assume.

sennight 5y ago
An OpenPOWER one, likely this with modification: https://github.com/antonblanchard/microwatt https://github.com/antonblanchard/microwatt
- jhallenworld 5y ago
  Microwatt looks nice (though I wish it was Verilog), it has a floating point unit which most of the low-end RISC-Vs do not. Also: "Anton Blanchard", Distinguished Engineer: IBM Total Duration 20 yrs 3 mos
  - sennight 5y ago
    Well the same guy (yes, he is a madman) did another one in Chisel, which is one step removed from Verilog: https://github.com/antonblanchard/chiselwatt https://github.com/antonblanchard/chiselwatt I don't spend enough time with FPGAs to even pretend to have an educated opinion on HDLs.
    - jhallenworld 5y ago
      Yeah, they are semantically equivalent, but I'm more comfortable in Verilog. It used to be that the open source situation for VHDL was not as good, but it's clearly improving.
    - deleted 5y ago
      [deleted]

jabl 5y ago

> They're replacing openbmc The press release says they're planning to use openbmc. The "LibreBMC" part seems to be about an open HW platform (incl. created with FOSS tools) for running openbmc. Or are you saying openbmc is planning on some major refactoring?

sennight 5y ago
The statement was "run software from OpenBMC"... so that could mean almost anything - anything except the conclusion to seem to have drawn. My guess would be that it means they'll grab some of the python code and carve up the systemd scripts. I've been living with an openbmc equipped system for a year or so - there is a lot about it that I won't miss, especially the way it handles serial communication.
- amboar 5y ago
  > there is a lot about it that I won't miss, especially the way it handles serial communication Out of curiosity, what were the issues you had with OpenBMC's serial communication?
  - sennight 5y ago
    It was eating characters, which is the second worst thing it could do. Digging into the source, I found a really wonky software buffer... which kind of blew my mind - since hardware buffers and flow control exist. I don't remember if that was a case where python was somehow in the pipeline, but that was unfortunately very common in OpenBMC. I also had a lot of trouble getting the thing to honor the most basic settings, like baud rate. But it is harder to confidently place the blame on that one. Is it OpenBMC's fault that the software provides no clue as to where things are going wrong in the serial plumbing? Is it the AST2500's fault that designers are routing every serial line through it and making it impossible to eliminate as the cause while troubleshooting? Is it IBM's fault, because the design of OPAL (OpenPower Abstraction Layer) encourages construction of this kind of Rube Goldberg machine? If anyone from IBM is listening: don't route all your serial lines through the BMC on your reference designs... system implementers will just copy it.

Teknoman117 5y ago

All I remember about OpenEmbedded/Yocto was trying to wrap my then teenage brain around it a decade or so ago when it was the build system / distribution of choice for Beagleboards (via Angstrom). Ended up going with buildroot instead at the time...

bfrog 5y ago
Seriously, nothing like spending a day building an image in a way documented only to see it blow up and fail, resulting in having to redo the whole thing. Wish Nix were more popular building embedded system images, the tooling is capable of doing everything bitbake and yocto do, with far saner usage.