special kernel parameter / how to?

[wendeloo]

Hi all,

I tried to use tc on a hardware platform, that provides 6 serial ports. I wondered, that I always see 4 serial ports. Hm? Searching something in the inet and found a kernel parameter named "CONFIG_SERIAL_8250_EXTENDED" that will help to have more than 4 serial ports. So far very nice! But how do I get a kernel created with this parameter (by default it seams to be dactivated)? Must I compile a kernel by myself? And if yes: how?!

Many Thanks

[Rich]

Hi wendeloo
Looking at the kernel config file, it appears as though you are limited to 4 ports. There is something you can try, but
it's a long shot. There is a boot code called  nr_uarts. You could try   nr_uarts=6   and see if the remaining ports show up.

[gerald_clark]

You could also try adding the boot code 8250.nr_uarts=8

[Rich]

Hi gerald_clark
Where did you find that syntax?

[gerald_clark]

I found that in the kernel docs for kernel 2.6,
and use it for an add-on 4 port serial card under CentOS 5.7.
It may or may not have changed for kernel 3.

[wendeloo]

Hi Rich & Gerald,

thank you for the help. Unfortunately the kernel boot parameters you provide don't work (with or without "8250."). I used them in the "menu.lst" in "grub" directory on the end of the "kernel" line (was that right?).

To get more precise I have to complete some informations about my environment: I tested with TC 3.7 (that has kernel 2.6.33-3). Are these parameters valid for this kernel? Or are the chances better with a newer version of TC?

Hope there are more helpful informations.

[Rich]

Hi wendeloo
The  nr_uarts  code is listed for both 2.6.33.3 and 3.2, so it should be valid for TC3.x and TC4.x. Based on what
gerald_clark said, his code should be valid under TC3.x. There still the possibility that the kernel config is the
overriding factor here.
Yes, the kernel line was the correct place for the boot code.

[wendeloo]

Hi Rich,
thank you very much. Now I see clear what is NOT working for me (the parameter is not working), but what is the way to become more than 4 serial ports working. Do I need a special compilation of the kernel with "CONFIG_SERIAL_8250_EXTENDED" set to "Y"? And if so, what do I need and how it will be done? Are there some How-to-Recompile-the-Tinycore-Kernel documents? And where to find?

I'm very frustrated about this. I never mentioned that a system kernel coult have a limit of serial devices of such a  low level. However, I still hope that someone has an idea that help.

[Rich]

Hi wendeloo
According to  http://www.tldp.org/HOWTO/Serial-HOWTO-15.html#ss15.3  you should be able to override the
number of ports using one of the two boot codes, depending on whether support is compiled in or supplied
as a module. Try the boot codes again with the value 6. Then check the  /dev  directory. If it worked, you
should find  ttyS0  through  ttyS5  listed.

   [EDIT]: Fixed link.

[wendeloo]

Hi Rich,
as described earlier in this thread, the parameters (tried both; with and without "8250.") do not change it as tought > the number of my ttyS's is constant on 4. I also tried different variances of the value (5..16) but everytime the same result: ttyS0..ttyS3 and nothing more.

Has somebody tried this with other results?

[Rich]

Hi wendeloo
Where are the ports located? Are they all built into the motherboard or are some on a separate card?
If some are on a separate card, you may just be missing a driver.

[maro]

