Introducing a new RISC-V Mainboard from DeepComputing

You’re completely off topic, dude

I understand it perfectly well. I think you don’t understand that your requirements are niche and not representative of the principal target audience.

So why did you called it a tantrum if you understand what I’m saying?

It is also not my niche. That is expanding to Framework from being basically developer’s kit to a niche market product. I’m dramatically expanding its customer base by presenting needs and requirements which this community simply doesn’t understand due to them being developers. What Framework is doing now is appealing solely to developers. They make smallest fraction of their audience. After developers come tech enthusiasts who want to try out new stuff. This is the group I belong and what Framework does now doesn’t at all satisfy those needs.

It is, but it is not me who is going off topic. It is people who are discussing ideas are making conversation go off topic.

Let’s keep this thread on topic please. Further off-topic posts will be removed.

This is really interesting to me, even though I’m not the target audience. I am looking forward to the future when a much more performant and supported RISC-V machine becomes available. Glad to see DeepComputing has selected the Framework platform for this product, and hope to see more from them in the future.

4 Likes

Asus, hp: we are introducing arm chips!
Framework: NUH UH, hold my beer

Best news ive heard in a while. If (When) arm motherboard will be announced, i genuinely dont know the any other company, who makes better laptops.

3 Likes

I heard RISC-V might be possible to get working with coreboot… Is that the plan here? Or is there something else in mind.

1 Like

The board will probably ship with the following open source UEFI implementation: GitHub - starfive-tech/edk2

(or if it doesn’t, you can probably flash that at least)

I have no idea how easy it would be to port coreboot to that board, but I’m sure it’s theoretically possible.

3 Likes

A post was merged into an existing topic: ARM-based CPUs

Framework made a 25-minute video a few days ago covering the development and some more details of the RISC-V mainboard.

One thing in particular that caught my attention is the only m.2 slot is dedicated to wifi and they’re using a microSD slot and a sort of defacto-standard eMMC socket for storage (and, of course, many Linux distros can be installed onto USB as well).

This begs the question though—is the wifi’s m.2 slot an E+M key (rather than the E-key only seen on the current Intel/AMD mainboards) so that an NVMe SSD can be used instead of wifi if so desired, like if using the 2.5Gb ethernet module? (the video even specifically mentioned the Cooler Master case which is a perfect use-case for not needing wifi and/or preferring ethernet—though, at that rate, why not have E+M key for the wifi slot on all Framework mainboards?)

I don’t think m.2 sockets can be dual key, only m.2 modules can have multiple keys (slots).

A socket that would accept both types of m.2 modules would have no keying at all (or needed somehow adjustable keying).

I guess it is pretty clear that for laptops like FW, one will need risc-v chips with far more pcie and usb4 interfaces and inter-cpu links, so one can put more cpu chips on the mainboard to get more processing power.

The pinouts of e and m-key are not really compatible, the keys are there for a reason. M.2 is a connector with multiple different pinouts, the keys are both to tell you what kind it is and prevent you from plugging the wrong thing into the wrong port.

See my post over here for a possible way to do it.

Another thought I just had—around 5 years ago, m.2 SATA SSDs were pretty common. Why not add a SATA-only m.2 slot? Or is the issue that SATA still requires PCIe lane(s) due to SATA presumably not being natively integrated into the SOC directly?

NVMe and wifi are both just PCIe devices, and so the m.2 connector is simply being used as a smaller version of the bog-standard PCIe slot you find on desktop motherboards or the like (even more-so since I don’t believe any Framework mainboards support m.2 SATA SSDs).

There was already another user that repurposed their wifi slot on the x86 Framework 13 mainboard for their SSD in order to use the main NVMe slot for an external GPU and it all “just worked”… at least on Linux:

Sata does require sata, some socs do provide that directly or you can convert pcie or usb or something into it.

You can easily, you just need an adabter that wires the 1 pcie lane for the wifi to the e-key pinout. You can do that pretty much anywhere pcie wifi cards are used (some devices use the same chipset with just the proprietary intel wifi protocol and no pcie).

Is the RISC-V chip on this Mainboard affected by this vulnerability? The article mentions a specific RISC-V based chip, but stops short of commenting on whether it affects all chips implementing this architecture or not…

Haven’t looked at that article, but have a read of this one. which explains the problem quite clearly. It only affects a chinese sourced chip family.

3 Likes

Wow,
this is a very interesting step, particularly with the way that power demands are growing.

I’d love to see a framework laptop with one of these RISC units:https://www.fujitsu.com/global/imagesgig5/FUJITSU-MONAKA.pdf

pcie6, CXL3, high bandwidth and performant memory with reduced power draw and optimised IO.

Looking forward to seeing you guys deliver :slight_smile: