coreboot

coreboot@coreboot.org

11 participants
39712 discussions

RE: FILO fixups
by Li-Ta Lo 01 Nov '04

01 Nov '04

On Mon, 2004-11-01 at 13:21, Dave Aubin wrote: > Hi, > > I'll voice my desire to have etherboot with filo. > I love the fact that I can first try to boot remotely > And then if not use filo. For this reason alone I am > A fan of the mechanism. Try remote first then if fail > Use local storage. If we can, can we please put the > Etherboot flavor in utils that has both network & filo support? > First of all, we didn't say we don't want choice. Actually we want more, including the choice of not having some choices. The problems of FILO/Etherboot are: 1. Some people have hard time building Etherboot. 2. Some people don't want the feature provided by Etherboot, they are satisfied by FILO itself. 3. FILO (as FILO itself) does not have an official host. If we want to continue maintain FILO to serve people in 1. and 2., we have to put it somewhere. If you want FILO as FILO+Etherboot, why don't you get it from etherboot project? Ollie

1 0

RE: FILO fixups
by Ronald G. Minnich 01 Nov '04

01 Nov '04

On Mon, 1 Nov 2004, Dave Aubin wrote: > Consider the redundancy aspect of it. First try remote. again, if you have remote to try, that's fine, go for it. If you don't have that ethernet connection, then counting on etherboot is kind of pointless :-) > There is also the error in filo where it can not handle an elf > With both a kernel and initrd. It can only handle a kernel. > To use filo I had to pack it up with initramfs, i.e. one big kernel. > Etherboot remote boot doesn't have this problem. ?? in an ext2 on filo, i've got a kernel and initrd and it loads it up just fine, so I don't see what you mean. ron

1 0

RE: FILO fixups
by Dave Aubin 01 Nov '04

01 Nov '04

Consider the redundancy aspect of it. First try remote. If that fails go local or vs versa. Kinda like if mom is Around listen to her, if she's not around well then think For yourself;) Consider embedded size aspect of it as well. A kernel and Initrd in my situation is about 4Meg. On my local drive it Is about half that. Size costs more on my embedded local side. I do like the versatility of etherboot having both local and Net in one, but I totally understand why you'd want just filo As the kernel can do the remote side. There is also the error in filo where it can not handle an elf With both a kernel and initrd. It can only handle a kernel. To use filo I had to pack it up with initramfs, i.e. one big kernel. Etherboot remote boot doesn't have this problem. -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Li-Ta Lo Sent: Monday, November 01, 2004 3:05 PM To: YhLu Cc: Ronald G. Minnich; LinuxBIOS Subject: RE: FILO fixups On Mon, 2004-11-01 at 12:00, YhLu wrote: > The reason for put filo in etherboot. > 1. It can let boot from HD or net according to CMOS setting. > 2. Etherboot can produce zelf. We may got more space to put other > stuff such as USB support... > 3. Etherboot structure and support... > > I may check if filo.zlef only include FILO ..., even it is not, we > still can make it clean. > You have the same blind spot as Eric. For many people, boot over net is irrelevant. Why do they need to live with the overhead of network protocol stack and driver if all they want to to boot form some mass storage device ? Ollie _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

RE: FILO fixups
by Ronald G. Minnich 01 Nov '04

01 Nov '04

On Mon, 1 Nov 2004, Dave Aubin wrote: > I'll voice my desire to have etherboot with filo. that's fine. choice is good. I have no complaints about that at all. That's why I am saying we chose filo. At some later time we might choose etherboot. ron

1 0

RE: FILO fixups
by Dave Aubin 01 Nov '04

01 Nov '04

