coreboot

coreboot@coreboot.org

5 participants
39567 discussions

Re: romcc portability (cont)
by ebiederman＠lnxi.com 09 Oct '03

09 Oct '03

<standard rant> Please use the list for basic stuff like this. As the reply at least is educational to multiple people. </standard rant> "Peter Fox" <peter.fox(a)ifrsys.com> writes: > For various reasons I won't bore you with, I'm trying out the > freebios2 stuff on freebsd. I had a couple of problems compiling > romcc that you might like to address in the next version: > > Freebsd doesn't have <stdint.h>. > > I forgot to mention - I just commented out <stdint.h> and it seemed to compile > ok without it, so I guess you don't actually need to include it. I do use uint8_t, uint16_t, and uint32_t so stdint.h is needed. It sounds like Freebsd may be defining these somewhere else at the moment. Short of building a configure script I really can't address this. If someone would like to contribute a configure script I would happily accept one. I am busy with more core aspects of the code at the moment. I totally support the idea of building on Freebsd. There is nothing inherently Linux specific about LinuxBIOS at this point > __error() clashes with an entry in <errno.h> - perhaps you should > prefix your functions by '_romcc_', rather than '__' ? Ouch this is a problem. Everything with a leading underscore is reserved to the implementation. Double underscore is reserved for global scope and a single underscore is reserved for file scope definitions. So this is my bug. I have just changed those three instances from __ to romcc_ and all looks good here. I will see what I can do about committing these changes. Eric

1 0

romcc error in smbus code
by Stefan Reinauer 09 Oct '03

09 Oct '03

Hi Eric, I recently added the function smbus_write_byte() to src/southbridge/amd/amd8111/amd8111_early_smbus.c. if the code within #if 0 in that function is enabled, I get the following internal compiler error: ./romcc -mcpu=k8 -O ./auto.E > auto.inc <built-in>:1.0: warning: edge: <built-in>:1.0: warning: 0x2fe7e40 __inw amd8111_early_smbus.c:120.39: warning: edge: amd8111_early_smbus.c:120.39: warning: 0x2fe80e0 copy <built-in>:1.0: warning: edge: <built-in>:1.0: warning: 0x3126060 copy <built-in>:1.0: warning: edge: <built-in>:1.0: warning: 0x2fea8d0 __inw amd8111_early_smbus.c:125.63: warning: edge: amd8111_early_smbus.c:125.63: warning: 0x2feab70 copy <built-in>:1.0: warning: edge: <built-in>:1.0: warning: 0x2feba50 __inw io.h:39.1: warning: edge: io.h:39.1: warning: 0x2febb70 copy amd8111_early_smbus.c:128.48: warning: 0x2febcf0 copy <built-in>:1.0: warning: edge: <built-in>:1.0: warning: 0x2fe6450 __inw auto.c:102.45: warning: def: auto.c:102.45: warning: 0x2fe5020 copy amd8111_early_smbus.c:131.33: warning: 0x2fec520 copy auto.c:102.45: 0x2fe5020 copy Internal compiler error: live range with already used color %ax Is the code running out of registers? What's happening here? Stefan -- Architecture Team SuSE Linux AG

2 4

LNXI hdama merge status...
by ebiederman＠lnxi.com 08 Oct '03

08 Oct '03

I have just gone through and done the bulk of the merge work, between my internal stable tree and the main LinuxBIOS tree. I have a bunch of details to check to make certain things are working. And to double check I have not done something stupid, but so far things look promising. Among other things I have gotten a 32 bit kernel without mptable support to boot and find it's irqs successfully. Although I will agree that not scanning all pci busses just in case something might go wrong is a reasonable conservative approach. Anyway properly handling irqs, and getting the LinuxBIOS interfaces right looks like the next step for v2.0. Later, Eric

1 0

V2 Epia
by Nathanael Noblet 08 Oct '03

08 Oct '03

Hello, So I don't have an etherboot setup, and am trying to build the epia target. I would like the payload to be filo.elf and have changed the payload options. Then I couldn't get it done because with the fallback image it was saying the romimage was too large. Well I don't use a fallback image anyway (or never have) so commented out everything that was related to FALLBACK I could find in the Config.lb file. It wouldn't compile after that because elfboot.c had missing link for boot_successful() so I commented that out.. anyway I didn't look at the boot successful function, but suffice it to say it didn't work. It built and flashed and all that but it didn't come up. So I'm wondering what is the preferred method in V2 to not have a fallback image. The other thing I noticed is that my linuxbios.rom file is only 192Kb instead of 256kb... Is that why the fallback image wouldn't work? -- Nathanael Noblet Gnat Solutions 4604 Monterey Ave NW Calgary, AB T3B 5K4 T/F 403.288.5360 C 403.809.5368 http://www.gnat.ca/

2 2

FILO 0.3
by SONE Takeshi 08 Oct '03

08 Oct '03

