coreboot

coreboot@coreboot.org

10 participants
39711 discussions

Re: Trouble with etherboot-5.2.2 [resolution]
by Dave Ashley 07 Jan '04

07 Jan '04

The problem turned out to be I didn't build etherboot 5.2.2 properly, in addition to editing the src/Config file I had to edit arch/i386/Config and switch to the CFLAGS+= relating to linuxbios. In etherboot 5.0.10 the only config file (that I know of) is the src/Config one. I did try reading the docs, but there was very little mention of linuxbios in the etherboot docs. This whole thing could have been avoided if etherboot had a top level README.Linuxbios or something like that. The whole point of this exercise was to be able to get etherboot to output to the vga even without a normal pc bios. I tried the CONSOLE_DIRECT_VGA option Eric mentioned, and it works as needed. There is still an issue with my epia-m vga init code that doesn't set the sync for composite/svideo properly. That means in order to view the output of etherboot you've got to plug in a vga monitor, which we want to avoid. The epia-m vga init code sometimes detects that a monitor is plugged into composite/svideo and automatically switches to the appropriate sync, but this appears somewhat random. -Dave

2 1

support for msi mb's?
by Morten Arnesen 07 Jan '04

07 Jan '04

i couldn't figure out whether there are support for msi mobos, could anyone of u tell me so? i'm very interesting in using linuxbios if it's possible on my msi-kt7-pro2 ver 1 this is a motherboard with an amibios on. -- Morten Arnesen, Dyrkorn 6250 Stordal tlf: +47 7027 7036, fax: +47 70 27 82 77 for å svare på mail, fjern det åpenbare i mailadressen. (gjelder news) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2 1

Re: Trouble with etherboot-5.2.2
by Dave Ashley 07 Jan '04

07 Jan '04

I wrote: >... >rhine disable >ROM segment 0x0001 length 0x0000 reloc 0x00020000 Ok, this message "ROM segment..." is coming from the new etherboot 5.2.2, so it looks like linuxbios is out of the picture. I'll start going on a printf fest and see where it is failing in etherboot. Eric: Thanks for the idea of doing it this way, it speeds up development a lot, having last known good load the new etherboot. Now the cycle is compile, copy file, reset machine, see what I got, instead of compile, copyfile to box, enter box, flash bootrom, reboot, see what I got, switch to safe bootrom, reboot. -Dave

1 0

Re: Trouble with etherboot-5.2.2
by Dave Ashley 07 Jan '04

07 Jan '04

Eric wrote: >Easy things to try. >1) load the new etherboot with the old etherboot, over the network. > That should confirm that the code actually works. >2) Play with RELOCADDR in etherboot so we don't trigger the bounce > buffer case. I tried #2 first, I put RELOCADDR=0x80000 and that didn't trigger the bounce code but it still locked up. Then I tried #1 where I serve the via-rhine.elf file from 5.2.2 to etherboot 5.0.10. I get this: Searching for server (BOOTP)... .Me: 172.30.6.71, Server: 172.30.6.100, Gateway 172.30.6.254 Loading 172.30.6.100:via_rhine_elf ...(ELF)... ................done rhine disable ROM segment 0x0001 length 0x0000 reloc 0x00020000 This is a lot easier to experiment with since I don't have to burn bootroms. I'll keep working on it. All I'm trying to get is some sign of life from etherboot 5.2.2 that it loaded correctly. Thanks-- Dave

1 0

Re: Source code control
by Adam Megacz 07 Jan '04

07 Jan '04

ebiederman(a)lnxi.com (Eric W. Biederman) writes: > > Nobody talked about subversion in this thread, and I'm not sure why... > It's not distributed. Multiple repositories are hard. > LinuxBIOS development is inherently distributed, and needs > multiple repositories. It also depends on a ton of other software being installed to make it work (Apache, WebDAV, etc), or at least it did last time I evaluated it. The beauty of next-gen systems like arch and darcs is that any http server, ftp server, or ssh-able machine can be a repo. - a

1 0

Re: Trouble with etherboot-5.2.2
by Dave Ashley 06 Jan '04

06 Jan '04

