coreboot October 2004

coreboot@coreboot.org

45 participants
197 discussions

RE: status information
by YhLu 31 Oct '04

31 Oct '04

If the ROMCC can handle function not as inline. You may don't need to enlarge the 64K limit. Current Auto.c compiled is some big. Esp the print_debug causes the problem Regards YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 29, 2004 12:22 PM To: Richard Smith Cc: ollie(a)lanl.gov; Eric W. Biederman; Stefan Reinauer; LinuxBIOS Subject: Re: status information On Fri, 29 Oct 2004, Richard Smith wrote: > Ronald G. Minnich wrote: > > > The issue is this: right now, linubios compressed payload AND romcc object > > fit in the top 64k. There is no need to do this. They're not fitting anyway > > at this point. romcc object startup can turn on full flash access, so the > > linuxbios > > compressed payload can be placed, not in the top 64k, but in the next-to-top > > 64k. The linuxbios image will then have 128k available to it, not just 64k. > > Then we can put all the debug prints we want into romcc code, which would be > > nice. old-fashioned linuxbios ----------- (e.g.) 0xfff80000 | payload | | | | | ----------- 0xffff0000 | linux | | bios | ----------| V2: --------------0xfff80000 | smith | | payload | --------------0xffff0000 | c_payload | | uncompress | | to ram | | ---- | | auto.C | | compiled | | code | -------------- So there are really two "payloads" There is startup code -- now compiled by romcc -- that turns on ram and uncompresses the c_payload to ram. The RAM code then does final setup and uncompresses the "smith payload" or whatever (Etherboot, filo, linux, ADLO) to ram. So I'm just saying do this. --------------0xfff80000 | smith | | payload | --------------0xfffe0000 | c_payload | | uncompress | | to ram | |------------|0xffff0000 | auto.C | | compiled | | code | -------------- That's all you have to do to fix the issues with romcc getting too big. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

4 4

RE: Kernel for linuxbios
by Sagiv Yefet 31 Oct '04

31 Oct '04

I took your advise and try the 2.6. I am using the initramfs_data.cpio.gz from the link you send me. The mkelf command is: ./objdir/sbin/mkelfImage -t bzImage-i386 --kernel=/home/sagivy/bzImage-2.6. --command-line="rw console=ttyS0,115200 root=/dev/ram0" --initrd=/home/sagivy/initramfs_data.cpio.gz --output=/home/sagivy/bzImage2.6.8.elf And here is the output: Jumping to Linux Linux version 2.6.8 (root@hermes) (gcc version 3.3.3) #6 Mon Nov 17 21:49:23 IST 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000d54 (rese BIOS-e820: 0000000000000d54 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. DMI not present. ACPI: Unable to locate RSDP Built 1 zonelists Kernel command line: rw console=ttyS0,115200 root=/dev/ram0 Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 1603.740 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes).. Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) PCI: Using configuration type 1 Memory: 515700k/524288k available (1525k kernel code, 7824k reserved, 702k data, K8 Northbridge Enumerating: AMD K8 CPU 228k init, 0k highmem)g: AMD 8111 Southbridge Checking if this processor honours the WP bit even in supervisor mode... Ok. Enumerating buses... amdk8_scan_root_bus Calibrating delay loop... 3162.11 BogoMIPSart scaning pci bus Mount-cache hash table entries: 512 (order: 0, 4096 bytes) PCI: 00:18.0 [1022/1100] enabled CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) PCI: 00:18.2 [1022/1102] enabled CPU: L2 Cache: 1024K (64 bytes/line)022/1103] ops Enabling fast FPU save and restore... done. HyperT rese Enabling unmasked SIMD FPU exception support... done.for bus 1 PCI: 01:01.0 [10 Checking 'hlt' instruction... OK. PCI: 01:01.0 [1022 checking if image is initramfs... it is PCI: 01:02.0 [1022/7468] bus ops Freeing initrd memory: 151k freedCI: 01:02.0 [1022/7468] enabled NET: Registered protocol family 16 01:02.1 [1022/7469] ops EISA bus registeredCI: 01:02.1 [1022/7 PCI: Using configuration type 1 PCI: 01:02.2 [1022 mtrr: v2.0 (20020519) Linux Plug and Play Support v0.97 (c) Adam Belay PCI: 01:02.3 [1022/746b] enabled PCI: Probing PCI hardware PCI: 01:02.5 [1022/746 PCI: IRQ 0 for device 0000:02:00.0 doesn't match PIRQ mask - try pci=usepirqmask7463] ops PCI: 02:00.2 [1022/7463] disabled PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask - try pci=usepirqmaskPCI: 02:01.0 [1022/7462] disabled PCI: 02:0a.0 PCI: IRQ 0 for device 0000:02:0a.0 doesn't match PIRQ mask - try pci=usepirqmask PCI: 02:0b.0 [1002/4752] enabled PCI: IRQ 0 for device 0000:02:0b.0 doesn't match PIRQ m PCI: 02:0e.0 [14e PNP: 002e.7 disabled apm: BIOS not found. disabled VFS: Disk quotas dquot_6.5.1d PNP: 0 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) scan_static_bus done PC isapnp: Scanning for PnP cards...=02 isapnp: No Plug & Play device found 0 new max: 2 Real Time Clock Driver v1.12ort scan link done Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled PCI: pci_scan_bus returning with max=02 ttyS0 at I/O 0x3f8 (irq = bus: AMD8111: not 100% native mode: will probe irqs later AMD8111: 0000:01:02.1 (rev 03) UDMA133 controller ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio ide-floppy driver 0.99.newide mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 EISA: Probing bus 0 at eisa0 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 131072 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 Freeing unused kernel memory: 228k freed Kernel panic: Attempted to kill init! ================ ================== This kernel uses initramfs ================================== Unknown root filesystem type! Sagiv. -----Original Message----- From: Dave Aubin [mailto:daubin@actuality-systems.com] Sent: Wednesday, October 13, 2004 2:47 PM To: Sagiv Yefet; Stefan Reinauer Cc: linuxbios(a)clustermatic.org Subject: RE: Kernel for linuxbios Sorry for the late response. Are you using Linux 2.6.*. If so give initramfs a try. Here is a link to aid you in how: http://linuxfromscratch.org/pipermail/lfs-hackers/2004-June/001424.html Dave -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Sagiv Yefet Sent: Wednesday, October 13, 2004 8:10 AM To: Stefan Reinauer Cc: linuxbios(a)clustermatic.org Subject: RE: Kernel for linuxbios I tried to use initrd - same problem. Sagiv -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Monday, October 11, 2004 11:21 AM To: Sagiv Yefet Cc: linuxbios(a)clustermatic.org Subject: Re: Kernel for linuxbios * Sagiv Yefet <sagivy(a)3vium.com> [041011 11:06]: > > I add the console support and there is output. Thanks. > > My machine has no disks and I need initrd. So I took initrd from > Thinstation and build the elf file by the command : > > RAMDISK: Couldn't find valid RAM disk image starting at 0. > Freeing initrd memory: 11922k freed > Kernel panic: VFS: Unable to mount root fs on 01:00 use initrd, not ramdisk! Stefan _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Starting with linuxbios
by Adilson Oliveira 30 Oct '04

