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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
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
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
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
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
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
"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
Nobody talked about subversion in this thread, and I'm not sure why...
I haven't used it, only considered it for future projects after reading the
docs. But the concept was to make a cvs replacement, with its advantages and
without its hassles/disadvantages. Last time I checked, the apache project was
seriously considering moving to subversion, so it can't be that bad. Oh, and the
license is Apache/BSD, just for comparison with the bk/arch crossfire... ;-)
I also found a brief comparison of version control systems, for the
decisionmakers:
http://better-scm.berlios.de/comparison/comparison.html
Fernando
