Libreboot & TCL

[GNUser]

Just a quick note: This weekend I flashed Libreboot onto a new (to me) X200 Thinkpad. I then transferred hard drive with my personal data and frugal install of TC Pure64 10.1 from my prior laptop to the X200. TCL worked perfectly on the new laptop, no tweaks of any kind were required!

(The only apparent compatibility issue between TCL and Libreboot that I've ever encounted is that Xvesa doesn't work. However, Xfbdev and Xorg work perfectly.)

If anyone here ever needs help flashing Libreboot or has any questions about my experience, just let me know. I'll be happy to share and help in whatever way I can.

P.S. Learning to use TCL has made my computing so much simpler and more enjoyable. Thank you, curaga, juanito, Rich, Robert Shingledecker, and friends. You have created something quite special.

[Rich]

Hi GNUser

... (The only apparent compatibility issue between TCL and Libreboot that I've ever encounted is that Xvesa doesn't work. However, Xfbdev and Xorg work perfectly.) ...

Xvesa is 32 bit only, see:
http://forum.tinycorelinux.net/index.php/topic,19587.msg121287.html#msg121287
http://forum.tinycorelinux.net/index.php/topic,16299.msg97256.html#msg97256

[GNUser]

Thanks, Rich. I know. When I first started using TCL on a Libreboot machine, I was using TCL 32-bit and graphics wouldn't work with Xvesa. This is not an issue anymore, I just mentioned it for completion's sake because it is the only compatibility issue I'm aware of.

Again, only for completion's sake: There are some totally benign errors during boot. However, these are not unique to TCL (they show up when booting other distros). See here for an example: http://forum.tinycorelinux.net/index.php/topic,23333.0.html (note the *ERROR* CPU pipe A FIFO underrun in reply #4).

[Rich]

Hi GNUser
Ah, but your original post only mentioned:

... frugal install of TC Pure64 10.1 ...

I saw no mention of 32 bit in there. Check and mate.

[GNUser]

Mea culpa.
My first post would have been better had I mentioned no compatibility issues with either TCL 64-bit or TCL 32-bit, except for Xvesa in 32-bit

[curaga]

Yes, the VESA bios is proprietary and not included in libreboot I believe.

[GNUser]

Thank you, curaga. I didn't realize Xvesa required proprietary code in BIOS. If that's the case, no wonder it doesn't work with Libreboot. Libreboot does not include any proprietary code.

While on the topic, is there proprietary code anywhere in the base system? How about in xf86-video-intel.tcz?

[GNUser]

It seems xf86-video-intel is free software: https://www.x.org/releases/X11R7.5/doc/intel.html

It would be nice to know about base system. BusyBox and the Linux kernel are free software, of course, but I know there is more to the base system than that (e.g., TCL-specific shell scripts). Are there any components in base system that are not free software?

P.S. The question is not political, merely informational. My goal with TCL is to build a free software-only system, but I realize that other users' goals might be different.

[curaga]

Well, your laptop is Intel graphics; normally the vesa bios is on the graphics card's rom.

No, all code in base is open source, and no firmware is included in the base. Extensions may have binary-only files and firmware. I don't know the specifics for Intel drivers, but I think they don't require firmware currently.

Our scripts are GPL-licensed.

[GNUser]

Many thanks for the helpful information

[GNUser]

If you wish to run linux-libre instead of the default kernel (but want the convenience of using the kernel modules that are provided with your version of TCL), here are the steps:

-> go here http://linux-libre.fsfla.org/pub/linux-libre/releases and download the linux-libre source code tarball (.tar.bz2) that corresponds to desired kernel version (for TCL11 you want version 5.4.3)
-> extract the tarball (e.g., now $HOME/Downloads/linux-5.4.3 exists)
-> change EXTRAVERSION at top of $HOME/Downloads/linux-5.4.3/Makefile from -gnu to nothing, so that it looks like this: EXTRAVERSION=
-> go to http://tinycorelinux.net/11.x/x86/release/src/kernel/ and download the TCL-specific patches and config file to ~/Downloads
-> copy the downloaded TCL config file to ~/Downloads/linux-5.4.3/.config
-> do these steps in a terminal:

