121–130 of 276 posts
Earlier quoted context omitted.
I suspect it's because AMD's resurgence is so recent and these things need long lead times for procurement, development, and validation. I'm less familiar with laptops: Do Intel and AMD CPUs even share a common socket?
Not only do Intel and AMD processors not share the same socket, processors change socket from generation to generation.
Earlier quoted context omitted.
Yeah
are there tools for parsing the firmware bin? are they a threat vector? is it like a settings file?
Binwalk, IDA pro, etc. All the normal reverse engineering tools.
>are they a threat vector?
Absolutely.
>is it like a settings file?
No, it's code executing on the WiFi card.
Earlier quoted context omitted.
Do you plan on offering laptops that are 16:9 or 3:2, rather than the 1080p? That's probably the last thing keeping me on a Mac, the panel ratio.
1080p is 16:9. I presume you meant 16:10 (which is also my preference)
Earlier quoted context omitted.
>The ME is disabled by way of a HECI message early in the boot process, so there are no runtime ME components similar to using the HAP bit on older ME versions. But why would I believe this? It seems you're selling snake oil. You can't really call it open firmware if there's still a lot of closed firmware in it.
> You can't really call it open firmware I can implement IEEE1275-1994 as fully closed sourced code and call it open firmware. > if there's still a lot of closed firmware in it. Downthread you mention "With nonCPU blobs there is (usually) a memory boundary", which I'll take as the boundary you made for yourself in these matters. With this boundary, the amount of "closed" firmware doesn't matter. The right 8 bytes at…
Initial bootstrap can be ROM, can be closed, but need not be. Stop compromising and accepting the status quo. The IBM POWER systems by Raptor have open firmware at every level. Is the CPU design open? Not entirely, but it is overall better, and I'm not trying to mislead people about it like the sales rep in this thread.
Your firewire example is disingenious, and no, I would disagree that it is open. Charlatans like System76 abuse the terms to sell their products taking advantage of the goodwill of those who do not know better.
Earlier quoted context omitted.
Works with coreboot though somehow. AGESA prevents it as far as I know, since it does some stuff that coreboot has to be doing. I'm not that familiar with details, may be some coreboot experts can comment.
coreboot on modern Intel requires (some amount of) ME firmware (without which the x86 core wouldn't even turn on) + some parts of the Intel FSP binaries. coreboot on modern AMD requires (some amount of) PSP firmware (without which the x86 core wouldn't even turn on) + some parts of AGESA which were most recently shipped as "BinaryPI". The situation is comparable, just that Intel has ~7 years of dealing with coreboot…
Doesn't that mostly boil down to "avoid anything newer than Ivy Bridge/Bulldozer"?
> high performance memory […] controller function blocks
There are DDR4 controllers with FOSS training code out there :) https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/...
Earlier quoted context omitted.
Atheros chipsets tend to not require any non-free code (be it on the driver or firmware side), including their USB wifi dongles. I've had mediocre (at best) experiences with them, however, what with frequent stability and signal strength issues on what I'm pretty sure to be the hardware side (though I've found this is true of pretty much every wifi chipset out there, so I guess it's okay relatively-speaking).
This used to be true, but since Qualcomm bought them out, they have done a complete 180 and basically reverted to totally closed designs (closed firmware, closed drivers, no spec sheet). The 9xxx chip-sets (which are only 802.11n) are the last ones designed before Qualcomm took over, the 10xxx chip-sets (802.11AC+) are closed and completely locked down, you cant even change your MAC address its all stuffed into a gia…
Earlier quoted context omitted.
1080p is 16:9. I presume you meant 16:10 (which is also my preference)
I don't understand why we need another competing standard for such a small difference. Given how small the difference is, I'm in favor for whichever one is more common to avoid black bars below media or other ill-fitting content. As far as I can tell, 16:9 is much more common so I am happy to stick with that on any device and resolution.
Earlier quoted context omitted.
This might be a stupid question, but would adoption of RISC V help fix this issue?
> would adoption of RISC V help fix this issue? If you're in the market for some slow CPU, maybe. For high performance stuff the creator will likely have to license some function blocks that come with strings attached. I'd love to see a fully open RISC-V core with a DDR4 interface (and USB2/3 for all kinds of interfaces), but somehow I just don't see that happening before DDR4 is all but obsolete: those interfaces ar…
I do care that the in-memory key can not be read and transmitted without my OS' knowledge.
I have other computers for games and development and servers, and the NSA can have my steam password and already have my work email.
Earlier quoted context omitted.
1080p is 16:9. I presume you meant 16:10 (which is also my preference)
I don't understand why we need another competing standard for such a small difference. Given how small the difference is, I'm in favor for whichever one is more common to avoid black bars below media or other ill-fitting content. As far as I can tell, 16:9 is much more common so I am happy to stick with that on any device and resolution.
Earlier quoted context omitted.
It's not a laptop, but the Talos II workstation runs on POWER9 and has open firmware. https://www.raptorcs.com/TALOSII/
It uses OpenBMC firmware, now under The Linux Foundation. EDK2 is also open source, a UEFI implementation. Looks like Coreboot has been around about as long as EFI, and supports most of the same architectures. So is the Coreboot advantage argument mainly that it's simpler than UEFI?