Hi, I'll voice my desire to have etherboot with filo. I love the fact that I can first try to boot remotely And then if not use filo. For this reason alone I am A fan of the mechanism. Try remote first then if fail Use local storage. If we can, can we please put the Etherboot flavor in utils that has both network & filo support? Kind thanks, Dave:) -----Original Message----- From: linuxbios-admin(a)clustermatic.org [mailto:linuxbios-admin@clustermatic.org] On Behalf Of Ronald G. Minnich Sent: Monday, November 01, 2004 2:56 PM To: YhLu Cc: Li-Ta Lo; LinuxBIOS Subject: RE: FILO fixups On Mon, 1 Nov 2004, YhLu wrote: > 1. It can let boot from HD or net according to CMOS setting. only useful if your ethernet is hooked up. 15/16 of our nodes here have no ethernet. > 2. Etherboot can produce zelf. We may got more space to put other > stuff such as USB support... not that important to us. > 3. Etherboot structure and support... not clear at the moment if this is a plus or minus. Seeing that it has trouble building under certain tool chains, there still seem to be problems with it. > I may check if filo.zlef only include FILO ..., even it is not, we > still can make it clean. We still need to add my performance improvements. ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

FILO fixups
by Ronald G. Minnich 01 Nov '04

01 Nov '04

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. Now it scans until the device is found and returns it. Even in the worst case, the new pci scan is always faster than the old. There are new options in addition to PCI_BRUTE_SCAN. PCI_BRUTE_SCAN means: scan everything ... PCI_BRUTE_SCAN_START ... but start at this bus (VERY good on k8, as the scan of 0:19.* takes FOREVER). PCI_BRUTE_SCAN_LIMIT = 2 ... and end here -1(useful when you know that the busses don't range to 256) And the 'instant gratification' option: IDE_HINT_BUS IDE_HINT_DEV IDE_HINT_FUNC All three must be set or not set or you get a compile-time warning. IF all three are set, FILO will probe the device and IF it is an ide controller use that. If it's not an ide controller, filo will scan busses as usual. This last option REALLY speeds things up ron

4 8

RE: FILO fixups
by YhLu 01 Nov '04

01 Nov '04

You can get filo only under Etherboot. make bin/filo.zelf or make bin/tg3--filo.zelf Also I added something into the filo in Etherboot. Regards YH -----Original Message----- From: Ronald G. Minnich [mailto:rminnich@lanl.gov] Sent: Friday, October 29, 2004 3:39 PM To: YhLu Cc: Li-Ta Lo; LinuxBIOS Subject: RE: FILO fixups On Fri, 29 Oct 2004, YhLu wrote: > The filo is merged into Etherboot. And it will be released in 5.2.6 formally > I guess. that's a plus and a minus for us. It's nice seeing FILO get pulled into supported software like Etherboot. But we've had uneven luck building a working etherboot here. And ETherboot still does far more than we want. I would need to put the same kinds of mods into etherboot, and then build etherboot in a way in which all the ethernet support is not compiled in. In other words, I want to compile an etherboot down to FILO! It is simpler to just use FILO directly. ron

3 2

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

01 Nov '04

> On Tue, 26 Oct 2004 Stephen.Kimball(a)bench.com wrote: > > > > Can someone tell me what the starting sequence is with LinuxBIOS? > > > > Reset jumps to crt0.s. crt0.s calls auto.E. auto.E is built using > > romcc, so source-level debugging is not possible. > > ah well :-) > > > The statement > > locations can be found using the Lxxxx labels in linuxbios.map. Then > > hardwaremain is called. Hardwaremain is the first C function called. > > yep. > > > Crt0 and auto run out of FLASH. Hardwaremain is the first function > > called after LinuxBIOS is copied to RAM. > > sounds good so far. > > ron 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? Steve

3 2

RE: Kernel for linuxbios
by Dave Aubin 01 Nov '04

01 Nov '04

Two things strike me as odd. 1. Your ," PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask - try pci=usepirqmaskPCI: 02:01.0 [1022/7462] disabled" Type of errors. Looks like you pcirqp map is bad? Are you making your Own mother board? If so it is important that you get this and the mp Table correct based on your wiring. 2. You did get to initramfs, good job, but it did fail to mount you File system. This could be anything. Please send your init script And Describe what are you trying to mount. A USB stick, ide, what? -----Original Message----- From: Sagiv Yefet [mailto:sagivy@3vium.com] Sent: Sunday, October 31, 2004 5:45 AM To: Dave Aubin Cc: linuxbios(a)clustermatic.org Subject: RE: Kernel for linuxbios 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

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

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