Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-Sourcing our Firmware

frame.work

Post reply on HN
Print view View original

271–280 of 382 posts

Re: Open-Sourcing our Firmware

#271

Post by pvillano »

grp000 wrote: post #260
ohazi wrote: post #124

I've been so happy to see what Framework has been doing lately, and really want to support them, but I already have a desktop as my primary computer and two Thinkpads that are already set up nicely, but that I rarely use. I moved from 15" laptops to 14" when Lenovo added the numpad on the larger variant, and 14" is about as small as I want to go. I kind of want to buy a framework though, just to support them? But I h…

I'm waiting for something with beefier internals, or an AMD variant, or both. That being said, they'd have to redesign the power delivery system and thermals, so maybe it would no longer be as modular? Anyone with the knowledge care to weigh in?

there wouldn't be any new parts except the mainboard/cpu/heatsink. It's unlikely for someone to want to replace only one of those*. I don't see a loss for customizability or repairability

* very few people can solder a cpu and I've never heard of a heatsink needing replacement

Re: Open-Sourcing our Firmware

#272

Post by lukeschlather »

ad8e wrote: post #165

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithms that scramble keys or add delays, so it's good to see Framework has a correct solution. [0]: https://github.com/FrameworkComputer/EmbeddedController/blob...

This reminds me of a weird issue I have with my Lenovo where sometimes the trackpoint and mouse buttons stop working until a reboot (but the trackpad still works.) I think I must trigger a race condition in the trackpoint drivers somehow but I have no idea how to debug it.

Re: Open-Sourcing our Firmware

#273

Post by danuker »

alufers wrote: post #149
ohazi wrote: post #124

I've been so happy to see what Framework has been doing lately, and really want to support them, but I already have a desktop as my primary computer and two Thinkpads that are already set up nicely, but that I rarely use. I moved from 15" laptops to 14" when Lenovo added the numpad on the larger variant, and 14" is about as small as I want to go. I kind of want to buy a framework though, just to support them? But I h…

Sorry for changing the topic but does anybody know the reason Intel has removed the seep states? It drives me absolutely nuts when I open my bag and feel the heat coming out of it, and my laptop is left with 20% charge.

The correct course of action is to return the "defective" product.

Re: Open-Sourcing our Firmware

#274

Post by grp000 »

pvillano wrote: post #271
grp000 wrote: post #260

Earlier quoted context omitted.

I'm waiting for something with beefier internals, or an AMD variant, or both. That being said, they'd have to redesign the power delivery system and thermals, so maybe it would no longer be as modular? Anyone with the knowledge care to weigh in?

there wouldn't be any new parts except the mainboard/cpu/heatsink. It's unlikely for someone to want to replace only one of those*. I don't see a loss for customizability or repairability * very few people can solder a cpu and I've never heard of a heatsink needing replacement

Funny you say that, my current laptop has a really low wattage chip and as a result, a very small heatsink. As I was removing the plasticy thermal dividers that insulate the rest of the board from the heat of the heatsink so I could lap the contact area, I bent the heat-pipe and pinched it, since it was so thin and fragile.

That being said, that's a bummer. Would be nice to get a higher end compute option or one with a dGPU.

Re: Open-Sourcing our Firmware

#275

Post by JohnTHaller »

TranquilMarmot wrote: post #209

I bought a Framework for personal use and love it so much. I have it running Windows 11, if only because it was easier to get longer battery life out of it without doing endless tweaks on a *nix OS. Upsides: - Hardware feels VERY premium and nice. It's not too heavy. You'd never guess it's the first laptop made by a new company. - Keyboard is a pleasure to type on. I did nanowrimo last year on it and wrote ~60k words…

Thanks for this detailed write up of your experience with it. I love what they're doing but don't need a new laptop at the moment.

On the expansion card front, I think I tweeted to them about doing some kind of card bay to put a USB dongle in.

Re: Open-Sourcing our Firmware

#276

Post by bsder »

ad8e wrote: post #165

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithms that scramble keys or add delays, so it's good to see Framework has a correct solution. [0]: https://github.com/FrameworkComputer/EmbeddedController/blob...

I find the has_ghosting() function more problematic and reminds me of why C just sucks even if it is the appropriate choice.

c and c2 loop variables so a typo can hose you horribly. A global variable to hold the array length. ! instead of comparison to 0. Having to offset the second loop by 1. Early return which means the function will normally work fine but might result in N^2 extra time depending upon the data state. A bit trick relying on unsigned underflow without pointing out that unsigned is a key constraint even though it has a comment. An extra missing const on the incoming pointer (should be: const uint8_t * const). Braces left off the short-circuit if conditionals.

The worst part is I have personally written tons of functions like this. This is a "normal" function in C--in fact, it's far better than average.

The fact that you write C like this just shows how much we need something better.

Re: Open-Sourcing our Firmware

#278

Post by jhallenworld »

I've extracted the Chromium-EC encryption functions, they are convenient for signing / verifying firmware on other platforms. Chromium-ec is nice for example code like this:

https://github.com/jhallen/rsa-verify

On the other hand, if you are looking for some generic embedded system code all in C, here is our library (it's been cleaned up for ATSAM and STM32 targets, but we've used in on many other platforms):

https://github.com/nklabs/libnklabs

I think it's most unique feature is the embedded schema-based database- so you can save things like calibration and configuration information in local flash memory (think protocol buffers, but for tiny systems). Recently I've been adding device drivers for all common devices I can find on break-out boards from the Arduino and Raspberry-PI communities.

Re: Open-Sourcing our Firmware

#279

Post by willmorrison »

rnk wrote: post #53
smasher164 wrote: post #41

I've been running NixOS on my Framework for the last few months, and I've been really happy with it. I initially got it so I'd have viable hardware to do osdev on, so learning that they are going to open-source its firmware makes me even more happy.

Seems too good to be true. Reasonable prices, upgradable, no soldered ram. So has it been a reliable Linux laptop, what's the battery life with your options?

Battery life on mine with a pretty minimal Arch install and TTY is around 10 hours when doing light web browsing and programming. Only problems I’ve had are hardware related. The trackpad isn’t 100% reliable (sometimes clicks don’t work and I have to press hard to get it to work again) and the hinge is far too loose. Love the laptop overall.

Re: Open-Sourcing our Firmware

#280

Post by AndroidKitKat »

dheera wrote: post #216
tata71 wrote: post #204

Earlier quoted context omitted.

> disabling secure boot solved the issue Lovely...

Isn't secure boot just a Microsoft thing to try to stymie competition by preventing booting OSes other than Windows?

Debian seems to indicate otherwise: https://wiki.debian.org/SecureBoot
Post reply on HN