ok, I think objcoyp is doing the right thing. Whew!
Here are the sections: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .rom PROGBITS ffff4000 001000 002400 00 AX 0 0 8 [ 2] .payload PROGBITS ffff6400 003400 0049b3 00 WA 0 0 1 [ 3] .reset PROGBITS fffffff0 007ff0 000010 00 A 0 0 1 [ 4] .id PROGBITS ffffffd3 007fd3 00001d 00 A 0 0 1 [ 5] .text PROGBITS fffffff0 007ff0 000000 00 AX 0 0 4 [ 6] .data PROGBITS fffffff0 007ff0 000000 00 WA 0 0 4 [ 7] .bss NOBITS fffffff0 008ff0 000000 00 WA 0 0 4 [ 8] .shstrtab STRTAB 00000000 008ff0 000045 00 0 0 1 [ 9] .symtab SYMTAB 00000000 0091f0 0010e0 10 10 bf 4 [10] .strtab STRTAB 00000000 00a2d0 0010f8 00 0 0 1
The .rom starts at 0xffff4000, which gives you a 49152-byte section.
I think the .ldscript is giving a fixed-size linuxbios without regard to how big it actually is, which means tuning via things like max log message etc. is no longer a real option. It also means my etherboot, which is 17K, no longer fits together with linuxbios into 64K.
OK, back to the drawing board :-)
ron
Greetings,
The size in the ldscripts is controlled by ROM_IMAGE_SIZE in the mainboard config file. With care, it should be changable, but there is a good bit of magic in there (I'm trying to get rid of some of that in the boards I have, but it is slow going and some of it is hard to get rid of).
Of course, if the selected size is too small, bad things happen (I don't know if it will build a broken image, or just fail to build).
The thing is, a build where ionly the actual size needed gets used presents some real problems for getting target addresses right.
G'day, sjames
On Wed, 5 Feb 2003, Ronald G. Minnich wrote:
ok, I think objcoyp is doing the right thing. Whew!
Here are the sections: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .rom PROGBITS ffff4000 001000 002400 00 AX 0 0 8 [ 2] .payload PROGBITS ffff6400 003400 0049b3 00 WA 0 0 1 [ 3] .reset PROGBITS fffffff0 007ff0 000010 00 A 0 0 1 [ 4] .id PROGBITS ffffffd3 007fd3 00001d 00 A 0 0 1 [ 5] .text PROGBITS fffffff0 007ff0 000000 00 AX 0 0 4 [ 6] .data PROGBITS fffffff0 007ff0 000000 00 WA 0 0 4 [ 7] .bss NOBITS fffffff0 008ff0 000000 00 WA 0 0 4 [ 8] .shstrtab STRTAB 00000000 008ff0 000045 00 0 0 1 [ 9] .symtab SYMTAB 00000000 0091f0 0010e0 10 10 bf 4 [10] .strtab STRTAB 00000000 00a2d0 0010f8 00 0 0 1
The .rom starts at 0xffff4000, which gives you a 49152-byte section.
I think the .ldscript is giving a fixed-size linuxbios without regard to how big it actually is, which means tuning via things like max log message etc. is no longer a real option. It also means my etherboot, which is 17K, no longer fits together with linuxbios into 64K.
OK, back to the drawing board :-)
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
steven james pyro@linuxlabs.com writes:
Greetings,
The size in the ldscripts is controlled by ROM_IMAGE_SIZE in the mainboard config file. With care, it should be changable, but there is a good bit of magic in there (I'm trying to get rid of some of that in the boards I have, but it is slow going and some of it is hard to get rid of).
Of course, if the selected size is too small, bad things happen (I don't know if it will build a broken image, or just fail to build).
It will just fail to build. So it is safe to set ROM_IMAGE_SIZE arbitrarily small.
The thing is, a build where ionly the actual size needed gets used presents some real problems for getting target addresses right.
Thinking about it the only way that might work is to link the entire rom image into a .o file. And then compute what the start address would need to be. And then do a final link to the rom image.
Eric
-
ebiederman＠lnxi.com -
Ronald G. Minnich -
steven james