On 30/06/07 16:32 +0200, Uwe Hermann wrote:
> On Fri, Jun 29, 2007 at 10:55:25PM +0200, Stefan Reinauer wrote:
> > I think we really want to freeze lar in the long or even short run. we
> > should get this finished within the next few weeks. Lets not freeze or
> > version the format during developm
On Sun, Jul 01, 2007 at 02:21:04AM +0200, Carl-Daniel Hailfinger wrote:
> > If need be, teach elfboot to peek into compressed streams so that
> > it can tell the decompressor a safe place to decomress to.
>
> Sorry, our implementation of lzma decompression does not decompress
> to a stream, only i
"ron minnich" <[EMAIL PROTECTED]> writes:
> I think we have a lot of control with the ROM payload, so much so that
> requiring it to locate itself above 512K is a simple thing to do.
> LinuxBIOS does not load general payloads, just ROM payloads, and it is
> reasonable to create some restrictions.
On 01.07.2007 00:51, Peter Stuge wrote:
> On Fri, Jun 29, 2007 at 10:03:26PM +0200, Patrick Georgi wrote:
>> My proposal would be to decompress the ELF image to some location,
>> lookk if that location overlaps with the places the data is copied
>> to, and if so, determine a large-enough chunk of m
* Peter Stuge <[EMAIL PROTECTED]> [070701 00:51]:
> > > Right now, my solution is to mark it nocompress:, before that,
> > > I just decompressed it to a fixed location for experimentation.
> > > It has to be done one way or the other.
> >
> > I think the uncompress: marker is fine.
>
> It must
On Fri, Jun 29, 2007 at 10:03:26PM +0200, Patrick Georgi wrote:
> My proposal would be to decompress the ELF image to some location,
> lookk if that location overlaps with the places the data is copied
> to, and if so, determine a large-enough chunk of memory and
> decompress it to there again
Sor
* ron minnich <[EMAIL PROTECTED]> [070630 18:38]:
> i think it's sounding like we should just bring the v2 elf loader back in?
>
> It seems simpler than the other options I've seen so far.
It does not solve Patrick's problem though I think.
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freibu
i think it's sounding like we should just bring the v2 elf loader back in?
It seems simpler than the other options I've seen so far.
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
* Patrick Georgi <[EMAIL PROTECTED]> [070630 07:47]:
> Anyway: The proposal is to decompress the ELF image (the file generated by
> the linker) a second time, if the default location where it is compressed to
> collides with the memory used by the payload. When doing it the second time,
> al
* Uwe Hermann <[EMAIL PROTECTED]> [070630 16:32]:
> We definately need a version field in the lar header, we probably cannot
> use the same format forever, there _will_ be changes one day.
So what? The lar archive will always work with the lar program that came
with that version of linuxbios.
I
On Fri, Jun 29, 2007 at 10:55:25PM +0200, Stefan Reinauer wrote:
> I think we really want to freeze lar in the long or even short run. we
> should get this finished within the next few weeks. Lets not freeze or
> version the format during development. If early versions stop working at
> some point,
Stefan Reinauer wrote:
> Ah! In this case I think the file needs to be in rom uncompressed all
> the time because we want to read cmos options before ram is up.
>
Good to know.
> So the program will not live at the address it asked for?
>
It will - terminology is a bit unforgiving here, as t
I think we have a lot of control with the ROM payload, so much so that
requiring it to locate itself above 512K is a simple thing to do.
LinuxBIOS does not load general payloads, just ROM payloads, and it is
reasonable to create some restrictions.
thanks
ron
--
linuxbios mailing list
linuxbios@
* Patrick Georgi <[EMAIL PROTECTED]> [070629 22:03]:
> I don't. At some point in _LinuxBIOSv3_, some code searches for option_table
> and returns a pointer to ROM for further use.
> Of course, this mechanism won't work if the option_table is compressed
> there.
Ah! In this case I think the f
ok, guys, I am attaching the v2 elfboot.c to force you all to read it again :-)
The question you need to think about: is your proposal easier or
harder than what you see done here? I can't comment, I am not sure.
Can we have a "fixup" step in ROM which, if the ELF collides with the
running LB, t
Stefan Reinauer wrote:
> You read the option table in grub2? Why? (sorry I think we talked about
> it but it slipped away in the patch orgies of the recent days.
>
I don't. At some point in _LinuxBIOSv3_, some code searches for
option_table and returns a pointer to ROM for further use.
Of cours
On 6/29/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> almost? What was the exception?
ah, well, I said 'almost' .. but I don't recall the exception :-)
it's possible that in some cases memtest was an exception. But it need
not have been.
ron
--
linuxbios mailing list
linuxbios@linuxbios.or
* ron minnich <[EMAIL PROTECTED]> [070629 21:42]:
> For the first pass, I yanked it from v3 as I had too many 'what the
> hell is this doing' questions over the years. It reduced from 668
> tricky lines to 215 dead-simple lines. But we also lost the ability to
> run arbitrary code. That ability
The 'copy yourself out of the way' elfboot code was incredibly
powerful and fun to read. It was also tricky.
For the first pass, I yanked it from v3 as I had too many 'what the
hell is this doing' questions over the years. It reduced from 668
tricky lines to 215 dead-simple lines. But we also lost
On 29/06/07 20:56 +0200, Stefan Reinauer wrote:
> Jordan's talk here at the OLS described how LinuxBIOS relocates itself
> from the very low space to TOM during the boot process. I think we
> should think carefully about this stuff. Will any OS ever claim to be
> copied into the low 1M?
Eric can c
* Patrick Georgi <[EMAIL PROTECTED]> [070627 20:54]:
> I got quite far with adding decompression to lar (lzma'd data runs fine,
> nrv2b decompression seems to hang), but ran into issues that need
> discussion.
Wow. I would have expected this the other way round.
> Currently, two files in the lar
Hi,
I got quite far with adding decompression to lar (lzma'd data runs fine,
nrv2b decompression seems to hang), but ran into issues that need
discussion.
Currently, two files in the lar archive are parsed directly out of rom
(using the find_file function which returns a pointer to there).
One of
22 matches
Mail list logo
