overflowed source buffer ... segment exceeding memory
steven james
pyro at linuxlabs.com
Fri Nov 15 17:22:01 CET 2002
Greetings,
Hrmm, the kernel should be in control by that point. The most likely
problems are kernel compiled fro wrong processor type, and not passing
console=ttyS0,115200n8 (or whatever speed you're using) to the kernel
(using mkelfImage's --command-line switch).
G'day,
sjames
On Thu, 14 Nov 2002, Bill Rugolsky Jr. wrote:
> On Thu, Nov 14, 2002 at 08:17:21AM -0500, steven james wrote:
> > I don't think it's the compression here. I have a working BIOS built from
> > CVS on 11/05/2002. I don't think it matters to this, but I did hack
> > zkernel_start on the fallback image to be fff00000 and modify the linker
> > script to hard code the primary image at fffe0000 - 8.
>
> OK, well I was doing a bunch of things wrong. But I'm getting closer.
>
> First, CVS is using the linuxbios table, but Eric's etherboot-5.1.0 patch
> does not include it. It is in the 5.0.5 patchset.
>
> Doing that, etherboot loads the kernel, and jumps to it.
> I've applied Eric's linux-2.4.18-pre7.linuxbios.diff on top of
> 2.4.20-rc1.
>
> The mkelfImage-1.18 startup code prints "LinuxBIOS" and then does nothing.
>
> Should I be applying a more recent patch to my kernel? Do I need
> other patches?
>
> My next step is to sprinkle the mkelfImage header with debugging puts()
> and the kernel startup with early_printk.
>
> Thanks for your help.
>
> -Bill
>
--
-------------------------steven james, director of research, linux labs
... ........ ..... .... 230 peachtree st nw ste 701
the original linux labs atlanta.ga.us 30303
-since 1995 http://www.linuxlabs.com
office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------
More information about the coreboot
mailing list