Simon Wood writes:
>
> 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....)
I am sorry, this is my fault for failing to communicate properly, but I
have re-organised the code so that there is not need for the arch/psion
directory. I have got the code to the point where it compiles cleanly
to produce an 8086 version of the kernel. I have not yet tested the sibo
build.
I have thought about this alot, and tried various ways of aproaching the
problem, and this is in my opinion the best. It makes it much easier to
make changes to the code, keeping both version in sync. The only files
that are so different that separate version are required for the sibo
kernel are crt0.S, crt1.c and irqtab.c, so these sit in a directory
called arch/i86/sibo. Symlinks are impossible because CVS won't manage them
properlly, and rules which refer to files on other directories make for a
very messy build process, and no devent deps.
Releasing this code has been delayed because CVS was down, and I could
not face merging the code by hand. I will check the code in today, and do
a snapshot release, then merge it into the main branch if you are happy.
The work I have put in merging the sibo code with the changes made to the
low level code to accomodate booting from ROM were pretty hairy, and I
am now confident it is stable.
Al
>
> 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.
>
