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: 0x0000000000100000 memsz: 0x00000000000240e0 filesz: 0x000000000000a048 Clearing Segment: addr: 0x000000000010a048 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001240e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 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
On Mon, 5 Jul 2004 scheng@msica.com 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: 0x0000000000100000 memsz: 0x00000000000240e0 filesz: 0x000000000000a048 Clearing Segment: addr: 0x000000000010a048 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001240e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 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
On Mon, 5 Jul 2004 scheng@msica.com 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: 0x0000000000100000 memsz: 0x00000000000240e0 filesz: 0x000000000000a048 Clearing Segment: addr: 0x000000000010a048 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001240e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 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 Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .note NOTE 00100000 0000c0 000078 00 A 0 0 32 [ 2] .text PROGBITS 00100080 000140 008d28 00 WAX 0 0 16 [ 3] .rodata PROGBITS 00108dc0 008e80 000f29 00 A 0 0 32 [ 4] .eh_frame PROGBITS 00109cec 009dac 000058 00 A 0 0 4 [ 5] .data PROGBITS 00109d60 009e20 0002e8 00 WA 0 0 32 [ 6] .bss NOBITS 0010a060 00a120 01a080 00 WA 0 0 32 [ 7] .initctx PROGBITS 001240e0 00a120 000048 00 WA 0 0 32 [ 8] .note.GNU-stack NOTE 00000000 00a168 000000 00 X 0 0 1 [ 9] .shstrtab STRTAB 00000000 00a168 00004d 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 0x0000c0 0x00100000 0x00100000 0x0a048 0x240e0 RWE 0x20 LOAD 0x00a120 0x001240e0 0x001240e0 0x00048 0x00048 RW 0x20 NOTE 0x0000c0 0x00100000 0x00100000 0x00078 0x00078 R 0x20 STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 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 found in this file. ******************************************************************* Ron, I am a newbie to LinuxBIOS and booting area. There are too many things to learn. Thank you for your help. Simon
David, what do you think?
ron
On Tue, 6 Jul 2004 scheng@msica.com 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
ron minnich <rminnich@lanl.gov> writes:
On Mon, 5 Jul 2004 scheng@msica.com 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
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
Garbled output is usually a symptom of incorrect serial baud rate. It seems fine in the boot loader, perhaps he needs to pass console=ttys0,115200 to his kernel.
******************************************************************* 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: 0x0000000000100000 memsz: 0x00000000000240e0 filesz: 0x000000000000a048 Clearing Segment: addr: 0x000000000010a048 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001240e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 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 Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
ron minnich <rminnich@lanl.gov> 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
On Tue, 6 Jul 2004 scheng@msica.com 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 Whats' your build machine again?
ron
I adjusted the baud rate to 115200 for LinuxBIOS, filo and kernel command. Right now, I can get into filo, but right after it began relocate system info, the LinuxBIOS restarts. A truncation of screen shot is: ************************************** Found ELF candiate at offset 0 New segment addr 0x100000 size 0x264e0 offset 0xc0 filesize 0xc448 (cleaned up) New segment addr 0x100000 size 0x264e0 offset 0xc0 filesize 0xc448 New segment addr 0x1264e0 size 0x48 offset 0xc520 filesize 0x48 (cleaned up) New segment addr 0x1264e0 size 0x48 offset 0xc520 filesize 0x48 Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000264e0 filesz: 0x000000000000c448 Clearing Segment: addr: 0x000000000010c448 memsz: 0x000000000001a098 Loading Segment: addr: 0x00000000001264e0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 Jumping to boot code at 0x108c68 FILO version 0.4.2 (root@epia1) Tue Jul 6 15:55:32 PDT 2004 collect_sys_info: boot eax = 0xe1fb007 collect_sys_info: boot ebx = 0x9ff5294 collect_sys_info: boot arg = 0x9ff5294 collect_linuxbios_info: Searching for LinuxBIOS tables... find_lb_table: Found canidate at: 00000500 find_lb_table: header checksum o.k. find_lb_table: table checksum o.k. find_lb_table: record count o.k. collect_linuxbios_info: Found LinuxBIOS table at: 00000500 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: 0x00000000000000 0x00000000000b3c 16 convert_memmap: 0x00000000000b3c 0x00000009fff4c4 1 collect_sys_info: 0000000000000b3c-000000000a000000 collect_sys_info: RAM 160 MB collect_sys_info is done begin relocate systeminfo _start = 100000 ; _end = 126528 relocate: prog_addr=100000 relocate: prog_size=26528 relocate: Current location: 0x100000-0x126527 relocate: Relocating to 0x9fd9ad0-0x9fffff7... 0 LinuxBIOS-1.1.6.0Fallback Tue Jul 6 15:57:28 PDT 2004 starting... 87 is the comm register SMBus controller enabled vt8601 init starting 00000000 is the north 1106 0601 0120d4 is the computed timing ************************************** My build machine is EPIA800. Here is the lspci: ************************************ epia1:~# lspci 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05) 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev 10) 0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1e) 0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1e) 0000:00:11.4 Bridge: VIA Technologies, Inc. VT8235 ACPI (rev 10) 0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 40) 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 51) 0000:01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) ************************************** Thanks a lot. Simon Cheng www.msica.com
On Tue, Jul 06, 2004 at 04:23:39PM -0700, Simon Xin Cheng wrote:
collect_linuxbios_info: Found LinuxBIOS table at: 00000500 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: 0x00000000000000 0x00000000000b3c 16 convert_memmap: 0x00000000000b3c 0x00000009fff4c4 1 collect_sys_info: 0000000000000b3c-000000000a000000 collect_sys_info: RAM 160 MB collect_sys_info is done begin relocate systeminfo _start = 100000 ; _end = 126528 relocate: prog_addr=100000 relocate: prog_size=26528 relocate: Current location: 0x100000-0x126527 relocate: Relocating to 0x9fd9ad0-0x9fffff7... 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
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=0x00004000 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
participants (6)
-
ebiederman＠lnxi.com -
Hendricks David W. -
ron minnich -
scheng＠msica.com -
Simon Xin Cheng
-
Takeshi Sone