Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: bitpusher on December 04, 2013, 11:50:33 AM
-
I need to compile the kernel (because of more than 4 UARTS in my machine and to use UIO for proprietary hardware) in TinyCore 5.0.1.
However I already found some traps before I even could type make.
Found the how-to at http://wiki.tinycorelinux.net/wiki:custom_kernel (http://wiki.tinycorelinux.net/wiki:custom_kernel), but it dose not really describe the files found at http://tinycorelinux.net/5.x/x86/release/src/kernel/ (http://tinycorelinux.net/5.x/x86/release/src/kernel/) - "patched" seems quite obvious, but maybe the how-to could benefit from a rework?
Next I downloaded linux-3.8.13-patched.txz and tried to unpack with tar - which unpacks some files but stops with
"short read" - in spite of the fact that the txz is intact.
Tried it with tar.tcz (1.26) from the apps installed - stopped at a different point with the same error message...
Tried it with linux-3.12.2.tar.xz from kernel.org - same problem.
When I finally tried to unpack linux-3.12.2.tar.xz with xz it seemed to work - at least it finished without error.
However when I used xz on linux-3.8.13-patched.txz it left me with a tar-file. On this tar-file the tar from TinyCore seemed to work OK then.
Am I overlooking the obvious or doing something wrong here?
BTW: I found some older discussions on a bug of the xz embedded in tiny core causing a "short read" error - on the other hand xz seemed to finally work for me?
-
try
tar xf linux-3.8.13-patched.txz
:)
-
No need to compile.
Use the boot code 8250.nr_uarts=X where X is the number of uarts you have.
-
try
tar xf linux-3.8.13-patched.txz
As to be expected, I can not reproduce the "short read" today!
However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.
But when I tried again today:
tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$
Different complain from tar, but does not succeed either.
Now if I do the same in a "real" directory on sda1:
tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$
So the problem seems to be filesystem related?
-
No need to compile.
Use the boot code 8250.nr_uarts=X where X is the number of uarts you have.
I have already tried
8250.nr_uarts=5.
While this gives me /dev/ttyS4 in the filesystem:
tc@box:~$ ls /dev/ttyS* -l
crw-rw---- 1 root staff 4, 64 Dez 3 08:31 /dev/ttyS0
crw-rw---- 1 root staff 4, 65 Dez 3 08:31 /dev/ttyS1
crw-rw---- 1 root staff 4, 66 Dez 3 08:31 /dev/ttyS2
crw-rw---- 1 root staff 4, 67 Dez 3 08:31 /dev/ttyS3
crw-rw---- 1 root staff 4, 68 Dez 3 08:31 /dev/ttyS4
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
The problems start when I try to configure ttyS4.
Setting the address and IRQ works OK, but the UART is not auto-detected:
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x03a8, IRQ: 2
I could live with setting the UART-type manually, but as soon as I set it with setserial I get:
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 10
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 11
/dev/ttyS4: Device or resource busy
Searching the net gave me the impression that at some point CONFIG_SERIAL_8250_RUNTIME_UARTS was set to 4 at some point, while it was 32 before.
From what I understood I will have to change CONFIG_SERIAL_8250_RUNTIME_UARTS to make more than 4 UARTS work.
-
CONFIG_SERIAL_8250_RUNTIME_UARTS kernel help:
Set this to the maximum number of serial ports you want the kernel to register at boot time. This can be overridden with the module parameter "nr_uarts", or boot-time parameter 8250.nr_uarts
-
CONFIG_SERIAL_8250_RUNTIME_UARTS kernel help:
Set this to the maximum number of serial ports you want the kernel to register at boot time. This can be overridden with the module parameter "nr_uarts", or boot-time parameter 8250.nr_uarts
I wish I could agree with you, but from the same file:
config SERIAL_8250_NR_UARTS
int "Maximum number of 8250/16550 serial ports"
depends on SERIAL_8250
default "4"
help
Set this to the number of serial ports you want the driver
to support. This includes any ports discovered via ACPI or
PCI enumeration and any ports that may be added at run-time
via hot-plug, or any ISA multi-port serial cards.
And there is no overriding boot-time paramter mentioned.
Also this matches my observation that I can get all 5 physical UARTS to work when I assign any of them to ttyS0 ... ttyS3 - but can't get any physical UART to work as ttyS4.
-
OK, after changing to a "real" directory (see above) I advanced to step 6 of http://wiki.tinycorelinux.net/wiki:custom_kernel (http://wiki.tinycorelinux.net/wiki:custom_kernel).
However this is what I get:
tc@box:/mnt/sda1/dokument/gcc/linux-3.8.13-patched$ make oldconfig
HOSTCC scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:157:0,
from /usr/include/limits.h:145,
from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/limits.h:169,
from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/syslimits.h:7,
from /tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/include-fixed/limits.h:34,
from scripts/basic/fixdep.c:114:
/usr/include/bits/local_lim.h:39:26: fatal error: linux/limits.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2
Thus make is looking for linux/limits.h but can't find it.
There are two limits.h in the source tree:
tc@box:/mnt/sda1/dokument/gcc/linux-3.8.13-patched$ find -iname limits.h
./include/uapi/linux/limits.h
./arch/arm/include/asm/limits.h
but obviously not in the directory where make is looking for it?
-
$ grep SERIAL_8250_NR_UARTS config-3.8.13-tinycore
CONFIG_SERIAL_8250_NR_UARTS=32
-
try
tar xf linux-3.8.13-patched.txz
As to be expected, I can not reproduce the "short read" today!
However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.
But when I tried again today:
tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$
Different complain from tar, but does not succeed either.
Now if I do the same in a "real" directory on sda1:
tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$
So the problem seems to be filesystem related?
Out of space?
-
try
tar xf linux-3.8.13-patched.txz
As to be expected, I can not reproduce the "short read" today!
However I am pretty sure I used tar xvf linux-3.8.13-patched.txz yesterday.
But when I tried again today:
tc@box:~/dokument/gcc$ tar xf linux-3.8.13-patched.txz
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
tc@box:~/dokument/gcc$
Different complain from tar, but does not succeed either.
Now if I do the same in a "real" directory on sda1:
tc@box:/mnt/sda1/dokument/gcc$ tar xf linux-3.8.13-patched.tar
tc@box:/mnt/sda1/dokument/gcc$
So the problem seems to be filesystem related?
Out of space?
I thought of this too after it worked with the "real" directory, but it seems like there still is some space left:
tc@box:~/dokument/gcc$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
rootfs 54K 48K 6,4K 89% /
-
"df -i" shows inodes, not space.
-
"df -i" shows inodes, not space.
Ah, yes, exactly. Note to self: Read what you pasted before posting.
tc@box:~/dokument/gcc$ df
Filesystem Size Used Avail Use% Mounted on
rootfs 394M 297M 97M 76% /
tc@box:~/dokument/gcc$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
rootfs 54K 48K 6,4K 89% /
-
tmpfs is also limited by currently free shared mem (RAM + swapspace).
-
Just checked, my kernel build dir including modules after compilation is 1.8 GByte. If you do not have 2 GB free file system space, no way to do that.
-
$ grep SERIAL_8250_NR_UARTS config-3.8.13-tinycore
CONFIG_SERIAL_8250_NR_UARTS=32
I see. Then you think my problem with using /dev/ttyS4 is caused by something different?
(If I could get the kernel compiling business going I would just try setting CONFIG_SERIAL_8250_RUNTIME_UARTS=5 in the config file and report back, but unfortunately I'm still stuck with make oldconfig).
-
tmpfs is also limited by currently free shared mem (RAM + swapspace).
[Linux-Newbie-Question]
Thus tar is using space in the tmpfs while working and it could be running out of space while working but I would not see this with df after tar terminated with an error?
[/Linux-Newbie-Question]
(Just asking because after tar terminated the usage of tmpfs is just like 1% - both inodes and space)
-
Just checked, my kernel build dir including modules after compilation is 1.8 GByte. If you do not have 2 GB free file system space, no way to do that.
I now changed to sda1 which is a (still almost empty) 32GB CF-Card, so this should not be a problem.
-
OK, so here is where I am at the moment:
Unpacking the sources works when I use a directory on sda1 instead of a directory in /home/.
The how-to http://wiki.tinycorelinux.net/wiki:custom_kernel (http://wiki.tinycorelinux.net/wiki:custom_kernel) tells me to:
"Move the kernel config file from the standard TC kernel into the same directory and rename it to ”.config”"
The "kernel config file from the standard TC kernel" is config-3.8.13-tinycore from http://tinycorelinux.net/5.x/x86/release/src/kernel/, right?
So I copied and renamed it.
However make oldconfig can't find linux/limits.h.
Some searching on the net brought up that the symbolic link to my sources in /usr/... might be missing (what I found was not tiny core related however) - and there's also nothing about this in the how-to?
-
tmpfs is also limited by currently free shared mem (RAM + swapspace).
[Linux-Newbie-Question]
Thus tar is using space in the tmpfs while working and it could be running out of space while working but I would not see this with df after tar terminated with an error?
[/Linux-Newbie-Question]
(Just asking because after tar terminated the usage of tmpfs is just like 1% - both inodes and space)
Sure the source code would reveal all the gory details, but I couldn't see any practical relevance in that question as it seems to be pretty obvious what is happening.
-
Just checked, my kernel build dir including modules after compilation is 1.8 GByte. If you do not have 2 GB free file system space, no way to do that.
I now changed to sda1 which is a (still almost empty) 32GB CF-Card, so this should not be a problem.
tmpfs could be resized on the fly, but of course that would require sufficient swapspace.
-
Hi bitpusher
Maro did a very good writeup of the kernel config relating to serial ports here:
http://forum.tinycorelinux.net/index.php/topic,12632.msg69097.html#msg69097
-
I have already tried
8250.nr_uarts=5.
While this gives me /dev/ttyS4 in the filesystem:
tc@box:~$ ls /dev/ttyS* -l
crw-rw---- 1 root staff 4, 64 Dez 3 08:31 /dev/ttyS0
crw-rw---- 1 root staff 4, 65 Dez 3 08:31 /dev/ttyS1
crw-rw---- 1 root staff 4, 66 Dez 3 08:31 /dev/ttyS2
crw-rw---- 1 root staff 4, 67 Dez 3 08:31 /dev/ttyS3
crw-rw---- 1 root staff 4, 68 Dez 3 08:31 /dev/ttyS4
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
The problems start when I try to configure ttyS4.
Setting the address and IRQ works OK, but the UART is not auto-detected:
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x03a8, IRQ: 2
I could live with setting the UART-type manually, but as soon as I set it with setserial I get:
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 10
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 11
/dev/ttyS4: Device or resource busy
Perhaps IRQ's play a rule??
http://cateee.net/lkddb/web-lkddb/SERIAL_8250_SHARE_IRQ.html
-
I stand corrected.
Most likely I mixed in some observations with Puppy-Linux.
My problem with having 5 UARTS usable was definitely not with CONFIG_SERIAL_8250_RUNTIME_UARTS or CONFIG_SERIAL_8250_NR_UARTS in the Kernel, and yes, boot code 8250.nr_uarts=5 does the trick.
@Rich: Thanks for pointing to the other thread. However the issue with CONFIG_SERIAL_8250_NR_UARTS=4 seems to be fixed, both the config files for 3.8.10 and 3.8.13 have CONFIG_SERIAL_8250_NR_UARTS=32, making boot code 8250.nr_uarts=n usable for up to 32 UARTS.
@tinypoodle: Seems your shot for the interrupt was in the right direction, however I am not trying to share interrupts, see below.
Summary:
Problem was using IRQ 9 for ttyS4 while the interrupt had already been grabbed by ACPI:
tc@box:~$ cat /proc/interrupts
CPU0
0: 75839 XT-PIC-XT-PIC timer
1: 1783 XT-PIC-XT-PIC i8042
2: 0 XT-PIC-XT-PIC cascade
4: 10 XT-PIC-XT-PIC
6: 2 XT-PIC-XT-PIC floppy
7: 693 XT-PIC-XT-PIC ehci_hcd:usb1, ohci_hcd:usb2, eth0
8: 0 XT-PIC-XT-PIC rtc0
9: 0 XT-PIC-XT-PIC acpi
12: 10189 XT-PIC-XT-PIC i8042
14: 1666 XT-PIC-XT-PIC pata_amd
[...]
After adding boot code acpi=off (my board doesn't have ACPI anyway) IRQ 9 was no longer in use, and after boot I get this (IRQs for ttyS2 and ttyS3 are not correctly detected, ttyS4 is unsurprisingly not detected at all):
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
ttyS2 and ttyS3 are easily fixed:
tc@box:~$ sudo setserial /dev/ttyS2 irq 10
tc@box:~$ sudo setserial /dev/ttyS3 irq 11
ttyS4 can be configured by setting uart and baud_base manually (baud_base is necessary because only ttyS0-3 get this as a default):
tc@box:~$ sudo setserial /dev/ttyS4 port 0x03a8 irq 9 uart 16550a baud_base 115200
=> And now I have 5 working UARTs:
tc@box:~$ setserial -g /dev/ttyS*
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 10
/dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 11
/dev/ttyS4, UART: 16550A, Port: 0x03a8, IRQ: 2
However I still need to get the kernel compiling business going because of UIO.
-
With your compiling error, it seems you didn't install a complete compiling environment. Please install compiletc.tcz and try again.
Kernel builds also need perl5, bash, and (if you use menuconfig) ncurses and ncurses-dev.
-
With your compiling error, it seems you didn't install a complete compiling environment. Please install compiletc.tcz and try again.
Kernel builds also need perl5, bash, and (if you use menuconfig) ncurses and ncurses-dev.
Thanks for the hint.
So far I installed:
• ncurses
• ncurses-dev
• perl5
• bash
• compiletc
then there were still "kernel headers" missing.
I found and installed
• linux-3.8.3_api_headers.tcz
this fixed the error message, but I wonder if using the headers from/for 3.8.3 with 3.8.13 might cause other problems?
This brought me up to step 10. of http://wiki.tinycorelinux.net/wiki:custom_kernel (http://wiki.tinycorelinux.net/wiki:custom_kernel)
I now have the new kernel, residing in arch/x86/boot/bzImage and the modules in lib/modules/kernel_version
Copying the kernel to /mnt/sda1/tce/boot and creating a boot-menu in extlinux.conf was easy enough - but how I am supposed to get my newly compiled modules into core.gz file? I understand that this is basically a filesystem packed into one file, but what is the most simple way to create it from my modules path without having to understand all the internals?
-
Read WIKI on remastering, how to unpack, modify and repack initrd:
zcat <initrd> | cpio -i -d -H newc
and
find | cpio -o -H newc | gzip > <newinitrd>
But if you don't want to understand what are you doing be prepared to fail and to waste more time than would spent to understand what are you doing.
As V. I. Lenin told:
Learn, learn and once again, learn!
:)
-
So far I installed:
• ncurses
• ncurses-dev
• perl5
• bash
• compiletc
then there were still "kernel headers" missing.
linux-3.8.3_api_headers is one of the deps of compiletc, so it should have been loaded
-
Read WIKI on remastering, how to unpack, modify and repack initrd:
Good advice indeed. I remember briefly looking at this wiki but skipping it as on the top it seems to be focusing on CDs and isos - and my system doesn't even have an optical drive... ::)
Therefore I missed the section down the page:
zcat <initrd> | cpio -i -d -H newc
and
find | cpio -o -H newc | gzip > <newinitrd>
which was what I was looking for.
But if you don't want to understand what are you doing be prepared to fail and to waste more time than would spent to understand what are you doing.
I think as usually it is a question of finding the right balance.
As V. I. Lenin told: [...]
Yeah, but this guy also said and wrote some other stuff which in hte end did not always turned out in favour of the people affected... :)
Anyway, thanks for the pointers, at least I was able to compile 3.8.13 (without any modifications by me - just as a prove of concept), pack up the modules and boot the thing - and everything seems normal so far.