coreboot

coreboot@coreboot.org

10 participants
39711 discussions

答复: [PROPOSAL] extended payload handling
by YhLu 16 Jun '04

16 Jun '04

Eric, Did you ever translate the E7501 into C? Regards YH -----邮件原件----- 发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com] 发送时间: Wednesday, June 16, 2004 10:25 AM 收件人: ron minnich 抄送: Stefan Reinauer; LinuxBIOS 主题: Re: [PROPOSAL] extended payload handling ron minnich <rminnich(a)lanl.gov> writes: > On 14 Jun 2004, Eric W. Biederman wrote: > > I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. > What's bloat? linuxbios overall is about the size of 'cat'. Ron can I have you version of romcc?. We have several ports that are routinely smacking up against the 64K limit during development. The last E7501 port I did in the freebios1 tree LinuxBIOS was running about 40K. With romcc inlining everything we are worse in the freebios2 tree. As far as bloat baring Stefan's concerns about redundancy between LinuxBIOS and OpenBIOS (the resource allocation code). Is not so much about the features we have to day, but more a feeling much more will be the pebble that starts the avalanche. Or maybe we feel we have seen the pebble, and we are watching it bounce downhill with dread. The bottom line is that to keep size under control you constantly have to be paying attention to size, just as you have to constantly watch correctness and performance. The long term trends in the industry are for very slow romsize growth. Anyway even at 32K you are twice as big as my cat :) ls -l /bin/cat -rwxr-xr-x 1 root root 15000 2003-10-04 17:10 /bin/cat* Eric _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 3

答复: Building Tyan AMD64 s2882 Linux BIOS
by YhLu 16 Jun '04

16 Jun '04

For Linux based Server, LinuxBIOS would be better than any other commercial BIOS. OS has been in GPL, So BIOS should be there too. Regards YH -----邮件原件----- 发件人: Tony Cheng [mailto:tony_cheng@pcmagic.net] 发送时间: Wednesday, June 16, 2004 1:29 PM 收件人: YhLu 抄送: LinuxBIOS 主题: Re: Building Tyan AMD64 s2882 Linux BIOS Yh, The source code I've got is coming from CVS, but it's about one or two month ago. I get the code and did do anything with it until now. I will update the code and try again. I will try Redhat 9.0, last time I try it, I saw the version of GCC on redhat 9.0 is lower than the required version mentioned by LinuxBIOS-AMD64, Author by Stefan Reinauer I'm not fully understand the paylod idea yet, but I will do some research on my side. I'm really appriciate the response you guys have given to me. I'm starting to feel much more confident with LinuxBIOS now. Some people in my company is a little hesitate about the LinuxBIOS as we use Phoenix BIOS before and afraid of the free Software, I will make a strong case for them because the good community I saw here. Tony ----- Original Message ----- From: "YhLu" <YhLu(a)tyan.com> To: <tony_cheng(a)pcmagic.net> Cc: "LinuxBIOS" <linuxbios(a)clustermatic.org> Sent: Wednesday, June 16, 2004 1:06 PM Subject: 答复: Building Tyan AMD64 s2882 Linux BIOS > Tony, > > Where did you get the source code? > > Via CVS or linuxbios snapshot? > > The update source code should be compiled no problem under RH 9 for i386. > > ROM_SECTION_SIZE should be 128K for fallback. > > If you want to boot local > 1. Etherboot: you can build ide_disk.zelf > 2. FILO: it can understand file system and kernel + rootfs instead of elf > format > 3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from sata > and it can boot from usb disk too. > > Regards > > YH > -----邮件原件----- > 发件人: root [mailto:tony_cheng@pcmagic.net] > 发送时间: Wednesday, June 16, 2004 12:58 PM > 收件人: YhLu > 抄送: LinuxBIOS > 主题: Building Tyan AMD64 s2882 Linux BIOS > > > Mr. Yh, > > I'm glag to see you here. I saw your name on the LinuxBIOS web site and > know you are the owner of Tyan AMD64 motherboard. > > I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2 > CPUs system for my comany, we are evaluating Tyan s2882 board for a > embeded Storage Server. I have some questions maybe you can enlighten > me. > > 1. I get a lot of warning messages from compiler when I build, is that > normal? I use Suse Linux 9.1, GCC 3.3.3 > > 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break > during the build, is that the way it is? > > 3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a > very small payload and use a flash utilty to program the Flash. I set > the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux > Kernel to fit into the Flash. Do you have any recommandation about the > payload? if you can send your payload "tg3--ide_disk_com1_2.zelf" to me > just for a testing purpose that will be great! > > > Thanks > > Tony > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

答复: Building Tyan AMD64 s2882 Linux BIOS
by YhLu 16 Jun '04

16 Jun '04

Tony, Where did you get the source code? Via CVS or linuxbios snapshot? The update source code should be compiled no problem under RH 9 for i386. ROM_SECTION_SIZE should be 128K for fallback. If you want to boot local 1. Etherboot: you can build ide_disk.zelf 2. FILO: it can understand file system and kernel + rootfs instead of elf format 3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from sata and it can boot from usb disk too. Regards YH -----邮件原件----- 发件人: root [mailto:tony_cheng@pcmagic.net] 发送时间: Wednesday, June 16, 2004 12:58 PM 收件人: YhLu 抄送: LinuxBIOS 主题: Building Tyan AMD64 s2882 Linux BIOS Mr. Yh, I'm glag to see you here. I saw your name on the LinuxBIOS web site and know you are the owner of Tyan AMD64 motherboard. I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2 CPUs system for my comany, we are evaluating Tyan s2882 board for a embeded Storage Server. I have some questions maybe you can enlighten me. 1. I get a lot of warning messages from compiler when I build, is that normal? I use Suse Linux 9.1, GCC 3.3.3 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break during the build, is that the way it is? 3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a very small payload and use a flash utilty to program the Flash. I set the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux Kernel to fit into the Flash. Do you have any recommandation about the payload? if you can send your payload "tg3--ide_disk_com1_2.zelf" to me just for a testing purpose that will be great! Thanks Tony

2 1

答复: Linux Centrino Notebook
by YhLu 16 Jun '04

16 Jun '04

What's the Northbridge? -----邮件原件----- 发件人: Bari Ari [mailto:bari@onelabs.com] 发送时间: Wednesday, June 16, 2004 9:46 AM 收件人: linuxbios(a)clustermatic.org 主题: Linux Centrino Notebook IBM now has a Linux notebook with Tier1 support. Maybe this is a laptop to get LinuxBIOS up on. http://www.theinquirer.net/?article=16550 http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId= 2049168&storeId=1&catalogId=-840&langId=-1 Anyone have one of these yet? -Bari _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

Phantom Devices
by Li-Ta Lo 16 Jun '04

16 Jun '04

Hello, I am porting LinuxBIOS to the AMD Serenade mainboard and encountered another problem with the device enumeration/ resource allcation. The Serenade is almost exactly like the HDAMA or E325 but the two CPUs are connected by LDT0 on each one and the NCHT to 8131/8111 is on LDT2 on CPU0. I reused the mainboard/hdama and CAREFULLY change the .c code to reflaect the difference in LDT. I didn't change the Config.lb because the "bus" hierachy is the same. After I boot with the image I found that the dynamic device structures converted from the static device structures are NOT connected to the real devices found in the pci bus scan. So I have a set of dynamic device strucures without any corresponding physical device (PHANTOMs) and another set of dynamic devices structures having no "static" device information from the Config.lb. The problem is caused by having uninitialized or incorrectly initialized bus->children. The dynamic device structures converted from static devices are on the other "link" (I would rather call it 'branch') of the "parent" i.e. they are the children of another "bus". The pci_scan_get_dev() or ht_scan_get_devs() can not find the pre-created device structures on this WRONG "bus/link" when scaning the bus/chain so it created a new instance. How can I solve this problem ? Does the "link" keyword in the config file actually been used ? I tried to change the "link" for 8131/8111 in the config file but it made no difference. Ollie

1 0

RE: cvs freebios locked? [PMX:#]
by John Usher (Maptek) 15 Jun '04

15 Jun '04

It all sorted itself out overnight for me. Thanks people... ...John... -----Original Message----- From: Greg Watson [mailto:gwatson@lanl.gov] Sent: Tuesday, 15 June 2004 10:19 PM To: John Usher (Maptek) Cc: Gregg C Levine; linuxbios(a)clustermatic.org Subject: Re: cvs freebios locked? [PMX:#] Strange. I just tried to co both freebios and freebios2 using pserver:anonymous and they both worked fine. Try removing the entire tree and start from scratch. Greg On Jun 14, 2004, at 10:34 PM, John Usher (Maptek) wrote: > > >> Hello from Gregg C Levine >> Check your CVS command string. SF updated to a newer release of BIND, >> and it has a problem with the way the domains were arranged from the >> earlier versions. So it becomes like this: >> "#cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios >> login" and then: >> > > Yeah. I discovered that cvs.freebios.sourceforge.net does nothing but > time out for me. > >> "#cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios >> co modulename". (With out the quotes or pound marks. And the line wrap >> included by my mailer.) > > The 'co' is working fine until it gets to that sis directory, so I've > got all the mainboard stuff etc down... > > My command is equivalent to the above though I have CVSROOT set rather > than using the -d flag. However, I would expect it to not work at all > if > wrong, not get half of it then complain about a lock on the repository. > Its obviously only meant to be a temporary lock as well, because cvs > retries every thirty seconds. > > There is a specific user with the lock on the .../northsouthbridge/sis > directory, I just don't want to post it on here. > > ...john... > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

RE: cvs freebios locked?
by John Usher (Maptek) 15 Jun '04

15 Jun '04

>Hello from Gregg C Levine >Check your CVS command string. SF updated to a newer release of BIND, >and it has a problem with the way the domains were arranged from the >earlier versions. So it becomes like this: >"#cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios >login" and then: > Yeah. I discovered that cvs.freebios.sourceforge.net does nothing but time out for me. >"#cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios >co modulename". (With out the quotes or pound marks. And the line wrap >included by my mailer.) The 'co' is working fine until it gets to that sis directory, so I've got all the mainboard stuff etc down... My command is equivalent to the above though I have CVSROOT set rather than using the -d flag. However, I would expect it to not work at all if wrong, not get half of it then complain about a lock on the repository. Its obviously only meant to be a temporary lock as well, because cvs retries every thirty seconds. There is a specific user with the lock on the .../northsouthbridge/sis directory, I just don't want to post it on here. ...john...

2 1

cvs freebios locked?
by John Usher (Maptek) 15 Jun '04

15 Jun '04

Hi all, I'm trying to 'cvs co freebios', but am getting 'waiting for xxxxxx's lock in /cvsroot/freebios/freebios/src/northsouthbridge/sis'. This was been happening for 16+ hours now. What is the story with that? ...ta...john....

2 1

Intel Chipset support in V2
by YhLu 11 Jun '04

11 Jun '04

Ron, Any plan to move the intel chipset support from V1 to V2? I mean E750x and 82801xx. Regards YH

5 4

Re: [PROPOSAL] extended payload handling
by YhLu 10 Jun '04

10 Jun '04

Eric, What's your idea abut that? They are use cache as ram. .... Regards YH -----邮件原件----- 发件人: Bari Ari [mailto:bari@onelabs.com] 发送时间: 2004年6月8日 14:06 收件人: YhLu 抄送: LinuxBIOS 主题: Re: 答复: [PROPOSAL] extended payload handling YhLu wrote: > Can you explain deailed about the difference between uboot and Linuxbios? Here's the entire README from U-Boot: http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/README?rev=HEAD Here's the section of the README from U-Boot that covers init. The differences to LinuxBIOS should be apparent like no ROMCC in U-Boot: The following is not intended to be a complete description of every implementation detail. However, it should help to understand the inner workings of U-Boot and make it easier to port it to custom hardware. Initial Stack, Global Data: --------------------------- The implementation of U-Boot is complicated by the fact that U-Boot starts running out of ROM (flash memory), usually without access to system RAM (because the memory controller is not initialized yet). This means that we don't have writable Data or BSS segments, and BSS is not initialized as zero. To be able to get a C environment working at all, we have to allocate at least a minimal stack. Implementation options for this are defined and restricted by the CPU used: Some CPU models provide on-chip memory (like the IMMR area on MPC8xx and MPC826x processors), on others (parts of) the data cache can be locked as (mis-) used as memory, etc. Chris Hallinan posted a good summary of these issues to the u-boot-users mailing list: Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)? From: "Chris Hallinan" <clh(a)net1plus.com> Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET) ... Correct me if I'm wrong, folks, but the way I understand it is this: Using DCACHE as initial RAM for Stack, etc, does not require any physical RAM backing up the cache. The cleverness is that the cache is being used as a temporary supply of necessary storage before the SDRAM controller is setup. It's beyond the scope of this list to expain the details, but you can see how this works by studying the cache architecture and operation in the architecture and processor-specific manuals. OCM is On Chip Memory, which I believe the 405GP has 4K. It is another option for the system designer to use as an initial stack/ram area prior to SDRAM being available. Either option should work for you. Using CS 4 should be fine if your board designers haven't used it for something that would cause you grief during the initial boot! It is frequently not used. CFG_INIT_RAM_ADDR should be somewhere that won't interfere with your processor/board/system design. The default value you will find in any recent u-boot distribution in Walnut405.h should work for you. I'd set it to a value larger than your SDRAM module. If you have a 64MB SDRAM module, set it above 400_0000. Just make sure your board has no resources that are supposed to respond to that address! That code in start.S has been around a while and should work as is when you get the config right. -Chris Hallinan DS4.COM, Inc. It is essential to remember this, since it has some impact on the C code for the initialization procedures: * Initialized global data (data segment) is read-only. Do not attempt to write it. * Do not use any unitialized global data (or implicitely initialized as zero data - BSS segment) at all - this is undefined, initiali- zation is performed later (when relocating to RAM). * Stack space is very limited. Avoid big data buffers or things like that. Having only the stack as writable memory limits means we cannot use normal global data to share information beween the code. But it turned out that the implementation of U-Boot can be greatly simplified by making a global data structure (gd_t) available to all functions. We could pass a pointer to this data as argument to _all_ functions, but this would bloat the code. Instead we use a feature of the GCC compiler (Global Register Variables) to share the data: we place a pointer (gd) to the global data into a register which we reserve for this purpose. When choosing a register for such a purpose we are restricted by the relevant (E)ABI specifications for the current architecture, and by GCC's implementation. For PowerPC, the following registers have specific use: R1: stack pointer R2: TOC pointer R3-R4: parameter passing and return values R5-R10: parameter passing R13: small data area pointer R30: GOT pointer R31: frame pointer (U-Boot also uses R14 as internal GOT pointer.) ==> U-Boot will use R29 to hold a pointer to the global data Note: on PPC, we could use a static initializer (since the address of the global data structure is known at compile time), but it turned out that reserving a register results in somewhat smaller code - although the code savings are not that big (on average for all boards 752 bytes for the whole U-Boot image, 624 text + 127 data). On ARM, the following registers are used: R0: function argument word/integer result R1-R3: function argument word R9: GOT pointer R10: stack limit (used only if stack checking if enabled) R11: argument (frame) pointer R12: temporary workspace R13: stack pointer R14: link register R15: program counter ==> U-Boot will use R8 to hold a pointer to the global data Memory Management: ------------------ U-Boot runs in system state and uses physical addresses, i.e. the MMU is not used either for address mapping nor for memory protection. The available memory is mapped to fixed addresses using the memory controller. In this process, a contiguous block is formed for each memory type (Flash, SDRAM, SRAM), even when it consists of several physical memory banks. U-Boot is installed in the first 128 kB of the first Flash bank (on TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After booting and sizing and initializing DRAM, the code relocates itself to the upper end of DRAM. Immediately below the U-Boot code some memory is reserved for use by malloc() [see CFG_MALLOC_LEN configuration setting]. Below that, a structure with global Board Info data is placed, followed by the stack (growing downward). Additionally, some exception handler code is copied to the low 8 kB of DRAM (0x00000000 ... 0x00001FFF). So a typical memory configuration with 16 MB of DRAM could look like this: 0x0000 0000 Exception Vector code : 0x0000 1FFF 0x0000 2000 Free for Application Use : : : : 0x00FB FF20 Monitor Stack (Growing downward) 0x00FB FFAC Board Info Data and permanent copy of global data 0x00FC 0000 Malloc Arena : 0x00FD FFFF 0x00FE 0000 RAM Copy of Monitor Code ... eventually: LCD or video framebuffer ... eventually: pRAM (Protected RAM - unchanged by reset) 0x00FF FFFF [End of RAM] System Initialization: ---------------------- In the reset configuration, U-Boot starts at the reset entry point (on most PowerPC systens at address 0x00000100). Because of the reset configuration for CS0# this is a mirror of the onboard Flash memory. To be able to re-map memory U-Boot then jumps to its link address. To be able to implement the initialization code in C, a (small!) initial stack is set up in the internal Dual Ported RAM (in case CPUs which provide such a feature like MPC8xx or MPC8260), or in a locked part of the data cache. After that, U-Boot initializes the CPU core, the caches and the SIU. Next, all (potentially) available memory banks are mapped using a preliminary mapping. For example, we put them on 512 MB boundaries (multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is programmed for SDRAM access. Using the temporary configuration, a simple memory test is run that determines the size of the SDRAM banks. When there is more than one SDRAM bank, and the banks are of different size, the largest is mapped first. For equal size, the first bank (CS2#) is mapped first. The first mapping is always for address 0x00000000, with any additional banks following immediately to create contiguous memory starting from 0. Then, the monitor installs itself at the upper end of the SDRAM area and allocates memory for use by malloc() and for the global Board Info data; also, the exception vector code is copied to the low RAM pages, and the final stack is set up. Only after this relocation will you have a "normal" C environment; until that you are restricted in several ways, mostly because you are running from ROM, and because the code will have to be relocated to a new address in RAM. U-Boot Porting Guide: ---------------------- [Based on messages by Jerry Van Baren in the U-Boot-Users mailing list, October 2002] int main (int argc, char *argv[]) { sighandler_t no_more_time; signal (SIGALRM, no_more_time); alarm (PROJECT_DEADLINE - toSec (3 * WEEK)); if (available_money > available_manpower) { pay consultant to port U-Boot; return 0; } Download latest U-Boot source; Subscribe to u-boot-users mailing list; if (clueless) { email ("Hi, I am new to U-Boot, how do I get started?"); } while (learning) { Read the README file in the top level directory; Read http://www.denx.de/twiki/bin/view/DULG/Manual ; Read the source, Luke; } if (available_money > toLocalCurrency ($2500)) { Buy a BDI2000; } else { Add a lot of aggravation and time; } Create your own board support subdirectory; Create your own board config file; while (!running) { do { Add / modify source code; } until (compiles); Debug; if (clueless) email ("Hi, I am having problems..."); } Send patch file to Wolfgang; return 0; } void no_more_time (int sig) { hire_a_guru(); }

2 1

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