coreboot

coreboot@coreboot.org

12 participants
39779 discussions

flash_rom and tiger-i7501
by Will Dinkel 15 Apr '03

15 Apr '03

flash_rom experts: Has anyone managed to successfully flash a tiger-i7501 with flash_rom? On all of my attempts it can't manage to find an EEPROM: ---------------- Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 485M loops per second OK, calibrated, now do the deed Enabling flash write on E7500...OK Trying Am29F040B, 512 KB probe_29f040b: id1 0x1f, id2 0x8b Trying At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0x60 Trying Mx29f002, 256 KB probe_29f002: id1 191, id2 96 Trying SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST28SF040A, 512 KB probe_28sf040: id1 0x1f, id2 0x8b Trying SST39SF020A, 256 KB probe_39sf020: id1 0xbf, id2 0x60 Trying SST39VF020, 256 KB probe_39sf020: id1 0xbf, id2 0x60 Trying W29C011, 128 KB probe_jedec: id1 0xbf, id2 0x60 Trying W29C020C, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying W49F002U, 256 KB probe_49f002: id1 0xbf, id2 0x60 Trying M29F400BT, 512 KB probe_m29f400bt: id1 0x1f, id2 0x8 Trying 82802ab, 512 KB probe_82802ab: id1 0x1f, id2 0x8b Trying 82802ac, 1024 KB probe_82802ab: id1 0x1f, id2 0x8b EEPROM not found ----------------- -- Will Dinkel Atipa Technologies wdinkel(a)atipa.com (785) 841-9513 x3111 http://www.atipa.com

4 3

[COMMIT] sync up pass 3
by ebiederman＠lnxi.com 14 Apr '03

14 Apr '03

First stab at synchronizing the questionable code. The NLBConfig.py and getpir changes are safe simple changes. The read_bytes.h and rom_fill_inbuf.c removes tag support from LinuxBIOS altogether. The code is in the baremetal toolkit so we should not need it bloating the common code. Eric include/rom/read_bytes.h - Remove baremetal toolkit code src/rom/rom_fill_inbuf.c - Remove tag support util/config/NLBConfig.py - Remove crt0.o from OBJECTS-1 util/getpir/Makefile - set LINUXBSIOSROOT to an always working path

2 2

Etherboot ...
by Denis Pilon 14 Apr '03

14 Apr '03

OK. Got an image built using etherboot-5.0.8 I think it works, but the e1000 driver is to old so it can't network boot. Using the etherboot-5.1.3, the elf image is to big. How do I shrink the romimage to fit 524288 ? Denis

2 1

RE: Still not having success with SM P4DPE
by Atherton, Stephen 14 Apr '03

14 Apr '03

Linuxbios.strip is 49152 bytes, and eepro100.elf is 22368. So that gives a total of 71520...larger than 65536. So one of them is too big. Any idea which? -Steve -----Original Message----- From: steven james To: Atherton, Stephen Cc: 'linuxbios(a)clustermatic.org' Sent: 4/11/03 9:25 AM Subject: Re: Still not having success with SM P4DPE Greetings, It looks like the fallback image is being built wrong. This can be hacked together manually. linuxbios.strip should be the actual LinuxBIOS code. The objective is to assemble a 64K (exactly) block containing: 1. etherboot 2. null padding (can be generated with dd if=/dev/zero) 3. linuxbios.strip. I just use calctool to figure out how much padding to use and cat eepro100.elf pad linuxbios.strip >fallback.bin the 64K fallback.bin can then be appended to the primary image to get the full rom image. That's a little ugly, but it should get the job done. Just as a final verification, in linuxbios.map, ZKERNEL_START for the fallback image should be 0xffff0000. That is whjere it will look for the fallback etherboot. Also, it will ljmp to ZKERNEL_START-8 to transfer control to the primary image. I'm slowly trying to disentangle that on the boards I have. Unfortunatly, I don't have a P4DPE. G'day, sjames On Fri, 11 Apr 2003, Atherton, Stephen wrote: > Ron and James, thanks for clueing me in on the fallback image stuff. I'm > still not quite doing something right though, it seems. > > My config files are below. I based these on the samples in > mainboard/supermicro/p4dpe. The fallback image is 81k and contains the > etherboot payload...this doesn't seem right to me but I don't know what else > to do. If I don't specify the etherboot payload, it tries to use vmlinux > which is much, much bigger. > > So I run the config script on both files, then go to the fallback/ and > primary/ directories and run make, and I get a primary romimage of 458752 > bytes and a fallback image of 81920 bytes. That doesn't seem right. What > am I doing wrong? Oh and though I was doubtful, I did do a "cat > primary/romimage fallback/romimage > finalimage" and burned the final image. > > > Also, from the looks of the makeprocess my two image files are basically the > same binary stuff but one has a lot of null padding. They both contain the > eepro100 elf image and linuxbios.rom... > > Anyone see what is wrong with this picture? > > -Steve > > > > > fallback.config -------------------------------------------- > > target ./fallback > mainboard supermicro/p4dpe > option USE_FALLBACK_IMAGE=1 > option ROM_SIZE=524288 > option ROM_IMAGE_SIZE=49152 > option SERIAL_CONSOLE=1 > option TTYS0_BAUD=9600 > option TTYS0_BASE=0x3f8 > option TTYS0_LCS=0x3 > option DEFAULT_CONSOLE_LOGLEVEL=9 > option MAXIMUM_CONSOLE_LOGLEVEL=6 > option USE_ELF_BOOT=1 > option USE_GENERIC_ROM=1 > payload ../eepro100.elf > option CPU_CLOCK_MULTIPLIER=XEON_X8 > option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON > > > primary.config -------------------------------------------------- > > target primary > mainboard supermicro/p4dpe > linux /usr/src/linux-2.4.18-14 > commandline root=/dev/hda2 console=ttyS0,9600 single > option USE_FALLBACK_IMAGE=0 > option ROM_SIZE=524288 > option ROM_IMAGE_SIZE=49152 > option SERIAL_CONSOLE=1 > option TTYS0_BAUD=9600 > option TTYS0_BASE=0x3f8 > option TTYS0_LCS=0x3 > option DEFAULT_CONSOLE_LOGLEVEL=9 > option MAXIMUM_CONSOLE_LOGLEVEL=8 > option USE_ELF_BOOT=1 > option BOOT_IDE=1 > payload ../eepro100.elf > option CPU_CLOCK_MULTIPLIER=XEON_X8 > option MAINBOARD_POWER_ON_AFTER_POWER_FAIL=MAINBOARD_POWER_ON > -- -------------------------steven james, director of research, linux labs ... ........ ..... .... 230 peachtree st nw ste 2701 the original linux labs atlanta.ga.us 30303 -since 1995 http://www.linuxlabs.com office 404.577.7747 fax 404.577.7743 -----------------------------------------------------------------------

4 3

Power PC support added
by ron minnich 14 Apr '03

14 Apr '03

I just did a commit for PPC. It all looks ok but as always there may be a problem or two. Let me know. Also welcome Greg Watson (gwatson(a)lanl.gov) as a new committer, managing the PPC. ron

1 0

supermicro ... etherboot
by Denis Pilon 14 Apr '03

14 Apr '03

Got linuxbios coming up on a x5dpe-g2, but it will not grab an IP. It just sits there looking for dhcp server. Looking at the dhcp logs, the etherboot never sends the DHCPACK. What do I do ? FYI: using etherboot 5.1.7 Denis -- =================================================== Denis E. Pilon Systems Integration Specialist Atipa Technologies http://www.atipa.com/ dpilon(a)atipa.com (785)841-9513 x3111 ===================================================

3 2

Re: Dear sir
by ebiederman＠lnxi.com 14 Apr '03

14 Apr '03

gururaj thirtha <gururajthirtha(a)yahoo.com> writes: > Dear Mr.Eric Biederman > > > How can I proceed to implement LinuxBIOS ? > > pls send me the details as known by you. > > Is new kernel building is necessary for that project ? I am bouncing your question to the LinuxBIOS mailing list. Eric

1 0

Geode
by J P 14 Apr '03

14 Apr '03

Hi, I am using geode sc1200 chip. I have to do some initialization to my sc1200 and then load my linux OS from hard disk to SDRAM. Can linux bios satisfy all these? What else can linux bios do? Catch all the cricket action. Download Yahoo! Score tracker

4 3

Kernel exec functions and new problems (long)
by Gregg C Levine 13 Apr '03

13 Apr '03

Hello again from Gregg C Levine Well, switching to the latest of Eric's kernel exec tool, has made a difference. Instead of getting those annoying "oops" messages, I am now getting something far more meaningful. Although it means nothing to me, (or it should and I don't know what to look for), it does indicate, that your assertions Andrew are leaning towards being correct. Here's the message: Script started on Sun Apr 13 11:36:57 2003 root@who4:/usr/src/LoBos/work# ./kexec kernel.elf kexec_load failed: Function not implemented entry = (nil) nr_segments = 4 segment[0].buf = 0x80a8ee8 segment[0].bufsz = 158 segment[0].mem = (nil) segment[0].memsz = 158 segment[1].buf = 0x80a3888 segment[1].bufsz = 55e0 segment[1].mem = 0x10000 segment[1].memsz = 55e0 segment[2].buf = 0x80a8e70 segment[2].bufsz = 0 segment[2].mem = 0x91000 segment[2].memsz = 0 segment[3].buf = 0x40001008 segment[3].bufsz = b48dc segment[3].mem = 0x100000 segment[3].memsz = 700000 root@who4:/usr/src/LoBos/work# exit Script done on Sun Apr 13 11:37:15 2003 At a guess, I'd say, it is telling me that the function was not correctly implemented on this kernel, which is 2.4.20. So, this does backup that notion that I should grab a copy of the raw 2.4.19 sources. I'll do that later today, and try again. However while building the version 1.8 tool, I received a number of warnings, nothing severe just simple warnings. I'll post them after the signature block. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) Script started on Sun Apr 13 11:38:51 2003 root@who4:/usr/src/LoBos/kexec-tools-1.8# make mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/kexec.o -c kexec/kexec.c mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/kexec-syscall.o -c kexec/kexec-syscall.c mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/kexec-x86.o -c kexec/kexec-x86.c mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/kexec-elf32-x86.o -c kexec/kexec-elf32-x86.c mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/kexec-bzImage.o -c kexec/kexec-bzImage.c kexec/kexec-bzImage.c: In function `bzImage_load': kexec/kexec-bzImage.c:163: warning: `fp_ramdisk' might be used uninitialized in this function mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/ifdown.o -c kexec/ifdown.c mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/x86-setup-32.o -c kexec/x86-setup-32.S mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/x86-setup-16.o -c kexec/x86-setup-16.S mkdir -p objdir/kexec gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -o objdir/kexec/x86-setup-16-debug.o -c kexec/x86-setup-16-debug.S /tmp/cc12pRzT.s: Assembler messages: /tmp/cc12pRzT.s:254: Warning: indirect jmp without `*' mkdir -p objdir/util_lib gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -c -o objdir/util_lib/compute_ip_checksum.o util_lib/compute_ip_checksum.c mkdir -p objdir ar rs ./objdir/libutil.a ./objdir/util_lib/compute_ip_checksum.o mkdir -p objdir/build/sbin gcc -Wall -g -O2 -fno-strict-aliasing -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -static -o objdir/build/sbin/kexec ./objdir/kexec/kexec.o ./objdir/kexec/kexec-syscall.o ./objdir/kexec/kexec-x86.o ./objdir/kexec/kexec-elf32-x86.o ./objdir/kexec/kexec-bzImage.o ./objdir/kexec/ifdown.o ./objdir/kexec/x86-setup-32.o ./objdir/kexec/x86-setup-16.o ./objdir/kexec/x86-setup-16-debug.o ./objdir/libutil.a mkdir -p objdir/kexec_test gcc -x assembler-with-cpp -E -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -DRELOC=0x10000 kexec_test/kexec_test16.S > objdir/kexec_test/kexec_test16.s mkdir -p objdir/kexec_test as -o objdir/kexec_test/kexec_test16.o objdir/kexec_test/kexec_test16.s mkdir -p objdir/kexec_test gcc -x assembler-with-cpp -E -I./util_lib/include -DVERSION='"1.8"' -DRELEASE_DATE='"01 December 2002"' -DRELOC=0x10000 kexec_test/kexec_test.S > objdir/kexec_test/kexec_test.s mkdir -p objdir/kexec_test as -o objdir/kexec_test/kexec_test.o objdir/kexec_test/kexec_test.s mkdir -p objdir/build/bin ld -e _start -Ttext 0x10000 ./objdir/kexec_test/kexec_test16.o ./objdir/kexec_test/kexec_test.o -o objdir/build/bin/kexec_test root@who4:/usr/src/LoBos/kexec-tools-1.8# exit exit Script done on Sun Apr 13 11:39:39 2003 And that's what it said. Now where do I install everything?

1 0

Kexec and kernel oops
by Gregg C Levine 12 Apr '03

12 Apr '03

Hello from Gregg C Levine Here is a strange bit of events, I just finished recompiling my Linux box's 2.4.20 kernel, after applying the kernel patch supplied by Andrew Ip. The patch applied with the usual amount of fuss. No problems surfaced during the build process. Nor with anything else. Except for the kernel exec tool. Since I wasn't sure if Andrew had back ported the ones from the 2.5 series to the 2.4.20, and 2.4.19 ones, I chose the original command line one, and built that. I chose the original 2..2.19 kernel as the one to exec. Original that is, because this version of Slackware is 8.0, and that's the version that works for it to install correctly here. Also the tools that I have used, are from that release version. Each of the different versions of the make elf Image tools from 1.6, to 2.0 that I tried,. gave me an oops message, and caused the program to abort with a segmentation fault. Here's a cut and paste of my oops message from the dmesg log: Script started on Sun Apr 13 02:36:24 2003 root@who4:/usr/src/LoBos/work# kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b6f18 edi: 0002df48 ebp: c0eafd40 esp: c0eafd20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 131, stackpage=c0eaf000) Stack: 04000000 00010740 c10b6f9c c0eafd9c 00000080 c10b6f1c 00000282 c105f2c0 c0eafd9c c014f00e c10b6f1c 00000080 c0eafdd0 c0eafe9c 00000000 00010740 00000004 c10b6f1c 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b69c8 edi: 0002df48 ebp: c0e8dd40 esp: c0e8dd20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 146, stackpage=c0e8d000) Stack: 04000000 00010740 c10b6a4c c0e8dd9c 00000080 c10b69cc 00000286 c105f2c0 c0e8dd9c c014f00e c10b69cc 00000080 c0e8ddd0 c0e8de9c 00000000 00010740 00000004 c10b69cc 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b6f18 edi: 0002df48 ebp: c0e8dd40 esp: c0e8dd20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 150, stackpage=c0e8d000) Stack: 04000000 00010740 c10b6f9c c0e8dd9c 00000080 c10b6f1c 00000282 c105f2c0 c0e8dd9c c014f00e c10b6f1c 00000080 c0e8ddd0 c0e8de9c 00000000 00010740 00000004 c10b6f1c 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b69c8 edi: 0002df48 ebp: c1e83d40 esp: c1e83d20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 170, stackpage=c1e83000) Stack: 04000000 00010740 c10b6a4c c1e83d9c 00000080 c10b69cc 00000286 c105f2c0 c1e83d9c c014f00e c10b69cc 00000080 c1e83dd0 c1e83e9c 00000000 00010740 00000004 c10b69cc 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b6f18 edi: 0002df48 ebp: c1727d40 esp: c1727d20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 213, stackpage=c1727000) Stack: 04000000 000107a0 c10b6f9c c1727d9c 00000080 c10b6f1c 00000282 c105f2c0 c1727d9c c014f00e c10b6f1c 00000080 c1727dd0 c1727e9c 00000000 000107a0 00000004 c10b6f1c 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b69c8 edi: 0002df48 ebp: c1727d40 esp: c1727d20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 840, stackpage=c1727000) Stack: 04000000 000107a0 c10b6a4c c1727d9c 00000080 c10b69cc 00000286 c105f2c0 c1727d9c c014f00e c10b69cc 00000080 c1727dd0 c1727e9c 00000000 000107a0 00000004 c10b69cc 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c012041d>] [<c01bdfbd>] [<c0186c38>] [<c017f32f>] [<c017b02e>] [<c017f14c>] [<c0132e27>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b6f18 edi: 0002df48 ebp: c19d9d40 esp: c19d9d20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 845, stackpage=c19d9000) Stack: 04000000 000107a0 c10b6f9c c19d9d9c 00000080 c10b6f1c 00000282 c105f2c0 c19d9d9c c014f00e c10b6f1c 00000080 c19d9dd0 c19d9e9c 00000000 000107a0 00000004 c10b6f1c 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c017e7b8>] [<c012041d>] [<c017cd39>] [<c017d2a2>] [<c017f32f>] [<c017b02e>] [<c0114dc6>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 kernel BUG at slab.c:1437! invalid operand: 0000 CPU: 0 EIP: 0010:[<c012b79a>] Not tainted EFLAGS: 00010016 eax: 5a2cf071 ebx: c10b6020 ecx: c105f2c0 edx: 6444c888 esi: c10b6f18 edi: 0002df48 ebp: c1a6fd40 esp: c1a6fd20 ds: 0018 es: 0018 ss: 0018 Process kexec (pid: 868, stackpage=c1a6f000) Stack: 04000000 000107a0 c10b6f9c c1a6fd9c 00000080 c10b6f1c 00000282 c105f2c0 c1a6fd9c c014f00e c10b6f1c 00000080 c1a6fdd0 c1a6fe9c 00000000 000107a0 00000004 c10b6f1c 464c457f 00010101 00000000 00000000 00030002 00000001 Call Trace: [<c014f00e>] [<c014b903>] [<c017e7b8>] [<c012041d>] [<c017cd39>] [<c017d2a2>] [<c017f32f>] [<c017b02e>] [<c0114dc6>] [<c0108a73>] Code: 0f 0b 9d 05 80 89 22 c0 8b 7d fc b8 71 f0 2c 5a 89 f2 03 57 root@who4:/usr/src/LoBos/work# exit Script done on Sun Apr 13 02:36:28 2003 As you can see, that's what caused the message. This time I tripped the kernel exec on a remote console, and watched the main one. The main one displayed the oops, and the remote console gave a segmentation fault as its error. So? Anybody out there, recognize the fault? I personally think it has to do with my choice of kernel exec command line tools. Also, versions 2.1, and 2.2. and 2.3 of the make elf Image too, didn't work here. I'll grab that as a script file for the latest release, and present it later. Andrew did you indeed back port the 2.5 series of kernel exec patch functions to the 2..4.19, and 2.4.20, as I have now decided? ------------------- P.S. If that's the case, then don't worry about it any. It is my fault for choosing the wrong tool to use first. --------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot