Christer Weinigel <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm back to hacking on LinuxBIOS again (I've been busy with work and
> life). I have updated the SCx200 code of LinuxBIOS so that it works
> with the latest version from CVS. The changes are:
>
> * Change SCx200_DOCCS_BASE from 0xc0000000 to 0x80000000 in the
> config file. It seems that LinuxBIOS has changed the memory
> region where it allocates PCI resources, so this collided with
> the DOCCS memory region. Using 0x80000000 works better.
Sorry about that. Well this convinces me the work I have been
pursuing for allowing any resource to be allocated with the pci
resource allocator, and to allow all resources to be seen by it,
is important long term, so we don't have this kind of accidental
breakage.
> * Change the ACCESS.bus base addresses to 0x820 and 0x840 in the
> config file, this matches what the NatSemi XpressROM.
>
> * Change a bunch of "option FOO" to "option FOO=1".
>
> * Fix a bug in scx200_setup.inc. SuperI/O device 5 was
> initialized twice, the second initialization has been changed to
> work on device 6 as it should do.
>
> By the way, I'm seeing a really strange error:
>
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Scanning PCI bus...PCI: pci_scan_bus for bus 0
> Error! malloc: Free_mem_ptr >= free_mem_end_ptr
>
> I decided to try to figure out what was going on and added a debug
> message to print out the values of eheap and heap in
> freebios/src/lib/malloc.c:
>
> void *malloc(size_t size)
> {
> void *p;
>
> + printk_info("heap = 0x%lx, eheap = 0x%lx\n", (long)_heap, (long)_eheap);
>
> MALLOCDBG((__FUNCTION__ " Enter, size %d, free_mem_ptr %p\n", size,
> free_mem_ptr));
>
>
> what is so strange is that this fixed the problem and it is
> repeatable, if I remove the printk, the error will reappear. Has
> anyone seen anything like this? Could it be gcc acting up?
I'd guess either gcc acting up or an overlapping memory problem.
Though I would also double check that
northbridge/nsc/gx1/northbridge.c:sizeram
is o.k. I don't see anything obvious in my changes but I'd double
check.
Running objdump --all-headers linuxbios is interesting as it will
tell you where everything lives in LinuxBIOS.
>
> bash$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/specs
> gcc version 2.95.3 20010315 (SuSE)
>
> bash$ ld -v
> GNU ld version 2.11.90.0.29 (with BFD 2.11.90.0.29)
>
> It could also be timing related, I'll try to explore a bit more.
Unless some of the hardware isn't working I can't see how it would
be timing related.
Eric
