RE: ELKS for ARM
Hi, I've been doing the Psion stuff, and also have an interest in an ARM port. Particularly with the embedded versions that contain a whole load of peripherals (serial/dram controllers/LCD etc. etc.). What platform/processor are you starting with? and (the big question) how far have you got? I'm assuming that you're using patched gcc/binutils, am I right? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
RE: Call for a README file - ELKSibo
I've already written a basic 'install' procedure for the Psion which is on my web site. This covers how to program a SSD (given the image) and how to install the Kernel. I don't feel I know enough about the PC stuff, but am happy to contribute more on the Psion specific stuff. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
RE: Elkscmd, building very small filesystems....
found it.. thanks to a local Guru. when doing mkfs.minix I wasn't specify an inode count, it was guess according to the size of the disk. This droped from 120 inodes (at 360K) to 42 (at 128K). adding the '-i 180' parameter solved the problem. Simon Wood
Elkscmd, building very small filesystems....
Hi all, I've got a problem with 'elkcmd' and building a small (128K) root image. I've chopped down the list of things included so that it is less than 128K. This was done whilst the disk image is 360K. When I adjust the image size down to the 128K the 'MAKEDEV' script falls over even though there is (appears) to be plenty of space. It is called after the disk structure is created, but before the executables are copied (which account for the most usage). Here's a snippet of the errors with MAKDEV (run by hand) ... leper:/mnt/dev # ./MAKEDEV /bin/mknod: bdb: No space left on device /bin/mknod: bdb1: No space left on device /bin/mknod: bdb2: No space left on device etc, etc, leper:/mnt/dev # df -h FilesystemSize Used Avail Capacity Mounted on /dev/hda3 309M 291M 1.7M 99% / /dev/hda1 1.2G 779M 420M 65% /dos /dev/hda4 343M 277M48M 85% /opt /opt/src/elkscmd/root 122K 31K91K 25% /mnt leper:/mnt/dev # Anyone got any bright ideas what's happening and how to solve it?? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Alistair Riddoch [SMTP:[EMAIL PROTECTED]] Sent: Monday, January 10, 2000 7:10 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: ELKS 0.0.82 has been released. ELKS 0.0.82 has been released and is available from the following locations:- ftp://linux.mit.edu/pub/ELKS/kernel/elks-0.0.82/elks-0.0.82.tar.gz ftp://ftp.ecs.soton.ac.uk/pub/elks/elks-0.0.82/elks-0.0.82.tar.gz The release directory contains the following files:- elks-0.0.82.tar.gz - Compressed kernel source. elks-0.0.82.diff.gz - Diff against elks-0.0.81. images.zip - Pre-compiled disk images. System.map.gz - System map of pre-compiled kernel. This is the first release to include support for the SIBO architecture used in Psion Series 3 organisers, and related machines. This code has been developed by Simon Wood. For full details on how to boot ELKS on a SIBO machine, see his webpage at http://www.mungewell.ndirect.co.uk/linux/index.htm. This code is extremely alpha at this stage, but is moving very fast. Please be aware that attempting to run this code will erase all the data stored on the machine. This is guaranteed, not just a risk. This release also includes updated interrupt support submitted by David Murn, some code optimisations to the filesystem code, and some bug fixes. Please submit bug reports to the list, or to the bug tracking system at http://www.elks.ecs.soton.ac.uk/bugs/. Over the next few weeks I would like to put a priority on getting the SIBO architecture support to the same level of stability as the rest of the kernel. Al
Common letters in the Alphabet.
For ELKSibo I have had to include a font bit map (as I have to draw each character to the LCD), this only has a few of the 255 ASCII codes and is the form: ASCII Value, data, data, data, etc, The renderer compares the first byte with it's desired character and moves to the next character should they not match. I would like to sequence the data so that the most common characters are near the start of the list and therefore speed up the display driver (believe me every little bit helps). Does anyone have letter probability table I could use??? (or any idea how to generate one) Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
ELKSibo Runlog.
I've got the ELKSibo stuff (that Alistair merged into /arch/i86) building and running up to the point of loading and running init (or shell). But I don't really understand how the ELKS system actually works. Here is a Runlog (with all the debug printing turned on), can anyone give me some pointers as to what might be happening??? The machine crashes (stops doing anything) at the end of this lot. runlog.txt Alistair:- I know you're busy until the Christmas break, I'll tar up what I've done and stick it on my web site. Hopefully I'll be able to get a few days hard coding over the break. Others:- If anyone has a series 3 (a, c, mx or siena - I want this to run on a seina) and want to hammer it over Christmas please email me at home ([EMAIL PROTECTED]) and I'll try to explain what I've done with the code Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Timer enabled... Console: Direct Dumb (3 virtual consoles) Calibrating delay loop.. ok - 0.65 BogoMips Psion Series 3a machine, CPU 0K base, CPUID `NEC V30'. ELKS kernel (0 text + 0 data + 0 bss) Kernel text at 4F0:, data at 14F0: 65452 K of memory for user processes. SSD driver (Major = 3) ELKS version 0.0.81-pre1 mapping buffer 0 (0) BUFMAP: Buffer 0 (block 1) mapped into L1 slot 0. unmapping buffer 0 mapping buffer 0 (0) mapping buffer 1 (0) BUFMAP: Buffer 1 (block 65538) mapped into L1 slot 1. unmapping buffer 1 mapping buffer 2 (0) BUFMAP: Buffer 2 (block 131075) mapped into L1 slot 2. unmapping buffer 2 iget called(8B00, 1, 0) iget: getting an empty inode... iget: got one... (8E44)! iget: Reading inode mapping buffer 3 (0) BUFMAP: Buffer 3 (block 196612) mapped into L1 slot 3. unmapping buffer 3 mapping buffer 3 (0) unmapping buffer 3 iget: Read it unmapping buffer 0 VFS: Mounted root (minix filesystem). Loading init EXEC: opening filelookup: calling fs lookup minix_lookup: Entering minix_find_entry mfs: minix_bread(36420, 0, 0) MINIXfs: file block #0 - disk block #6 MINIXfs: m_getblk returning CF78 for blk 0 MINIXfs: Reading block #0 with buffer #CF78 mapping buffer 4 (0) BUFMAP: Buffer 4 (block 262150) mapped into L1 slot 4. unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 minix_lookup: minix_find_entry returned CF78 0 mapping buffer 4 (0) unmapping buffer 4 iget called(8B00, 2, 0) iget: getting an empty inode... iget: got one... (8E92)! iget: Reading inode mapping buffer 3 (0) unmapping buffer 3 iget: Read it lookup: returning 0 lookup: calling fs lookup minix_lookup: Entering minix_find_entry mfs: minix_bread(36498, 0, 0) MINIXfs: file block #0 - disk block #7 MINIXfs: m_getblk returning CF90 for blk 0 MINIXfs: Reading block #0 with buffer #CF90 mapping buffer 5 (0) BUFMAP: Buffer 5 (block 327687) mapped into L1 slot 5. unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 mapping buffer 5 (0) unmapping buffer 5 minix_lookup: minix_find_entry returned 0 0 lookup: returning 65534 EXEC: open returned 65534lookup: calling fs lookup minix_lookup: Entering minix_find_entry mfs: minix_bread(36420, 0, 0) MINIXfs: file block #0 - disk block #6 MINIXfs: m_getblk returning CF78 for blk 0 MINIXfs: Reading block #0 with buffer #CF78 mapping buffer 4 (0) unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 mapping buffer 4 (0) unmapping buffer 4 minix_lookup: minix_find_entry returned CF78 0 mapping buffer 4 (0) unmapping buffer 4 iget called(8B00, 9, 0) iget: getting an empty inode... iget: got one... (8E92)! iget: Reading inode mapping buffer 3 (0) unmapping buffer 3 iget: Read it lookup: returning 0 lookup: calling fs lookup minix_lookup: Entering minix_find_entry mfs: minix_bread(36498, 0, 0) MINIXfs: file block #0 - disk block #91 MINIXfs: m_getblk returning CFA8 for blk 0 MINIXfs: Reading block #0 with buffer #CFA8 mapping buffer 6 (0) BUFMAP: Buffer 6 (block 393307) mapped into L1 slot 6. unmapping buffer 6 mapping buffer 6 (0) unmapping buffer 6
FW: imgtools released
The psion specific tools have been updated a bit. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Matt J. Gumbley [SMTP:[EMAIL PROTECTED]] Sent: Thursday, December 09, 1999 8:26 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: imgtools released Adam and Simon, I've released a new version of imgtools (incl. imgconv) with options for writing the code and data segments out to files. DOS and Linux versions are available at: http://www.gumbley.demon.co.uk/imgtools.html Regards, Matt -- Matt J. Gumbley - m a t t @ g u m b l e y . d e m o n . c o . u k Idiosyncratically euphemistic eccentricities promulgate dispensable obfuscation. Therefore, you must always simplify.
ELKSibo - Return to Witch Mountain
I've been getting a few emails wanting/offering help with ELKSibo (i.e. on the Psion Series 3). These have basically prompted me to get on with doing some more. I had a play last night and have a few questions/ideas to throw at the group - please bear with me. 1). I have modified the /arch/psion tree to refer to the /arch/i86 tree where there are not changes. This is easy for whole directories /arch/i86/lib, but more difficult for thing like /arch/psion/kernel which has a mix of new and old. I tried just referring to the files as ../../i86/kernel/signal.c but the problem came when generating dependencies as the '.c' weren't local to the makefile. At present I have used symbolic links to the files to overcome this. Any suggestions, as I believe sym-links are a no no..? (Al I'll send you a copy directly in the next couple of days) 2). Loader. Currently the psion stuff builds the whole kernel into an a.out, which is then converted to psion '.img' and copied across. This is run as an application, it then hi-jacks the processor, relocates and voila you're running Elks. This means the 'loader' part of the code is always resident and occupying space within the kernel code segment. I've been thinking around how to remove it and loader the minimum. Again any suggestions? 3). The fonts are also currently located in the kernel (data I think). I would like to remove them but need something to load them onto the machine..Does 'a.out' or Psion '.img' support extra segments? 4). A number of people who have contacted me don't have SSD's (external storage). The problem is that there is no way to get a minix/elks file system image into the machine before booting (until 'boot from network' is going ;-) ). My (theoretical) solution 2, 3 4 is to write a very simple loader application that will receive a hex file via the serial port and write it directly to memory. Each line would either start with a numerical address or an execute key word and then address. It would blindly load memory as instructed and then jump to the start of kernel code. I'm open to suggestion, directly or to the list. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
CONFIG_NOFS???
I've been looking through all the ROM stuff in 0.0.81 and it looks good.
However what is 'CONFIG_NOFS' supposed to do? (NOTE I may be missing the
point completely).
in /init/main.c it prevents root being mounted, but the next bit is
'sys_execve("/bin/init")'. Where is this (/bin/init) supposed to appear
from?
Simon Wood
Hardware Engineer
Pace Micro Technology plc
Victoria Road, Saltaire, Shipley
West Yorkshire, BD18 3LF
Tel : +44(0)1274 532000 Fax: +44(0)1274 532029
This E-Mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender.
RE: Some q's - Driving LCD Display within ELKS.
Unless your hardware provides BIOS for driving it like a vga/svga you will probably need to write (get some else to write) a display driver specifically for it. For the Psion stuff the screen is just memory mapped and I wrote a simple driver to render text (all 8bit wide) directly onto it. This unfortunately requires a font to be held somewhere in the memory (in the kernel code segment for the psion though I'm thinking of moving this). I was thinking that it would be better to abstract a little from this and try and get a 'framebuffer' style interface going. This would help development on various platforms that don't have a vga/svga plug in card. Presumably all our frame buffer would need to do is simple text (console 8*8 ??) and dots lines (micro-windows). Does any one else have any thoughts along these lines? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Jakov af Wallby [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, November 24, 1999 12:57 PM To: William Price Cc: [EMAIL PROTECTED] Subject: Re: Some q's On Wed, 24 Nov 1999, William Price wrote: Yes,I have questions about this as well. I wish to someday run ELKS on my Tandy HD 1000 laptop (8086 based) and its screen is LCD. Is anyone working on this, or does anyone have any knowledge about it? William Price [EMAIL PROTECTED] I believe we are discussing different things here. Biglinux boxes are by some people attached to LCD displays that use a serial interface. Your Tandy, in contrast, probably treats the display as any graphics card, for instance CGA compatible. (Or at least BIOS must handle text on it.) Thus, you can probably use ELKS right away. Boot it and see what happens. Jakob
Palm Pilot ELKS.
I am very aware of the uClinux stuff (their mailing list is very active) but personally I think that the main kernel is too big to fit on a Palm Pilot. Is anyone in the ELKS group planing (or doing) ELKS on the Pilot? We could afterall nick all the stuff they have discovered about the hardware and fold it back into the ELKS tree. Simon Wood PS. I don't own a Pilot - I'm just letting my mind wander from what it should be doing
RE: Palm Pilot ELKS.
Yes and No. So far ELKS has been '86 based because that is the most common architecture. I haven't looked at the uClinux code but assume that they have set up another (or modified) an architecture tree - so they will have drivers etc. I only suggested it because it seems like fun (I must be mad) and I'm having a very unproductive day so far I don't think it would dilute the main ELKS tree, the more people that get involve the better (even if they are just testers). Obviously nobody could be forced to work on other ports, it's just that some may be interested in trying it. Personally I would like to see ELKS branch out over many processors (just like it's big brother), and hopefully conquer the 16bit world. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Berghold, Peter [SMTP:[EMAIL PROTECTED]] Sent: Monday, November 15, 1999 6:00 PM To: 'Simon Wood'; [EMAIL PROTECTED] Subject: RE: Palm Pilot ELKS. Is anyone in the ELKS group planing (or doing) ELKS on the Pilot? We could Pardon my ignorance here, but is in the interests of the ELKS group to branch into the Pilot? Seems to me the expertise here is in the 808x architectures. The PalmPilot is a 68K device. Wouldn't effort in that arena bleach out the excellent work being done on the 808x architecture? Just my $0.02 worth Peter L. Berghold Lehman Brothers Unix Engineering Unix Architect VOX: (201) 524-5018 [EMAIL PROTECTED] Australian Cattle Dog Philosophy: "Seize the Cow! Bite the Day!"
Embedded Linux.
I found this link on LWN about embedding Linux, which is a interesting read. http://www.linuxdevices.com/cgi-bin/article_view.cgi?artid=AT2301017313 We even get a mention (about porting to the Palm - is anyone actually doing this with ELKS???). Perhaps Alistair should write and put them right, I think it particularly important to note that ELKS is 16bit and does not require nearly as much processing power/memory as the full Linux kernel. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
RE: ELKS on Psion?
Yes the start of a port has been done but I kind of got distracted by various other toys (new distro's, TV card, tiling Kitchen...) A (not quite up to date) version of the port can be found at: http://www.mungewell.ndirect.co.uk/linux/index.htm I'll try and get motivated enough to post the further changes that I have at home later in the week. Simon Wood -Original Message- From: Gaute Hvoslef Kvalnes [SMTP:[EMAIL PROTECTED]] Sent: Monday, September 20, 1999 10:40 AM To: [EMAIL PROTECTED] Subject: ELKS on Psion? I saw this note on the ELKS page: "[1999 07 21] ELKS booted on psion 3A." Is a Psion release expected? This looks really interesting, and I would very much like to see Linux on my 3c. Regards, Gaute Hvoslef Kvalnes 386 World: http://come.to/386 Psion 3a/c/mx/Siena: http://www.crosswinds.net/~gaute
SIBO/Psion Elks Init not completing...
I posted this earlier this morning but it hasn't appeared - so I'm trying
again.
Well I had another play last night and didn't find the solution as to why
init isn't completing the login sequence.
The last message is 'Loading Init' and then it gets stuck in a loop
Here's the system call log, can anyone see the problem?
( is a comment by me.)
Irq(0) Requested
Set up
Timer enabled...
Console: Direct Dumb (no screen store)
Calibrating delay loop.. ok - 2.09 BogoMips
Psion Series 3a (512K).
ELKS kernel (0 text + 0 data + 0 bss)
Kernel text at 4F0:, data at 14F0:
364 K of memory for user processes.
SSD driver (Major = 3)
ELKS version 0.0.78
VFS: Mounted root (minix filesystem).
Loading init
[1/2414: sys_gettimeofday()][1:sys_gettimeofday/ret=0]
[1/2424: sys_getpid()][1:sys_getpid/ret=1]
Why is this 1 (shouldn't it be 0 ??)
[1/2412: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2412: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2422: sys_fork()][1:sys_fork/ret=2]
First fork for tty1 (in spawn tty)
[1/2410: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2410: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2422: sys_fork()][1:sys_fork/ret=3]
Fork for tty2 (in spawn tty)
[1/2410: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2410: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2422: sys_fork()][1:sys_fork/ret=4]
Fork for tty3 (in spawn tty)
[1/2410: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2410: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2416: sys_wait(65535, 0, 0)][2/2418: sys_open("/dev/tty1"
, 2, 6)][2:sys_open/ret=0]
syswait on line 91?
[2/2418: sys_dup2()][2:sys_dup2/ret=0]
[2/2418: sys_dup2()][2:sys_dup2/ret=1]
[2/2418: sys_dup2()][2:sys_dup2/ret=2]
[2/2420: sys_exit()][3/2418: sys_open("/dev/tty2", 2, 6)][3:
sys_open/ret=0]
[3/2418: sys_dup2()][3:sys_dup2/ret=0]
[3/2418: sys_dup2()][3:sys_dup2/ret=1]
[3/2418: sys_dup2()][3:sys_dup2/ret=2]
[3/2420: sys_exit()][4/2418: sys_open("/dev/tty3", 2, 6)][4:
sys_open/ret=0]
[4/2418: sys_dup2()][4:sys_dup2/ret=0]
[4/2418: sys_dup2()][4:sys_dup2/ret=1]
[4/2418: sys_dup2()][4:sys_dup2/ret=2]
[4/2420: sys_exit()][1:sys_wait/ret=4]
[1/2414: sys_gettimeofday()][1:sys_gettimeofday/ret=0]
[1/2422: sys_fork()][1:sys_fork/ret=5]
[1/2410: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2410: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2416: sys_wait(65535, 0, 0)][5/2418: sys_open("/dev/tty3"
, 2, 8928)][5:sys_open/ret=0]
[5/2418: sys_dup2()][5:sys_dup2/ret=0]
[5/2418: sys_dup2()][5:sys_dup2/ret=1]
[5/2418: sys_dup2()][5:sys_dup2/ret=2]
[5/2420: sys_exit()][1:sys_wait/ret=5]
[1/2414: sys_gettimeofday()][1:sys_gettimeofday/ret=0]
[1/2422: sys_fork()][1:sys_fork/ret=6]
[1/2410: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2410: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 2, 69)][1:sys_open/ret=65
534]
[1/2398: sys_open("/var/run/utmp", 0, 69)][1:sys_open/ret=65
534]
[1/2416: sys_wait(65535, 0, 0)][6/2418: sys_open("/dev/tty3"
, 2, 19104)][6:sys_open/ret=0]
Repeat this loop for ever...
RE: SIBO/Psion Elks
See below Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Alan Cox [SMTP:[EMAIL PROTECTED]] Sent: Monday, August 16, 1999 11:18 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: SIBO/Psion Elks 1). Reduced character size to 8x8 to increase screen size and save memory (the font is held in Data segment) Can you not find the Psion font in rom ? Also you could push the font into its own segment and 'borrow' ES momentarily with a cli around a single char render. [Simon Wood] I haven't looked and have no idea where and what format it might be. I'm under the opinion that we should work completely separated from Psion ROM, that way the code written could be ported to other systems (which might not have similar steal-able features from ROM). Yes it could be placed in a separate segment - I need to check how this might be loaded from a Psion '.img' format executable as that's how the system is 'booted' at present 1). The current version of Init (in elkscmd) seems to need /var/utcp to be exist, what does this do and should this file be writable (which won't be possible with a read only file system!)? Eventually you are going to need a ram disk. [Simon Wood] Why ??? I agree that in a 'PC' type environment you will need disk storage, but there are many applications for ELKS that will not... In this specific case 'init' would need to create a RAM disk for /var before it continued booting - seems a suspect way of doing it to me. 2). PS requires '/proc', but I can't see any code where this 'created'. The mainstream Linux has a /proc we don't. The intention is to make /proc dig around in /dev/kmem [Simon Wood] So why is this PS in elkscmd if it can't possible work?? And on this line in whinging 'clock' talks directly to hardware (which in my case doesn't exist!) - it should be through a clock driver! 1). I still can't get Config #DEF's to link through to .S files for parsing. Is this working on other people's machines? (this is making life kind of difficult). .S files should go via the C pre processor. .s files dont [Simon Wood] Yep I get the concept, but I can't get it to work :-(, how are the config #DEF's passed through Makefile to gcc?? (they certainly don't appear if you do 'gcc -dD').
RE: cheep linux machines
There are some displays that take either serial or parallel (with a couple of strobes) input - I have one sitting at home. These could be used, but would be a little more expensive that the one without the controller built in. Personally I like the idea of helping a small industry like this start up... The other option, of course, is our competitors over in the uClinux team - but I think the dragonball might be too expensive. What would the requirement for the processor/screen/memory be for this project ??? Simon Wood -Original Message- From: David Murn [SMTP:[EMAIL PROTECTED]] Sent: Friday, August 13, 1999 6:17 PM To: thcg Cc: linux 8086 @ rutgers Subject: Re: cheep linux machines On Fri, 13 Aug 1999, thcg wrote: I am seriously considering starting a cottege industry making little diaries/laptops consisting of a cheap mcu like m68k or arm (?) LCD screen and keyboard running embedded linux. ..away from the rest of the process, the bottleneck seems to be the machine layout... not the OS. I just cant seem to find a good list of all available mcus that run linux. There has to be a website on the CHIPS not boards or machines that can run linux.. Firstly, you're not going to easily get many cheap systems in bulk to run Linux (you may be able to, but not that I'm aware of). You could design/build such a system based on a Z80 or 6502 fairly cheaply. The problem would be a display, as LCDs aren't cheap, and 7-seg doesn't quite cut it for a non-hacker type person. You may be able to get some used displays of some sort, but working to a budget of $2.50 is a bit tight. You're probably looking at around 3-4 times that price. Davey
SIBO/Psion Elks
I've done a little more hacking around: 1). Reduced character size to 8x8 to increase screen size and save memory (the font is held in Data segment) 2). Added 'Echo to Serial' option that echoes the current console output to the serial port - this should make debug a little easier 3). Modified the SSD driver to open, block-read, close disks - this appears to make it a lot more stable and hopefully a little faster. 4). Gave a brief demo at the West Yorkshire Linux Users Group last week. I'm having a few conceptual problems: 1). The current version of Init (in elkscmd) seems to need /var/utcp to be exist, what does this do and should this file be writable (which won't be possible with a read only file system!)? 2). PS requires '/proc', but I can't see any code where this 'created'. 3). What size stack are we supposed to be working with (I had 8K and was running out of space, so it's now 2K) and those code based ones.. 1). I still can't get Config #DEF's to link through to .S files for parsing. Is this working on other people's machines? (this is making life kind of difficult). 2). The build tree doesn't fully work with all the options. For example if you don't have loadable modules, 'sys_dlload' is not defined and causes a build error (have to then change the auto generated arch/xxx/kernel/entry.c file). If someone could summarise what needs to be where and why (for a minimum system, remember I'm working with a 128K disk for the time being) it would help my understanding of the system as a whole. Also 'strace' outputs a lot of numbers and text - the text at least make sense but what about the numbers? I'll post an up-to-date copy on my website tomorrow night, if any one wants help trying it email me Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
RE: SIBO/Psion Elks
Ok my beef (well it was only supposed to be a comment - I'm not steaming at the ears) was that the elkcmd package should really be transportable across all platforms. (I acknowledge that is basically PC at present but with talk about other platforms we should try to be versatile). I believe the meta device drive should enable device drivers in user space, or maybe we could make use of loadable modules and unload it quickly. How does the kernel/file system handle 'file dates' when creating/modifying files? RE: UTMP problems I think I've found MY mistake, the 'login' code has a compile option for utmp (which I've left in by mistake) but bombs out big time(i.e. no login) if the utent.c stuff returns NULL - which it does if the file doesn't exist. I'll try recompiling it. (it just that re-programming the Flash SSD takes so long :-( ). Simon Wood
Psion ELks - Code Release
Hi all, I sent this from home yesterday but it appears to have go lost on the way I've placed the latest 'state of the art' code on my web page.. http://www.mungewell.ndirect.co.uk/linux/index.htm If some people can give it a go, please let me know what you think. At present it gets as far as mounting the 'hard disk' and loading 'init' and then it falls over in a big heap. I suspect the kernel stack is a little screwed as this version has the psion 'stack/data/bss/heap' sequence. Have fun, Simon Wood
Unable to Mount Root
Hi all, I've grabbed the latest CVS stuff, patched in the Psion stuff and built it. I got 'Panic VFS: Unable to mount root fs on 0380', not supprising for the psion but it does the same on the PC version. It appears to not scan through the list of available files system types :-( I get the feeling that the config options are not completely independent, anyone else had this problem? Simon Wood
CVS Status?
Hi all, I've been reading up about how to use a CVS server... I think I ought to have a go at the practical side of things. Is the Elks CVS server functioning and if so where is it? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Romfs broken?
Hello all, I attempted to build ELKS with the Romfs, but got linking errors :-( Has anyone fixed this already? The Psion port is proceeding, I've had success read/writing/erase a flash SSD. I need ideas about how to get a filesystem image onto the SSD in the first place and then we should be cooking with gas. I am presuming the Romfs is the best to use as it will be impossible to alter the FAT (or superblock) after it is written. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
RE: Can someone explain (or point me towards an explaination for) the
see below... PS (Pre-script) does anyone know how to get MS outlook to append your reply to the END of the quoted message, rather than put it at the beginning? Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Alistair Riddoch [SMTP:[EMAIL PROTECTED]] Sent: Monday, June 28, 1999 3:06 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Can someone explain (or point me towards an explaination for) the IMPORTANT NOTE: Do not use any code in 0.0.77 as a reference for writing this driver. Please see 0.0.76 instead. I accidentally released some experimental code which will not be in the next release, and does not make sense. The code is not buggy, just unnecessary and wrong. If you write a driver like this it won't work with future kernels. END [Simon Wood] Whoops. The ramdisk driver is probably the best driver to use as a template. It is very simple, does not use interrupts or waiting, and copies memory in the simplest way. The block_read and block_write functions are generic function which allow character orientated reads/writes to occur on a block device. These are only used by things like mkfs and fsck. The important function for your driver to implement are the open and release functions, and the request function. You then create a file_operations structure just like the one in rd.c, but with entries pointing to your open, and release function (you won't need an ioctl yet). The open and release functions may or may not need to do anything, but they should verify that the device being accessed is valid, and return an error if not. Most of the functionality will be in the request function (see do_rd_request()) which actually reads and writes blocks. [Simon Wood] Had a look-see at this and got confused, looked again and did LOTS of fgreps and think I understand a little more. Could this area of code be 'cleaned up' to make it a little more readable? (do_rd_request() seems to be called via a #define). questions: What is ioctl() for ? Am I correct in assuming that this is running as kernel (i.e. kernel data segment)? Why is 512 hardcoded? If accesses are going to take a largish period of time is this going to get swapped out, or does the kernel reign supreme? You will then need an init function for the driver which calls register_blkdev and stores a pointer to the request function in the blk_dev array of structures in the correct place. Then all you have to do is put a call to this function in blk_dev_init() in ll_rw_blk.c, and you have your driver. Al
Psion ELKS Memory Mangament and Protection.
Hi all, I'm pressing on with the Psion port of ELKS and need some input into how to use the available memory. The included file details the Psion memory structure and has some sketchy suggestions for it's use. memory.htm Yours, Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. memory.htm
RE: Capabilities
In addition, the user programs could be protected from the kernel and vice versa... Note, without memory protection we really have no lower priviledged users, all users are the equivelent of root. Users exist merely to provide some logical division. [Simon Wood] Not 100% true, if a program behaves then the kernel can prevent inspection of privileged data. It's only when a program miss-behaves the trouble starts. FYI The Psion 3a have a simple memory protection of a range of address that the program may write to, if a write outside these is attempted then an interrupt is trigger - I will probably attempt to use this once I have code. However it is possible for a malicious program (i.e. the stuff I have done so far) to defeat this. Simon W.
RE: Editor
I'm afraid this is just one those 'blue touch papers', i.e. light and standback... I'm in support for both a 'Micky Mouse' (tm) style editor and a 'real' one. (OK I like Vi - it's very powerfull once you know the commands, but it IS difficult to learn). It should be difficult to do either (or both)... Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. -Original Message- From: Thor Harald Johansen [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, June 02, 1999 2:28 PM To: Linux 8086 Subject: Editor Is ELKS capable of displaying color ANSI graphics? I'm very interested in a more user friendly editor for this system. Compare with the MS-DOS Editor, for example. The first time I started 'vi' or 'ed', I didn't know what to type. The cursor keys seemed do produce some rather strange results, and it was impossible to Ctrl+Z/Ctrl+C yourself out of the program (add support for that to ELKS). When reading the manual page from Slackware, I found out you had to type a colon before a command, even adding lines. This is not a very efficient solution. I think the WordStar/MS-DOS Edit approach to it is much better. Could it be done in ELKS? -- Thor Harald Johansen [EMAIL PROTECTED]
RE: Capabilities
My wife is currently addicted to Sokoban, how as ASCII version of that. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. But seriously... I'm wanting to get my C skills back into shape. Can anyone think of a good program to port? Maybe "ed" wouldn't be such a bad start... or maybe some old games from Slackware's Y package...
RE: ROMable ELKS
The advent of nano-X and graphics under ELKS, together with this discusion has set me thinking more seriously about ROMing ELKS. In the bath last night (as always) I thought about how I could modify ELKS so it would run without a filesystem, and came up with a way of storing binary images in an area of ROM. The ROM would simply contain all the binaries in minix format concatenated together, the header of each aligned to a 16 byte boundary. The unused field of the header could contain a 4 character unterminated string which identifies the binary. exec would then be recoded to search this area of ROM for the binary in question, leaving the text segment and running it in place. The initialised data would then have to be copied into RAM, but very little RAM would be required as only the kernel and program data segments would need to be stored there. Any thoughts anyone? Al [Simon Wood] Hi Al (and others), my thoughts were along a similar approach. But I feel that the ROM File System should integrate with the VFS and allow the storage of any type of file. We know that the contents are NOT going to change (it's ROM!!) so perhaps we could used a small area as a Fixed-FAT that could reference the individual items on the drive. Providing the ROM area was mapped into main memory the loader could be made to create a new data segment and point to the ROM code segment. Perhaps this would be easiest if the ROM executables were of a slightly different type (i.e. not true minix), maybe just with a different magic number. As building the ROM filesystem image would be a one off task, it wouldn't be too much to do a conversion from minix to special This sort of thing could also be applied to a RAM only system, for example the Psion 3a - which I'm doing some work on. As a side comment about Psion stuff- I've got a keyboard scanning working and some basic screen stuff, but I need to find a 'free' bit mapped font to use (probably want 8*13 bits per character to make it readable, would be really flash if it was anti-aliased to include a grey and much easier on the eye). Any suggestions.. Simon W.
ELKS on the Psion 3a: Update
I have done some more investigation into the possibility of port ELKS to run
on the Psion.
I have had the following successes:
1). Compiling and running code built on Linux to control the IN and OUT
instructions without causing a Memory Protection Faults.
2). Using Psion Serial Cable ('soap on a rope') to transmit from Psion at
9600 baud, there's a problem with reception as I'm not attempting to use the
interrupts and 'received' flag isn't working - I'm working on it. This gives
us enough to see what's happen when we try and load the kernel.
3). The Page Select Registers read at 0x06, 0x07, 0xF8, 0xF9 respectively. I
now think that they are selecting full 64k pages and are configured like
this in a user task to give the maximum 'flat' memory size. I think they
might change when the system is accessing the RAM disk.
Things to do next:
1). Write to the LCD screen memory. Does anyone know whether this has a
'character' port as well as the 'bitmap' one?
2). Read the Keyboard.
3). Confirm uses of SSD's via ASIC4.
4). Probe Page Selects further to find out if there is any overlap and how
we might control them. This might make memory mapping awkward.
I have posted more information (plus example code) on my website:
http://www.mungewell.ndirect.co.uk
Simon Wood
Hardware Engineer
Pace Micro Technology plc
Victoria Road, Saltaire, Shipley
West Yorkshire, BD18 3LF
Tel : +44(0)1274 532000 Fax: +44(0)1274 532029
This E-Mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender.
RE: Is ELKS dead?
As 'Linux' is the current craze :-) then it seems appropriate to update the very outdated web page - the people have a right to know what is going on with ELKS, and perhaps some of them will be able to offer coding time towards the project. Secondly regarding Psion development. I have got the serial port working (well transmitting a 'O'), the code will shortly appear on my web site (http://www.mungewell.ndirect.co.uk/psion/beyond.htm) Thirdly (yes I know I go on too much...) What are the aims of the project? I have my own motivation (namely Linux on the Psion) but where does that fit in with the rest. Does the project have a 'Mission Statement' if you excuse the Dilbert Speak. Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
ELKS on Psion 3a
Hello all, I'm new to the list and was wondering what the 'state of play' is for those alternative bits of hardware, in particular the Psion 3a. I wouldn't be suprised if no code existed, but has any foundation work been done w.r.t. how ELKS might be implemented on a paged memory system without all those BIOS calls. I am currently investigating driving the 3a's hardware directly and would like to pool any effort 'we' can muster. Current progress isn't much but it's a start, see http://www.mungewell.ndirect.co.uk/psion/beyond.htm Simon Wood Hardware Engineer Pace Micro Technology plc Victoria Road, Saltaire, Shipley West Yorkshire, BD18 3LF Tel : +44(0)1274 532000 Fax: +44(0)1274 532029 This E-Mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