Code: [Select]

$ tce-load -i compiletc perl5 bash ncursesw-dev bc glibc_apps elfutils-dev
$ cd  ~/Downloads/linux-5.4.3
$ patch -p1 < ../advdef.patch # repeat for each TCL-specific patch
$ make oldconfig
$ make menuconfig # edit the configuration via the menu (if desired)
$ make bzImage
-> once compilation is done (it takes ~15 minutes on my ancient X200 laptop) you'll have bzImage/vmlinuz
-> in your boot partition, rename vmlinuz to vmlinuz-stock
-> rename the vmlinuz you just created to vmlinuz-libre and copy it to your boot partition
-> in your boot partition: $ ln -s vmlinuz-libre vmlinuz
-> reboot

Now you're running linux-libre, which has no blobs and will not load proprietary modules

P.S. If all your hardware is libre-friendly, it shouldn't make much difference whether you run stock kernel or linux-libre. This is mostly for convenience since if I'm running linux-libre and piece of hardware is working, I immediately know that the hardware is using libre firmware--no need for me to look into it.

[Rich]

Hi GNUser

If you wish to run linux-libre instead of the default kernel (but want the convenience of using the kernel modules that are provided with your version of TCL),
 ----- SNIP -----

$ make menuconfig # edit the configuration via the menu (if desired)

 ----- SNIP -----

Some configuration changes can affect the usability of certain modules requiring them to be rebuilt. I found this out when I selected:

Code: [Select]

CONFIG_X86_INTEL_LPSS=yThis forced the module  iosf_mbi  to be built into the kernel resulting in modprobe errors. A more detailed explanation is here:
http://forum.tinycorelinux.net/index.php/topic,23272.msg147325.html#msg147325

Another thing to be aware of is the menu config utility does not have  undo  capability. Using the above as an example:
1. iosf_mbi  is built as a module.
2. You select  CONFIG_X86_INTEL_LPSS=y
3. The menu config utility changes  CONFIG_IOSF_MBI=m  to  CONFIG_IOSF_MBI=y  forcing it to be built into the kernel.
4. You change  CONFIG_X86_INTEL_LPSS=y  back to  CONFIG_X86_INTEL_LPSS is not set.
5. The menu config utility does not change  CONFIG_IOSF_MBI=y  back to  CONFIG_IOSF_MBI=m.  You have to find that setting and fix it.

You can select  Help  for an option prior to selecting it to see what it effects. It's listed on the line labeled  Selects:.


    [EDIT]: Struck out my inaccuracies.  Rich

[GNUser]

Rich,
I did not make any custom changes to the configuration, so that step was untested. Thank you for pointing out the pitfalls.

I've been running linux-libre compiled with the default TCL configuration (I made no changes via the menu) and have found it to be a drop-in replacement for the default kernel. No remastering of corepure64.gz was needed, and I can use all the module-containing extensions (e.g., ipv6-netfilter-5.4.3-tinycore64.tcz) without any issues.

[GNUser]

One last detail, for completion's sake:

I've noticed that the number of benign/cosmetic Libreboot-related boot-time warnings increased a bit between linux version 4.19.10 (used in tc-10.x) and 5.4.3 (used in tc-11.x). This affects stock linux and linux-libre equally and is due to upstream changes in the kernel (i.e., it has nothing to do with TCL specifically).

To keep the kernel completely quiet during boot, just add the loglevel=0 kernel boot parameter (this is even stronger than quiet, which if I'm not mistaken is equivalent to loglevel=4). Now the kernel can only display emergency-level errors so it won't show anything unless your computer is having a meltdown. Now all I see during boot are the beautiful colorful messages from TCL

[Rich]

I did not make any custom changes to the configuration, so that step was untested. Thank you for pointing out the pitfalls. ...

I do have to make 1 correction:

... Another thing to be aware of is the menu config utility does not have  undo  capability. ...

This was behavior I thought I remembered from many years ago. Maybe I was mistaken. I just tried the example I posted and
IOSF_MBI  reverted back to  m  when I deselected  X86_INTEL_LPSS.  The undo worked even if I did a save between selecting
and deselecting  X86_INTEL_LPSS.