Well, this subject looked like another one for me to take a bit a closer look into the kernel sources. What I found is that both kernel configuration parameters of 'CONFIG_SERIAL_8250_NR_UARTS' and 'CONFIG_SERIAL_8250_RUNTIME_UARTS' need to be considered. As it stands the TC kernel (i.e. 3.0.21 in it's most recent incarnation) uses a value of 4 for each of them.

Reading the respective source file (i.e. 'drivers/tty/serial/8250.c'), comparison with some other distributions and some quick tests with a self-compiled kernel allow me now to summarise:

• The maximum number of supported serial interfaces is set by CONFIG_SERIAL_8250_NR_UARTS.
• The number of actually created '/dev/ttyS*' devices is set by CONFIG_SERIAL_8250_RUNTIME_UARTS. This default value can be overwritten by the 8250.nr_uarts=... boot code (but only up to the maximum defined by 'CONFIG_SERIAL_8250_NR_UARTS').
  This number (e.g. when using '8250.nr_uarts=2') gets reported as '... 2 ports, ...' in the kernel log (which can be shown via dmesg | grep '^Serial:').
  The device file creation takes place when /sbin/udevadm trigger --action=add is executed during the boot process (in '/etc/init.d/tc-config' after /sbin/udevd --daemon).This can be studied in more detail when one circumvents the "normal" boot process via the 'rdinit=/bin/sh' boot code.
• Somewhat independent from the number of '/dev/ttyS*' devices is the number of serial devices actually found and reported during the kernel boot phase (which can be shown via dmesg | grep '^serial8250:').
  Their number is capped by 'CONFIG_SERIAL_8250_RUNTIME_UARTS' (or the value supplied by '8250.nr_uarts'), but can also be lower than that value. This can lead to a situation where more '/dev/ttyS*' device files are been created than actual serial devices are available.
  In the reverse case (i.e. more actual devices available then permitted for the kernel to be registered) no way was found to exceed the limit set by 'CONFIG_SERIAL_8250_RUNTIME_UARTS' or '8250.nr_uarts' (which are again capped by 'CONFIG_SERIAL_8250_NR_UARTS').

It is therefore my view that the OP requires a differently configured kernel (e.g. via sed -i '/^CONFIG_SERIAL_8250_NR_UARTS=/ s#=4$#=8#' config-3.0.21-tinycore) to have any chance to use more than the current limit of four serial devices.

Some more notes:

• Most of my tests were done using QEMU (v0.11.1 with KQEMU on a WinXP host) as this allowed me to simulate up to four serial devices (e.g. by using the '... -serial file:s0.log -serial file:s1.log -serial file:s2.log -serial file:s3.log ...' parameters).
• Our "bloated cousins" are using fairly large values for 'CONFIG_SERIAL_8250_NR_UARTS' and 'CONFIG_SERIAL_8250_RUNTIME_UARTS'. For example the most recent Ubunutu (and Mint) releases are using 48 and 32 respectively, which leads to the IMHO ridiculous situation to have '/dev/ttyS0' up to '/dev/ttyS31' after system start and on "newish hardware" not a single serial device actually being registered. Fedora Core seems to be more reasonable as they are using values of 32 and 4 respectively.
• Considering that TC 4.4rc1 has just come out with a newly build kernel it could be a case of having "missed the boat" by only a few days (regarding a change of that kernel). I've therefore done a targeted kernel test build where I changed '.config' after a 'make all' and did another 'make all'. It appeared to me that none of the modules got changed during the second run (as I had hoped to see), so maybe now would still be a chance to "crank up" the value of 'CONFIG_SERIAL_8250_NR_UARTS' for the "offical" kernel and only change 'vmlinux', but without the need to touch any of the kernel module extensions.

[curaga]

I wouldn't risk it at this point. Added to the todo list for the next build.

[Astronomy]

I'm attempting to gain more than 4 serial ports as well.  Many of the Retail POS Environment PC's that I deal with use 10+ serial ports if not more (every device uses one, the magnetic-stripe reader, cash drawer, Receipt Printer, barcode scanner, keyboards (when they're not standard), touch screen, etc).  I'm loving tinycore but can't seem to recompile my kernel to allow me access to comm 5 and 6 (many IBM touchscreen use these and they're all that matter to me) as this thread suggests.

Thank you all for the continued work on this fine project!

[Rich]

Hi Astronomy
Did you read maros post? If you edit the kernel config file and use the following values for example:

Code: [Select]

CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=8Recompiling should now yield a kernel that can support 16 comm ports and sets up 8 devices when it boots.