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