headers
Peter Stuge | 1 Dec 02:53
Picon

Re: Qemu compile for LinuxBIOSV2

On Fri, Nov 30, 2007 at 02:53:03PM -0500, Marc Karasek wrote:
> When I try to compile v2 with a filo.elf payload I get the :
> 
> collect2: ld terminated with signal 11 [Segmentation fault]

The linker plain crashes.

Try vanilla upstream gcc and binutils packages.

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Carl-Daniel Hailfinger | 1 Dec 05:19
Picon
Gravatar

Calling non-PIC code from PIC code

Hi Segher,

thanks for looking into this! As per your request on IRC, attached are
the files which comprise the XIP code we are having problems with.
*.85.* has the non-extern variant of initram_printktest.c and does abort
with a linker error (duplicate symbols), *.86.* has the extern variant
and links fine.

Short list of files with explanations:
build/stage0-prefixed.85.o
build/stage0-prefixed.86.o
Object we link against with --just-symbols. It contains the non-PIC code
we want to call.

build/mainboard/emulation/qemu-x86/initram_xip.85.o
build/mainboard/emulation/qemu-x86/initram_xip.86.o
PIC object with "ret (*func)(args) = stage0_##func;" sequence, contains
main(), which calls printk() and printktest().

build/mainboard/emulation/qemu-x86/initram_printktest_xip.85.o
PIC object with "ret (*func)(args) = stage0_##func;" sequence, contains
printktest(), which calls printk().

build/mainboard/emulation/qemu-x86/initram_printktest_xip.86.o
PIC object with "extern ret (*func)(args);" sequence, contains
printktest(), which calls printk().

initram_printktest.85.i
initram_printktest.85.s
initram_printktest.86.i
(Continue reading)

Permalink | Reply | 0 comments |
headers
ron minnich | 1 Dec 06:32
Picon

Re: SPI flash

On Nov 30, 2007 3:44 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 <at> gmx.net> wrote:

> With the IT8716F SPI translation feature, the best possible result is:
> (freq/8/2) Byte/s
> That is roughly 2 MByte/s, way too slow to try to boot from it.

it's actually pretty tolerable  if you're just sucking in an initrd.
I've done this sort of thing.

ron

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Carl-Daniel Hailfinger | 1 Dec 08:12
Picon
Gravatar

Re: [PATCH] v3: Crash with a descriptive message in case of compiler bugs

On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
> Ron mentioned he had strange hangs in pll_reset on various targets. This
> may be due to miscompilation of XIP objects which do not have
> _MAINBOBJECT defined. This issue was impossible to see on qemu because
> no such object existed. Introduce initram_printktest.c in the Qemu
> target, which will test for miscompilation and crash with a descriptive
> error message.
>
> This has been build tested and runtime tested on Qemu, and with my
> compiler/linker combination it indeed crashes.
> gcc (GCC) 4.2.1 (SUSE Linux)
> GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
>
> Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and
> the linker above had exactly the same results.
>
> Unless we manage to fix the bug uncovered by this patch, leaving the
> Qemu target in crashing state is the best thing we can do because this
> behaviour mirrors the state of all other targets.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
>
> (don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c"
> if you commit)
>   

Ack anyone? I have another patch which fixes the bug revealed by this
patch, but I want to commit them in separate steps to make it more
obvious that one patch points out the problem, and one is a possible
solution.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andreas B. Mundt | 1 Dec 10:11
Picon

Re: flashrom fails on GA-M57SLI with 1MB ROM

Hi,

building a LAB-image with buildrom (I had to do this on an other
32-bit machine) flashing now works for me, too. I tried to find out
why, but so far without success. Some configuration might differ? 
What can go wrong switching to 1024kB? 

Ideas?

Thanks,

	Andi 

Below my LinuxBIOSv2/targets/gigabyte/m57sli/Config.lb:

$grep -Ev '^(#|$)' Config.lb

target m57sli
mainboard gigabyte/m57sli
option ROM_SIZE=0x100000
romimage "normal"
        option USE_FAILOVER_IMAGE=0
        option USE_FALLBACK_IMAGE=0
        option ROM_IMAGE_SIZE=0x20000
        option XIP_ROM_SIZE=0x40000
        option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal"
        payload ../../../../../../filo-0.5/filo.elf
        option DEFAULT_CONSOLE_LOGLEVEL=8
        option MAXIMUM_CONSOLE_LOGLEVEL=8
end
(Continue reading)

Permalink | Reply | 5 comments |
headers
Stefan Reinauer | 1 Dec 13:10
Picon

Re: [PATCH] v3: Crash with a descriptive message in case of compiler bugs

