Re: ELKS and TCP/IP
>Is the TCP/IP project totally dead, or is someone still working on it? I >have an AT&T PC6300 just waiting for me to install ELKS on it, but >without a TCP/IP stack, it is of limited use to me. I **really** want to >put it back into service!! Thanks - Larry AFAIK nobody's doing anything. I saw that Guy Lancaster's ucip stack is out there and ported to a micro or two. Only does PPP though. It appears to be derived from KA9Q, BSD and Linux code. I think the site is http://www.ucos-ii.com/
Re: 8086/88 80286 ||| 80386 80486 Pentium ...
>> works on an 8 MB machine, although the > >required 5Mb to install/4Mb to run. > > etc, etc For the definitive list of Linux distributions, go to lwn.net/bigpage.phtml There are a few tiny distributions listed there that may install and run in as little as 2 MB. The record holder may be Paul Gortmaker's 896kB on a 2.0 kernel. Because it could be done, as they say. Can we go back to discussing ELKS now?
Re: 32KB EEPROM on 3COM509B ISA/PnP
>Hallo ELKS-friends ! > >I have a problem with my 3COM 3C509B ISA/PnP card. >I can use 16KB boot roms, but if I want to use 32KB >eproms (like 27C256B), the config tool 3c5x9cfg.exe >set a range of for example c8000-cbfff, but 32KB >should be c8000-c. Only the first 16KB can be used. >Why, where is the problem. >I reported this problem also to 3COM. > >Greetings > Christoph Plattner I've never seen this. Are you sure you have the most up to date version of the config tool and that it's right for your board revision? BTW, this doesn't have much to do with ELKS, unless you are planning on putting ELKS code into the ROM.
Re: EPROMS on 3com 509 cards
>Hello, > >Does anyone have an idea of witch EPROM's are compatible with the 3com >509bCombo NIC for use in the boot prom slot ??? > >Cheers >G It will take 8kB, 16kB or 32kB (2764, 27128, 27256). Usually you will see a C after 27, that means CMOS == lower current consumption.
Re: a.out -> memory hex dump??
>Take a a.out executable and convert it to a hex dump of the memory it will >occupy (once loaded) and then transfer it across to the machine, and jump to >the base location. > >How can I do the expanding bit? Are the tools out there already? Or do I >have to code it myself? GNU objcopy might do the conversion for you, it understands lots of formats.
Re: Some q's
>BTW: very offtopic question: does any by any chance have a good (i mean >GOOD) description of parallel ports ?? By this i don't mean bit assignment - >i mean voltage levels (TTL ?), max. current (load) on pins, max. propagation >etc. I'm asking because i don't have PCI LPT controller and i need 3 LPT port >s >in one box. So the only solution is to make a dual LPT controller (i have one > >ISA slot avaliable) and since ISA is very simple i thought that 3 74LS245 per > >port (3*8 lines, i will only use them in one direction, hardwired) with simp >le >address decoder should do (i don't have PAL programmer). The original parport was based on discrete TTL chips. There might be a description of the chips in this parport interfacing page: http://www.senet.com.au/~cpeacock/ Yes, the voltage levels are TTL.
Re: Some q's
>> What sort of LCDs do you mean? If it's those 16x4 or whatever character >> LCDs those can be driven by a parallel port with any convenient software. >> If you mean VGA panels, I don't know what the interface is like. > >Actually even this display you mention couldn't be used in such a way >without (integrated ?) LCD controller. In theory one could buy VGA (or >XGA) with LCDC built-in, but unfortunately all i can get is stripped >down version (= bare LCD, you have to do char -> pixel decoding and >provide propepr voltage levels, sync signals and propepr polarity in >order to drive the display). Special chip takes care of that on displays >of kind you mention. Hmm. I guess I haven't seen such bare LCD panels. IMO it's not worth the trouble to try to work out the interface (electrical, timing) for them but to make sure you have the integrated LCD controller to match the panel. Unless one likes to play with hardware.
Re: Questions
>IMHO, and if my rusty RAM serves, an 8253 was the normal serial chip on the >old CP/M and early DOS machines. Er no, the 8253 is a programmable interval timer made by Intel. You may be thinking of the 8250, a UART made by National Semiconductor.
Re: Some q's
>1. A while back I remember someone talking about driving LCD's, Can Linux >drive LCD's well? Where can I get some info on this? What sort of LCDs do you mean? If it's those 16x4 or whatever character LCDs those can be driven by a parallel port with any convenient software. If you mean VGA panels, I don't know what the interface is like.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
>How do Video BIOS make sure they are executed before everything else? Video BIOSes are looked for as a special case. They are normally located from C to C8000.
Re: ELKS NIC that will take a 64K rom
> I am now stuck. I have tried a 3c509B, an SMC Ultra, and SMC 'Western > Digital' card, and various older NICS, and none of them take more than 32K. > > The only remaining options are purpose build cards. Another possibility is two NICs with a 32kB ROM each.
Re: ELKS NIC that will take a 64K rom
>I am now stuck. I have tried a 3c509B, an SMC Ultra, and SMC 'Western >Digital' card, and various older NICS, and none of them take more than 32K. > >The only remaining options are purpose build cards. Have you considered using a compressed ROM image like Etherboot does? With that you could get about 48k of code+initdata. BSS is blank of coures. It would have to run out of RAM after decompression of course.
Re: ELKS NIC that will take a 64K rom
>I have a 3c905 in my desktop machine which can take 64K or 128K, but it is >not clearly documented anywhere I can find which end of the socket I am >supposed to put the ROM, and I could not get it to work in either end when >I tried it in both. The other problem is that this card is PCI, so wont go >in my test machines, and the fact that I use this machine for development, >and for my job. I think the 905 takes a flash PROM, not a UVEPROM. Besides it's PCI and the boot ROM is mapped in by the PnP BIOS, so that's no good for ELKS.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
>Sorry, my fingers wasn't syncronized with my brain. What I meant was: > >So we are back to the usual problem, where in the 640kB..1024kB range should >we >put or own EPROM. Somewhere free from C8000 to F.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
>The code Christian has contributed does just this, though I have not yet >been able to get it to work as I am still tracking down a network card that >will take a 64K ROM. I have the plans for a flashcard, but have not yet >been able to get thte parts to build one. I've seen some NE2000 clones that take 64 kB ROMs. >I am slightly confused about the int 19h issue however. If cassette BASIC >uses this mechanism, but is not envoked until Floppy and HDD boot have >failed, is this what we want? I have seen references in BIOS setup programs >which refer to "int 18h devices such as network boot". Is int 18h also used >by boot ROMS, and if so how does it differ from int 19h? Basic uses INT18H. The bootstrap entry point is INT19H. This should try the primary bootstrap device, which could fall back to local booting if network booting fails.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
>Actually, 'format' simply means 0x55aa at the start of the image, and the >3rd byte contains the number of 256 byte pages in the ROM. Nothing else >is involved in the 'format'. 0x55aa number of 256 word = 512 byte pages entry point, entered with long jump and cs = segment of ROM All the bytes in the image must checksum to 0.
Re: ELKS 0.0.81 available from ftp.ecs.soton.ac.uk
>I have come across a few old machies that had sockets like this, but never >one that actually had a BASIC rom in it. I don't know what the ROM in this >socket needs to contain in order for the BIOS to recognise it as a BASIC >ROM and run it if boot fails. I think the BASIC ROM has a particular entry address for iniitialisation and hooks to INT18H I think.
Re: bcc errors
! 1625 Cell *sub(a,nnn)
! 1626 # 1625 "run.c"
! 1625 Node **a;
export _sub
_sub:
! 1626 # 1625 "run.c"
! 1625 int nnn;
! 1626 {
! 1627 char *sptr, *pb, *q;
! 1628 Cell *x, *y, *result;
! 1629 char buf[(20 * (3 * 1024))], *t;
! 1630 fa *pfa;
...
lea bx,$FFFEFFEF[bp]
The array buf is 60k. This combined with other variables in this function
causes the stack frame to be > 64k and some offsets to be > 64k absolute
from BP. This will not work in ELKS, which only supports small model =
64k code + 64k data+stack. The code will have to be rewritten.
Rob de Bath: Maybe the compiler should warn about offsets > 64k abs in
8086 mode.
Re: Dev86
>> The potential glibc 6 issue is that no static initializations of FILE >* xx >>= stdin >>work, these must be moved to main() >> > >YES that is the prob, on the line that it complained about it had a similar >line. How do I fix it? Has anyone got dev86 running on a RH 6.0 Box? Just comment out the initialisation, the FILE * gets set to something before it's used anyway.
Re: there's still life in the Z80
>> http://www.zilog.com/ez80/ > >Someone now design a cool linux box with the ez80. >Would it be possible as it has a MMU and supports 16mb of memory ? I looked at the datasheets and there are a couple of things that would make life harder for compiler writers. In Address Data Long mode (what they call the new mode), data is 24 bits. Which is a rather odd size so C compilers might just keep int=16 bits and long=32 bits. Also offsets from IX and IY are still signed 8 bits. This makes it more combersome to do large stack frames. Howver one interesting bit that emerges is the acknowledgment that the Z80 contained undocumented instructions that can address the separate halves of IX and IY. Anyway this is getting a bit off topic for ELKS.
there's still life in the Z80
Seen on /. Zilog announces the eZ80. http://www.zilog.com/ez80/ Mentions a TCP/IP stack too.
Re: Re Z80<->8088, was: Linux on TI?
>As far as I was told, the Zilog company was founded by some developers from I >ntel that disagreed on the calling convention(and probably other things too) Not quite, Zilog wanted to build a superset of the 8080. Also it had simpler hardware interfacing, single 5V supply instead of several, simplier clock source, etc. >Also I was given the impression that the 8086 was a Military grade of the 808 >8. But Intel has used a lot of energy to downgrade their top CPU to satisfy m >ore market segments. So the 8088 might be a civilian version of the 8086. The 8086 came first, and the 8088 was an 8-bit external bus version which made interfacing to memory cheaper at a performance cost.
Re: Linux on TI?
>I thought the Z80s were near 8088s or 188s...am I on Dr Pepper again??? No, they are more like 8080s. 8088s are 16 bit machines, whereas the Z80 remains an 8 bit machine.
Re: [Fwd: syntax doc. about as86]
>Personally I think if as86 code were converted this way, you keep the >as86 users happy. There's another advantage with this means of conversion that I forgot to mention. By using macros to retain compatibility with as86, it's easy to do regression tests to ensure the semantics of the code have not changed. As I convert the code to use my macros, I periodically run this make rule: first: first.S gcc -DUSE_AS86 -E -traditional -o first.s first.S as86 -0 -b first first.s cmp first first.ref where first.ref is a binary saved from a pristine assembly.
Re: [Fwd: syntax doc. about as86]
>> > I'm translatting the assembler source code of Linux (as86) to Nasm >> > syntax. I need to understand the syntax of as86 wich is (very??) >> > different from Nasm's one, in particular : >> >> Ye gods. Umm no idea >> >> > >> > movb4(di),*36; (What mean the * prefix of value 36) >> > ; does 4(di) means [di+4] ??? >> > >> > Do you know where I can find any documentation. If not may be I can >> > reach Bruce Evans himself. > >Hi all, > >Like part of my previous message will show you, I will apreciate any >documentation on as86 syntax, I mean, may be a document where stuff like >previous 'movb 4(di),*36' will be explain. This is equivalent to movb [di+4],#36, or in nasm format mov byte [di+4],36 Personally I think it's a double edged sword that as86 supports many equivalent syntaxes for the same purpose. I have developed a set of macros that allow me to assemble a file under as86 or nasm with the change of a #define. It requires a bit of discipline, i.e. no gratuitous use of alternate syntax, e.g. ; instead of !, db/dw/dd instead of .byte/.word/.long, some macros to cope with the constant/reference distinction, i.e. as86: CON(x) -> *x LOC(x) -> x STRDECL(x) -> .ascii x nasm: CON(x) -> x LOC(x) -> [x] STRDECL(x) -> db x Some pathological constructs need #ifdef AS86 and #ifdef NASM, but I can get away with perhaps 10 or so in 2000 lines of assembler. It works pretty well and I have attained byte for byte match of the resulting binaries, except for instructions like xchg ax,bx which have two equivalent forms, of course. Personally I think if as86 code were converted this way, you keep the as86 users happy. You can see the use of this technique in contrib/mkfreedosnbi/first.S, src/loader.asm and src/zloader.asm in the Etherboot distribution at www.slug.org.au/etherboot
Re: BCC and ANSI C without pain
>Yes, BCC doesn't even check prototypes when the "-ansi" switch is >given. It just pipes the text through unprotoize. Sorry, please explain to me again what we would gain by using the P() macros that unprotoize doesn't already do? I mean, isn't the source already or potentially ANSI syntax without using P() macros, and unprotoize just makes it palatable to bcc?
Re: Suitability of elks for serial log host
>I think that there's a syslogger for DOS, but I wouldn't care to >guess where it might be found. http://members.xoom.com/ken_yap/bsylg133.zip
Re: new rrd.c ?
> The pmode ideas are good, but I think you missed the point. >A normal, old-fashioned 8086 can be tricked into getting 65535 more bytes >of memory than the normal 1 megabyte. This is accomplished >by programming the keyboard controller on PC's to hold the A20 line >high and then use the 8086's real mode address wrap "feature". No, it can't. There are only 20 physical address lines on a 86/88. This addresses 1 MB, no more. If you try to access :0010 it will wrap around to low memory. 286s can address 16 MB and the A20 gate chooses whether going past :0010 wraps around to zero or continues past 1 MB.
Re: Technical question & boot problem
>I bet it definitely works (boot on XT drive) if one disables the onboard >IDE first. >The problem I see is using IDE and MFM/RLL drives at the same time, >which might prove difficult. To boot XT drives on an AT+, one usually has to disable the IDE drives so that the BIOS doesn't go looking there. XT controllers usually have an extension BIOS to hook into the main BIOS boot entry point.
Re: Technical question & boot problem
>Parking the drive is a good idea if you plan to move it around becasue I >think it helps prevent dammage to the the drive when transported. I don't >know that it'd make a difference if the computer is just moving around the >house or something though. My solution would be to make a DOS boot disk >with park on it, stick the disk in drive A, and re-boot and run park just >before shutting the power off. After a certain point in the technology, drives became self parking (weak spring in mechanism did it). So for those drives, parking is redundant but harmless. Still worth doing for old drives I suppose.
Re: LPD, printing filter, terminal program and other tools
>Sure, but that doesn't really answer the question. Why then is lpd typically >kicked off at boot time, when it could just be started dynamically from inetd >? Because local requests don't come over IP sockets, but through Unix domain sockets.
Re: [Fwd: C compiler for AppleII+]
>The story I got told was there was something amiss with the Stacks on >the MOS 6502, like they're not big enough or something. Anyone hear >about this? On the 6502, the high byte of the stack pointer is the constant 01 so the stack has to live on page 1; 256 bytes worth.
Re: LPD, printing filter, terminal program and other tools
>That uses (3) as a "transparent print spooler", as per my quoted >comment, and the development of a "translating print spooler" using >utilities such as ghostscript (can that be easily ported to ELKS) >would follow from there. Transparent print spoolers will work but I think translating print spoolers are a bit optimistic. A friend of mine tried to run ghostscript on his diskless 386 but it took ages to render anything. Besides have you looked at the size of ghostscript.
Re: chmod +t
>Can anyone tell me if the "t" mode for executables does anything. >Sometimes referred to as the "sticky bit", it is supposed to make an >executable stay in swap space after it is run, so the next time it >is run it simply swaps in and executes. Not anymore in modern Unixes. BTW, linux-8086 is not the list for big Linux questions. Cheers, Ken
Re: Off-Topic: EPROMs?
>I have an 8086 that I'd like to use for some embedded projects. One of >these is the dream of many linux people: the toaster that runs linux. >Hehe... 'telnet toaster'... Anyways, I have a bunch of EPROMs that I'd >like to program, but I can't get the silly things to erase. They're >supposed to be UV-erasable, but I don't have a good source of UV. I tried >sunlight but apparently the ozone is too thick here. Can anyone suggest a >source of UV suitable for erasing EPROMs, preferably without too much skin >cancer :) You need a germicidal lamp (looks like a short fluorescent tube and also uses a ballast) and a light tight enclosure (the UV will damage your eyes). Do a Web search, there should be some circuits around. Sunlight will take weeks if not years.
Re: will it eventually run X
>Ken, you are totally missing the point. Yes, Linux with X runs very well on >a 486DX or better. Nobody here is disputing that claim. That is the purpose >for Slackware, RedHat, Suse, Caldera, etc The reason for being of the >ELKS project is to try to port Linux (with any and all apps that can be >ported) back down to the 8086 architecture. >The stated reason is for impoverished 3rd world countries. Yes, here we can >pick up discarded 486DX boards mere pennies on the dollar (or even free out >of dumpsters), yet in many neglected parts of the world, even discarded 8086 >machines are expensive. When your yearly net worth is less than $100.00, a >$200.00 cast-off 486 is totally out of the question. >THAT is why this project exists. The added bonus to us is the fun of trying >to hack the end result. If you do not want to consider the 8086, then the >normal Linux listserves will serve you most adequately. Just please, do not >hinder our progress (or would it be regress? :> ) I think you misunderstand my drift. If you look at my page[1] at Geocities you will see my collection of software for old machines. Nobody would love to use these old machines more than I, I have about a dozen AT boards in good working condition. I have ported software to run on diskless XTs and ATs. Heck I have even written code to make boot ROMs[2] for XTs and ATs. But all that software is standalone or DOS based. I would love to see ELKS succeed. But all that happens on this list are people asking for unrealistic goals like X when not even networking is working in ELKS. And every day that passes, technology moves on and those XTs and ATs just get less and less attractive. I know, I'm not contributing either, just making noise too. The progress on ELKS has been so slow that I've turned to the task of making FreeDOS netboot. At least networking already works there. As for machines for the less-well off, well I'm involved in this project[3] too. I fail to see how pointing out the reality is hindering people. If anybody feels energised by this less than positive assessment of ELKS to want to prove me wrong, well good on you, as we say. And so what are your credentials? [1] http://www.geocities.com/SiliconValley/Lab/9247/ [2] http://www.slug.org.au/etherboot/ [3] http://www.computerbank.org.au/
Re: some questions
>I'm new to this list and am wondering if the message below means to >imply that an 8086 system with expanded memory is not supported >because drivers for all the different bank-switching schemes do not >exist. I have the same question for 80286 systems with extended >memory cards. Expanded memory cards are problematic because each card potentially had it's own hardware scheme. Extended memory cards are not a problem. Extended memory is just extended memory. But I haven't seen the PM version of ELKS yet.
Re: plip for elks?
>> We're gonna need a tcp/ip stack first. >> A plip driver won't be that hard, but we need something for it to sit on. > >The problem with PLIP in ELKS will be finding XTs with bi-directional >parallel ports. > >And finding 8-bit parallel add-on cards that support bi-directional >transfers. PLIP can work in nibble mode, using the status lines as a 4 bit input port. For those handy with a soldering iron it's a small hardware patch to make a bidi port out of those old discrete TTL parallel port cards.
Re: will it eventually run X
>> About the lowest platform I would consider X on is a 386-DX-25 or so >> with at least 16 MB of memory running a tiny mono X server or something >> like that. > >I don't suppose you ever used X on an 8 MHz 68010 (like early Sun machines). >I wonder if it's still possible to get X10 or X11R<3 source code anywhere. >X wasn't always as bloated as it is now. I have actually. You will find a couple of utilties that I wrote in the X10 distribution. It's just that my expectations have gone up since then; the "I would consider" signals a personal point of view. It may be "fun" to try to shoehorn X into a 286 in PM, but why be masochistic when I can pick up a 486DX for next to nothing and turn it into an X-terminal with a bootrom.
Re: will it eventually run X
>I've been wondering about this also. Any x terminal has limits on how >many resources it can handle, so what is the minimum amount that is required? >If an x command references a resource which has been dropped can't it just >re-request it? So in the limit couldn't it re-request it every time it >needs it? In the limit you could augment the Ethernet connection with a video cable to a video board on the real server and run only the mouse and keyboard traffic over the LAN. :-) NCSA telnet has a Tek emulator built in so vector graphics is feasible. But I think given the CPU power of these things, bitmap graphics is going to disappoint people spoiled by fast hardware. Not that I wish to be negative, I have been on the lookout for applications for old XTs and ATs for a while, and text mode terminals, even multiple sessions, are indeed perfectly feasible and usable, and you can find some of the links I have collected here: www.geocities.com/SiliconValley/Lab/9247/
Re: will it eventually run X
>I could see an XT/286 possibly running X, if the server, even, were >running on another machine. This would require some sort of networked X >server... Where EVERYTHING is kept in RAM on a BigLinux box, and ONLY the >info being displayed to the screen is transmitted over the network to an >ELKS machine. The ELKS machine would be a truely dumb X Terminal--not >keeping any fonts, window parameters, etc, in memory at all. Display only >what it's given over the network. > >Now if anything like this would ever be writtin, I have no idea... I won't >be the one to do it... but I could see that sort of model working on the >low-low-low-end machines. Maybe someone will care enough to do it. :-) Given that I occasionally am given or find in a local skip (dumpster or tip for you other people) perfectly good 386DX40 motherboards I doubt if this will ever be worth the trouble.
Re: will it eventually run X
>hi, this is probably completely off the wall, but I'm trying to get a handful >l of >8088,8086,80286 's running enough of an OS to boot up, and connect to a Linux > >machine running X, sorta Like an Xterminal. I realise that ELKS is not at a s >tage where >this can be done, however I'd like to know if it will eventually arrive at th >at point? >Sorry if this is Off topic, or just a little insane. I seriously doubt it will ever happen. 1. Not enough CPU power 2. Not enough memory space 3. Goto 1 You can however run them as telnet or serial terminals. About the lowest platform I would consider X on is a 386-DX-25 or so with at least 16 MB of memory running a tiny mono X server or something like that.
enhanced version of wattcp
http://www.bgnett.no/%7egiva/ Gisle Vanem did this work. It includes a BSD socket style API. It might be of some use to ELKS.
Re: enhanced version of wattcp
>> http://www.bgnett.no/%7egiva/ >> >> Gisle Vanem did this work. It includes a BSD socket style API. It might >> be of some use to ELKS. > >The old one had a license problem or 5 Erick Engelke is still around the traps. Maybe he could be persuaded to release it under a more suitable license seeing as it's hardly lucrative software.
Re: X?
>> X really needs a large address space so 32 bit addresses and pointers are >> critical. I don't think a 286 can hack it. Plus it will be slow. Even a >> 386 is a bit slow for X. If all you want is a diskless X-terminal there >> are lots of ways to do this with a 3/4/586 and Linux. >> >> A lighter windowing system like perhaps mgr or W may make it. But all >> this is speculation. People to code are needed more than discussion. >> > >Oops, this letter only comes to you, nevermind... > >One could hack a program where only changed bitmap data (nothing else) >is copied to the 286. VNC would be able to do this, but I have no idea how feasible it is.
Re: X?
>OK I know this sounds really strange, but are there any plans to port X to >ELKS? I know it won't run on most machines, but I guess a 286 with 2MB >might be able to handle it. After all, win3.1 runs on it... >Maybe just a subset of it's features, just enough to make it possible to >export apps running on another computer to it. This would make for a GREAT >low-end graphical terminal... >OC, TCP/IP would have to be implemented first... > >Just some silly idea... X really needs a large address space so 32 bit addresses and pointers are critical. I don't think a 286 can hack it. Plus it will be slow. Even a 386 is a bit slow for X. If all you want is a diskless X-terminal there are lots of ways to do this with a 3/4/586 and Linux. A lighter windowing system like perhaps mgr or W may make it. But all this is speculation. People to code are needed more than discussion.
networking for ELKS, another approach
Hi, I've been playing with another approach to getting networking of sorts onto ELKS. I just remembered that in the early days of Linux, there was a package called term, which provided networking across a serial link using a shell login without IP or root privilege. The idea is that after logging onto the remote host, one runs a proxy program to talk to the serial link. On the local side one runs programs that have been linked to a special library, one that intercepts all the usual networking system calls and turns them into requests to the remote proxy. Term even could sidestep characters that would be swallowed by the serial link. In this way all network requests appear to come from the remote host. In this way people were able to run termified versions of the usual networking applications. After SLIP and PPP access became widespread, term slipped into obscurity. I obtained term-2.3.5 and hacked it to compile under bcc. I have got it to make the termnet.a library, which is the replacement library for networking functions. Unfortunately the test program doesn't compile due to a compiler bug. I also found that ELKS misses a set of good header files, even if the libraries don't exist yet. Anyway, as I don't have a good ELKS setup, if someone wants to play with the source, I've put it at: http://www.geocities.com/SiliconValley/Lab/9247/term-2.3.5-elks.tar.gz The original is at metalabs.unc.edu.au (ex sunsite) under linux/system/network/serial Ken
Re: date
>: * Usage: /bin/date >: * date [?[?]] | > >One small point: Isn't '?' a shell wildcard character? This means that if w >ildcards >are enabled on the shell (currently not with ELKS, but should be) then the >? will have to be escaped? Perhaps we should use a more standard option >scheme, with dashes. > >Greg Yes probably -i for interactive input or -s for set or something like that.
someone's embedded system project: tiny PPC board
This appeared in slashdot.org, maybe it's much easier to deal with than the x86 architecture. http://www.rpcgllc.com/rpcgproducts.htm Anyway it's getting a bit off-topic for this list.
Re: My embedded linux project
>Chipsets? I'm building custom hardware because I want to get away from >chipsets. completely unnecessary for my task. Plus, I'd have to go thru >the expense of developing a custom bios and its not worth it. I think you will find that the complexity of the current offerings in the x86 family can only be tamed by lots of glue silicon. Chipsets have been used since 286 days. I have a few 286 motherboards with discrete TTL glue and they aren't pretty. If you are talking about other (more elegant) processor architectures, the requirements may be less demanding for glue logic.
Re: My embedded linux project
>I want to build some custom hardware and run linux on it. I'm planning >to go with something like a Mobile Pentium II processor and a southbridge >chip. I don't care if this hardware is "PC compatible" or not, in fact, >I don't want ti to be as its unnessary and adds costs to custom hardware. > >My question is, is it possible ot boot the linux kernal directly from >ROM. IE: No BIOS, just a rom at mem location 0 that starts up lilo and >loads the kernal into RAM. Has anyone done this or seen it? > >Those doing embedded linux on non-intel platforms must do something like >this as there isn't always a BIOS around. > >(And linux doesn't really use the bios at all, does it?) No you don't *really* have to, Linux has it's own drivers for peripherals, but booting up with the BIOS has some advantages. The chipsets that are used these days need initialisation and the BIOS knows about them. Anyway the BIOS only occupies the top 64kB of the bottom 1MB and once the OS is running, all you lose is some memory space, and maybe not even that since you couldn't really do anything with that 64kB anyway.
