Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
Maybe the memory map information is wrong. (FILO tries to relocate itself to non-existent RAM area and crashes?) Are you sure you have 160MB RAM and none of it is allocated for framebuffer? You should run memtest86 as payload so you can see if memory configuration is ok. -- Takeshi Takeshi, Thank you for your suggestion. I tried memtest86-3.1.a. This guy creates a 69356Byte elf file. It exceeds 64KB. So, I disabled fallback. However, I can not boot from the romimage I created (i.e. cann't get any information from serial console). Following is the configure file. If you have time, would you please check it. Thanks again! *** loadoptions target epia uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVEL uses CONFIG_CONSOLE_SERIAL8250 uses MAINBOARD uses CONFIG_CHIP_CONFIGURE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses LINUXBIOS_EXTRA_VERSION uses TTYS0_BAUD option TTYS0_BAUD=115200 option CONFIG_CHIP_CONFIGURE=1 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option ROM_SIZE=256*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=0 ### ### Compute the location and size of where this firmware image ### (linuxBIOS plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=0 ## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. option ROM_IMAGE_SIZE=65536 ## LinuxBIOS C code runs at this location in RAM option _RAMBASE=0x4000 romimage normal option USE_FALLBACK_IMAGE=0 option PAYLOAD_SIZE=69356 option LINUXBIOS_EXTRA_VERSION=.0Normal mainboard via/epia payload /usr/src/memtest end buildrom ./linuxbios.rom ROM_SIZE normal Simon Cheng www.msica.com ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
You may only disabe normal instead of fallback. LB will execute failover at first. -- : Simon Xin Cheng [mailto:[EMAIL PROTECTED] : 200477 15:43 : Takeshi Sone : Simon Xin Cheng; [EMAIL PROTECTED] : Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c Maybe the memory map information is wrong. (FILO tries to relocate itself to non-existent RAM area and crashes?) Are you sure you have 160MB RAM and none of it is allocated for framebuffer? You should run memtest86 as payload so you can see if memory configuration is ok. -- Takeshi Takeshi, Thank you for your suggestion. I tried memtest86-3.1.a. This guy creates a 69356Byte elf file. It exceeds 64KB. So, I disabled fallback. However, I can not boot from the romimage I created (i.e. cann't get any information from serial console). Following is the configure file. If you have time, would you please check it. Thanks again! *** loadoptions target epia uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVEL uses CONFIG_CONSOLE_SERIAL8250 uses MAINBOARD uses CONFIG_CHIP_CONFIGURE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses LINUXBIOS_EXTRA_VERSION uses TTYS0_BAUD option TTYS0_BAUD=115200 option CONFIG_CHIP_CONFIGURE=1 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option ROM_SIZE=256*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=0 ### ### Compute the location and size of where this firmware image ### (linuxBIOS plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=0 ## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. option ROM_IMAGE_SIZE=65536 ## LinuxBIOS C code runs at this location in RAM option _RAMBASE=0x4000 romimage normal option USE_FALLBACK_IMAGE=0 option PAYLOAD_SIZE=69356 option LINUXBIOS_EXTRA_VERSION=.0Normal mainboard via/epia payload /usr/src/memtest end buildrom ./linuxbios.rom ROM_SIZE normal Simon Cheng www.msica.com ___ 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: : A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
Also, you might want to make PAYLOAD_SIZE = (ROM_SECTION_SIZE - ROM_IMAGE_SIZE) On Wed, 7 Jul 2004, YhLu wrote: You may only disabe normal instead of fallback. LB will execute failover at first. -ÓʼþÔ¼þ- ·¢¼þÈË: Simon Xin Cheng [mailto:[EMAIL PROTECTED] ·¢ËÍʱ¼ä: 2004Äê7ÔÂ7ÈÕ 15:43 ÊÕ¼þÈË: Takeshi Sone ³ËÍ: Simon Xin Cheng; [EMAIL PROTECTED] Ö÷Ìâ: Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c Maybe the memory map information is wrong. (FILO tries to relocate itself to non-existent RAM area and crashes?) Are you sure you have 160MB RAM and none of it is allocated for framebuffer? You should run memtest86 as payload so you can see if memory configuration is ok. -- Takeshi Takeshi, Thank you for your suggestion. I tried memtest86-3.1.a. This guy creates a 69356Byte elf file. It exceeds 64KB. So, I disabled fallback. However, I can not boot from the romimage I created (i.e. cann't get any information from serial console). Following is the configure file. If you have time, would you please check it. Thanks again! *** loadoptions target epia uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVEL uses CONFIG_CONSOLE_SERIAL8250 uses MAINBOARD uses CONFIG_CHIP_CONFIGURE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses LINUXBIOS_EXTRA_VERSION uses TTYS0_BAUD option TTYS0_BAUD=115200 option CONFIG_CHIP_CONFIGURE=1 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option ROM_SIZE=256*1024 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=0 ### ### Compute the location and size of where this firmware image ### (linuxBIOS plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=0 ## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. option ROM_IMAGE_SIZE=65536 ## LinuxBIOS C code runs at this location in RAM option _RAMBASE=0x4000 romimage normal option USE_FALLBACK_IMAGE=0 option PAYLOAD_SIZE=69356 option LINUXBIOS_EXTRA_VERSION=.0Normal mainboard via/epia payload /usr/src/memtest end buildrom ./linuxbios.rom ROM_SIZE normal Simon Cheng www.msica.com ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios ___ 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: : A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
Here is a config file that only has fallback, not normal. It uses a kernel as the payload. # the Arima HDAMA # This will make a target directory of ./hdama loadoptions target hdama uses ARCH uses CONFIG_COMPRESS uses CONFIG_IOAPIC uses CONFIG_ROM_STREAM uses CONFIG_ROM_STREAM_START uses CONFIG_UDELAY_TSC uses CPU_FIXUP uses FALLBACK_SIZE uses HAVE_FALLBACK_BOOT uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses HAVE_HARD_RESET uses i586 uses i686 uses INTEL_PPRO_MTRR uses HEAP_SIZE uses IRQ_SLOT_COUNT uses k7 uses k8 uses MAINBOARD_PART_NUMBER uses MAINBOARD_VENDOR uses CONFIG_SMP uses CONFIG_MAX_CPUS uses MEMORY_HOLE uses PAYLOAD_SIZE uses _RAMBASE uses _ROMBASE uses ROM_IMAGE_SIZE uses ROM_SECTION_OFFSET uses ROM_SECTION_SIZE uses ROM_SIZE uses STACK_SIZE uses USE_FALLBACK_IMAGE uses USE_OPTION_TABLE uses HAVE_OPTION_TABLE uses MAXIMUM_CONSOLE_LOGLEVEL uses DEFAULT_CONSOLE_LOGLEVEL uses CONFIG_CONSOLE_SERIAL8250 uses MAINBOARD uses CONFIG_CHIP_CONFIGURE uses XIP_ROM_SIZE uses XIP_ROM_BASE uses LINUXBIOS_EXTRA_VERSION option CONFIG_CHIP_CONFIGURE=1 option MAXIMUM_CONSOLE_LOGLEVEL=8 option DEFAULT_CONSOLE_LOGLEVEL=8 option CONFIG_CONSOLE_SERIAL8250=1 option CPU_FIXUP=1 option CONFIG_UDELAY_TSC=0 option i686=1 option i586=1 option INTEL_PPRO_MTRR=1 option k7=1 option k8=1 option ROM_SIZE=0x10 option HAVE_OPTION_TABLE=1 option CONFIG_ROM_STREAM=1 option HAVE_FALLBACK_BOOT=1 ### ### Compute the location and size of where this firmware image ### (linuxBIOS plus bootloader) will live in the boot rom chip. ### option FALLBACK_SIZE=ROM_SIZE ## LinuxBIOS C code runs at this location in RAM option _RAMBASE=0x4000 # ### ### Compute the start location and size size of ### The linuxBIOS bootloader. ### # # Arima hdama romimage fallback option USE_FALLBACK_IMAGE=1 option ROM_IMAGE_SIZE=0x1 # option ROM_SECTION_SIZE=0x10 option LINUXBIOS_EXTRA_VERSION=.0Fallback mainboard arima/hdama # payload ../../../../tg3--ide_disk.zelf payload ../../../../opteron_phase1_p4_noapic # payload ../../../../../../hdama-1 # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf end buildrom ./luxbios.rom ROM_SIZE fallback ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On Mon, 5 Jul 2004 [EMAIL PROTECTED] wrote:
I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
(EPIA 800 board).
I found that LinuxBIOS executes an infinite loop in dumpnorth() function
of freebios2/src/northbridge/via/vt8601/raminit.c .
The function is:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; r 256; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
}
}
Since r is an unsigned char, it will never reach 256. To fix the problem,
I simply added a line at the end of the loop: if( r = 240 ) break;
thanks for the fix, did you do something like this:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; ; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
if (r = 240)
break;
}
}
(r and c are u8 because we're trying to use bytes whereever possible; this
is rommcc-compiled)
Let me know if this works and I'll commit it.
***
By the way, I am still working on filo. In my machine, after elfboot
passing control to filo, LinuxBIOS Fallback restarts again. Following is
a piece of screenshot:
..
Loading Segment: addr: 0x0010 memsz: 0x000240e0
filesz: 0xa048
Clearing Segment: addr: 0x0010a048 memsz: 0x0001a098
Loading Segment: addr: 0x001240e0 memsz: 0x0048
filesz: 0x0048
Jumping to boot code at 0x107d28
.8(=±sioÿ.
This looks like baud rate troubles in part.
also, what does readelf -a of the filo show? your start address seems odd.
David, what do you think?
ron
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On Mon, 5 Jul 2004 [EMAIL PROTECTED] wrote:
I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
(EPIA 800 board).
I found that LinuxBIOS executes an infinite loop in dumpnorth() function
of freebios2/src/northbridge/via/vt8601/raminit.c .
The function is:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; r 256; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
}
}
Since r is an unsigned char, it will never reach 256. To fix the
problem,
I simply added a line at the end of the loop: if( r = 240 ) break;
thanks for the fix, did you do something like this:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; ; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
if (r = 240)
break;
}
}
(r and c are u8 because we're trying to use bytes whereever possible; this
is rommcc-compiled)
Let me know if this works and I'll commit it.
Yes, it works.
***
By the way, I am still working on filo. In my machine, after elfboot
passing control to filo, LinuxBIOS Fallback restarts again. Following
is
a piece of screenshot:
..
Loading Segment: addr: 0x0010 memsz: 0x000240e0
filesz: 0xa048
Clearing Segment: addr: 0x0010a048 memsz: 0x0001a098
Loading Segment: addr: 0x001240e0 memsz: 0x0048
filesz: 0x0048
Jumping to boot code at 0x107d28
.8(=±sioÿ.
This looks like baud rate troubles in part.
also, what does readelf -a of the filo show? your start address seems odd.
Here is the readelf -a filo.elf:
epia1:/usr/src# readelf -a filo.elf
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x107d28
Start of program headers: 52 (bytes into file)
Start of section headers: 41400 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 4
Size of section headers: 40 (bytes)
Number of section headers: 10
Section header string table index: 9
Section Headers:
[Nr] Name TypeAddr OffSize ES Flg Lk
Inf Al
[ 0] NULL 00 00 00 0
0 0
[ 1] .note NOTE0010 c0 78 00 A 0
0 32
[ 2] .text PROGBITS00100080 000140 008d28 00 WAX 0
0 16
[ 3] .rodata PROGBITS00108dc0 008e80 000f29 00 A 0
0 32
[ 4] .eh_frame PROGBITS00109cec 009dac 58 00 A 0
0 4
[ 5] .data PROGBITS00109d60 009e20 0002e8 00 WA 0
0 32
[ 6] .bss NOBITS 0010a060 00a120 01a080 00 WA 0
0 32
[ 7] .initctx PROGBITS001240e0 00a120 48 00 WA 0
0 32
[ 8] .note.GNU-stack NOTE 00a168 00 00 X 0
0 1
[ 9] .shstrtab STRTAB 00a168 4d 00 0
0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0xc0 0x0010 0x0010 0x0a048 0x240e0 RWE 0x20
LOAD 0x00a120 0x001240e0 0x001240e0 0x00048 0x00048 RW 0x20
NOTE 0xc0 0x0010 0x0010 0x00078 0x00078 R 0x20
STACK 0x00 0x 0x 0x0 0x0 RWE 0x4
Section to Segment mapping:
Segment Sections...
00 .note .text .rodata .eh_frame .data .bss
01 .initctx
02 .note
03
There is no dynamic segment in this file.
There are no relocations in this file.
There are no unwind sections in this file.
No version information
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On Tue, 6 Jul 2004 [EMAIL PROTECTED] wrote: Let me know if this works and I'll commit it. Yes, it works. I just committed the fix, thanks what's you serial port baud rate? I can just send you one of our filo images to test. Whats' your build machine again? ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
ron minnich [EMAIL PROTECTED] writes:
On Mon, 5 Jul 2004 [EMAIL PROTECTED] wrote:
I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
(EPIA 800 board).
I found that LinuxBIOS executes an infinite loop in dumpnorth() function
of freebios2/src/northbridge/via/vt8601/raminit.c .
The function is:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; r 256; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
}
}
Since r is an unsigned char, it will never reach 256. To fix the problem,
I simply added a line at the end of the loop: if( r = 240 ) break;
thanks for the fix, did you do something like this:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; ; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
if (r = 240)
break;
}
}
(r and c are u8 because we're trying to use bytes whereever possible; this
is rommcc-compiled)
Hmm.. Using bytes does not help the register pressure and in fact
slightly increases code size. If the byte register instructions
on x86 were more symmetric this might be different, but...
I cannot think of an architecture where using bytes would be better.
The increase in code size is because of the need to clamp the values
at their maximum so code like this fails properly.
Earlier versions of romcc were buggy and did not clamp values
after they were put into a register even if you said it was a
character value. So an unsigned char could hold the value of 256
if you incremented it to there.
Probably the easiest way to imagine how code generation works in romcc
is to think of a non byte addressed machine, and how awkward that
makes smaller than word size quantities. Not really bad but
certainly awkward.
Let me know if this works and I'll commit it.
The code will be more efficient if you just use an int or an unsigned int.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On 6 Jul 2004, Eric W. Biederman wrote: Hmm.. Using bytes does not help the register pressure and in fact slightly increases code size. If the byte register instructions on x86 were more symmetric this might be different, but... sad that they don't work well. I cannot think of an architecture where using bytes would be better. The increase in code size is because of the need to clamp the values at their maximum so code like this fails properly. They exist :-) thanks for the tip, this is very good to know. thanks ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
ron minnich [EMAIL PROTECTED] writes: On 6 Jul 2004, Eric W. Biederman wrote: Hmm.. Using bytes does not help the register pressure and in fact slightly increases code size. If the byte register instructions on x86 were more symmetric this might be different, but... sad that they don't work well. They work well unless you are register starved, and since romcc is always register starved they don't work well in that context. There are no general register to register move instructions to let me move a byte register into a longer register and vice versa. So generally I don't even bother with the byte registers. I cannot think of an architecture where using bytes would be better. The increase in code size is because of the need to clamp the values at their maximum so code like this fails properly. They exist :-) Where bytes are better for register pressure? Beyond the theoretical case where something could be built I would love to see one. Note this is limited to treating any instruction set as a load/store architecture, because register to memory instructions can't be used. Which is the primary thing that cripples the x86 case and bytes. thanks for the tip, this is very good to know. There are 2 important cases for registers. 1) Using them. 2) Storing data in them. When you are using a register it is best to have the value unpacked and to just use that register. When you are simply storing data in a register the trade offs change because you can afford a second register to hold the value when you take it out and modify it. For optimizing the storage case I have implemented bitfields. When they are unpacked and being manipulated they need an extra. In the cases where registers are tight bitfields could be handy, in structures could be handy for passing around multiple values. A loop counter usually does not fit that description though. Especially not when you don't have something else to put in the same register. Since values are mostly used and not stored in registers I leave it up to the programmer to implement the storage optimization case. Although by implementing bitfields I am as helpful as I can be. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On 6 Jul 2004, Eric W. Biederman wrote: They exist :-) Where bytes are better for register pressure? on the Tera machine this kind of thing is called 'puddle arithmetic' and it was kind of neat. My memory of the instruction set is that it works. ron ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
On Tue, Jul 06, 2004 at 04:23:39PM -0700, Simon Xin Cheng wrote: collect_linuxbios_info: Found LinuxBIOS table at: 0500 malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks) malloc_diag: alloc: 40 bytes (1 blocks), free: 16336 bytes (1 blocks) convert_memmap: 0x00 0x000b3c 16 convert_memmap: 0x000b3c 0x0009fff4c4 1 collect_sys_info: 0b3c-0a00 collect_sys_info: RAM 160 MB collect_sys_info is done begin relocate systeminfo _start = 10 ; _end = 126528 relocate: prog_addr=10 relocate: prog_size=26528 relocate: Current location: 0x10-0x126527 relocate: Relocating to 0x9fd9ad0-0x9f7... 0 LinuxBIOS-1.1.6.0Fallback Tue Jul 6 15:57:28 PDT 2004 starting... Maybe the memory map information is wrong. (FILO tries to relocate itself to non-existent RAM area and crashes?) Are you sure you have 160MB RAM and none of it is allocated for framebuffer? You should run memtest86 as payload so you can see if memory configuration is ok. -- Takeshi ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
A bug was found in freebios2/src/northbridge/via/vt8601/raminit.c
I am trying to use LinuxBIOS V2 + Filo to boot local Linux on hard disk
(EPIA 800 board).
I found that LinuxBIOS executes an infinite loop in dumpnorth() function
of freebios2/src/northbridge/via/vt8601/raminit.c .
The function is:
void
dumpnorth(device_t north)
{
uint8_t r, c;
for(r = 0; r 256; r += 16) {
print_debug_hex8(r);
print_debug(:);
for(c = 0; c 16; c++) {
print_debug_hex8(pci_read_config8(north, r+c));
print_debug( );
}
print_debug(\r\n);
}
}
Since r is an unsigned char, it will never reach 256. To fix the problem,
I simply added a line at the end of the loop: if( r = 240 ) break;
***
By the way, I am still working on filo. In my machine, after elfboot
passing control to filo, LinuxBIOS Fallback restarts again. Following is
a piece of screenshot:
..
Loading Segment: addr: 0x0010 memsz: 0x000240e0
filesz: 0xa048
Clearing Segment: addr: 0x0010a048 memsz: 0x0001a098
Loading Segment: addr: 0x001240e0 memsz: 0x0048
filesz: 0x0048
Jumping to boot code at 0x107d28
.8(=±sioÿ.
LinuxBIOS-1.1.6.0Fallback Mon Jul 5 15:38:49 PDT 2004 starting...
87 is the comm register
SMBus controller enabled
...
Does anyone have any suggestion about this?
Thanks,
Simon
MSICA.com
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
