As i noticed a discussion on RAM limit above, I would like to start one
too, but about my board:
I have a HP Compaq t5500 Thin Client
http://h18002.www1.hp.com/products/quickspecs/11746_div/11746_div.HTMLhttp://www.transmeta.com/success/thin/hp/hp_t5500.htmlhttp://www.transmeta.com/success/thin/hp/hp_t5500_spec.html
It has a TRANSMETA CRUSOE 5800A073310 CPU (TM5800) with integrated
northbridge, and a VIA VT8231 southbridge.
29LV160ATTC-90 2 MB flash chip (soldered).
I would like to put LinuxBIOS on it, and I would like to put as much RAM
as possible in it.
It has 1 SO-DIMM 200-pin DDR slot, and some place for soldering RAM
chips on the board.
In the slot there is a 128 MB module now. HP specs say you can put max
512 MB module there.
What are the real RAM limits? The TM5800 CPU supports 4 GB of RAM, so
thats the upper limit, but is there anything that limits it lower, and
if so what?
I am now planning to buy a 1 GB DDR SO-DIMM module, and I hope it'll
work in the slot. Will it? Will only some modules work? If so what
should I look for? Will this module work:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=6821167601
I found somewhere that:
TM5800 memory subsystems can be populated with
64-Mbit (4M x 16 or 8M x 8),
128-Mbit (8M x 16 or 16M x 8),
256-Mbit (16M x 16 or 32M x 8), or
512-Mbit (32M x 16 or 64M x 8) devices.
Note that only x8 and x16 memory devices are supported.
Does it mean that if only my module is made of 32Mx16 or 64Mx8 chips,
it'll work? Or is there anything more required? Does the VIA VT8231 or
the thing's BIOS creates any more limits? With LinuxBIOS will I be able
to put more RAM in than with stock BIOS?
And finally is there anyone here who uses LinuxBIOS on such CPU and
southbridge, and can share some expirience?
--
Miernik _________________________ xmpp:miernik@amessage.info
___________________/_______________________/ mailto:miernik@ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en
I have a small geode board that has a ram limit of 128MB. This is
stated in the doc's, I have not yet been able to test this, yet. If it
does cap out at 128mb would this be a factor of the bios or the
hardware, or both?
-Adam Talbot
Is the cache as ram a AMD specific feature? The code looks like it would work for intel CPU, but I seems remember intel CPU would just return FF when reading from a cacheable location before memory becomes avialbe.
beneo
Hi.
I boot LX2 with etherboot payload. I see how ip-address is assigned and process of loading NBI image from TFTP server. Unfortunately NBI image can't be run - the reasons are obscured. How to trace back it's execution?
P.S. etherboot payload is "via-rhine.elf". NBI's structure is below. Any ideas?
$ readelf -a thinstation.nbi
ELF Header:
Magic: 7f 45 4c 46 01 01 01 ff 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: Standalone App
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x82800
Start of program headers: 52 (bytes into file)
Start of section headers: 276 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 1
Section header string table index: 0
Section Header:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] <corrupt> NULL 00000000 000000 000000 00 0 0 0
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000200 0x00082800 0x00082800 0x01400 0x01400 RWE 0x200
LOAD 0x001600 0x00082400 0x00082400 0x00200 0x00200 RWE 0x200
LOAD 0x001800 0x00080000 0x00080000 0x00200 0x00200 RWE 0x200
LOAD 0x001a00 0x00080200 0x00080200 0x01400 0x01400 RWE 0x200
LOAD 0x002e00 0x00100000 0x00100000 0xa2800 0xa2800 RWE 0x200
LOAD 0x0a5600 0x001a3000 0x001a3000 0xa2d000 0xa2d000 RWE 0x200
NOTE 0x0001e8 0x00000000 0x00000000 0x00018 0x00000 0
--
Sincerely, Anton Borisov
Hi,
what exactly is this structure good for?
declared in src/include/boot/linuxbios_tables.h:
struct lb_uint64 {
uint32_t lo;
uint32_t hi;
};
It is used in the following files:
src/arch/i386/boot/linuxbios_table.c
src/arch/ppc/boot/linuxbios_table.c
src/boot/elfboot.c
since each machine that can compile LinuxBIOS, ie that has a
(cross-)gcc, does have a uint64_t we should use that one.
Stefan
Hi,
Some suggestions:
1) We could put a checksum in the LinuxBIOS rom image so it can be
checked for integrity during boot time. Usually safety relevant
embedded devices require such a checksum and use CRC16 or CRC32
for that.
2) Is there any distinct way of finding out whether a flash image
is a LinuxBIOS image? One thing that can be read from an image
is the mainboard vendor and id, but the code looks somewhat ugly:
void show_id(unsigned char *bios, int size)
{
unsigned char *manuf, *id;
id=bios+size-0x1d;
while (*id==0) id--;
while (*id) id--;
manuf=id-1; id++;
while (*manuf && *manuf!=0xff) manuf--;
manuf++;
printf("MANUFACTURER: %s\n", manuf);
printf("MAINBOARD ID: %s\n", id);
}
3) There should be a flash description map in the rom file that allows
a program accessing the flash to automatically exclude certain
flashing areas such as the onboard option rom space or the fallback
image.
Stefan
Hi,
flash_and_burn does not compile in gcc 4 anymore since it comes
with -Werror. This makes sense since it is touching a very sensitive
part of a system :-)
Since gcc 4 warns a lot more about signed/unsigned pointer confusion
I changed major parts of flash_and_burn to use unsigned pointers only.
We are coping with data, so signedness is not interesting in the code.
In fact it might rather hurt.
I'll apply the patch to the repository shortly, when someone signs it
off.
Other questions:
- Can we drop flash_on? The code seems included in flash_rom and it
only works on old sis stuff anyways. We will not drop functionality
by dropping this extra binary.
- Should we rename the utility to flash_and_burn or should we rename
the directory to flash_rom? There's a lot of confusion since the
utility and it's location in the source tree have different names.
Stefan
Any use? For comparison?
YH
-----Original Message-----
From: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com]
Sent: Friday, November 11, 2005 1:31 PM
To: Lu, Yinghai
Cc: Ronald G Minnich; Stefan Reinauer; linuxbios(a)openbios.org
Subject: Re: [LinuxBIOS] results in romcc
"Lu, Yinghai" <yinghai.lu(a)amd.com> writes:
> Stephan,
>
> Can you remove util/romcc/results/*?
You want to remove the expected output of the romcc regression tests?
Eric
