Definitely not the best pricing, but also not completely bad considering you get a 64GB microSD and case alongside?
Looking forwards to the next-gen mainboard they hint at in the "value-added package" as the JH7110 really is quite a weak chip (even by RISC-V standards)...
1.5 GHz CPU core frequency, some old RISC-V cores while we're still waiting for cores with decent single-core performance to compete with modern desktop processors.
Sorry, but for me this board is dead in the water, unless you can't use ARM/x86 for political reasons.
A suitable RVA22+V chip (SpacemiT 8 core) has only been out on dedicated dev boards for a few months. That's probably going to be their 2025Q2 main board.
Their 2025Q4 main board will be the first high performance RVA22+V one. If the chip happens ... it's struck some political (sanctions) problems.
JH7110 is the right chip for a first board to get the wrinkles ironed out. No one has ever done a 3rd party or non-x86 mainboard for Frame laptops before.
First retail customer deliveries of mass-production JH7110 chip and board were February 2023. First laptops with it were at the end of 2023.
The CPU cores used (U74) were announced in October 2018. The first high-priced dev boards using essentially test chips (HiFive Unmatched $650, BeagleV Starlight unknown price, 300 were made and given away to developers) were mid 2021.
It is important to distinguish the dates of availability of RTL for a core, first tests chips of a complete SoC using it, and mass-production as there is usually several years between each stage.
You hear about all these dates in the RISC-V and Arm worlds where each thing (core, SoC, board) is done by different companies, each with a vendor-customer relationship with the previous stage company. You don't hear about them in the more vertically-integrated x86 and Apple worlds.
For example my 6 core Zen2 laptop runs my primes benchmark (small code, long-running, the best possible case for qemu-user) 10% slower than my VisionFive 2. If you want to run a whole emulated OS then qemu-system is a lot slower than qemu-user.
My i9-13900 laptop runs the same benchmark in qemu-user 2.6x faster than the VisionFive 2, but it also costs 30x more -- or about 2x more than the Frame laptop with the JH7110 mainboard. Or 5x more than the original DC Roma laptop with the JH7110 now costs ($299).
If you want a RISC-V laptop then Frame is a very expensive way to get one. It might be higher quality, and it will be upgradable to better specs later.
These CPU cores were announced three years before the Vector extension spec was ready.
Check the updates coming next year.
I guess that all falls under "curiosity", but I really do hope that the ecosystem for framework compatible parts blow up.
So what? It would be great to use this as a developer platform because you have the whole chassis and peripherals of a laptop and all you have to make is the mainboard
And unfortunately, that's even without build parallelism.
With multiple vendor-customer relationships in the chain there is not only likely to be no overlap in stages, but even there may be 6, 12, 24 months of gap between the RTL for the core being available and someone even making a decision to make an SoC using those cores, and a similar gap from a chip being available to someone else deciding to buy it to design a motherboard around it.
So with FPC/Lazarus you have a full dev system if works as wiki suggests.
You just know someone's gonna make an Amiga one.
And a whole bunch of aging German and Scandinavian hackers are gonna come out and try to convince people, no seriously, this is a great daily driver, you just have to go to Aminet and get the right RTG driver pack for the display panel and...
Sorry to burst your bubble.
I bought a macbook a while ago specifically because I can get it to last about 45-50 hours non-stop usage on one charge, so getting a system tailored for even better performance and a longer battery life (macbooks could probably double or triple battery life if they bulked up and stopped trying to be so petite) would be incredible.
>100 hour battery lifes should be very achiebable for developers, as limiting screen brightness and using only terminal with a black background can increase battery life _enormously_.
Are you aware that major chip company Microchip just announced a new family of chips, the PIC64GX -- a big deal for them -- with a dev board that has just become available in the last month or so, which uses RISC-V cores first used in the HiFive Unleashed in early 2018 (and announced in Oct 2017, when they already had working test chips)?
https://www.microchip.com/en-us/development-tool/curiosity-p...
Are you aware that people still announce new chips based on the Arm A53, a core announced in 2012?
Or that 70% of Arm's revenue comes from CPU cores announced in 1994 (ARM7TDMI) - 2009 (Cortex-M0)?
"Old" is not relevant to anything. Only design features are relevant.
Also, linkers other than GNU `ld` (or `gold` which is faster but used more RAM) use a lot less RAM e.g. `mold`, or even better LLVM's own `lld`.
Check the green build matrix on this page: https://qa.debian.org/developer.php?login=alexander.kjall%40...
I don't think anyone implied otherwise. But the product in my hand is still lacking.
> Are you aware that major chip company Microchip
I don't see how this affects my argument in any way?
> Are you aware that people still announce new chips based on the Arm A53, a core announced in 2012?
Not for the main cores of laptops they don't.
> "Old" is not relevant to anything. Only design features are relevant.
There is sufficient context here to tie the two together. These cores are slow because of relative lack of development time. These cores lack vector units specifically because of their age, because they were designed before there was a spec (which you brought up).
Yes, the real ARM vs. x86 discussion will come around Ryzen Max 2025Q1 with 128mb on-package dram (hope we get desktop board manufacturers to sell this).
I hate corporate software.
(being IBM, they later tried to "upgrade" to a locked-down microchannel bus, but it happily didn't go anywhere)
other things got standardized (motherboards, power supplies, peripherals, etc) and it has been going ~ 40 years now.
Also, a number of people have come unstuck by writing and testing things ONLY on qemu, and then had them fail on real hardware. For example, qemu was historically much more lenient with PMP settings than real hardware (if you didn't touch the PMU then qemu acted as if you didn't have one at all). Also anything that needs fences on real RISC-V (or Arm) hardware is likely to work even when it's incorrect on a PC that is jitting multiple instructions per RISC-V instruction and is TSO anyway. Qemu being lenient about setting up the UART (e.g. it doesn't care about baurd rate, start/stop bits etc) compared to real hardware is another example.
Price and size and overall state of tech back then didn't really allow to have several PCs in one (for some rare and pricey exceptions like PowerPC CPU extension boards, etc.). These days we can potentially have inside regular size laptop a backboard with standard bus (something like Sipeed cluster board which takes up to 7 credit card sized SoCs [1]) into which we can potentially plug various SoCs of the same or different arc. Say one SoC is RISC-V, one x86 and several SoCs with powerful NPUs - configure your laptop(cluster) for the mission at hand. Dare i say from a common bin of parts in the office (or even from public library - the SoCs are just tens of dollars nowdays, like say a game cartridge).
[1] one can imagine if the cards were inserted at angle instead of vertically https://www.amazon.com/Sipeed-Lichee-Cluster-High-Performanc...
0. https://buildd.debian.org/status/architecture.php?a=riscv64&...
Joke aside, typo, s/mb/gb/g - thanks for catching.
E.g. arm64 dropped very low for a while or all arches dropped around 2024.68
If there's a huge drop, it is most of the time because a package a lot of software depends on got updated or modified (e.g. built with different options) and it caused ABI changes, thus causing rebuilds of everything that depends on it.
I usually get barely a working day out of my corporate MacBook Pro M1 with Corpo Security Special Sauce, CLion and Teams. But I have to kill CLion when it gets too crazy (i.e. often). Do you have any insights from Activity Monitor on who is draining the battery?
My biggest offenders: - Symantec Data Loss Prevention Agent (x86 Emulation) - $Corporation App Store (I never use it, don't know why it burns CPU time)
This corporate "security" software is the essence of everything that's wrong with a corporation.
But that only shows "Apps", not processes. If I list all processes, the one that's almost always in the top is Crowdstrike Falcon. Specially when there's disk access, as it seems to intercept everything...
