diff --git a/site/contact.it.md b/site/contact.it.md new file mode 100644 index 0000000000000000000000000000000000000000..c9025462124152c3894f43f2f58a045841fa1cdc --- /dev/null +++ b/site/contact.it.md @@ -0,0 +1,74 @@ +--- +title: Contatti +x-toc-enable: true +... + +Supporto utenti +=============== + +IRC o Reddit sono consigliati, sebbene preferiamo che usi il canale IRC +per avere o per offrire supporto tecnico. Continua a leggere per avere +ulteriori informazioni. + +Mailing list +============ + +No mailing lists at present. + +Discussione sullo sviluppo +========================== + +Per ora dai un occhiata sulla +[pagina Git](git.md) per avere maggiori informazioni su come puoi +assistere con lo sviluppo. + +Su quella stessa pagina puoi trovare informazioni su come inviare +correzioni (patches) tramite pull requests. + +Canale IRC +========== + +IRC e' il modo principale per contattare chi collabora con il progetto Canoeboot. +Il canale ufficiale e' `#canoeboot` su Libera IRC. + +Webchat: +<https://web.libera.chat/#canoeboot> + +Libera e' una tra le piu' grandi reti IRC usate per i progetti di software libero. +Maggiori informazioni le trovi qui: <https://libera.chat/> + +Puoi usare il client IRC che preferisci (come weechat or irssi) usando le seguenti informazioni: + +* Server: `irc.libera.chat` +* Canale: `#canoeboot` +* Porta (TLS): `6697` +* Porta (non-TLS): `6667` + +Ti suggeriamo di usare la porta `6697` e ablitare la cifratura TLS... + +Inoltre ti suggeriamo di abilitare l'autenticazione SASL. Le pagine web +di Libera spiegano come: + +* Guida per WeeChat: <https://libera.chat/guides/weechat> +* Guida per Irssi: <https://libera.chat/guides/irssi> +* Guida per HexChat: <https://libera.chat/guides/hexchat> + +Comunque dovresti sempre controllare la documentazione del tuo client IRC preferito. + +Reti sociali online +=================== + +Canoeboot esiste ufficialmente in molte piattaforme. + +Mastodon +-------- + +Il fondatore e sviluppatore principale, Leah Rowe, e' su Mastodon: + +* <https://mas.to/@libreleah> + +Posta elettronica +----------------- + +Leah puo' essere contattata anche via email a questo indirizzo: +[leah@libreboot.org](mailto:leah@libreboot.org) diff --git a/site/docs/hardware/dell_thermal.md b/site/docs/hardware/dell_thermal.md new file mode 100644 index 0000000000000000000000000000000000000000..4ae28d350e00718182e74d7bf4e38dea47219e81 --- /dev/null +++ b/site/docs/hardware/dell_thermal.md @@ -0,0 +1,54 @@ +--- +title: Dell Latitude thermal throttling +x-toc-enable: true +... + +On some Dell Latitude laptops, you may encounter random shutdowns on +heavy load. We believe this is because the SMSC EC is overly conservative +by default; it is in charge of handling thermals and fan control on this +machine. Our theory is that coreboot needs to write certain EC commands +to allow higher temperatures; please read: + +<https://codeberg.org/libreboot/lbmk/issues/202> (NOTE: libreboot issue page, +no point duplicating in Canoeboot. Fixes in Libreboot that are suitable for +Canoeboot get put in Canoeboot anyway) + +Basically, what you need to do is: + +* Use high quality thermal paste (don't use the same dried up paste that the + laptop came with, if you bought it on ebay for example). Arctic MX-6 is good. +* Check that the fan works reliably + +Also: the `intel_pstate` driver can be used to artifically cap CPU speed. See: + +<https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html> + +When you use this machine, it is recommended that you cap the CPU speed once +you've booted into Linux. Set it to something like 50% at first. Then run a +stress test, for example: + + stress -c x + +Where `x` is the number of CPU cores, e.g. 2. Monitor the temperatures using +something like `xsensors`, making sure the CPU doesn't exceed 80c temperature. + +You can also monitor CPU speeds in Linux like so: + + watch -n .2 grep MHz /proc/cpuinfo + +This will let you know what speed you're at. You can use this to determine +whether the `intel_pstate` driver is working. How to cap speed to 50 percent, as +in the above example: + + echo 50 > /sys/devices/system/cpu/cpufreq/intel_pstate/max_perf_pct + +Gradually increase the CPU speed (up to 100 on `max_perf_pct`), waiting a few +minutes each time. You should ensure that your machine does not exceed 80C. + +Dell's thermal safety is far too protective by default, on some of these, and +we don't yet know how to properly configure it. Running a CPU below 80c in +temperature and never higher than that, is a good idea anyway, for the +long term life of your CPU. + +Regardless, thermal shutdown is extremely reliable on this machine, but Dell +makes it shut down *earlier*, before it can even start to CPU throttle. diff --git a/site/docs/install/index.md b/site/docs/install/index.md index 7b503eabd553cfe47c95b29672d12c8fa0a5e9fe..fbdfeabcfabfc9c01c92d6b11070969ecfb65a5c 100644 --- a/site/docs/install/index.md +++ b/site/docs/install/index.md @@ -3,53 +3,6 @@ title: Installation instructions x-toc-enable: true ... -**GRUB payload warning** -==================== - -Firstly, it should be stated: in almost all cases, GRUB works just fine, on -all of the machines that we test, but as of 26 May 2024 we got the error -report: - -See: <https://codeberg.org/libreboot/lbmk/issues/216> - -We've seen this elsewhere too, always on Sandybridge-based Dell Latitude -laptops, which Canoeboot doesn't support anyway (the above report is for -Libreboot, upon which Canoeboot is based), but: - -Although we've only seen this thus far (as per user reports) on Intel -SandyBridge based Dell Latitude laptops, we advise: - -**DO NOT use a ROM image where GRUB is the first payload. If you want to -use the GRUB payload, please use a ROM image with `seabios_` at the start -of the file name. Avoid images with `grub_` at the start of the file name.** - -ROM images with `grubonly` in them should also be avoided; if you want GRUB -to be the first thing you see (without interruption), use a ROM image -with `seabios_` at the start of the file name, and `grubfirst` at the end; -these place a bootorder file in CBFS, so that SeaBIOS loads GRUB first, but -you can still press ESC to bring up the SeaBIOS boot select menu. - -*This warning applies to Canoeboot 20240504/20240510 and other recent releases.* - -**We have since fully mitigated this bug**; SeaBIOS is now the primary payload on -all boards, with GRUB still available in the boot select menu, and we have -identified that it was caused by the xHCI driver which has since been removed -for the affected machines(machines which don't have xHCI anyway, but they -touch code that does run on the given machines). The xHCI support works fine -on some newer machines and will be re-added there by making GRUB multi-tree, -so that different boards can use different versions of GRUB. This will be done, -and present in the next Canoeboot release after 20240510, in addition to fixing -the actual bug itself. **For now, there are no problems!** - -Canoeboot releases after 20240510 will *only* (on x86) contain ROM images where -SeaBIOS is the first payload, without disabling the SeaBIOS menu (no `grubonly`). You'll still be able to use GRUB, either by pressing ESC for the boot -select menu, and/or using an image with `grubfirst` in the file name so that -SeaBIOS loads it first (while still permitting boot select via ESC keypress). - -GRUB's code is vast, and complicated, so this policy change is permanent, -until GRUB can be well-audited (likely forked, with dead/legacy code removed). -SeaBIOS code is much smaller and more robust. Remember always: code equals bugs. - Flashprog ========= diff --git a/site/news/canoeboot20240504.md b/site/news/canoeboot20240504.md index 7ca44084a3948c2f3b15e225d37ea9a3314baa2f..0ce395e2fead9ef9cac0f9607630a3ddc22ff651 100644 --- a/site/news/canoeboot20240504.md +++ b/site/news/canoeboot20240504.md @@ -466,3 +466,53 @@ All of the following boards have been disabled in the build system: D510MO and D945GCLF images not included either, due to lack of testing. *All other boards have ROM images in this release.* + +Errata +====== + +See: <https://codeberg.org/libreboot/lbmk/issues/216> + +This bug has been *fixed* in lbmk.git, and the fix will be included in +the next release, but it wasn't caught in the 20240504 release. The same +fix has been applied to Canoeboot's build system, cbmk. + +It is almost certainly guaranteed that *no* Canoeboot users were ever +affected by this, but extreme measures have been taken to ensure that it +is *entirely* guaranteed from now on. Read on to know more: + +The bug is quite serious, and it was previously decided that documentation +should be written warning about it (in docs/install/). The bug was *only* +triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never +reported on other boards, but there's no way to fully know; what is known +is that the offending patch that caused the bug has been *removed*; namely, +xHCI GRUB patches, which are now only provided on Haswell and Broadwell +hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the +GRUB tree with xHCI support is provided, but not currently used on any +mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.** + +The next release will exclude xHCI support on machines that don't need it, which +is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510), +and a mitigation is in place that makes SeaBIOS the primary payload, to prevent +effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the +first payload then the machine remains bootable even if a similar bug occurs. + +It is now the default behaviour, in the next release, that certain images +contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can +still press ESC to access the SeaBIOS boot menu if you want to directly boot +an OS from that. This, and the other change mentioned above, will guarantee +stability. GRUB is *no longer* the primary payload, on any mainboard. + +However, it was later decided to put this release in the `testing` +directory instead; it was initially designated as a stable release. + +All ROM images for the 20240504/20240510 releases have been *removed* from +rsync, but the source tarball remains in place. + +For now, you are advised to use the November 2023 release, or build from +cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known +to be reliable and is the current revision as of this time of writing) - or, +alternatively, you are advised to use the next release after 20240510. + +A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024, +fixing this and many issues; a new *true* stable release will be made available +some time in June 2024. diff --git a/site/news/canoeboot20240510.md b/site/news/canoeboot20240510.md index 333481341e5b77e9a376cd06c5c47c900de7233e..5496f23cc78d52f0bdcbc54d29e5075d134e93b3 100644 --- a/site/news/canoeboot20240510.md +++ b/site/news/canoeboot20240510.md @@ -148,3 +148,53 @@ Again, very minor release. I wasn't fully happy with the last one, specifically the last Canoeboot release, so I decided to another quick one. That is all. + +Errata +====== + +See: <https://codeberg.org/libreboot/lbmk/issues/216> + +This bug has been *fixed* in lbmk.git, and the fix will be included in +the next release, but it wasn't caught in the 20240504 release. The same +fix has been applied to Canoeboot's build system, cbmk. + +It is almost certainly guaranteed that *no* Canoeboot users were ever +affected by this, but extreme measures have been taken to ensure that it +is *entirely* guaranteed from now on. Read on to know more: + +The bug is quite serious, and it was previously decided that documentation +should be written warning about it (in docs/install/). The bug was *only* +triggered on Intel Sandybridge hardware (e.g. ThinkPad X220) and was never +reported on other boards, but there's no way to fully know; what is known +is that the offending patch that caused the bug has been *removed*; namely, +xHCI GRUB patches, which are now only provided on Haswell and Broadwell +hardware (where the bug has not occured) in *Libreboot*; in Canoeboot, the +GRUB tree with xHCI support is provided, but not currently used on any +mainboards in Canoeboot. **Therefore, we know that the bug will no longer occur.** + +The next release will exclude xHCI support on machines that don't need it, which +is *every machine that Canoeboot supports* (as of Canoeboot 20240504/20240510), +and a mitigation is in place that makes SeaBIOS the primary payload, to prevent +effective bricks in the future; the bug was in GRUB, but if SeaBIOS is the +first payload then the machine remains bootable even if a similar bug occurs. + +It is now the default behaviour, in the next release, that certain images +contain a bootorder file in CBFS, making SeaBIOS try GRUB first, but you can +still press ESC to access the SeaBIOS boot menu if you want to directly boot +an OS from that. This, and the other change mentioned above, will guarantee +stability. GRUB is *no longer* the primary payload, on any mainboard. + +However, it was later decided to put this release in the `testing` +directory instead; it was initially designated as a stable release. + +All ROM images for the 20240504/20240510 releases have been *removed* from +rsync, but the source tarball remains in place. + +For now, you are advised to use the November 2023 release, or build from +cbmk.git at revision `4f6fbfde81f5176e5892d1c00627f8f680fd3780` (which is known +to be reliable and is the current revision as of this time of writing) - or, +alternatively, you are advised to use the next release after 20240510. + +A new [audit](audit1.md) has been conducted, marked complete as of 9 June 2024, +fixing this and many issues; a new *true* stable release will be made available +some time in June 2024.