Joseph Smith schrieb:
> Hmm, maybe I stumbled onto something. But I need figure out how it works.
> Can someone explain to me how it works when you password protect a normal
> bios? Where and how does the ASCII text get saved. You guys may or may not
> know where I am going with this but I have an
Hmm, maybe I stumbled onto something. But I need figure out how it works.
Can someone explain to me how it works when you password protect a normal
bios? Where and how does the ASCII text get saved. You guys may or may not
know where I am going with this but I have an idea if I can figure this
out
Author: stepan
Date: 2008-09-12 23:50:57 +0200 (Fri, 12 Sep 2008)
New Revision: 3578
Modified:
trunk/payloads/libpayload/curses/tinycurses.c
Log:
* Implement scrolling in tinycurses
* Fix an off by one bug
Signed-off-by: Stefan Reinauer <[EMAIL PROTECTED]>
Acked-by: Jordan Crouse <[EMAIL PROTE
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "hawke" checked in revision 3577 to
the coreboot source repository and caused the following
changes:
Change Log:
For the jetway jf2/4 series of mainboards:
* change the comment for device f.0 from "IDE"
On Fri, 12 Sep 2008 16:28:53 -0400, Joseph Smith <[EMAIL PROTECTED]>
wrote:
>
>
>
> On Fri, 12 Sep 2008 14:05:50 -0600, Jordan Crouse <[EMAIL PROTECTED]>
> wrote:
>> On 12/09/08 15:55 -0400, Joseph Smith wrote:
>>>
>>>
>>>
>>> On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" <[EMAIL PROTECTE
Author: hawke
Date: 2008-09-12 22:39:04 +0200 (Fri, 12 Sep 2008)
New Revision: 3577
Modified:
trunk/coreboot-v2/src/mainboard/jetway/j7f24/Config.lb
Log:
For the jetway jf2/4 series of mainboards:
* change the comment for device f.0 from "IDE" to "SATA"
* turn on firewire device a.0
* turn on p
On Fri, 12 Sep 2008 14:05:50 -0600, Jordan Crouse <[EMAIL PROTECTED]>
wrote:
> On 12/09/08 15:55 -0400, Joseph Smith wrote:
>>
>>
>>
>> On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" <[EMAIL PROTECTED]>
>> wrote:
>> > On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith <[EMAIL PROTECTED]>
>> wrote
#3: re-specifying 'root' command doesn't replace the root value
-+--
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect|Status: new
Priority:
#4: specifying 'initrd' multiple times appends extra initrd parameters
-+--
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect|Status: new
Prio
#1: ext2 won't work if FAT is enabled
-+--
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect|Status: new
Priority: minor |
#2: root command is not validated
-+--
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: enhancement |Status: new
Priority: major | Mi
#5: 'configfile' doesn't work as advertised
-+--
Reporter: [EMAIL PROTECTED] | Owner: stepan
Type: defect|Status: new
Priority: critical
On 12/09/08 15:55 -0400, Joseph Smith wrote:
>
>
>
> On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" <[EMAIL PROTECTED]>
> wrote:
> > On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith <[EMAIL PROTECTED]>
> wrote:
> >
> >> Maybe so for a virus. But when it allows an end user to have a
> > complet
#5: 'configfile' doesn't work as advertised
+---
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect| Status: new
Priority: minor | Milestone:
On Fri, 12 Sep 2008 12:46:57 -0700, "ron minnich" <[EMAIL PROTECTED]>
wrote:
> On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith <[EMAIL PROTECTED]>
wrote:
>
>> Maybe so for a virus. But when it allows an end user to have a
> completely
>> configurable boot loader...
>
> If people want it I guess
On Fri, Sep 12, 2008 at 12:45 PM, Joseph Smith <[EMAIL PROTECTED]> wrote:
> Maybe so for a virus. But when it allows an end user to have a completely
> configurable boot loader...
If people want it I guess. But we computer people need to be more
careful about opening holes to provide features. Ju
On Fri, 12 Sep 2008 11:40:09 -0700, "ron minnich" <[EMAIL PROTECTED]>
wrote:
> On Fri, Sep 12, 2008 at 10:15 AM, Joseph Smith <[EMAIL PROTECTED]>
wrote:
>>
>>
>> On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer
> <[EMAIL PROTECTED]>
>> wrote:
>>> I think this might be even better...
>>>
>>> w
On Fri, Sep 12, 2008 at 12:20 PM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> In theory, gcc is free to reload esp from a cached register after
> disable_car. That would cause pretty explosions due to the stack pointer
> being in a now invalid location.
>
how can this be? I don't see how
#4: specifying 'initrd' multiple times appends extra initrd parameters
+---
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect| Status: new
Priority: minor
On Fri, Sep 12, 2008 at 12:05 PM, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> Mats Erik Andersson wrote:
>> Hello all,
>>
>> I have observed a phenomenon too many times now to ignore it.
>> When I leave an eepro100 network adapter in the pci slot, the
>> emulator on Coreboot all to often comes to
#3: re-specifying 'root' command doesn't replace the root value
+---
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect| Status: new
Priority: minor
#2: root command is not validated
+---
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
#1: ext2 won't work if FAT is enabled
+---
Reporter: [EMAIL PROTECTED] | Owner: somebody
Type: defect| Status: new
Priority: minor | Milestone:
Carl-Daniel Hailfinger wrote:
> On 12.09.2008 18:19, ron minnich wrote:
>
>> W.r.t. Kevin's question: if we wrote stage1 as follows:
>>
>> stage1(){
>> .
>> .
>> .
>> disable_car();
>> stage1_after_car();
>> }
>>
>> How would people feel about that?
>>
>> There are still real concerns in my
On 12.09.2008 18:19, ron minnich wrote:
> W.r.t. Kevin's question: if we wrote stage1 as follows:
>
> stage1(){
> .
> .
> .
> disable_car();
> stage1_after_car();
> }
>
> How would people feel about that?
>
> There are still real concerns in my mind about lingering addresses in
> registers that
Mats Erik Andersson wrote:
> Hello all,
>
> I have observed a phenomenon too many times now to ignore it.
> When I leave an eepro100 network adapter in the pci slot, the
> emulator on Coreboot all to often comes to a halt, but its removal
> and an immediate cold boot lets Coreboot progress all the
Hello all,
I have observed a phenomenon too many times now to ignore it.
When I leave an eepro100 network adapter in the pci slot, the
emulator on Coreboot all to often comes to a halt, but its removal
and an immediate cold boot lets Coreboot progress all the way
into Filo. Of course the emulator
On Fri, Sep 12, 2008 at 10:15 AM, Joseph Smith <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer <[EMAIL PROTECTED]>
> wrote:
>> I think this might be even better...
>>
>> writing to drives from firmware might be a bad idea,
>>
> Why? Even if it is simple text fil
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Kevin O'Connor wrote:
> I had the same problem. I added
> device pci f.1 on end # IDE
> to the southbridge area of Config.lb and it seemed to resolve the
> issue.
Yep, that fixed it for me as well. I shouldn't have missed that one...
Attached please find a patch which:
*
The new FILO has been committed to buildrom. Because
the SVN tree has changed, the svn fetch script will
get confused. Before building FILO again, please remove
the FILO svn tree from your sources/ directory:
rm -rf sources/filo/
And run 'make distclean' before rebuilding.
Thank you,
Jordan
-
On Fri, 12 Sep 2008 10:26:11 -0600, Jordan Crouse <[EMAIL PROTECTED]>
wrote:
> On 12/09/08 09:42 +0200, Stefan Reinauer wrote:
>> Peter Stuge wrote:
>> > So you're teaching FILO how to act like a BIOS.
>> >
>> > I will fight that patch hard. I'm afraid I think this design is
>> > completely misg
Author: jcrouse
Date: 2008-09-12 19:18:00 +0200 (Fri, 12 Sep 2008)
New Revision: 226
Removed:
buildrom-devel/packages/filo/conf/alix1c-Config
buildrom-devel/packages/filo/conf/alix2c3-Config
buildrom-devel/packages/filo/conf/asus_a8v-e_se-Config
buildrom-devel/packages/filo/conf/db800-
On Fri, 12 Sep 2008 15:37:41 +0200, Stefan Reinauer <[EMAIL PROTECTED]>
wrote:
> I think this might be even better...
>
> writing to drives from firmware might be a bad idea,
>
Why? Even if it is simple text file?
>
> though... can this
> be done with cmos bits?
>
Not sureyou would have basic
On 12/09/08 11:57 -0400, Jake Peavy wrote:
> On 9/11/08, Joseph Smith <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > On Thu, 11 Sep 2008 23:53:04 +0200, Peter Stuge <[EMAIL PROTECTED]> wrote:
> > > Joseph Smith wrote:
> > >> My JMP question is about copying a drives mbr to memory 0x7c00 and
> > >>
On 12/09/08 08:15 -0400, Joseph Smith wrote:
>
>
>
> On Fri, 12 Sep 2008 11:20:04 +0200, "Vincent Legoll"
> <[EMAIL PROTECTED]> wrote:
> > On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> >>> > As an optional feature, everyone pretty much said they want to be
> >>> > abl
On 12/09/08 09:42 +0200, Stefan Reinauer wrote:
> Peter Stuge wrote:
> > So you're teaching FILO how to act like a BIOS.
> >
> > I will fight that patch hard. I'm afraid I think this design is
> > completely misguided.
> >
>
> Citing Jordan:
>
> Indeed - lets stop trying to beat up Joseph and
W.r.t. Kevin's question: if we wrote stage1 as follows:
stage1(){
.
.
.
disable_car();
stage1_after_car();
}
How would people feel about that?
There are still real concerns in my mind about lingering addresses in
registers that gcc might leave hanging around. The call nicely removes
the worr
On 9/11/08, Joseph Smith <[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Thu, 11 Sep 2008 23:53:04 +0200, Peter Stuge <[EMAIL PROTECTED]> wrote:
> > Joseph Smith wrote:
> >> My JMP question is about copying a drives mbr to memory 0x7c00 and
> >> or 0x0600 at 512 byte blocks.
> > ..
> >> What do you think?
Stefan Reinauer skrev alldeles nyss
> Mats Erik Andersson wrote:
> > data += ( fn(0x10) >> 1 ) && 0x007f;
> >
> > where fn(0x10) == 0x1010. However, the actual outcome of the previous
> > calculation is the value 0x01, instead of the expected 0x08.
> 1 is very much the expected result because
ron minnich wrote:
> >> In the light of all this, I mean to have found a bug in romcc,
> >
> > No doubt.
(Yes, doubt.)
> > Did your research so far allow you to also suggest a fix?
>
> romcc is end of life and unmaintained for many years now.
>
> I think it is a mistake to change something thi
On 12.09.2008 14:59, Andriy Gapon wrote:
> on 12/09/2008 15:30 Mats Erik Andersson said the following:
>> data = 0;
>> data += ( fn(0x10) >> 1 ) && 0x007f;
>>
>> where fn(0x10) == 0x1010. However, the actual outcome of the previous
>> calculation is the value 0x01, instead of the expected 0
Peter Stuge wrote:
> Stefan Reinauer wrote:
>
>>> evaluating all current disklabel schemes
>>>
>> I still like Amiga's Rigid Disk Label best. It stores the
>> firmware's filesystem driver for each file in the "partition table"
>> to a partition so the firmware can always read a disk, no m
On Fri, Sep 12, 2008 at 5:40 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Mats Erik Andersson wrote:
>> after much backtracking I have identified an unexpected case
>> of (implicit) casting where romcc fails miserably.
>
> Great work!
>
>
>> In the light of all this, I mean to have found a bug in r
Peter Stuge schrieb:
> Stefan Reinauer wrote:
>
>>> evaluating all current disklabel schemes
>>>
>> I still like Amiga's Rigid Disk Label best. It stores the
>> firmware's filesystem driver for each file in the "partition table"
>> to a partition so the firmware can always read a disk, no
On Fri, Sep 12, 2008 at 5:10 AM, Kevin O'Connor <[EMAIL PROTECTED]> wrote:
> I'm wondering what you felt was lacking in your previous idea of
> passing a new stack location/execution address into disable_car()?
When I floated the idea last year everyone hated it :-)
>
> Also, in an earlier email
Stefan Reinauer wrote:
> > evaluating all current disklabel schemes
>
> I still like Amiga's Rigid Disk Label best. It stores the
> firmware's filesystem driver for each file in the "partition table"
> to a partition so the firmware can always read a disk, no matter
> how new and weird the filesys
Mats Erik Andersson wrote:
> data += ( fn(0x10) >> 1 ) && 0x007f;
>
> where fn(0x10) == 0x1010. However, the actual outcome of the previous
> calculation is the value 0x01, instead of the expected 0x08.
1 is very much the expected result because the above is a boolean
expression, not a bitwi
Hi,
Stefan Reinauer wrote:
> > So you're teaching FILO how to act like a BIOS.
> >
> > I will fight that patch hard. I'm afraid I think this design is
> > completely misguided.
>
> Citing Jordan:
>
> Indeed - lets stop trying to beat up Joseph and let him write some
> code.
My point which I hop
Sorry for top posting - did you by a chance confused '&' and '&&" as in
your examples below?
on 12/09/2008 15:30 Mats Erik Andersson said the following:
Hello all,
after much backtracking I have identified an unexpected case
of (implicit) casting where romcc fails miserably.
I desire a com
Mats Erik Andersson wrote:
> after much backtracking I have identified an unexpected case
> of (implicit) casting where romcc fails miserably.
Great work!
> In the light of all this, I mean to have found a bug in romcc,
No doubt. Did your research so far allow you to also suggest a fix?
//Pet
Hello all,
after much backtracking I have identified an unexpected case
of (implicit) casting where romcc fails miserably.
I desire a computation
uint16_t fn(uint8_t d);
uint8_t data;
data = 0;
data += ( fn(0x10) >> 1 ) && 0x007f;
where fn(0x10) == 0x1010. Ho
On Fri, 12 Sep 2008 11:20:04 +0200, "Vincent Legoll"
<[EMAIL PROTECTED]> wrote:
> On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>>> > As an optional feature, everyone pretty much said they want to be
>>> > able to do such a drive scan only a few days ago. Would be great
On Thu, Sep 11, 2008 at 08:42:44AM -0700, ron minnich wrote:
[...]
> Given these rules, here is how disable_car can work on core 2 and
> others that don't back CAR with RAM.
> 1. compute a new stack area. The minimum size is the size of the
> stack. Note that stack contains sysinfo (at its base).
>
On Thu, Sep 11, 2008 at 05:20:59PM -0500, Alex Mauer wrote:
> But back in src/southbridge/via/vt8237r/vt8237r_ide.c (around line 41),
> sb->ide0_enable and sb->ide1_enable are both 0.
[...]
> But the question is, what's going on there? Why are these values set to
> 0? Is ide_init accessing chip_in
On 12.09.2008 01:31, Peter Stuge wrote:
> Joseph Smith wrote:
>
>> I really think it is possible to take the data from the
>> mbr/partition table and manipulate it to our advantage, thus
>> bypassing ALL real mode interrupts. The problem would be if an OS
>> (like windows) deciedes to make a INT
Jordan Crouse wrote:
> Attached patch updates the FILO in buildrom to the brand new edition.
> By IRC concensus, filo-0.5 support has been removed entirely.
>
> [PATCH] libpayload: Update FILO to the trunk
>
> Update FILO to build from the trunk - we will use the
> default configuration for al
On Fri, Sep 12, 2008 at 5:43 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>> > As an optional feature, everyone pretty much said they want to be
>> > able to do such a drive scan only a few days ago. Would be great if
>> > you want to hack on it! :)
>>
>> I do think this would be better approach. I d
Joseph Smith wrote:
>
> On Fri, 12 Sep 2008 03:01:31 +0200, Peter Stuge <[EMAIL PROTECTED]> wrote:
>
>> Joseph Smith wrote:
>>
>>> So, Peter do you have any ideas on how we could make this happen?
>>>
>> Peter Stuge wrote:
>>
>>> Do a comparison with all other disk labels that t
Peter Stuge wrote:
> As for a new standard I think we should start out by evaluating all
> current disklabel schemes to see what state of the art is, and how we
> can improve upon it.
>
I still like Amiga's Rigid Disk Label best. It stores the firmware's
filesystem driver for each file in the "
On Fri, Sep 12, 2008 at 1:20 AM, Russell Whitaker <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 12 Sep 2008, Joseph Smith wrote:
>
>>
>>
>>
>> On Fri, 12 Sep 2008 00:24:32 -0400, "Corey Osgood"
>> <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Fri, Sep 12, 2008 at 12:19 AM, Joseph Smith <[EMAIL PROTECTED]>
>>
Peter Stuge wrote:
> So you're teaching FILO how to act like a BIOS.
>
> I will fight that patch hard. I'm afraid I think this design is
> completely misguided.
>
Citing Jordan:
Indeed - lets stop trying to beat up Joseph and let him write some code.
We do not want to be that project that neve
62 matches
Mail list logo