I released FILO version 0.3, featuring bzImage loader. Steve Gehlbach has helped me a lot. Version 0.3 ts1 2003-10-07 * Added loader for Linux bzImage/zImage/Image (a.k.a. /vmlinuz). Many thanks to Steve Gehlbach <steve(a)nexpath.com> for early work on this. * New "context switch" routine to unify the assembly starters for ELF and Linux, and even the C startup. This reduced the amount of assembly code. * Debug prints are now automatically prefixed with function names. * Lots of internal tweaks. It can be downloaded from http://te.to/~ts1/filo/. -- Takeshi

3 4

Can linuxbois support VGA for EPIA-M10000 ?
by gimyung han 07 Oct '03

07 Oct '03

>>David Hendriks has tested and I have committed these new idt.c and >>vgabios.c You mean Now vga for EPIA-10000 is available? Is it possible to use by setting Config file or is there other way? _________________________________________________________________ 증권 정보 가장 빠르고 편하게 보실 수 있습니다. MSN 증권/투자 http://www.msn.co.kr/stock/

1 0

Re: TUSL2-C 815ep failed
by Yap Ee Huey 07 Oct '03

07 Oct '03

I have read about the SMBUS issue on CUA board. I have just tried to pull all GPIO high and all low, but the SPD testing program in the linuxbios tree doesn't detect any memory . Am I too nervous ? I will try again tomorrow. Ron, do you have any other method of finding the GPIO besides using PCI analyzer ? I dont have one. Thanks. eehuey >From: ron minnich <rminnich(a)lanl.gov> >To: Yap Ee Huey <yapeehuey(a)hotmail.com> >CC: linuxbios(a)clustermatic.org >Subject: Re: TUSL2-C 815ep failed >Date: Mon, 6 Oct 2003 09:15:10 -0600 (MDT) > >ASUS boards have two SMBUSes in many cases. Unless you set the right kind >of bits you can't read SPD. > >When we did the CUA we had to set up a PCI analyzer to work out some of >the issues with board setup. > >ron > _________________________________________________________________ Download ringtones, logos and picture messages from MSN Malaysia http://www.msn.com.my/mobile/ringtones/default.asp

1 0

cleanup: SMBUS_MEM_DEVICE_[START|END]
by Stefan Reinauer 07 Oct '03

07 Oct '03

Hi, the two config variables SMBUS_MEM_DEVICE_START and SMBUS_MEM_DEVICE_END are only used by ./src/sdram/generic_dump_spd.c. Does it make sense to keep those? dump_spd_registers() could use the ram_controller struct to get the values. Then I would remove SMBUS_MEM_DEVICE_[START|END] occurences in the code. Stefan -- Architecture Team SuSE Linux AG

2 2

Re: w49f002u.c ?
by Damien Charlet 07 Oct '03

07 Oct '03

Ok guys, back on my ol' mail after some other work :) Thanx for all your replies so here's where I am now : 1 - The original chip is a sst39 part whereas my savior has a w49 2 - This is the part referenced by IOSS for epia 3 - This chip almost work with my via : I can flash it, read it, boot on it... BUT there are a few bytes which are not flashed well. The wrong bytes always change after reflash. So, I believe the 49 should work with the epia, at the exception of a little something while flashing. Where could I dig more in depth ? Thx, Damien On Mon, 22 Sep 2003 14:16:55 -0600 (MDT) ron minnich <rminnich(a)lanl.gov> wrote: > On Mon, 22 Sep 2003, Damien Charlet wrote: > > > Sorry, this is related to my previous mail "flash_rom and epia 800". > > > > I got a BIOS Savior on my via epia 800. The chip in the RD1-PL is > > (recognized as ?) a w49f002u. Maybe I should check physically which chip > > is on the savior ? > > my turn to be surprised. The EPIA takes a 49F part? Can somebody fill me > in here -- I didn't think it took these. If it does, well, this is very > good news. > > ron -- Damien(.)Charlet(AT pu-pm.univ-fcomte.fr) Doctorant UIN:78754463 Laboratoire d'Informatique de l'Universite de Franche-Comte FRE CNRS 2661 - Centre de Developement du Multimedia de Montbeliard Tel: +33-(0)3.81.99.47.76 damien.charlet(a)pu-pm.univ-fcomte.fr

2 4

re: K8 MTRR reboot on Solo
by YhLu 06 Oct '03

06 Oct '03

I enabled it, and use X86-64 bin to make elf image with mkelfimage 2.5. Please try my zelf instead. Regards YH. -----邮件原件----- 发件人: Stefan Reinauer [mailto:stepan@suse.de] 发送时间: 2003年10月6日 10:29 收件人: YhLu 抄送: linuxbios(a)clustermatic.org 主题: Re: K8 MTRR reboot on Solo * YhLu <YhLu(a)tyan.com> [031006 18:12]: > There is an X86-64 option in Etherboot config, did you enable it? yes. But I thought it only affects the binary loader. Should I switch it off? Stefan -- Architecture Team SuSE Linux AG

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot