Re: Disk is cheap?
On Sat, 24 Feb 2001, Ralf Baechle wrote: > On Wed, Jan 31, 2001 at 02:29:54PM +0100, Robert Kaiser wrote: > > > Perhaps a more convincing argument may be that in embedded devices, > > disk as well as memory and CPU power are _not_ cheap. > > > > The more resources Linux requires, the less are it's chances of being > > accepted as a viable alternative in embedded systems. > > > > > I'm still stuck with a P-133, 56 MB RAM (60-70 ns, some EDO, > > > some FPM) and not only Linux but also W2K on a 2.1 and a 0.8 GB > > > HDD. > > > > That would be _a_ _lot_ for an embedded system! > > Oh this common missconception that embedded system equals small systems. I didn't say that. I'm talking about what's common in embedded systems and it is _very_ common for an embedded system to be small both in mechanical dimension and computational horsepower. This is not a misconception but simply practical experience. > There are embedded systems that outrun supercomputers without sweating, > have gigs of RAM and sometimes if you look at them closly even have the > names of well known big iron companies on their boards. Sure these systems exist, but trust me, they are a very small fraction of a very big market. > The whole > embedded term is just so weakly defined and everybody seem to have his > personal definition How about this: An embedded system is a computer system designed to fulfill a particular purpose. Since embedded systems are usually made in large quantities, there is a strong pressure to make them as cheap as possible. Thus, the amount of resources assigned to a system is usually just barely enough for it to fulfill it's purpose. If it has gigs of RAM, you can be sure it needs every bit of it for doing whatever it is supposed to do. Running on low resources is symptomatic to all embedded systems. Helau Rob Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH http://www.elinos.com Am Pfaffenstein 14 http://www.sysgo.de D-55270 Klein-Winternheim / Germany - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Anybody got 2.4.0 running on a 386 ?
Hi list, I can't seem to get the new 2.4.0 kernel running on a 386 CPU. The kernel was built for a 386 Processor, Math emulation has been enabled. I tried three different 386 boards. Execution seems to get as far as pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as if someone had pressed the reset button. The same kernel boots fine on 486 and Pentium Systems. Any ideas/suggestions ? Rob Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Die, 09 Jan 2001 you wrote: > Robert Kaiser wrote: > > I can't seem to get the new 2.4.0 kernel running on a 386 CPU. > > The kernel was built for a 386 Processor, Math emulation has been enabled. > > I tried three different 386 boards. Execution seems to get as far as > > pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as > > if someone had pressed the reset button. The same kernel boots fine on > > 486 and Pentium Systems. > > > > Any ideas/suggestions ? > > > is "Checking if this processor honours the WP bit even in supervisor > mode... " the last thing you see before the reset? > No, I don't see _any_ messages from the kernel. The last thing I see is "Uncompressing Linux... Ok, booting the kernel." I have added some quick and dirty debug code that writes messages directly to the VGA screen buffer. According to that, execution seems to get as far as the statement *pte = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Die, 09 Jan 2001 you wrote: > Robert Kaiser wrote: > > > > On Die, 09 Jan 2001 you wrote: > > > Robert Kaiser wrote: > > > > I can't seem to get the new 2.4.0 kernel running on a 386 CPU. > > > > The kernel was built for a 386 Processor, Math emulation has been enabled. > > > > I tried three different 386 boards. Execution seems to get as far as > > > > pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as > > > > if someone had pressed the reset button. The same kernel boots fine on > > > > 486 and Pentium Systems. > > . The last thing I see is > > "Uncompressing Linux... Ok, booting the kernel." I have added some > > quick and dirty debug code that writes messages directly to the VGA > > screen buffer. According to that, execution seems to get as far as the > > statement > > > > *pte = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); > > > > Could it be possible that memory size is being misdetected? Try mem=8M > (or less) on the command line. Try to catch the value of pte when it > crashes. I tried "mem=4M" -- no effect. The value of pte is 0xc0001000, so it seems to be the first invocation of that statement in the for() loop. Now comes the amazing (to me) part: I split the above statement up into: temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); *pte = temp; where temp is declared "volatile pte_t". I inserted test-prints between the above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the mk_pte_phys() macro is causing the crash! I am still trying to figure out what mk_pte_phys() does. Apparently it involves an access to the kernel's data section. My current guess is that the data section is not correctly mapped at this point. Would that be possible ? Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Mit, 10 Jan 2001 you wrote: > > How much physical memory does this box really have? > The one I'm currently using is an old Olivetti 386SX with 5 MB, I also tried two more boards, one 386SX, one 386DX, both with 8MB. All showed the same behavior. -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
No Subject
Hi, In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Timur Tabi) writes: > ** Reply to message from Robert Kaiser <[EMAIL PROTECTED]> on Tue, 9 Jan 2001 > 23:17:11 +0100 > > >> temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); >> *pte = temp; >> >> where temp is declared "volatile pte_t". I inserted test-prints between the >> above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the >> mk_pte_phys() macro is causing the crash! > > In that case, it's either a compiler bug or a race condition. > > Compiling this source file with the -S option will generate an assembly output. > The output should be the same regardless of whether you use the temp variable or > not. That will answer the question as to what the cause is. If you're lucky, > it's a compiler bug, because they're easier to fix. > > I thought that by declaring temp "volatile" I could force the compiler to not optimize it away, i.e. make sure that the evaluation of the mk_pte_phys() macro and the assignment to *pte indeed get seperated. Is this not the case ? Anyway, the actual code I'm using has debug output in between the lines, so it looks more like this: *((volatile unsigned char*)0xb8000) = '1'; temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); *((volatile unsigned char*)0xb8000) = '2'; *pte = temp; *((volatile unsigned char*)0xb8000) = '3'; When the system crashes, just before the BIOS clears the screen, I can clearly see a '2' in the upper left corner of the screen. Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Mit, 10 Jan 2001 you wrote: > How big is the kernel image? Are you making a zImage or bzImage? > I'm using bzImage. It's size is 566964 bytes. According to System.map, Symbol _end is 0xc0252cf0. That would mean the uncompressed kernel size would be 1387760 bytes (0xc0252cf0-0xc010), right ? -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Die, 09 Jan 2001 you wrote: > On Tue, 9 Jan 2001, Robert Kaiser wrote: > > > Now comes the amazing (to me) part: I split the above statement up into: > > > > temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL); > > *pte = temp; > > this is almost impossible (except some really weird compiler bug) - unless > the mem_map address is invalid. This could happen if your kernel image is > *just* too large. Do things improve if you disable eg. ext2fs support (i > know, but should be enough to boot). Sorry, no ext2fs in this kernel (it is for a diskless embedded system). I seem to recall though that the problem at one point magically went away when I disabled the FPU emulation, but I have not been able to reproduce this recently, so I'm not sure. Making minor changes to the kernel code (such as adding/removing some test-prints) certainly does not affect the behavior. > Or if that part is not mapped > correctly (which does happen sometimes as well). What could I do to check/fix this ? > > and are you sure it crashes there? [are you putting delays between your > printouts?] I have put a "halting statement" (i.e. "while(1);") after my printouts to make sure execution does not go any further than that point. I moved this halting statement ahead in the code line by line until the crash would occur again. So, yes, I am pretty sure. > > > where temp is declared "volatile pte_t". I inserted test-prints between the > > above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the > > mk_pte_phys() macro is causing the crash! > > it accesses mem_map variable, which is near to the end of the kernel > image, so it could indeed something of that sort. An uncompressed kernel > image (including the data area) must not be bigger than 4MB (IIRC). According to my System.map file, mem_map is at 0xc0244f78. Does that help ? Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Wed, 10 Jan 2001, Alan Cox wrote: > > Does linux cater of all the old 386 chip bugs - especially the memory > > management oddities? > > So called 'sigma sigma' 386 and higher. Ie we dont support the 386 with the > 32bit mul bugs. Is this a new thing in 2.4.0 ? Could it possibly cause a crash as early as pagetable_init() ? -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germanyfax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
Hi Miles, Thanks very much for your suggestions! On Tue, 9 Jan 2001, Miles Lane wrote: > Just out of curiosity, did you use a 2.2 series > .config file and then run make oldconfig or did > you build a new .config file from scratch? No, I built it from scratch with make xconfig. > > I have periodically built kernels that crashed > immediately at the point you mention. Usually this > was due to me choose configuration options that > were incompatible with my machine's hardware. You mean they crashed at the exact same statement ? That would be an interesting hint, can you confirm it ? > > Another time, the machine wouldn't boot because > I needed a new version of LILO. I also have seen > at least one machine where I needed to specify > "linear" as one of the options in lilo.conf. > If you aren't specifying "linear" now, give it > a try. I am not using LILO (yet). I tried booting with SYSLINUX or by dumping the kernel binary to floppy and booting from it. Both showed the same result. Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germanyfax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Wed, 10 Jan 2001, Anuradha Ratnaweera wrote: > > I was just wondering if the kernel size has got to do anything to do with > this. Did you try a very very small kernel with the minimal features > anyway? > I tried this: kernel is now 277KB compressed, 725KB uncomressed. Still no effect :-( -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germanyfax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Wed, 10 Jan 2001, Ingo Molnar wrote: > math-FPU emulation takes up quite some space in the kernel image, so this > could indeed be the case. Could you disable any non-boot-essential > subsystem (networking, or the serial driver, or anything else), to > significantly reduce the image size? > I tried this: apparently no effect. However, there may be hardware issues involved (see below). > not really. Could you write a small function that just reads the kernel > image from the first symbol to the last one, and see whether it crashes? > (read it into a volatile variable to make sure GCC reads it.) I tried this: Reading the entire image never caused any crashes. However, I did have some (rare) instances of the kernel booting successfully. Then it would fail again, booting the very same image that had worked before. I am beginning to suspect that I may be dealing with flaky hardware. (I'm working from home today and I only have access to one of my 386 specimen here). I guess I'll better shut up until I can double check on some other 386 boards tomorrow In the meantime, it would be helpful if anyone who has successfully booted a 2.4.0 kernel on a 386 could report this to the list. -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germanyfax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Anybody got 2.4.0 running on a 386 ?
On Wed, 10 Jan 2001, Alan Cox wrote: > > > So called 'sigma sigma' 386 and higher. Ie we dont support the 386 with the > > > 32bit mul bugs. > > > > Is this a new thing in 2.4.0 ? Could it possibly cause a crash as > > early as pagetable_init() ? > > We've never supported pre sigmasigma cpus although someone posted a patch to > Linux 1.2 once. You won't find many of the cpus before that. At the time 386 > was priced like a Xeon is now and most were recalled/pulled when the mul bug > came out. > Ok, in that case it can't be related to the problem I am seeing. Thanks for the info. Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germanyfax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[SOLVED + PATCH] Re: Anybody got 2.4.0 running on a 386 ?
Hi everybody,
I finally found the reason why 386es have trouble booting the 2.4.0 kernel:
In routine pagetable_init() in arch/i386/mm/init.c, a pte gets installed before
it actually has been filled with valid entries. This causes the kernel text
segment to be temporarily unmapped. Pentiums are only lucky to not crash
because they have a bigger TLB than 386s.
Here is a patch to fix this:
--- init.c.orig Wed Nov 29 07:43:39 2000
+++ init.c Mon Jan 15 18:36:08 2001
@@ -317,7 +317,7 @@
pgd_t *pgd, *pgd_base;
int i, j, k;
pmd_t *pmd;
- pte_t *pte;
+ pte_t *pte, *pte_base;
/*
* This can be zero as well - no problem, in that case we exit
@@ -366,11 +366,7 @@
continue;
}
- pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
- set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte)));
-
- if (pte != pte_offset(pmd, 0))
- BUG();
+ pte_base = pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
for (k = 0; k < PTRS_PER_PTE; pte++, k++) {
vaddr = i*PGDIR_SIZE + j*PMD_SIZE + k*PAGE_SIZE;
@@ -378,6 +374,10 @@
break;
*pte = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
}
+ set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte_base)));
+ if (pte_base != pte_offset(pmd, 0))
+ BUG();
+
}
}
Thanks to everybody who helped with ideas and suggestions, especially Ingo
Molnar!
Cheers
Rob
----
Robert Kaiser email: [EMAIL PROTECTED]
SYSGO RTS GmbH
Am Pfaffenstein 14phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
No Subject
On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86 > hardware? It doesn't even seem to start (I get nothing on the screen from >t he kernel, it just sits there and does nothing). :( What processor does it use ? (386 or 486 perchance?) -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 on Cobalt hardware
On Fre, 19 Jan 2001 you wrote: > On Fri, 19 Jan 2001, RobertKaiser wrote: > > > On Thu Jan 18 16:30:30 2001 [EMAIL PROTECTED] wrote > > > Has anyone had any luck getting a 2.4 kernel to run on Cobalt x86 > > > hardware? It doesn't even seem to start (I get nothing on the screen from > > >t he kernel, it just sits there and does nothing). :( > > > > What processor does it use ? (386 or 486 perchance?) > > AMD K6 (so 586) - I was trying the i386 version of the kernel on it > though, if that's going to be a problem, I can try the 586 version... I was asking because the 2.4.0 kernel has a bug that causes it to fail on 386 and 486 CPUs with the same symptoms as you described. I don't know much about the K6, so I can't tell whether it will fall into the same trap (I guess it won't). Nevertheless, if you want to be sure, try the latest (pre8) patch from ftp://ftp.kernel.org/pub/linux/kernel/testing/ that particular bug has been fixed in that version. Good Luck Rob Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
unresolved reference to hd_init (2.4.0-test10, ll_rw_blk.c)
Hi, I just ran into a small problem trying to build the 2.4.0-test10 kernel with only the "Old hard disk (MFM/RLL/IDE) driver" enabled. The following patch fixed this for me, (though I'm not sure I haven't broken anything else with it). diff -ur linux-2.4.0-test10/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c --- linux-2.4.0-test10/drivers/block/ll_rw_blk.cFri Oct 27 08:35:47 2000 +++ linux/drivers/block/ll_rw_blk.c Mon Nov 6 17:34:39 2000 @@ -1063,7 +1063,7 @@ #if defined(CONFIG_IDE) && defined(CONFIG_BLK_DEV_IDE) ide_init(); /* this MUST precede hd_init */ #endif -#if defined(CONFIG_IDE) && defined(CONFIG_BLK_DEV_HD) +#if defined(CONFIG_IDE) && defined(CONFIG_BLK_DEV_HD) && +!defined(CONFIG_BLK_DEV_HD_ONLY) hd_init(); #endif #ifdef CONFIG_BLK_DEV_PS2 -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: setup.S: A20 enable sequence (once again)
> This doesn't really work. Neither the fast A20 gate nor the KBC is > guaranteed to have immediate effect (on most systems they won't.) In that case, maybe I should do repeated calls to a20_check with a (not too big) retry count after the port 92 write ? Problem is, it happens to work this way on all hardware I have access to, so I can't really reproduce such timing problems. Anyone ? > What's worse, once you have done an "out" to the KBC you need to > finish the sequence. I need to think about this for a bit. ??? I'm not touching the KBC if the port 92 access was successful at enableing A20. If, however, A20 is still disabled, I'm doing the same KBC sequence as the original code, so there shouldn't be any incomplete KBC interactions (unless I mistyped something...). > (Arguably, what you're doing is running on completely nonstandard > hardware, which may need a CONFIG_ option. However, if we can avoid > it I guess it's better.) That was exactly my intention :-) ---- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: setup.S: A20 enable sequence (once again)
On Mon, 06 Nov 2000 you wrote: H. Peter Anvin wrote > I just looked at the code, and it's worse than I first thought: if > memory location 0x200 happens to contain 0x0001 when the kernel is > entered, this code with loop indefinitely. Ooops, you're right ! How about this one: diff -ur linux-2.4.0-test10/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S --- linux-2.4.0-test10/arch/i386/boot/setup.S Mon Oct 30 23:44:29 2000 +++ linux/arch/i386/boot/setup.SMon Nov 6 21:14:45 2000 @@ -631,6 +631,26 @@ # appropriate # that was painless, now we enable a20 +# Try the "fast A20" version first: +# You must preserve the other bits here. Otherwise embarrasing things +# like laptops powering off on boot happen. Corrected version by Kira +# Brown from Linux 2.2 +# + inb $0x92, %al # + orb $02, %al# "fast A20" version + andb$0xfe, %al # be sure not to reset CPU + outb%al, $0x92 # some chips have only this + +# See if that already did the job, skip keyboard controller +# accesses if so: some boards do not have a keyboard controller. +# These boards (especially if running on a slowish 386 EX) +# can spend several *minutes* in silence, polling for the +# non-existent keyboard controller. + + movw$0x100,%cx # small retry count + calla20_check + jne a20_enabled + callempty_8042 movb$0xD1, %al # command write @@ -641,20 +661,20 @@ outb%al, $0x60 callempty_8042 -# -# You must preserve the other bits here. Otherwise embarrasing things -# like laptops powering off on boot happen. Corrected version by Kira -# Brown from Linux 2.2 -# - inb $0x92, %al # - orb $02, %al# "fast A20" version - outb%al, $0x92 # some chips have only this - # wait until a20 really *is* enabled; it can take a fair amount of # time on certain systems; Toshiba Tecras are known to have this # problem. The memory location used here (0x200) is the int 0x80 # vector, which should be safe to use. +a20_recheck: + movw$0x,%cx # large retry count + calla20_check + jne a20_enabled + jmp a20_recheck # loop until no longer aliased + +# +# cx has retry count +a20_check: xorw%ax, %ax# segment 0x movw%ax, %fs decw%ax # segment 0x (HMA) @@ -663,9 +683,11 @@ incw%ax # unused memory location <0xfff0 movw%ax, %fs:(0x200)# we use the "int 0x80" vector cmpw%gs:(0x210), %ax# and its corresponding HMA addr - je a20_wait# loop until no longer aliased + loopz a20_wait + ret # make sure any possible coprocessor is properly reset.. +a20_enabled: xorw%ax, %ax outb%al, $0xf0 calldelay -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
A20 Gate enable sequence (setup.S)
Hi list, There seem to be two common methods for ix86-based boards to enable the A20 line: The traditional method that uses the keyboard controller (this is what Linux supports) and a method (sometimes referred to as "fast A20 Gate") that uses a special port address (0x92). Some boards (especially in the embedded PC area) implement only the latter method (some don't even _have_ a keyboard controller). With these boards, Linux fails to boot. The fix for this is pretty simple (see below) and I wonder if it would be possible to get this fix into the kernel by default. Cheers Rob -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14http://www.elinos.com D-55270 Klein-Winternheim / Germany http://www.sysgo.de diff -urN linux-2.4.0-test8/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S --- linux-2.4.0-test8/arch/i386/boot/setup.SWed Jul 19 07:00:33 2000 +++ linux/arch/i386/boot/setup.SFri Oct 13 18:00:42 2000 @@ -631,6 +631,16 @@ # appropriate # that was painless, now we enable a20 + +# enable the "fast" A20 gate + + in al,#0x92 + or al,#2 + and al,#0xfe + out #0x92,al + +# enable the keyboard controller A20 gate + callempty_8042 movb$0xD1, %al # command write - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A20 Gate enable sequence (setup.S)
On Fre, 13 Okt 2000 you wrote: > > Some boards (especially in the embedded PC area) implement only the > > latter method (some don't even _have_ a keyboard controller). > > With these boards, Linux fails to boot. > > Try the current 2.2.18pre. This has fast A20 too and I suspect will boot > on your box. Its had no problems on 2.2.18pre reported against it so far. I've > not done a 2.4 test patch but yours seems to be the sam ething Thanks for the hint, I hadn't checked that version > > AMD ELAN ? Actually several different boards, some using AMD ELAN, some 386 EX. Rob -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A20 Gate enable sequence (setup.S)
On Fri, 13 Oct 2000, Albert Cranford wrote: > Robert Kaiser wrote: > > > > On Fre, 13 Okt 2000 you wrote: > > > > Some boards (especially in the embedded PC area) implement only the > > > > latter method (some don't even _have_ a keyboard controller). > > > > With these boards, Linux fails to boot. > > > > > > Try the current 2.2.18pre. This has fast A20 too and I suspect will boot > > > on your box. Its had no problems on 2.2.18pre reported against it so far. I've > > > not done a 2.4 test patch but yours seems to be the sam ething > > > > Thanks for the hint, I hadn't checked that version > > > > > > > > AMD ELAN ? > > > > Actually several different boards, some using AMD ELAN, some 386 EX. > > > > Rob > > > > Here is a wroking 2.4.0 version, which is from Randy Dunlaps patch. > Later, > Albert Thanks Albert! Actually I was aware of this patch (saw it in the archives), but, it seemed to me that this patch hadn't made it into the standard kernel (2.4.0-test8 didn't have it), so I thought I might bring up this issue once more. I just learned from Alan, that he added it in 2.2.18pre, so I'll test that one and if it works, I'll be all happy :-). Rob Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14 http://www.elinos.com D-55270 Klein-Winternheim / Germany http://www.sysgo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A20 Gate enable sequence (setup.S)
> The AMD/Elan box snoops for the sequence sent to the keyboard > controller to enable A<20>. Are you sure this is true of all boards using the AMD Elan ? So far, I've dealt with three different AMD Elan boards and only one of them (Jumptec DIMM-PC) seemed to have this feature. But even on that one, Linux wouldn't boot out of the box because of A20 problems (you had to reset the keyboard controller to make it work). > However, it also respects the port > 0x92 control. The i386EX has port 0x92 built in (it does not have a built-in keyboard controller ..), so port 0x92 should work on all 386EX boards whereas the keyboard controller sequence may or may not work. > The AMD/Elan chip also comes to life after a hardware reset with > A<20> enabled. So, if you don't turn it OFF, there won't be any > problem during the protected-mode transition. Sure, but whether you CAN leave it on depends on the board's BIOS. Some of them are "smart" and won't let you configure the initial A20 state. Adding the port 0x92 method to setup.S as I'm suggesting would be safe in all cases (assuming it won't break anything else). Rob Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14http://www.elinos.com D-55270 Klein-Winternheim / Germany http://www.sysgo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: A20 Gate enable sequence (setup.S)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Richard B. Johnson) writes: > On Sun, 15 Oct 2000, Robert Kaiser wrote: > >> > The AMD/Elan box snoops for the sequence sent to the keyboard >> > controller to enable A<20>. >> > Robert Kaiser didn't write this. I did. And yes. It makes no difference > about the 'board' it's in the chip. Well, if it is in the chip, then what ever is in there doesn't work properly: I have seen several different AMD Elan boards that failed to boot Linux. Adding the "fast A20 enable" via port 0x92 to setup.S fixed the problem in all cases. >> > The AMD/Elan chip also comes to life after a hardware reset with >> > A<20> enabled. So, if you don't turn it OFF, there won't be any >> > problem during the protected-mode transition. >> >> Sure, but whether you CAN leave it on depends on the board's BIOS. >> Some of them are "smart" and won't let you configure the initial >> A20 state. Adding the port 0x92 method to setup.S as I'm suggesting >> would be safe in all cases (assuming it won't break anything else). >> > > Many who use Linux in embeded systems write their own BIOS as I > have done. Then you don't have to pay $10/box you ship to a BIOS > vendor who ripped off all the code anyway. I hope you are not seriously suggesting that everyone who uses Linux in embedded systems should be prepared to write their own BIOS. Of course it's nice if you don't have to pay BIOS royalties, but in my experience, people who have a high enough volume so that writing their own BIOS would make sense tend to go for a different architecture (PPC, ARM, MIPS, SH) in the first place. (BTW, is your BIOS under GPL perchance ?) > FYI, the code that was submitted can't possibly work (it was backwards). > If it made your board 'work' there is something else broken. Yep, my fault: The code _did_ work in a 2.2.x kernel, but I applied the change to the latest 2.4 kernel, not realizing that the assembly syntax had been changed in the meantime. I should have at least tested it. See below for a corrected version. This time I've tested it: the unmodified kernel fails to boot on a JUMPtec DIMM-PC (with AMD Elan SC410), the patched kernel does boot. Some may argue that simply writing 0x02 to port 0x92 would do the job and they may well be right (it does work that way on the DIMM-PC). My suggested code makes sure to keep bits #7-#2 unmodified and it always clears bit #0 (CPU reset). Call me paranoid, but I think this is worth two extra assembly instructions :-). diff -urN linux-2.4.0-test8/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S --- linux-2.4.0-test8/arch/i386/boot/setup.SWed Jul 19 07:00:33 2000 +++ linux/arch/i386/boot/setup.SMon Oct 16 15:27:48 2000 @@ -631,6 +631,16 @@ # appropriate # that was painless, now we enable a20 + +# enable the "fast" A20 gate + + inb $0x92, %al + orb $0x02, %al + andb $0xfe, %al + outb%al, $0x92 + +# enable the keyboard controller A20 gate + callempty_8042 movb$0xD1, %al # command write Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Disk is cheap?
> Everyone who says, disk is cheap, ought to donate me one. > Everyone who says, memory is cheap, has to send me some. :-) Perhaps a more convincing argument may be that in embedded devices, disk as well as memory and CPU power are _not_ cheap. The more resources Linux requires, the less are it's chances of being accepted as a viable alternative in embedded systems. > I'm still stuck with a P-133, 56 MB RAM (60-70 ns, some EDO, > some FPM) and not only Linux but also W2K on a 2.1 and a 0.8 GB > HDD. That would be _a_ _lot_ for an embedded system! -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Patrizio Bruno) writes: > I built a embedded dvd/cdda/mp3 player based on linux, using a p200mmx > with 24mb with a bus of 75mhx, but it still takes about 20 seconds to boot, > I think that an embedded device (for home use) should boot in less than > 5 seconds, how could be possible with a slow p133? (I've also tried a p133 > on 66mhz of bus and it takes almost 35 seconds to boot) Usually most of the startup time is spent by the BIOS doing extensive self-test stuff and for firing up services (http, inetd, sendmail, ...) that many embedded systems have little use for. I have a 25MHz 386EX (~2.2 Bogomips) here that boots Linux out of ROM in roughly 30 seconds. Most of _that_ time however is spent decompressing the kernel. > However, first or last old hardware will finish, and who wants to build > an embedded device should use high cost embedded hardware (high cost for me). Hmm, since embedded devices are usually built in large scale series, cost is quite an important factor. Neverthless, even if you leave that aside, there is the even more important question of size, power consumption and heat dissipation: Any processor that requires a fan is simply unacceptable in most embedded designs. (Plus, you don't need the speed of an 1GHz Athlon to control a washing machine...) That is the reason why relatively low-performing chips such as i386EX, AMD Elan SC[45][012]0 are very popular in embedded devices. These chips are by no means "old hardware" ! Did you know that about 95% of the worldwide microprocessor production end up in some sort of appliance/embedded system ? I'm pretty sure these "low-end" processors will not go away as quickly as you might think. Whether they will be running Linux in the future will depend on Linux's resource requirements. Cheers Rob ---- Robert Kaiser email: rkaiser AT sysgo DOT de SYSGO RTS GmbHhttp://www.elinos.com Klein-Winternheim / Germany http://www.sysgo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
On Sam, 03 Feb 2001 you wrote: > > Usually most of the startup time is spent by the BIOS doing > > extensive self-test stuff and for firing up services (http, > > inetd, sendmail, ...) that many embedded systems have little use > > for. > > Actually, most of that time is spent running bash/sleep 1. Startup > scripts tend to be poorly designed. Yes! > > I have a 25MHz 386EX (~2.2 Bogomips) here that boots Linux out of ROM > > in roughly 30 seconds. Most of _that_ time however is spent decompressing > > the kernel. > > You might want to set up XIP and run kernel directly off the ROM... > Hmm, that board has only 512KB ROM. I can fit a minimal Linux kernel and root-FS in that, but only if it's compressed. ROM, in my experience, is more expensive than RAM, so it often makes sense to save ROM space even at the expense of using a little more RAM. But I'm curious: is there a simple procedure to set up a linux Kernel to execute from ROM ? ---- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Disk is cheap?
On Die, 06 Feb 2001 you wrote: > But paring down the startup scripts is a good idea. For something like an embedded > device, you might even want to go with a custom init, Yes, I'm using busybox (see busybox.lineo.com). It's a multi-call binary that contains a simplified init, a shell and a host of other nice things. > that just runs your main program. Well the _very_ minimal approach is to have your main program _be_ init :-) -------- Robert Kaiser email: [EMAIL PROTECTED] SYSGO RTS GmbH Am Pfaffenstein 14phone: (49) 6136 9948-762 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
