On this Embest SBC2410-II that I have been working on with Linux pre-installed by Embest, there is a serial port that functions as a Shell Command port. I would like to use this port for my application without rebuilding the kernel. Here is the original startup script in /etc/init.d/rcS:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - What I would like to do is to modify this script so that the enabling of the /dev/tty0 port as a Shell Command port is optional - the option being determined by the pressing of a pushbutton on the board during bootup which I know how to read in an application. This brings up several questions:
Is there a line in the above startup script that enables the /dev/tty0 port as a Shell Command port? Or is there a line I could insert to disable that port?
Is there a better way to share a serial port between an application and a Shell Command port? I would need a way of interrupting the boot-up to take control in case my application is bombing. Without access to that serial port, I can't replace the application. Also my application needs to run the serial port at a different baud rate than the one the Shell Command port is currently configured for.
hat are you trying to accomplish ? Use the serial port with an application (started from the command line) or with a daemon (that has no user interface ?
With an application, can't you simply use the standard in and out data streams for the serial data ?
With a daemon: if you don't start a shell (usually done by the init process, mostly by means of inittab) the serial port should be free for other use.
If you want both (switching the serial port between a shell and your application, I suppose you need to modify (inittab and/or) the startup shell scrips so that the shell starts your application after other initializations. If your application exits the shell is ready to communicate again.
hat are you trying to accomplish ? Use the serial port with an application (started from the command line) or with a daemon (that has no user interface ?
With an application, can't you simply use the standard in and out data streams for the serial data ?
With a daemon: if you don't start a shell (usually done by the init process, mostly by means of inittab) the serial port should be free for other use.
If you want both (switching the serial port between a shell and your application, I suppose you need to modify (inittab and/or) the startup shell scrips so that the shell starts your application after other initializations. If your application exits the shell is ready to communicate again.
The board has a frame buffer LCD and a matrix keypad that is scanned by my software. This provides the user interface to my application.
The board actually has 3 serial ports. Only one of them (the Shell port) is fully buffered to RS-232 voltage levels. The other two serial ports are unbuffered logic level and inverted, coming directly from the microprocessor pins. In order to use either of the unbuffered ports I have to use an additional interface chip, like the Maxim MAX232, to convert them to real RS-232. So far I have been using one of those other ports to drive a laser engraving machine using a little interface board with a MAX232 chip on it for development. But for the production model I would like to eliminate the interface board and just use the one good RS-232 port that is currently used by the Shell.
During development, I use the Shell port extensively, to load updates to my application, and to run the application. But during production my application will be launched by the startup script, and will not need the Shell port at all. So that is why I am wondering if I can use it to drive the laser engraving machine. But whatever I do, I want to maintain the ability to power-up in a mode where the Shell port does have control, because otherwise I would not be able to change my application if something goes wrong. Is there something equivalent to hitting "CNTL-C" during an MS-DOS boot-up to grab control away from an AUTOEXEC.BAT? If not, then my solution is to use a pushbutton on the board to condition the startup-script to either go directly to my application or go directly to the Shell port. I can write a tiny application that reads the pushbutton and returns and exit code to the startup script.
I don't know. Aren't these streams ASCII formatted? The laser engraving machine needs to be driven by some absolute binary data that might not come through as standard output. I already have a non-Shell port working fine using open("/dev/stty1",...). I would like to do the same with the Shell port.
What should I look for to find this initialization?
This is risky. If my application has a bug and never exits, then I will never be able to get control of the Shell port to correct it. No, my method of getting to a Shell port must work by preventing the launching of my application.
Do you have to log in on the port, or does a shell prompt just show up on it?
I don't see why you'd have to rebuild the kernel.
[...]
It doesn't look to me like that script has anything to do with what you're asking about.
No.
I don't think that script is the right place to look.
Better than what?
By "take control" you mean log in on the serial port?
If you see a login prompt, there's probably a getty being started on that port. I don't know how your system is startup works , but that is often done by a line in a file called /etc/inittab. If you don't want a getty started on that port, comment out the line in /etc/inittab that starts it.
If you do that, you're not going to be able to log in on that port.
If you'r startup system has different "boot levels", you can edit the /etc/inittab file so that the getty is started only for certain boot levels (e.g. boot level 1). Then you could set it up so that your app is only started for a different boot level (boot level 3).
Then you use your bootloader to tell the kernel what boot level you want -- that will determine whether a getty starts on the serial port or whether your application starts on the serial port.
Sharing the port seems pretty dicey. Why not just swap them? Use the first port (with the RS323 level translators on the board) to always talk to the engraver and put the shell console on one of the raw TTL ports. That way, you use your level translator dongle for development and the product ships without any excess hardware. I'm sure someone here can tell you how to do that in linux but it doesn't sound like it should be hard to map the shell to whatever port you want.
Perfect! I didn't know that was possible, but if it is, it solves everything with minimum risk. Now if I can just figure out where the serial port for the Shell is assigned...
In answer to Grant Edwards:
It just shows up.
I looked and there is no file by that name in /etc or anywhere else.
Here is what streams out of the Shell Console on power-up:................. ........................................................
VIVI version 0.1.4 ( snipped-for-privacy@localhost.localdomain) (gcc version 2.95.3 20010315 (release)) #0.1.4 Sun Jul 2 18:43:06 EDT 2006 MMU table base address = 0x33FBC000 Succeed memory mapping.
+---------------------------------------------+ | S3C2410X USB Downloader ver R1.11 SEP/03/02 |
+---------------------------------------------+ FCLK=200MHz,DMA mode USB: IN_ENDPOINT:1 OUT_ENDPOINT:3 FORMAT: +++ NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M) Could not found stored vivi parameters. Use default vivi parameters. Press Return to start the LINUX/Wince now, any other key for vivi Copy linux kernel from 0x00050000 to 0x30008000, size = 0x00100000 ... done zImage magic = 0x016f2818 Setup linux parameters at 0x30000100 linux command line is: "noinitrd root=/dev/mtdblock/0 init=/linuxrc console=ttyS0" MACH_TYPE = 193 NOW, Booting Linux...... Uncompressing Linux................................................................ done, booting the kernel. Linux version 2.4.18-rmk7-pxa1 ( snipped-for-privacy@localhost.localdomain) (gcc version 2.95.3
20010315 (release)) #1 Thu Nov 2 17:15:00 CST 2006 CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0 Machine: Samsung-SMDK2410 Security risk: creating user accessible mapping for 0x08000000 at 0xe0000000 Security risk: creating user accessible mapping for 0x10000000 at 0xe0100000 On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: noinitrd root=/dev/mtdblock/0 init=/linuxrc console=ttyS0 DEBUG: timer count 15626 Console: colour dummy device 80x30 Calibrating delay loop... 99.94 BogoMIPS Memory: 64MB = 64MB total Memory: 62360KB available (1545K code, 415K data, 144K init) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket CPU clock = 200.000 Mhz, HCLK = 100.000 Mhz, PCLK = 50.000 Mhz Initializing S3C2410 buffer pool for DMA workaround S3C2410 USB Controller Core Initialized USB Function Character Driver Interface - 0.5, (C) 2001, Extenex Corp. usbctl: Opened for usb-char usbctl: Started for usb-char Starting kswapd devfs: v1.10 (20020120) Richard Gooch ( snipped-for-privacy@atnf.csiro.au) devfs: boot_options: 0x1 ttyS%d0 at I/O 0x50000000 (irq = 52) is a S3C2410 ttyS%d1 at I/O 0x50004000 (irq = 55) is a S3C2410 ttyS%d2 at I/O 0x50008000 (irq = 58) is a S3C2410 Samsung 320x240 LCD Samsung 320x240 LCD Console: switching to colour frame buffer device 40x30 Installed S3C2410 frame buffer pty: 256 Unix98 ptys configured leds initialized touchpanel: installed S3C2410 Real Time Clock Driver v0.1 block: 128 slots per queue, batch=32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx eth0: cs8900 rev K(3.3 Volts) found at 0xd0000300 cs89x0 media RJ-45, IRQ 37 PPP generic driver version 2.4.1 Linux video capture interface: v1.00 SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices UDA1341 audio driver initialized NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M) bon0: 00000000-00030000 (00030000) 00000000 bon1: 00030000-00130000 (00100000) 00000000 bon2: 00130000-03ffc000 (03ecc000) 00000000 usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xe9000000, IRQ 26 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found port #1 suspened! port #0 alived! hub.c: 1 port detected usb.c: registered new driver usblp printer.c: v0.8:USB Printer Device Class driver usb.c: registered new driver ov511 ov511.c: v1.48a for Linux 2.4 : OV511 USB Camera Driver usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic usbserial.c: USB Serial Driver core v1.4 Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com yaffs: dev is 7936 name is "1f:00" VFS: Mounted root (yaffs filesystem). Mounted devfs on /dev Freeing init memory: 144K Using /lib/mmcsd_core.o Warning: loading mmcsd_core will taint the kernel: non-GPL license - Not GPL, Proprietary License See
formatting link
for information about tainted modules Using /lib/mmcsd_slot.o Warning: loading mmcsd_slot will taint the kerneM: non-GPL licenMe - Not GPL, PrCprietary Licens/ See
formatting link
for informationSabout tainted modules lot initialized Using /lib/mmcsd_disk.o Warning: loading mmcsd_disk will taint the kernel: non-GPL license - Not GPL, Proprietary License See
formatting link
for information about tainted modules /etc/rc.d/init.d/OILFILMs start
Please press Enter to activate this console. [30/Dec/2003:21:49:42 +0000] boa: server version Boa/0.94.13 [30/Dec/2003:21:49:42 +0000] boa: server built Feb 28 2004 at 21:47:23. [30/Dec/2003:21:49:42 +0000] boa: starting server pid=32, port 80
The "streams" (op pipes) are just streams of bytes. If the shell starts a program (and is to wait on it to finish), it hooks it's input and output stream to the input and output stream of the program it starts. The origin / destination of theses streams can be (e.g.) serial ports, TCP/IP ports ("Telnet"), files or other processes (piping).
Thanks. That's good to know. But another reason for totally switching off the Shell console, or at least switching to a different serial port, is that on power up, the stream of reporting data that comes out of that port during boot-up may do bad things to the laser engraver machine that is connected to that port. I'm really looking now for a way to change the configuration so that the Shell Console starts out attached to /dev/ttyS1 instead of /dev/ttyS0
I just realized that I obviously can't totally eliminate any boot-up reporting from the /dev/ttyS0 port and switch everything to the /dev/ttyS1 port without rebuilding the VIVI boot loader. So the solution is probably more than just a configuration file change. Like it or not, I'm going to have to get out the JTAG interface and learn how to re-flash the boot loader. I did find somewhere on the Internet an indication that the VIVI boot loader passes to the kernel which port it should use for the Shell Console.
You should be able to define Kernel parameters in the configuration of the boot loader. here it should be possible to define the tty port that is use for Kernel startup output.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.