popkonserve wrote:
> What i really don't get is:
> Why trying to support bleeding edge hardware almost nobody has
> datasheets for instead of writing reliable custom drivers that would
> support older hardware. development itself would be far easier, at least
> SOME hardware would be supported a
Peter Stuge wrote:
> On Tue, Aug 28, 2007 at 11:51:08AM -0700, ron minnich wrote:
>
>> fallback/preboot should probably not exist, as in fallback we want
>> minimal features.
>>
>
> Someone will probably want it.
>
>
> //Peter
>
Especially if the fallback requirement still stands, other
On Tue, Aug 28, 2007 at 08:59:53PM +0200, popkonserve wrote:
> Why trying to support bleeding edge hardware
News value.
> my problem is not that i don't understand the hardware itself but
> the linuxbios framework.
You are not alone.
> what i would like to see is: generic support for usb/cdro
On Tue, Aug 28, 2007 at 11:51:08AM -0700, ron minnich wrote:
> We could do this:
>
> normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu
> normal/payload0, 1, 2, 3, the actualy payload
Nak. Why do we need to create specialized functionality? Can't we
keep it general?
> fallback/preboo
Hi guys,
I completed the LBdistro LinuxBIOS build system and need testers to
verify it's compilation on other Linux distribuitions. It was tested
on Debian Still In Development, Ubuntu 7.04 and Fedora (tnx Augusto).
To test it just follow this simple tutorial:
http://linuxbios.org/Build_LinuxBIOS_
On 28.08.2007 20:41, ron minnich wrote:
> Round 2.
>
> I had not realized that lar had changed. So all my patches were
> against the wrong files.
>
> This code is against the right files in lar. I have also done a fair
> amount of refactoring as I needed it.
>
> don't get upset about the close o
Quoting popkonserve <[EMAIL PROTECTED]>:
> What i really don't get is:
> Why trying to support bleeding edge hardware almost nobody has
> datasheets for instead of writing reliable custom drivers that would
> support older hardware. development itself would be far easier, at least
> SOME hardware
What i really don't get is:
Why trying to support bleeding edge hardware almost nobody has
datasheets for instead of writing reliable custom drivers that would
support older hardware. development itself would be far easier, at least
SOME hardware would be supported and people would be able to TE
I don't see a real problem meshing uwe's work with mine.
We could do this:
normal/preboot0, 1, 2, 3 --> preboot payloads such as lbmenu
normal/payload0, 1, 2, 3, the actualy payload
fallback/preboot should probably not exist, as in fallback we want
minimal features.
thanks
ron
--
linuxbios
Hi, Uwe, please be sure to check what I am doing and make sure we
mesh. One possibility is a flag we attach on the lar command line like
this:
run:filename
Which will set a 'run this code' bit in the LAR. I will try to read
your patch more thoroughly now.
thanks
ron
--
linuxbios mailing list
l
Joseph Smith wrote:
> Quoting "Nathanael D. Noblet" <[EMAIL PROTECTED]>:
>
>
>> Uwe Hermann wrote:
>>
>>
>>> The real problems (in my view) are:
>>>
>>> 1. Lack of developers
>>> 2. Lack of time
>>> 3. Lack of proper datasheets (for some/many chipsets)
>>>
>> I agree, but would ad
Round 2.
I had not realized that lar had changed. So all my patches were
against the wrong files.
This code is against the right files in lar. I have also done a fair
amount of refactoring as I needed it.
don't get upset about the close of the fd right after mmap; it's legal
and even recommended
Quoting "Nathanael D. Noblet" <[EMAIL PROTECTED]>:
> Uwe Hermann wrote:
>
>> The real problems (in my view) are:
>>
>> 1. Lack of developers
>> 2. Lack of time
>> 3. Lack of proper datasheets (for some/many chipsets)
>
> I agree, but would add that #1 has a correlation to #3. I tried porting
>
On 28.08.2007 19:38, Uwe Hermann wrote:
> On Tue, Aug 28, 2007 at 12:48:06AM +0200, Carl-Daniel Hailfinger wrote:
>>> created. So I carefully wonder what the real goal of such a call would
>>> be, except gathering random people with random boards? Something like:
>>> We have 10 people who are willi
Hi all,
I hope to buy a motherboard to start playing around with Linuxbios
somewhere in the near future. I have no job, so I have to get that
sorted first, but after that...
Here is my wish-list:
Micro ATX format or smaller. I think I already have ny fair share of
bit bulky ATX computers and want
Uwe Hermann wrote:
> The real problems (in my view) are:
>
> 1. Lack of developers
> 2. Lack of time
> 3. Lack of proper datasheets (for some/many chipsets)
I agree, but would add that #1 has a correlation to #3. I tried porting
a board over waaay back in the v1 days. With the limited inform
On Tue, Aug 28, 2007 at 12:48:06AM +0200, Carl-Daniel Hailfinger wrote:
> > hardware. Unfortunately not a single new port resulted from this, though
> > many people participated and lots of (unaccomplished) expectations were
>
> The expectations are a bit of a problem. This also has to do with our
On Mon, Aug 27, 2007 at 05:21:08PM -0500, Corey Osgood wrote:
> > We had such calls before, and people would send in their board
> > information, assuming that this would be enough for us to support their
> > hardware. Unfortunately not a single new port resulted from this, though
> > many people p
On Tue, Aug 28, 2007 at 05:55:17PM +0200, [EMAIL PROTECTED] wrote:
> Author: jcrouse
> Date: 2007-08-28 17:55:17 +0200 (Tue, 28 Aug 2007)
> New Revision: 16
>
> Modified:
>buildrom-devel/config/platforms/Config.in
>buildrom-devel/config/platforms/platforms.conf
> Log:
> Somewhere along the
* ron minnich <[EMAIL PROTECTED]> [070828 17:43]:
> Until I know exactly why that failure occurred, I'd like to leave my
> emergency patch in. Esp. since it turns out we WERE being smart ...
thats fine as long as it's not committed like that.
We had so many workarounds in older versions because w
* Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070828 18:08]:
> lib/lar.c and util/lar/example.c differ in subtle ways in find_file.
> Inverted logic in one file, bogus calculations in the other one. We
> might want to make sure they behave the same way.
I remember "fixing" something because the c
On 28.08.2007 18:37, Stefan Reinauer wrote:
> Instead of iterating over data, the code should iterate over the linked
> list of archive headers. This would easily fix the problem.
It seems to do that (at least that's what the code looks like. Now we
just have to find out why iterating hits non-hea
* Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070828 16:59]:
> Can we change the MAGIC to some less likely string, perhaps even with
> version info? A lot of filesystems have mixed-case magic strings, for
> example ReiserFS has "ReIsErFs" or "ReIsEr2Fs" or "ReIsEr3Fs". Nobody is
> going to include
On 27.08.2007 22:08, Robert Millan wrote:
> On Mon, Aug 27, 2007 at 01:41:54PM +0200, Carl-Daniel Hailfinger wrote:
>> This patch makes ITE SuperI/O probing/dumping a little bit more generic,
>> fixes minor codingstyle issues and prepares the table for supporting
>> more chips of the ITE IT87xx Sup
On 28.08.2007 18:11, ron minnich wrote:
> On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>> OK, so I was unclear. The idea was to number the payloads as well, not
>> only the segments.
>
> Let's hold off on that, it will require a lot of changes, and it is
> not really what we plann
On 28.08.2007 18:19, ron minnich wrote:
> On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>
>> lib/lar.c and util/lar/example.c differ in subtle ways in find_file.
>> Inverted logic in one file, bogus calculations in the other one. We
>> might want to make sure they behave the same w
On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>
> lib/lar.c and util/lar/example.c differ in subtle ways in find_file.
> Inverted logic in one file, bogus calculations in the other one. We
> might want to make sure they behave the same way.
>
> > header = (struct la
On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>
> OK, so I was unclear. The idea was to number the payloads as well, not
> only the segments.
Let's hold off on that, it will require a lot of changes, and it is
not really what we planned. We have normal and fallback; there is
really
On 28.08.2007 17:41, ron minnich wrote:
> On 8/28/07, ron minnich <[EMAIL PROTECTED]> wrote:
>> On 8/28/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
>>
>>> Yes, good idea IMO.
>>>
>>> Maybe 'LAR Magic 0.01' or something similar?
>> Again, given current brute force search, this won't help, since that
Author: jcrouse
Date: 2007-08-28 17:55:17 +0200 (Tue, 28 Aug 2007)
New Revision: 16
Modified:
buildrom-devel/config/platforms/Config.in
buildrom-devel/config/platforms/platforms.conf
Log:
Somewhere along the line we missed adding the db800 stuff to the Config.in
and the Makefile. Doing that
On 28.08.2007 17:29, ron minnich wrote:
> On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>
>> Can't we do that in an easier way? Idea:
>> struct {
>> char misalign[1];
>> char magic[8];
>> } lar_magic __attribute__ ((aligned(16))) = {
>> 0, "LARCHIVE"
>> };
>
On 28.08.2007 17:26, ron minnich wrote:
> On 8/28/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
>> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070828 01:54]:
>>> What about creating directories for each payload so we can differentiate
>>> between multiple payloads (in the original sense)?
>> Yes
Until I know exactly why that failure occurred, I'd like to leave my
emergency patch in. Esp. since it turns out we WERE being smart ...
thanks
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On 8/28/07, ron minnich <[EMAIL PROTECTED]> wrote:
> On 8/28/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
>
> > Yes, good idea IMO.
> >
> > Maybe 'LAR Magic 0.01' or something similar?
>
> Again, given current brute force search, this won't help, since that
> string will appear in the data segment. T
On 28/08/07 17:34 +0200, Uwe Hermann wrote:
> On Tue, Aug 28, 2007 at 04:59:58PM +0200, Carl-Daniel Hailfinger wrote:
> > Can we change the MAGIC to some less likely string, perhaps even with
> > version info? A lot of filesystems have mixed-case magic strings, for
> > example ReiserFS has "ReIsErF
On 8/28/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> Yes, good idea IMO.
>
> Maybe 'LAR Magic 0.01' or something similar?
Again, given current brute force search, this won't help, since that
string will appear in the data segment. The most reliable fix is the
one I posted; the most proper fix is
On Tue, Aug 28, 2007 at 04:59:58PM +0200, Carl-Daniel Hailfinger wrote:
> Can we change the MAGIC to some less likely string, perhaps even with
> version info? A lot of filesystems have mixed-case magic strings, for
> example ReiserFS has "ReIsErFs" or "ReIsEr2Fs" or "ReIsEr3Fs". Nobody is
> going
On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Can't we do that in an easier way? Idea:
> struct {
> char misalign[1];
> char magic[8];
> } lar_magic __attribute__ ((aligned(16))) = {
> 0, "LARCHIVE"
> };
>
> That should guarantee the string to be always mi
On 28.08.2007 17:12, ron minnich wrote:
> On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>
>> Can we change the MAGIC to some less likely string, perhaps even with
>> version info? A lot of filesystems have mixed-case magic strings, for
>> example ReiserFS has "ReIsErFs" or "ReIsEr2
On 8/28/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070828 01:54]:
> > What about creating directories for each payload so we can differentiate
> > between multiple payloads (in the original sense)?
>
> Yes, I would prefer something like that, too
On 8/27/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> What about creating directories for each payload so we can differentiate
> between multiple payloads (in the original sense)?
>
> normal/payload0/segment0 (33192 bytes, lzma compressed to 18088 bytes
> @0x38 load @0x10, entry 0x1
* Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070828 01:54]:
> What about creating directories for each payload so we can differentiate
> between multiple payloads (in the original sense)?
Yes, I would prefer something like that, too
> normal/payload0/segment0 (33192 bytes, lzma compressed to
On 8/28/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Can we change the MAGIC to some less likely string, perhaps even with
> version info? A lot of filesystems have mixed-case magic strings, for
> example ReiserFS has "ReIsErFs" or "ReIsEr2Fs" or "ReIsEr3Fs". Nobody is
> going to includ
On 28.08.2007 16:49, ron minnich wrote:
> On 8/28/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
>> * ron minnich <[EMAIL PROTECTED]> [070828 06:16]:
>>> ===
>>> --- lib/lar.c (revision 480)
>>> +++ lib/lar.c (working copy)
>>> @@ -42,
* ron minnich <[EMAIL PROTECTED]> [070828 16:49]:
> > I think the fix could be even simpler. Instead, if the first header is
> > found,
> > the second header should be searched _after_ the end of the first file
> > in the LAR archive. Going through all of the ROM including the data
> > itself is p
On 8/28/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> * ron minnich <[EMAIL PROTECTED]> [070828 06:16]:
> > ===
> > --- lib/lar.c (revision 480)
> > +++ lib/lar.c (working copy)
> > @@ -42,9 +49,31 @@
> >
> > for (walk = archi
On 27.08.2007 19:25, ron minnich wrote:
> 7. Since we have a load address, we can create this lar entry:
> normal/cmdline
> and specify that it be loaded at a place where linux will find it as
> the cmdline.
>
> The change is simple. Add a load address and entry point to the lar
> header. Extend t
On 19.08.2007 20:14, Uwe Hermann wrote:
> here's a first (draft) implementation for having multiple LinuxBIOS
> payloads in one image, which will be executed one after the other.
>
> The current implementation has the following limitations:
>
> - Payload files must be named 'payload[0-9]', i.e.
On 27.08.2007 18:12, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> Hi,
>>
>> since we're aiming for broader coverage in LinuxBIOS and related tools,
>> I think we should publish a "Call for Action" which urges interested
>> people to give us dumps of their board configuration etc.
>>
On 27.08.2007 19:25, ron minnich wrote:
> LAR is a very capable format. With two simple extensions, we can use
> LAR to replace all that we are using ELF for now.
> [...]
> The change is simple. Add a load address and entry point to the lar
> header. Extend the lar tool to parse the elf file and cr
Hello Johannes,
On 17.08.2007 14:30, Johannes Engel wrote:
> As Carl-Daniel suggested attached you find the info for a Dell Latitude
> D820 laptop.
Thank you for the information. I'll keep it for reference when extending
flashrom.
Right now your flash chip (or board enablement) seems to be unsupp
Hello together!
Im trying to build a linuxbios for my AMD Geode LX db800 board. First
time i tryed it directly with linuxbiosv2 and v3.
After i find out that v3 wont work i tryed it with v2 and dont get
anything working - i tryed it by hand with the lx_vsa and so on.
I read a lot of papers i fou
Dear LinuxBIOS readers!
This is the automated build check service of LinuxBIOS.
The developer "uwe" checked in revision 2750 to
the LinuxBIOS source repository and caused the following
changes:
Change Log:
This patch makes ITE Super I/O probing/dumping a little bit more generic,
fixes minor cod
On Mon, Aug 27, 2007 at 01:41:54PM +0200, Carl-Daniel Hailfinger wrote:
> This patch makes ITE SuperI/O probing/dumping a little bit more generic,
> fixes minor codingstyle issues and prepares the table for supporting
> more chips of the ITE IT87xx SuperI/O family.
>
> Signed-off-by: Carl-Daniel H
Author: uwe
Date: 2007-08-28 12:43:57 +0200 (Tue, 28 Aug 2007)
New Revision: 2750
Modified:
trunk/LinuxBIOSv2/util/probe_superio/probe_superio.c
Log:
This patch makes ITE Super I/O probing/dumping a little bit more generic,
fixes minor coding style issues and prepares the table for supporting
m
* ron minnich <[EMAIL PROTECTED]> [070828 06:16]:
> ===
> --- lib/lar.c (revision 480)
> +++ lib/lar.c (working copy)
> @@ -42,9 +49,31 @@
>
> for (walk = archive->start;
>(walk - 1) < (char *)(archive->start + arch
56 matches
Mail list logo