Eric wrote: >Take a look at the values in the segment list in elfboot.c and see >if you can track down how it is getting corrupted. My hunch says it is >most likely a mis setup of your DRAM controller. I've tracked the problem to the function get_bounce_buffer in src/lib/elfboot.c, it is returning 5f646e8 for some reason. I added some printk's to that function and get this: zzz mem_entries = 3, lb_size=9b918 zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8 zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8 Here is the debug output. I also changed printk_spew to printk_debug: Found ELF candiate at offset 0 header_offset is 0 Try to load at offset 0x0 zzz mem_entries = 3, lb_size=9b918 zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8 zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8 n_type: 00000001 n_name(8): ELFBoot n_desc(10): Etherboot n_type: 00000002 n_name(8): ELFBoot n_desc(6): 5.2.2 Loading Etherboot version: 5.2.2 Dropping non PT_LOAD segment New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc (cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc lb: [0x0000000000004000, 0x0000000000051c8c) segment: [0x0000000000020000, 0x0000000000025abc, 0x000000000002efc0) buffer=5f646e8, seg->s_addr=20000, lb_start=4000 bounce: [0x0000000005f806e8, 0x0000000005f861a4, 0x0000000005f8f6a8) Loading Segment: addr: 0x0000000005f806e8 memsz: 0x000000000000efc0 filesz: 0x0c [ 0x0000000005f806e8, 0000000005f861a4, 0x0000000005f8f6a8) <- 00000000000000b0 Clearing Segment: addr: 0x0000000005f861a4 memsz: 0x0000000000009504 Loaded segments verified segments closed down stream Jumping to boot code at 0x20000 ROM segment 0x0004 length 0x0000 reloc 0x00020000 Here is the same debug output but with the 5.0.10 etherboot payload: Found ELF candiate at offset 0 header_offset is 0 Try to load at offset 0x0 zzz mem_entries = 3, lb_size=9b918 zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8 zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8 New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460 (cleaned up) New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460 lb: [0x0000000000004000, 0x0000000000051c8c) Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000006f68 filesz: 0x00 [ 0x0000000000094000, 0000000000097460, 0x000000000009af68) <- 0000000000000060 Clearing Segment: addr: 0x0000000000097460 memsz: 0x0000000000003b08 Loaded segments verified segments closed down stream Jumping to boot code at 0x94000 ROM segment 0x0004 length 0x0000 reloc 0x9400 Etherboot 5.0.10 (GPL) ELF for [VIA 86C100] The 5.2.2 elf file exercises more of the elfboot.c. The bounce buffer should be in valid memory, there is 128M total minus 32M for video, which now that I think about it is way more than we need. So 0x6000000 total memory. I'll keep digging... -Dave

2 1

Re: Trouble with etherboot-5.2.2
by Dave Ashley 06 Jan '04

06 Jan '04

Eric wrote: >Agreed. What does readelf -e say they are in the file? Here it is: dave% readelf -e bin/via-rhine.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x20000 Start of program headers: 52 (bytes into file) Start of section headers: 0 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 0 (bytes) Number of section headers: 0 Section header string table index: 0 There are no sections in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align NOTE 0x000074 0x00000074 0x00000074 0x0003c 0x0003c RWE 0 LOAD 0x0000b0 0x00020000 0x00020000 0x05abc 0x0efc0 RWE 0 -Dave

2 1

Trouble with etherboot-5.2.2
by Dave Ashley 06 Jan '04

06 Jan '04

I'm trying to use my bastardized epia-m tree with etherboot-5.2.2 using the bin/via-rhine.elf image in place of my 5.0.10 bin32/via6105m.ebi image that has been working fine. I get this with linuxbios + 5.0.10: Found ELF candiate at offset 0 New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460 (cleaned up) New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460 Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000006f68 filesz: 0x00 Clearing Segment: addr: 0x0000000000097460 memsz: 0x0000000000003b08 Jumping to boot code at 0x94000 ROM segment 0x0001 length 0x0000 reloc 0x9400 Etherboot 5.0.10 (GPL) ELF for [VIA 86C100] ... everything proceeds normally I get this with linuxbios + 5.2.2: Found ELF candiate at offset 0 Loading Etherboot version: 5.2.2 Dropping non PT_LOAD segment New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc (cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc Loading Segment: addr: 0x0000000005f81028 memsz: 0x000000000000efc0 filesz: 0x0c Clearing Segment: addr: 0x0000000005f86ae4 memsz: 0x0000000000009504 Jumping to boot code at 0x20000 ROM segment 0x0001 length 0x0000 reloc 0x00020000 These addr: values for Loading + Clearing Segment seem way off. I looked into linuxbios src/lib/elfboot.c and there is only one line difference between my version and the latest off cvs: head->phdr_next = head->phdr_prev = head; at line 369 or 370. I added that but no difference. This question is probably directed at Eric again: What should I try? My config for etherboot 5.2.2 is pretty much stock, except I added this line: CFLAGS += -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCONSPEED=115200 I also tried taking out -DRELOCATE but that made no difference. Thanks! Dave

2 1

Re: Source code control
by Dave Ashley 06 Jan '04

06 Jan '04

The only problems I have with CVS are: 1) Doesn't deal with symlinks 2) Your source tree is littered with CVS directories 3) Versioning is on a file basis, not a tree basis 4) Dealing with binaries seems complicated I was watching the subversion project since I saw a posting about it on slashdot, and the two things that were interesting about it were 1) Will eventually handle symlinks 2) The whole tree is versioned, not individual files I've kept checking back in on subversion but they're not at 1.00 yet and it seems like for the longest time the symlink handling never got implemented. I don't know for sure if it is working now even. It seemed like subversion was moving forward with glacial speeds, so I figured it was a dead project. -Dave

1 0

Re: [Etherboot-developers] Source code control
by ebiederman＠lnxi.com 06 Jan '04

06 Jan '04

"Timothy Legge" <tlegge(a)rogers.com> writes: > > Once my evaluation is finished I plan on pushing the projects I work > > on in that direction. So this is something to think about. > > > > Does arch have anything like webcvs? I tend to use that quite a bit > when I don't want to be bothered with vi. I have not seen a webcvs equivalent. However you can get mirror the repository local so it isn't needed as much. This is one of those areas where since arch is immature it doesn't have a tool set as rich as cvs does today. > My needs are fairly simple as long as arch does what cvs does, it should > meet them. I assume it runs on the command line... Yes arch runs on the command line. Although if arch did exactly what CVS does there would be no point in using it. Eric

1 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