coreboot

coreboot@coreboot.org

39717 discussions

[LinuxBIOS] Re: [linuxbios-checkins] r2079 - in trunk/LinuxBIOSv2: src/southbridge/amd/amd8111 util/abuild
by Stefan Reinauer 26 Oct '05

26 Oct '05

* svn(a)openbios.org <svn(a)openbios.org> [051026 00:24]: > Author: jschildt > Date: 2005-10-26 00:24:46 +0200 (Wed, 26 Oct 2005) > New Revision: 2079 > > Modified: > trunk/LinuxBIOSv2/src/southbridge/amd/amd8111/amd8111_usb2.c > trunk/LinuxBIOSv2/util/abuild/abuild.sh > Log: > - Fixed fat-finger typo enable - enabled Please do run abuild _before_ commit. > - Fixed abuild.sh to use larger size for ROM_IMAGE_SIZE. This will work for some, but fail for others. Some of the non-k8 boards. Stefan

1 0

RE: [LinuxBIOS] Latest commit - clarification
by Lu, Yinghai 26 Oct '05

26 Oct '05

Don't worry, Please stay with the old code. After LNXI put back apic id lifting back, I will enable the CAR shortly in the public tree. YH ________________________________ From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of San Mehat Sent: Tuesday, October 25, 2005 4:59 PM To: LinuxBIOS Subject: [LinuxBIOS] Latest commit - clarification Hey Jason, Would you mind just chucking up an exec summary of all the changes?.. I'm trying to adapt our port to the new code and am trying to figure out whats going on ;) Mainly: set_apicid_cpuid_low() = gone start_other_cores() = gone __cpu_reset = gone get_apicid_base() = gone Actually, the __cpu_reset: thing looks broken on CAR systems... looking at the tyan s4882 board, the Config.lb only brings in arch/i386/lib/cpu_reset.inc if we're NOT CAR.... We're basicaly doing everything as CAR. Are there more changes comming? or should we just start hacking to pick up the pieces? thanks man... ;) -san

4 6

[LinuxBIOS] lnxi checkins
by Richard Smith 26 Oct '05

26 Oct '05

I see... Log: - See Issue Tracker id-7 "lnxi-patch-7" Is this some sort of internal issue tracker at lnxi? Or did linuxbios gain one when I wasn't looking? -- Richard A. Smith

2 3

[LinuxBIOS] LNXI mega patch commits beginning
by Jason Schildt 25 Oct '05

25 Oct '05

All, We're in a conference room going over the lnxi patches and will be commiting them to the repository over the next few minutes. Please stand by... --jason-- -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx

1 0

[LinuxBIOS] Proposed change to hypertransport.c for better error handling
by San Mehat 24 Oct '05

24 Oct '05

Hey all, It appears that under certain situations / hardware, HT can come up with the LinkFail and CrcError bits set on certain devices, even though the bus isn't *currently* in an error state. This causes 'hypertransport_scan_chain()' to stop traversing down a chain. I've made the following patch which knocks down the error state and re-reads to identify if the error is transient or not (It also reports the error rather than silently aborts the chain scan which caused me about 6 hours of hunting to find): *****BEGIN CUT***** Index: hypertransport.c =================================================================== --- hypertransport.c (revision 2064) +++ hypertransport.c (working copy) @@ -345,12 +345,25 @@ /* Wait until the link initialization is complete */ do { ctrl = pci_read_config16(prev.dev, prev.pos + prev.ctrl_off); - /* Is this the end of the hypertransport chain? - * Has the link failed? - * If so further scanning is pointless. - */ - if (ctrl & ((1 << 6) | (1 << 4))) { - goto end_of_chain; + + if (ctrl & (1 << 6)) + goto end_of_chain; // End of chain + + if (ctrl & ((1 << 4) | (1 << 8))) { + /* + * Either the link has failed, or we have + * a CRC error. + * Sometimes this can happen due to link + * retrain, so lets knock it down and see + * if its transient + */ + ctrl |= ((1 << 6) | (1 <<8)); // Link fail + Crc + pci_write_config16(prev.dev, prev.pos + prev.ctrl_off, ctrl); + ctrl = pci_read_config16(prev.dev, prev.pos + prev.ctrl_off); + if (ctrl & ((1 << 4) | (1 << 8))) { + printk_alert("Detected error on Hypertransport Link\n"); + goto end_of_chain; + } } } while((ctrl & (1 << 5)) == 0); ****END CUT*****

3 5

RE: [LinuxBIOS] Mainboard MSI-6330
by Lu, Yinghai 22 Oct '05

22 Oct '05

Need someone add via SB support.... YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of 2481-287 Sent: Monday, December 26, 2005 3:54 PM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] Mainboard MSI-6330 Hello, My questions are attached Thank You Stephan

3 3

[LinuxBIOS] Re: [linuxbios-checkins] r2065 - trunk/LinuxBIOSv2/src/stream/fs
by ebiederman＠lnxi.com 21 Oct '05

21 Oct '05

svn(a)openbios.org writes: > Author: gwatson > Date: 2005-10-21 02:52:52 +0200 (Fri, 21 Oct 2005) > New Revision: 2065 This commit is broken. We are never going to be able to set ARCH to the character constant 'i386'. The basic sentiment sane but not the implementation. Eric > Modified: > trunk/LinuxBIOSv2/src/stream/fs/ext2fs.c > trunk/LinuxBIOSv2/src/stream/fs/fat.c > Log: > Some compilation issue fix for PPC970 port > > Modified: trunk/LinuxBIOSv2/src/stream/fs/ext2fs.c > =================================================================== > --- trunk/LinuxBIOSv2/src/stream/fs/ext2fs.c 2005-10-20 01:44:21 UTC (rev 2064) > +++ trunk/LinuxBIOSv2/src/stream/fs/ext2fs.c 2005-10-21 00:52:52 UTC (rev 2065) > @@ -239,7 +239,7 @@ > * ffz = Find First Zero in word. Undefined if no zero exists, > * so code should check against ~0UL first.. > */ > -#ifndef PPC > +#if ARCH == 'i386' > static __inline__ unsigned long > ffz (unsigned long word) > { > > Modified: trunk/LinuxBIOSv2/src/stream/fs/fat.c > =================================================================== > --- trunk/LinuxBIOSv2/src/stream/fs/fat.c 2005-10-20 01:44:21 UTC (rev 2064) > +++ trunk/LinuxBIOSv2/src/stream/fs/fat.c 2005-10-21 00:52:52 UTC (rev 2065) > @@ -54,7 +54,7 @@ > > #define FAT_CACHE_SIZE 2048 > > -#ifndef PPC > +#if ARCH == 'i386' > static __inline__ unsigned long > log2 (unsigned long word) > { > > > -- > To unsubscribe send an email to > linuxbios-checkins+unsubscribe(a)openbios.org

1 0

RE: [LinuxBIOS] Tyan S2865 LinuxBIOS
by Lu, Yinghai 20 Oct '05

20 Oct '05

I have ported the s2865 support at Tyan. So you can ask tyan to release that code to public tree. They need to remove some NDA info.... YH -----Original Message----- From: linuxbios-bounces(a)openbios.org [mailto:linuxbios-bounces@openbios.org] On Behalf Of Jeremy Jackson Sent: Thursday, October 20, 2005 7:24 AM To: linuxbios(a)openbios.org Subject: [LinuxBIOS] Tyan S2865 LinuxBIOS Hi, I inquired about this with Charlie at Tyan, but I haven't heard anything and it's been over a month; maybe someone here knows about the status of LinuxBIOS for the S2865? (ck804 based) Regards, Jeremy -- Jeremy Jackson Coplanar Networks W:(519)489-4903 C:(519)897-1516 http://www.coplanar.net -- LinuxBIOS mailing list LinuxBIOS(a)openbios.org http://www.openbios.org/mailman/listinfo/linuxbios

1 0

[LinuxBIOS] Tyan S2865 LinuxBIOS
by Jeremy Jackson 20 Oct '05

20 Oct '05

Hi, I inquired about this with Charlie at Tyan, but I haven't heard anything and it's been over a month; maybe someone here knows about the status of LinuxBIOS for the S2865? (ck804 based) Regards, Jeremy -- Jeremy Jackson Coplanar Networks W:(519)489-4903 C:(519)897-1516 http://www.coplanar.net

1 0

[LinuxBIOS] Via Epia-m and VGA Bios emulation
by Nick Barker 19 Oct '05

19 Oct '05

I now have some more information on running the VGA bios through the emulator on the epia-m I have implemented both real mode and emulated VGA initialisation. The real mode brings up the vga properly, whilst the emulation does not. The emulated version runs to completion and also returns with Carry Flag set which I'm assuming means that it has given up trying. Using TSC, a performance counter set to count instructions, and a simple instruction counter in the main loop of the emulator, I have come up with the following statistics for the vga initialisation sequence: Real Mode --------- CPU Clocks = 691,530,971 (600Mhz processor = 1.1 seconds approx) Instructions executed = 16,481,875 Interestingly this gives a clocks/instruction ratio of about 43, which we can put down to intensive I/O and which must stall the processor by many clock cycles per I/O. Emulation mode -------------- CPU Clocks = 4,618,464,706 (= 7.7 seconds approx) Instructions executed = 1,946,308,181 Emulated instructions = 13,756,300 This gives us 2 ratios of interest: Average clocks per instruction = 2.37 (much less than real mode since the emulation is much more memory intensive) Average instructions per emulated instruction = 141 The emulator is also running nearly 3 million fewer instructions, which could be down to it doing fewer loop iterations whilst waiting for things to come ready, or could also be attributed to the bios giving up early. I am now working on the hypothesis that the emulator has to be faster if it is going to work at all for the epia-m, which means fewer instructions per emulated instruction. I have a few ideas which I intend investigating and trying out: 1) embed/inline the memory read/write and io functions directly where they are used rather than having trivial subroutines accessed via arrays of function pointers. I believe that this processor is easily stalled by jumps to subroutines, and so inlining these should help. 2) hard code the emulator memory base at 0, so that this addition is avoided on every memory access (since linuxbios always sets it at 0 anyway) 3) Implement the primitive operations in assembler - as has been done in prim_asm.h for the Watcom compiler, but this time for gcc 4) Investigate the emulated repeat move string operation to see if this is done efficiently by the emulator etc.... Nick Barker

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot