Re: : Magazine article on USB and Embedded systems
YhLu [EMAIL PROTECTED] writes: That's kernel, how about rootfs or initrd? I have some preliminary work but I need to dust off two years of bitrot, before it is usable again. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ACPI DSDT
Stefan Reinauer [EMAIL PROTECTED] writes: Standards are a fine thing. Let's have everybody implement it's own. One thing about EFI that really sucks is that it is just absolutely chock full of pointers in it's interfaces. Which makes it extremely ugly to support on platforms with both a 32/64bit platforms. At least that is what it looks like to me. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: : : : [COMMIT] romcc 0.63 and some fixes...
YhLu [EMAIL PROTECTED] writes:
Eric,
I add in console.c
static void printo_debug(const char *str) __attribute__((noinline))
{
print_debug(str);
}
About only chang print_debug in auto.c
It said
./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault
./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault
Cool, my first bug report. I knew I had touched to much code
for the new release to run without a hitch.
Could you look at the core dump with gdb and give me a back trace?
That should help even if I can't reproduce the problem on this end.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: romcc questions
John Usher (Maptek) [EMAIL PROTECTED] writes: Hi, I'm trying to get freebios2 going on a VT8606/VT82C686B board with a 533MHz VIA C3 processor. When trying to compile romcc, it gets to simple_test26 but reports it is out of registers. Can someone give me some indication of what is going on here? simple_test26 is one of the regression tests. In particular it is a register pressure test and it only works when romcc has been given the options to enable all of the registers. You can use make -k to get through all of the regression tests if you want. You should not need to build romcc independently of LinuxBIOS right now. The normal build process should ensure it is build before you need it. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios available for via kt400 chipset?
Has anyone linuxbios running on a asus a7v8x-x with kt400? regards Markus -- Sie haben neue Mails! - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
pirq checking
Hi, the current pirq code defines intel_irq_routing_table as const, thus making it potentially readonly. OTOH the code in arch/i386/boot/pirq_routing.c tries to correct the checksum and size entries in that table. I think that table should not be declared const, especially since we might want to create it dynamically later on. Opinions? Stefan ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: w86327hf superio.c
On Wed, 2 Jun 2004, YhLu wrote: Someone overwrite the superio.c for w86327hf. Before that it enter_ext_func mode and enable HWM of Winbond. that's our fault. The code for this part was really out of date in the way it worked, because it did not use Eric's new generic PNP functions, and we couldn't figure out what should stay and what should go. Can you send me a patch for what you think should happen and we'll put that support back in. thanks ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, 2004-06-03 at 02:56, Richard Smith wrote: What i've noticed that the emulator causes the Vbios to get stuck in some delay loops. Eventually it probally would exit but its currently making my logs huge and causing the knashing of much teeth. So I'm thinking that the emulator needs to intercept reads and writes to the system timer and provide a fake timer that increments 1 tick per some x instructions emulated. And hopfully the chips and the bioses that need this won't mind that the actuall delay is longer than what was requested. The original emulator in xfree86 use the system's gettimeofdate to emulate the timer. Since we are not going to have that function in linuxbios, I removed it. Probably we need an other way to emulate the timer. Ollie Any comments before I hack this in? I'm off to bed. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
The 'help me!' form on http://www.linuxbios.org/help/index.html is broken
Hi People, Just like the subject says: the form at http://www.linuxbios.org/help/index.html gives a really cute 404. Should I therefore mail my request for help to the mailing list or should I wait until the form gets back working? Regards, Erik Smit ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: pirq checking
On Thu, 3 Jun 2004, Stefan Reinauer wrote: the current pirq code defines intel_irq_routing_table as const, thus making it potentially readonly. should be const due to execute-in-place issues. OTOH the code in arch/i386/boot/pirq_routing.c tries to correct the checksum and size entries in that table. that's my fault I bet. I think that table should not be declared const, especially since we might want to create it dynamically later on. no, leave const unless we ALWAYS copy to memory and then work with it. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
Strange, I get a 404 at
http://www.linuxbios.org/cgi-bin/linuxbios/help.cgi when I click the
'submit form' button.
Anyhow, here's my information.
I have a 'Lex CV860A' which is untested at
http://www.linuxbios.org/status/index.html.
The flash device is a AMIC A29002.
I tried the freebios/src/mainboard/lex/cv860a/example.config with both a
memtest86+ payload and filo payload.
At first this does not compile due to what seems to be something that
was forgotten in the freebios/src/southbridge/via/vt82c686/southbridge.c
file.
+++ freebios.cvs060304/src/southbridge/via/vt82c686/southbridge.c 2002-10-11
01:55:17.0 +0200
+++ freebios/src/southbridge/via/vt82c686/southbridge.c 2004-06-03 20:11:04.0
+0200
@@ -93,7 +93,7 @@
// 0x80 is enable com port b, 0x1 is to make it com2, 0x8 is enable com port a
as com1
enables = 0x80 | 0x1 | 0x8 ;
if (dev) {
- pci_write_config_byte(0, devfn, 0x83, enables);
+ pci_write_config_byte(dev, 0x83, enables);
}
// note: this is also a redo of some port of assembly, but we want everything
up.
// set com1 to 115 kbaud
After flashing the machine does not boot or give any output over the
serial port.
We have a nullmodem cable from the ttyS0 to another machine which I'm
sure is functioning because the linuxkernel and getty are able to work
over it.
I have added 'option SERIAL_POST=1' to the configfile and retried but
still nothing appears on the serial line.
Anything else I can try to debug this problem?
This is the lspci output:
debian:/# lspci
:00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05)
:00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP]
:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06)
:00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev
1a)
:00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev
1a)
:00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio
Controller (rev 50)
:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
:01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
debian:/# lspci -n
:00:00.0 Class 0600: 1106:0601 (rev 05)
:00:01.0 Class 0604: 1106:8601
:00:07.0 Class 0601: 1106:0686 (rev 40)
:00:07.1 Class 0101: 1106:0571 (rev 06)
:00:07.2 Class 0c03: 1106:3038 (rev 1a)
:00:07.3 Class 0c03: 1106:3038 (rev 1a)
:00:07.4 Class 0680: 1106:3057 (rev 40)
:00:07.5 Class 0401: 1106:3058 (rev 50)
:00:08.0 Class 0200: 10ec:8139 (rev 10)
:00:09.0 Class 0200: 10ec:8139 (rev 10)
:00:0b.0 Class 0200: 10ec:8139 (rev 10)
:01:00.0 Class 0300: 1023:8500 (rev 6a)
Regards,
Erik Smit
On Thu, Jun 03, 2004 at 09:21:58AM -0600, Hendricks David W. wrote:
Works fine as far as I can tell, I am not getting the 404. But feel free
to post here anyway if it's more convenient for you.
On Thu, 3 Jun 2004, Erik Smit wrote:
Hi People,
Just like the subject says: the form at
http://www.linuxbios.org/help/index.html gives a really cute 404.
Should I therefore mail my request for help to the mailing list or
should I wait until the form gets back working?
Regards,
Erik Smit
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: recommendations to run LB on ASUS A7V8X, TX97E
Sorry, I don't think either of those will run with LinuxBIOS in the immediate future. There has been extensive work done on VIA platforms, particularly the EPIA. Perhaps some of that work could be ported to the KT400, but I'm not sure if anyone on this list is actively working on such a project. On Thu, 3 Jun 2004, Anton Borisov wrote: Hi. I wonder whether these motherboards supported? First based on VIA KT400 chipset, second - very famous :) What kind of PLCC should I use? M-Systems? ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, 3 Jun 2004, Li-Ta Lo wrote: Probably we need an other way to emulate the timer. can we just read the timer? ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken
On Thu, 3 Jun 2004, Erik Smit wrote: Just like the subject says: the form at http://www.linuxbios.org/help/index.html gives a really cute 404. my fault. I gave up on that because the messages I got through it were useless. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
I think that ought to work as a via epia, use V2. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, Jun 03, 2004 at 09:37:53AM -0600, ron minnich wrote: I think that ought to work as a via epia, use V2. freebios2? Well, the EPIA has a vt8231 southbridge where this board has a vt82c686. Won't this give problems? Regards, Erik Smit ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, 3 Jun 2004, Erik Smit wrote: Well, the EPIA has a vt8231 southbridge where this board has a vt82c686. Won't this give problems? There used to be 8231 support. If think they are similar enough it could work. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, 3 Jun 2004, Li-Ta Lo wrote: richard's point is that the emulator is much slower than the timer. The delay loop is facing overflow problem with the emulated io access to the physical counter. oops, sorry. Too much email this morning. I did not read his note carefully enough. Actually I'm surprised that the emulator is that much slower than an old 8086. OK, now what do we do ... Ah, we could use the TSC, right? ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
: w86327hf superio.c
It call the generic PNP function, but before that should enter ext_function mode, otherwise nothing in the superio can be changed. Regards YH -- : ron minnich [mailto:[EMAIL PROTECTED] : 200463 7:16 : YhLu : [EMAIL PROTECTED]; Gregg C Levine; Linuxbios : Re: w86327hf superio.c On Wed, 2 Jun 2004, YhLu wrote: Someone overwrite the superio.c for w86327hf. Before that it enter_ext_func mode and enable HWM of Winbond. that's our fault. The code for this part was really out of date in the way it worked, because it did not use Eric's new generic PNP functions, and we couldn't figure out what should stay and what should go. Can you send me a patch for what you think should happen and we'll put that support back in. thanks ron superio.c Description: Binary data
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, Jun 03, 2004 at 09:44:56AM -0600, ron minnich wrote: On Thu, 3 Jun 2004, Erik Smit wrote: Well, the EPIA has a vt8231 southbridge where this board has a vt82c686. Won't this give problems? There used to be 8231 support. If think they are similar enough it could work. I just tried to build freebios2/targets/via/epia by running buildtarget on it and then running make. This is on the cvs of today. I got the following error: /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table': /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table' /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum' make[1]: *** [pirq_routing.o] Error 1 I just commented these two lines out since they only appear to be used when something is broken. Then it compiled fine. Then I flashed in the resulting linuxbios.bin using uniflash since flash_and_burn doesn't support the AMIC A29002 chip on this board. Still, after rebooting, nothing appears on the serial port. Can I conclude from this that this board is not yet supported (out of the box)? Is there anything else I can try or maybe help debug the problem? Regards, Erik Smit ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
What DiskOnChip?
Hello I wanted to try linuxbios on my computer and read on your homepage that only DiskOnChip Millennium is supported. They seem to have went out of production, and the Norwegian salesman recommended the DiskOnChip 2000 models as a replacement. Do they work too or will I have to find a Millennium-edition? I apologize if this is the totally wrong place to post this, in that case I would be happy if someone could point me in the right direction. Yours, Dag Hovland ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, 3 Jun 2004, Erik Smit wrote: Then I flashed in the resulting linuxbios.bin using uniflash since flash_and_burn doesn't support the AMIC A29002 chip on this board. linuxbios.rom -- you got the wrong file. sorry about that. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: What DiskOnChip?
On Thu, 3 Jun 2004, Dag Hovland wrote: I wanted to try linuxbios on my computer and read on your homepage that only DiskOnChip Millennium is supported. WOW, how did you infer that from the web page? I need to change it if it says something like that. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote: timer. In numerious locations my Vbios is writing a 0x00 to IO 0x43 and then does 2 reads from 0x40. So its latching the value of counter 0 and then reading it out. Right, it also sets counter mode 0, zero detection interrupt. Are there any hints of the code actually using the interrupt anywhere? I'm guesing that what it uses for delays. Indeed. It's the only way I know for measuring ms without rdtsc. The delay routine is written such that it polls for a rollover to mark the increment of 838.1 ns. For this to happen the latch values must be equal. In a system where the cpu instructions are running much faster than one timer clock cycle I guess would not be much of a problem. 838.1ns is one tick, not a complete 16-bit rollover, right? What I don't understand though was how this ever was reliable. [..] Consider the following: [..asm..] Am I missing somthing? The resolution could be lowered.. Are there any writes to 0x40 setting a divisor? If not, then the snippet will simply not be reliable down to the exact iteration. Since the code uses jb to detect when to stop looping the count doesn't have to be an exact match. Even if an extra tick passes, the loop will still end. I don't think the timing is critical in any other way than that it should be as short as possible to keep the user happy, but with a minimum limit decided by hardware. //Peter ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, Jun 03, 2004 at 10:55:14AM -0600, ron minnich wrote: On Thu, 3 Jun 2004, Erik Smit wrote: Then I flashed in the resulting linuxbios.bin using uniflash since flash_and_burn doesn't support the AMIC A29002 chip on this board. linuxbios.rom -- you got the wrong file. sorry about that. Sorry, that was a typo, I did infact take linuxbios.rom. (There isn't even a linuxbios.bin. :) Regards, Erik Smit ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [COMMIT] romcc 0.63 and some fixes...
Eric,
The
printo_debug(this mainboard is only designed for 2 cpus\r\n);
causes the segment dump.
Another problem. After only change print_debug in raminit.c, the final image
size get bigger from 68663 to 70203.
Regards
YH
--
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
: 200463 1:31
: YhLu
: LinuxBIOS
: Re: : : : [COMMIT] romcc 0.63 and some fixes...
YhLu [EMAIL PROTECTED] writes:
Eric,
I add in console.c
static void printo_debug(const char *str) __attribute__((noinline))
{
print_debug(str);
}
About only chang print_debug in auto.c
It said
./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault
./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault
Cool, my first bug report. I knew I had touched to much code
for the new release to run without a hitch.
Could you look at the core dump with gdb and give me a back trace?
That should help even if I can't reproduce the problem on this end.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: recommendations to run LB on ASUS A7V8X, TX97E
* Hendricks David W. [EMAIL PROTECTED] [040603 17:34]: Sorry, I don't think either of those will run with LinuxBIOS in the immediate future. There has been extensive work done on VIA platforms, particularly the EPIA. Perhaps some of that work could be ported to the KT400, but I'm not sure if anyone on this list is actively working on such a project. I've not seen enough information (data sheets) available without NDA to make this happen. Might be that I looked in the wrong places though. If you don't buy a lot of motherboards, you normally don't get this kind of information from VIA. Stefan ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
On Thu, Jun 03, 2004 at 07:07:12PM +0200, Erik Smit wrote: On Thu, Jun 03, 2004 at 10:55:14AM -0600, ron minnich wrote: On Thu, 3 Jun 2004, Erik Smit wrote: Then I flashed in the resulting linuxbios.bin using uniflash since flash_and_burn doesn't support the AMIC A29002 chip on this board. linuxbios.rom -- you got the wrong file. sorry about that. Sorry, that was a typo, I did infact take linuxbios.rom. (There isn't even a linuxbios.bin. :) Still, after rebooting, nothing appears on the serial port. Can I conclude from this that this board is not yet supported (out of the box)? Is there anything else I can try or maybe help debug the problem? Also, is it possible to sponsor one (or more) boards or perhaps fund somebody to work on this? Regards, Erik Smit ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
what about this. Build a composite timer with the top X bits coming from TSC, and the bottom Y bits coming from the time-of-day counter. Would that work? ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
OK, I finally read this in detail and I'm sorry for my noise on this subject. I think it would be useful to keep an 'emulated instruction count' in the emulator, and have a virtual timer that increments very X (pick a number) instructions. X can be constant across different architectures as we are somewhat divorced from time (it's an emulator). The emulated timer would increment every emulated instruction count ticks. Would this do it? ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
with the fuctory bios in place, make sure that your minicom setup is right. Let me know. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: recommendations to run LB on ASUS A7V8X, TX97E
On Thu, 3 Jun 2004, Stefan Reinauer wrote: I've not seen enough information (data sheets) available without NDA to make this happen. Might be that I looked in the wrong places though. If you don't buy a lot of motherboards, you normally don't get this kind of information from VIA. It depends. At times via has been incredibly helpful, but not in all cases. If you can make the case for this they might be able to help you. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: pirq checking
On Thu, 3 Jun 2004, Stefan Reinauer wrote: * ron minnich [EMAIL PROTECTED] [040603 17:23]: the current pirq code defines intel_irq_routing_table as const, thus making it potentially readonly. should be const due to execute-in-place issues. What's the benefit in this case? we have dram long before this code is run, and the table is really small. Should it be copied to ram completely maybe? the only reason is that in the execute in place case you can't write to it. Leaving it as const will catch bugs involving people writing to it. That's all. Nope, parts of that is my fault. But I still think it is a good idea to go towards dynamic table creation. yes. we're just not there. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, 3 Jun 2004, Richard Smith wrote: Yes. I think it would. Got any ideas on the implementation? I'm ready to try an implement this. in the main loop for instruction decode there is a single instruction dispatch function. Create a global counter (emulate_counter?) and increment it once each time the dispatch function returns. You can in the emulator redirect I/O port access to a function. Write the code to handle read/write on those ports and use the emulate_counter to drive the clock value. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
On Thu, 3 Jun 2004, Richard Smith wrote: This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO. All I know is BIOS code sucks and it looks like VGA BIOS code is worse than BIOS code. IT's amazing that any of it ever worked at all. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: testbios and the system timer
ron minnich wrote: On Thu, 3 Jun 2004, Richard Smith wrote: This will only skip the jump (and do the BX decrement) if ax is zero. For ax to be zero the result of the 2's complement subtraction must be zero or the when the 2 reads are the same number. But I just don't see how this would happen repeatably at .6us per ISA IO. Hold up. I'm baked. Gotta get more sleep. The above is obviously wrong. Its should be when they differ by 2. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [COMMIT] romcc 0.63 and some fixes...
./romcc -mcpu=k8 -O2 ./auto.E auto.inc make[1]: *** [auto.inc] Error 139 ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [COMMIT] romcc 0.63 and some fixes...
YhLu [EMAIL PROTECTED] writes: Eric, I'm not familiar the gdb, and if you like I can send the auto.E to you. That would be good thanks. I guess slightly simpler would be to do: Which will ensure core file generation is not turned off. Then you can do. ulimit -c unlimited make find . -name 'core*' -print find . -name 'romcc' -print And send me (off list) the file named core file and the file named romcc, that the above find commands found. This feels like gcc miscompiled romcc or something like that. ulimit -c unlimited ensures core generation is enabled. make does the build that fails find . -name 'core*' -print locates core file generated by the sigsegv find . -name 'romcc' -print locates the romcc binary you were running. If it is a compilation error I really need to see what the binaries look like. If it a bug in romcc I should be able to feed in your auto.E and reproduce this. Some very strange things are going on and I don't know how to call it. Running dmesg and seeing if the oom killer kicked in would also be interesting. romcc tends to be a bit of a memory hog. Not so much that it has been unusable but I am grasping at straws. It looks like my next step in instrumenting romcc is to start catching signals like sigsegv so I can exit moderately gracefully when they occur. My coworkers have been using the romcc with no ill effects so I am truly mystified, as to what is going wrong. Thanks, Eric P.S. Brain storming on naming conventions, I think the sanest thing to do is to indicate a function is not inline by appending an underscore to it's name. So we will have print_debug(str) and pring_debug_(str) Unless there are any objections. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
Mathieu Deschamps [EMAIL PROTECTED] writes: Hello, Since i have mostly 'directly choose' Filo, i haven't had much time asking for the difference between Linuxbios native's Elfboot and Linuxbios native's filo. I know you did made some work around theses... The native ``filo'' is scheduled for deletion, it touches hardwaremain which it should not. As implemented it is a maintenance nightmare and an implementation of policy and I refuse to support it, in the core of LinuxBIOS. Until just a little while ago I thought it was much less intrusive so was not forcing the issue. (i have read the doc of Sone Takeshi and i have the features of filo.) Could you explain me what differences there are and/or whether this one best suited for DoC or CF or other types i'am ignoring ? Please also let me know what type of filesys elfboot boots, and other thing about support ELF boot is a minimal loader just good enough to load something real out off some device. ELF boot just grabs an ELF image at the offset in a device it is pointed at. The image can be sparse so it can exist with partition tables and filesystems. The trivial solution is to put a partition right after partition table for the ELF image. More interesting forms of coexistance are possible by noone has implemented more than a proof of concept. If you want to use filo which understand filesystems and partitions get the real one. It has been developing faster and it appears to have more features. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [COMMIT] romcc 0.63 and some fixes...
I will add RAM to test again. Regards YH ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
: [COMMIT] romcc 0.63 and some fixes...
Just sent out the core. -- : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] : 200463 17:23 : YhLu : LinuxBIOS : Re: [COMMIT] romcc 0.63 and some fixes... YhLu [EMAIL PROTECTED] writes: Eric, I'm not familiar the gdb, and if you like I can send the auto.E to you. That would be good thanks. I guess slightly simpler would be to do: Which will ensure core file generation is not turned off. Then you can do. ulimit -c unlimited make find . -name 'core*' -print find . -name 'romcc' -print And send me (off list) the file named core file and the file named romcc, that the above find commands found. This feels like gcc miscompiled romcc or something like that. ulimit -c unlimited ensures core generation is enabled. make does the build that fails find . -name 'core*' -print locates core file generated by the sigsegv find . -name 'romcc' -print locates the romcc binary you were running. If it is a compilation error I really need to see what the binaries look like. If it a bug in romcc I should be able to feed in your auto.E and reproduce this. Some very strange things are going on and I don't know how to call it. Running dmesg and seeing if the oom killer kicked in would also be interesting. romcc tends to be a bit of a memory hog. Not so much that it has been unusable but I am grasping at straws. It looks like my next step in instrumenting romcc is to start catching signals like sigsegv so I can exit moderately gracefully when they occur. My coworkers have been using the romcc with no ill effects so I am truly mystified, as to what is going wrong. Thanks, Eric P.S. Brain storming on naming conventions, I think the sanest thing to do is to indicate a function is not inline by appending an underscore to it's name. So we will have print_debug(str) and pring_debug_(str) Unless there are any objections. ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: : [COMMIT] romcc 0.63 and some fixes...
YhLu [EMAIL PROTECTED] writes: Just sent out the core. Thanks. I have done the basic tracking. And it is clearly a code bug. tdominates depends on some code analysis that is not currently present in expand_function_call, and I wind up with a null pointer dereference. I need to stare at the code a little more but should take just a little bit to fix... The back trace is: #0 tdominates (state=0xbfffb78c, dom=0x829fbd0, sub=0x86f7698) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:16019 #1 0x0805c41f in expand_function_call (state=0xbfffb78c, me=0x8204290, fcall=0x829fbd0) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14422 #2 0x0805c747 in inline_function (state=0xbfffb78c, me=0x8204290, arg=0x0) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14599 #3 0x0805c838 in inline_functions (state=0xbfffb78c, func=0x8204290) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14606 #4 0x0805cd20 in join_functions (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14801 #5 0x08065efd in optimize (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:21488 #6 0x0806a4c7 in compile (filename=0xbfffecf8 ./auto.E, compiler=0x0, arch=0x0) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:24910 #7 0x0806a638 in main (argc=1, argv=0xbfffd93c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:25029 (gdb) Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Looking for Laptop Candidates for LinuxBIOS Port
We are in search of good candidates for laptops for a LinuxBIOS Port. These will be the easiest to port: Intel laptops with Intel integrated graphics, not ATI or nVidia graphics Intel Chipsets (TBA) i915 http://www.tbreak.com/reviews/article.php?id=305 These should be out in the next month or so. 855GM http://developer.intel.com/design/chipsets/mobile/855gm.htm?iid=dev_chips855fam+855gm; 852GME http://developer.intel.com/design/chipsets/mobile/855GME.htm?iid=dev_chips855fam+855gme; 852GM http://developer.intel.com/design/chipsets/mobile/852gm.htm 852GMV http://developer.intel.com/design/chipsets/mobile/852gmv.htm Along with any of these Renesas keyboard/system controllers: http://www.renesas.com/eng/products/mpumcu/16bit/h8s/2100/ Everyone please crack open those lids and check your lspci's. Go down in LinuxBIOS history as the one that came up with the winner! -Bari ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