30 Oct '04

Hello guys. I'm thinking about create (another one) Car-PC and I want to use linuxbios to improve the boot time. Is there any place you can recomend I can read about the basics of this project? I mean how it works, etc? Just to give me an outline before I start to dig into it? BTW, I want to use miniITX boards as the Via EPIA. Thanks. Adilson.

3 2

RE: status information
by YhLu 29 Oct '04

29 Oct '04

If the kernel can be tailed to (1MByte - LinuxBIOS size(64K *2)), There is no need for Etherboot or others. YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 29, 2004 10:13 AM To: Li-Ta Lo Cc: Eric W. Biederman; Stefan Reinauer; LinuxBIOS Subject: Re: status information On Fri, 29 Oct 2004, Li-Ta Lo wrote: > I bet there are a lot of people using CF in the embedded world, they > can't use Etherboot to fetch the kernel from the net as you do. We > should not only think about HPC applications. People in embedded > market are in different enviroment and have different cost structure > than you. good point. The Sandia mini clusters use CF. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

3 2

RE: FILO fixups
by YhLu 29 Oct '04

29 Oct '04

The filo is merged into Etherboot. And it will be released in 5.2.6 formally I guess. Regards YH -----Original Message----- From: Li-Ta Lo [mailto:ollie@lanl.gov] Sent: Friday, October 29, 2004 3:05 PM To: Ronald G. Minnich Cc: LinuxBIOS Subject: Re: FILO fixups On Fri, 2004-10-29 at 15:59, Ronald G. Minnich wrote: > I've just finished fixups to filo that make it quite a bit faster. > > First, it used to scan the bus twice, the first time to do a count. That's > slow, although it was a nice algorithm. But it only needed to find at most > 2 devices. > Since it appears nobody is maintaining FILO do you think we should put it in util directory in freebios2? Ollie _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

RE: LinuxBIOS debugging with an emulator
by Stephen.Kimball＠bench.com 29 Oct '04

29 Oct '04

> On Thu, 2004-10-28 at 16:03, Stephen.Kimball(a)bench.com wrote: > > > > It seems that LinuxBIOS copies itself to _RAMBASE, which is 0x4000. > > Then it branches to 0x4000 into _start, which sets up the stack and > > calls hardwaremain. The address of hardwaremain from linuxbios_c.o is > > wrong. The address is not the Flash address and it's not the RAM > > address. Can someone explain how linuxbios_c.o is linked with RAM > > addresses? > > > > What do you mean ? In the S2885 I built, the _RAMBASE is 0x4000 and > hardwaremain is 0x5fe0 as you can get from the linuxbios_c.map. They > are both in RAM. If you use "objdump -drS linuxbios_c.o" you will > find the hardwaremain is at offset 0x1fe0 from the _RAMBASSE. > > BTW, if you specify the -g option for gcc, you can use the -S option > in objdump to see the source code with the disassebmly (-d). > > Ollie In the amd/serenade I built, the _RAMBASE is 0x4000 and hardwaremain is at 0x60B8 from the linuxbios_c.map. Hardwaremain is at 0x20B8 in the objdump. That all make sense. But if I step through the execution of _start from 0x4000 to the call to hardwaremain. I see it branch to 0x5F70 and the instructions at 0x5F70 match the hardwaremain in objdump. So I think it's really at 0x5F70 not 0x60B8. It's only off by 0x148 bytes. I bet your hardwaremain isn't at 0x5FE0. Steve

2 1

RE: Starting with linuxbios
by YhLu 29 Oct '04

29 Oct '04

What's the usage for the CAR-PC? GPS navigation? Regards YH -----Original Message----- From: Nathanael Noblet [mailto:nathanael@gnat.ca] Sent: Thursday, October 28, 2004 1:27 PM To: Adilson Oliveira Cc: linuxbios(a)clustermatic.org Subject: Re: Starting with linuxbios On Oct 28, 2004, at 12:54 PM, Adilson Oliveira wrote: > Hello guys. > > I'm thinking about create (another one) Car-PC and I want to use > linuxbios to improve the boot time. > Is there any place you can recomend I can read about the basics of > this project? > I mean how it works, etc? Just to give me an outline before I start to > dig into it? > BTW, I want to use miniITX boards as the Via EPIA. The website is sorely out of date, and the source tree has just gone through a *major* overhaul. In that vein, the source for the epia version isn't functional (as I understand it right now). But will in a few weeks when it gets cleaned up. The website will be revamped when some of the volunteers (like myself) get to it. We've been really busy as well. I'm not nearly as knowledgeable in the arena here about the actual functioning of LinuxBIOS, but there are plenty here who are. I would suggest going through the mailing list archive as start. There was a great FAQ type submission a few months ago that helped me understand what was going on. -- Nathanael D. Noblet Gnat Solutions 204 - 131 Gorge Road E Victoria, BC V9A 1L1 T/F 250.385.4613 http://www.gnat.ca/ _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

5 10

New developer: Mark Wilkinson
by Ronald G. Minnich 29 Oct '04

29 Oct '04

Mark Wilkinson is now fixing up the epia tree. ron

1 0

removing .name from the .c files is a bad idea
by Ronald G. Minnich 29 Oct '04

29 Oct '04

1) it will save little space at all. Here are all the strings for the arima/hdama Arima HDAMA mainboard AMD 8111 NSC 87360 socket 940 AMD K8 Northbridge Arima HDAMA mainboard AMD 8111 It is 105 bytes. Compressed by itself with gzip -3 it is 99 bytes. that's conservative because on a bigger binary the dictionary will be better and it will probably get smaller. If we're that tight we're in big trouble and it is time to move c_payload to 0xfffe0000, not fool around removing this type of nit, which will only buy us a small amount of time. 2) The string names could be printed as SPEW by the device tree code as it walks the tree, and aid comprehension.That code is not in yet but it is trivial to write and should go in. If people are really that worried about it, I can add an option to config.g and you can #ifdef to the .c files using that name. I don't see the point but if you really need that 99 or so bytes I guess that you can do that. This issue brings up an important question. We have just made a far-reaching set of changes that had to be made -- but we impacted every port in V2. We need to start being careful about how global changes are made. With the current user base growing rapidly I think we're going to need to create a formal process for this type of global change. This would be (e.g.) a Configuration Review Board composed of stakeholders that would vote up or down on changes. I think we are almost past the point where people can make big changes such as this with no consultation. I try to consult via the mailing list but I don't think that always works. Any comments on this idea? ron

1 0

i845 ddr init pass but still problem
by zhu shi song 29 Oct '04

29 Oct '04

Now I can pass DDR SDRAM init process. But still there are some problem, After copying linuxbios to ram, when jmp *%edi, MB reset. The key point to make it pass is set Reg 0xC7 = 08, then reset to make it effective. If letting sdram work correctly ,it looks like some work still to be done. zhu __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

2 1

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 October 2004