Carl-Daniel Hailfinger wrote:
> On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
>   
>> Ron mentioned he had strange hangs in pll_reset on various targets. This
>> may be due to miscompilation of XIP objects which do not have
>> _MAINBOBJECT defined. This issue was impossible to see on qemu because
>> no such object existed. Introduce initram_printktest.c in the Qemu
>> target, which will test for miscompilation and crash with a descriptive
>> error message.
>>
>> This has been build tested and runtime tested on Qemu, and with my
>> compiler/linker combination it indeed crashes.
>> gcc (GCC) 4.2.1 (SUSE Linux)
>> GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
>>
>> Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and
>> the linker above had exactly the same results.
>>
>> Unless we manage to fix the bug uncovered by this patch, leaving the
>> Qemu target in crashing state is the best thing we can do because this
>> behaviour mirrors the state of all other targets.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
>>
>> (don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c"
>> if you commit)
>>   
>>     
>
> Ack anyone? I have another patch which fixes the bug revealed by this
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Smith | 1 Dec 14:13
Picon

Re: USB booting in LinuxBIOS

Uwe Hermann wrote:

> Sure, but how is the "boot from USB" functionality implemented? Forth
> code? C code? Can we port it to LinuxBIOS/FILO/GRUB somehow?

Its all forth.  There are some forth/C hackers on the list.  They  could 
certainly look at the code and how its done.  The setup is starting to 
mature.  USB mostly just "works" now.

Devices that don't work are better off just discarded rather than 
messing with.  There are only a few troublesome keys left floating 
around at 1cc and I quarantine them when they get brought to me.

USB is a ton of work and seemingly a bottomless pit with respect to "my 
xxx device won't boot" reports.

-- 
Richard A. Smith
smithbone <at> gmail.com

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Carl-Daniel Hailfinger | 1 Dec 14:43
Picon
Gravatar

Re: [PATCH] v3: Crash with a descriptive message in case of compiler bugs

On 01.12.2007 13:10, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> On 30.11.2007 18:35, Carl-Daniel Hailfinger wrote:
>>   
>>     
>>> Ron mentioned he had strange hangs in pll_reset on various targets. This
>>> may be due to miscompilation of XIP objects which do not have
>>> _MAINBOBJECT defined. This issue was impossible to see on qemu because
>>> no such object existed. Introduce initram_printktest.c in the Qemu
>>> target, which will test for miscompilation and crash with a descriptive
>>> error message.
>>>
>>> This has been build tested and runtime tested on Qemu, and with my
>>> compiler/linker combination it indeed crashes.
>>> gcc (GCC) 4.2.1 (SUSE Linux)
>>> GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
>>>
>>> Trying with gcc-4.1 (GCC) 4.1.3 20070724 (prerelease) (SUSE Linux) and
>>> the linker above had exactly the same results.
>>>
>>> Unless we manage to fix the bug uncovered by this patch, leaving the
>>> Qemu target in crashing state is the best thing we can do because this
>>> behaviour mirrors the state of all other targets.
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>
>>>
>>> (don't forget "svn add mainboard/emulation/qemu-x86/initram_printktest.c"
>>> if you commit)
>>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
ron minnich | 1 Dec 18:24
Picon

Re: [PATCH] v3: Crash with a descriptive message in case of compiler bugs

I am comfortable with this. If hardware is broken, qemu should be
broken. I avidly wait the fix :-)

Acked-by: Ronald G. Minnich <rminnich <at> gmail.com>

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Uwe Hermann | 1 Dec 21:30
Picon
Favicon
Gravatar

Re: Booting Windows with QEMU+LinuxBIOS

On Thu, Nov 29, 2007 at 06:37:10PM +0900, Jun Koi wrote:
> Hmm... I managed to do like this:
> 
> - Compile ADLO separately, then I have a file named "payload"
> - In LinuxBIOSv3, I run "make menuconfig", then specify the path of
> payload option to the above "payload".
> - Save options, quit and compile.
> 
> As a result, I have build/bios.bin, and I overwrites this file onto
> the original bios.bin of my QEMU.

No need to overwrite. Just use the '-L build' command line option for
QEMU and it will use the bios.bin in the build/ directory instead of
the normal one.

> Then, I run QEMU with my Linux image. It works, and I can login to my
> Linux QEMU.
> 
> Now, the problem is that I am not sure if my Linux on QEMU really uses
> LinuxBIOS. How can I confirm that? "dmesg" doesnt seem to return
> anything special to me.

Use the '-serial stdio' command line option with QEMU, that will
print a "LinuxBIOS starting..." or similar message if it's really
LinuxBIOS.

Uwe.
--

-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane