Hi,
I'll be at FrOSCon next weekend in St. Augustin (near Bonn, Germany) to
show off coreboot, and I need a demo board. Buying an ASRock E350M1 is
easy (the local computer shop has that board in stock), but I don't know
the current state of the tree, and I don't have any matching spare flash
chips
Hi,
does anyone have a working ASRock E350M1 coreboot image with SeaBIOS?
I hope to demo that board this weekend at the FrOSCon conference.
Thanks in advance,
Carl-Daniel
Am 15.08.2011 01:26 schrieb Carl-Daniel Hailfinger:
> Hi,
>
> I'll be at FrOSCon next weekend in St. Augus
Hi!
Am 19.08.2011 16:34 schrieb theUser BL:
> http://www.pro-linux.de/news/1/17403/thomas-krenn-open-source-foerderungen-2011-vergeben.html
> http://www.heise.de/open/meldung/Gewinner-der-Open-Source-Foerderaktion-stehen-fest-1326270.html
> http://www.admin-magazin.de/News/Gewinner-von-Open-Source
Hi Scott,
thanks a lot for the image! I'll try and report back.
Regards,
Carl-Daniel
Am 17.08.2011 01:08 schrieb Scott Duplichan:
> Carl-Daniel Hailfinger wrote:
>
> ]Hi,
> ]
> ]does anyone have a working ASRock E350M1 coreboot image with SeaBIOS?
> ]I hope to demo tha
t shows no messages, but the serial port works under Linux
just fine
Regards,
Carl-Daniel
Am 17.08.2011 01:08 schrieb Scott Duplichan:
> Carl-Daniel Hailfinger wrote:
>
> ]does anyone have a working ASRock E350M1 coreboot image with SeaBIOS?
> ]I hope to demo that board this weekend at
Am 23.08.2011 07:53 schrieb Philip Prindeville:
> On 8/22/11 4:00 PM, Andres Salomon wrote:
>
>> Also, if you email the patch inline (rather than as an attachment),
>> then we can include comments inline as well.
>>
> I wish I could, but alas I use Thunderbird. Some misguided hacker rewrot
Hey,
it seems we forgot to apply for a devroom (well, at least I didn't see
anything on the mailing list).
Should we submit talks to the individual devrooms?
Should we ask for a coreboot/flashrom booth/table?
Regards,
Carl-Daniel
--
coreboot mailing list: coreboot@coreboot.org
http://www.corebo
Call for lightning talks and stands is NOW!
http://fosdem.org/2012/call-for-participation
I will be at FOSDEM. Anybody else?
Regards,
Carl-Daniel
Am 11.11.2011 18:48 schrieb Carl-Daniel Hailfinger:
> Hey,
>
> it seems we forgot to apply for a devroom (well, at least I didn't see
Am 20.11.2011 21:07 schrieb Joshua Roys:
> This patch prevents a long loop through memory until superiotool finds
> an EOT.
>
> Signed-off-by: Joshua Roys
Acked-by: Carl-Daniel Hailfinger
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@
es and writes random data to random I/O locations.
>
> Reported-by (on IRC): Carl-Daniel Hailfinger
>
> Signed-off-by: Paul Menzel
>
Acked-by: Carl-Daniel Hailfinger
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Hi,
crossgcc won't build on openSUSE 12.1 x86_64 because the gmp libraries
end up in xgcc/lib64/ (as designed) but mpfr expects them to be in
xgcc/lib/ (why?). Workaround is to add a symlink xgcc/lib -> xgcc/lib64 .
autoconf is claimed to be needed to build binutils (at least according
to buildgcc
We (coreboot+flashrom) will have one main talk (coreboot on laptops) and
one joint booth at FOSDEM.
Thanks to Rudolf Marek for applying for the booth.
http://www.coreboot.org/FOSDEM_2012
I'll only have intermittent internet access while I finish the slides
for the main talk. Could someone else pl
In case you ever want to clean a Patchwork instance of spam
registrations and assuming that nothing on your site besides Patchwork
uses Django, try the following script which should kill a majority of
spam accounts.
Disclaimer: This script is an absolutely gross 5-minute hack, and it
should remove
Am 29.02.2012 08:39 schrieb Patrick Georgi:
> Am 28.02.2012 23:06, schrieb Marc Jones:
>> I found this bug building tint with libpayload. libpayload is built
>> with defconfig and using the same coreboot crosstools gcc. The bug
>> happens in the first call to alloc() when the first header of the
>>
I'm glad to announce libhwremote 0.1, a library which forwards hardware
accesses over a serial line to a machine running SerialICE. No QEMU needed!
All you have to do to run lspci/superiotool/... against a remote
SerialICE target is to compile those tools against libhwremote, and then
just run them
Am 10.03.2012 17:52 schrieb Idwer Vollering:
> 2012/3/10 Carl-Daniel Hailfinger :
>> I'm glad to announce libhwremote 0.1, a library which forwards hardware
>> accesses over a serial line to a machine running SerialICE. No QEMU needed!
>> All you have to do to run lspci
Hi,
given the lack of affordable and available hardware tools for coreboot
development, I propose to look for a different set of projects this
year: Tools which would help developers, and which are usable especially
with current hardware. A list of ideas follows.
- Flash ICE device with SPI suppo
Adding the flashrom mailing list to CC:
Please keep flash...@flashrom.org in CC for all flashrom related
questions. Thanks!
Am 21.03.2012 17:09 schrieb HighlyCaffeinated:
> Two files attached. In fromregboot.txt the machine was booted to the factory
> BIOS, the chips swapped, and flashrom-V execu
Am 06.04.2012 22:38 schrieb ron minnich:
> On Fri, Apr 6, 2012 at 11:12 AM, Marc Jones wrote:
>
>>> One such a nice app would be zmodem download of raminit.
>> This is an interesting thought, but really a debug/development
>> feature.
> We even talked about this in v3. But it never got done, seems
Am 14.04.2012 01:11 schrieb Ronald G. Minnich (rminn...@gmail.com):
> commit e4fc5283d5c2e5fe8f75875a8229319696f8990b
> Author: Ron Minnich
> Date: Thu Apr 12 04:26:22 2012 -0700
>
> Add the memory reference code binary for sandybridge chipsets
>
> This binary is required for anyone
Am 15.04.2012 04:57 schrieb ron minnich:
> On Sat, Apr 14, 2012 at 3:12 AM, Carl-Daniel Hailfinger
> wrote:
>
>> I hope this is not going into the main repository, but into some
>> separate repository instead.
>> Right now we can tell people that all code in our offici
Am 15.04.2012 22:08 schrieb ron minnich:
> On Sun, Apr 15, 2012 at 3:49 PM, Carl-Daniel Hailfinger
> wrote:
>> Am 15.04.2012 04:57 schrieb ron minnich:
>> It's a slippery slope, though. We call the blob from coreboot and expect
>> it to return to coreboot (wh
On 18.01.2008 18:16, ron minnich wrote:
> On Jan 18, 2008 9:14 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>
>
>> I think v1 should be completely unchanged. It's neither active nor
>> supported so I don't think it should have the current name.
>>
>
> I agree.
>
Same here.
Regards,
Carl-
0:0x0003
> writeglmsr: MSR 0x4020, val 0x2000:0x000fff80
> writeglmsr: MSR 0x4021, val 0x2000:0x080fffe0
> sizeram: _MSR MC_CF07_DATA: 10076013:00061a40
> sizeram: sizem 0x100MB
> sysmem_init: enable for 256MBytes
> Usable RAM: 268304383 bytes
> sysmem_init:
On 19.01.2008 01:08, Carl-Daniel Hailfinger wrote:
> On 19.01.2008 00:17, Ronald Hoogenboom wrote:
>
>> On Fri, 2008-01-18 at 23:31 +0100, Carl-Daniel Hailfinger wrote:
>>
>>
>>> Thanks for reworking the code! I have factored out some common status
>
the datasheet, but sensors-detect says
> 0x8853 is also possible. Also, the ASUS A8V-E Deluxe
> (W83627EHF) has an ID of 0x8854 (verified on actual hardware).
>
> So assume all 0x88?? IDs to mean W83627EHF/EF/EHG/EG.
>
> Signed-off-by: Uwe Hermann <[EMAIL PROTECTED]>
>
that on my board, it works ;)
>>> Thanks for Uwe to help me make a SVN diff patch.
>>>
>
> Looks good!
>
>
>
>>> signed-off-by : Bingxun Shi <[EMAIL PROTECTED]>
>>>
>
> Acked-by: Peter Stuge <[EMAIL PROTECTED]>
h that fixed, or if no one thinks that will ever happen:
>>>> Acked-by: Myles Watson <[EMAIL PROTECTED]>
If we used grep, the buildtarget snippet could probably be made a bit
smaller:
ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (doe
On 19.01.2008 01:23, Peter Stuge wrote:
> On Sat, Jan 19, 2008 at 01:18:11AM +0100, Carl-Daniel Hailfinger wrote:
>
>> +while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>> myusec_delay(10);
>>
>
> Indent this prope
On 18.01.2008 20:02, Uwe Hermann wrote:
> On Fri, Jan 18, 2008 at 07:51:00PM +0100, Stefan Reinauer wrote:
>
>> Peter Stuge wrote:
>>
>>> On Fri, Jan 18, 2008 at 06:20:11PM +0100, Uwe Hermann wrote:
>>>
>>>
> The utility will be renamed, too.
>
>
On 19.01.2008 00:17, Ronald Hoogenboom wrote:
> On Fri, 2008-01-18 at 23:31 +0100, Carl-Daniel Hailfinger wrote:
>
>> Thanks for reworking the code! I have factored out some common status
>> registers to duplicate less code and hope the code still works. Could
>> you p
On 18.01.2008 21:09, Ronald Hoogenboom wrote:
> OK, I've checked it again and fixed a few things, see the read function
> and the erase also has the block protect disable, and it works again.
>
Thanks! It seems I was half asleep while coding the if (size > 512k) part.
> It takes just under a m
---
Support SPI flash chips bigger than 512 kByte sitting behind IT8716F
Super I/O performing LPC-to-SPI flash translation.
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Signed-off-by: Ronald Hoogenboom <[EMAIL PROTE
On 18.01.2008 08:17, ron minnich wrote:
> OK, SiS sent me this nice board with some 2 MB flash parts and I have
> not gotten much past step 1, "Program the flash", as it is a 2 MB
> flash. I had no idea what a mess the superio/flash interface was going
> to be.
>
> So, Ronald, I am most interested
On 19.01.2008 09:15, ron minnich wrote:
> I am wondering for VSA if we should not have a post-ram step where we
> find all LAR entries with names like
> prestage2/*
> and run them. Still not sure of the right approach for VSA. Is VSA so
> special that we shouldn't worry about handling it in the ge
On 19.01.2008 07:39, ron minnich wrote:
> Marc, should we modify the LX build to somehow wget the VSA and copy
> it in to LAR? Or should we have a top-level "blob" directory in v3
> that includes the vsa file, and then build it in to LAR?
>
Please don't store any blobs in the v3 tree directly.
On 19.01.2008 18:07, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> On 19.01.2008 07:39, ron minnich wrote:
>>
>>> Marc, should we modify the LX build to somehow wget the VSA and copy
>>> it in to LAR? Or should we have a top-level "blob" dir
On 19.01.2008 19:34, Ronald Hoogenboom wrote:
> Carl-Daniel Hailfinger wrote:
>
>> */
>> -//while (generic_spi_read_status_register() &
>> JEDEC_RDSR_BIT_WIP)
>> +while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>>
On 18.01.2008 23:10, Ward Vandewege wrote:
> On Wed, Jan 16, 2008 at 10:34:29PM -0500, Ward Vandewege wrote:
>
>>> Winbond W25X16VSSI
>>> Winbond W25X32VSSI
>>>
>>> Problem with Winbond is they really only want to sell large
>>> quantities. I haven't even gotten a quote and delivery time
>>> bac
Hi Marc!
To commit your patch, I need a signoff from you because you created the
patch. Please see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
details.
Thanks!
On 19.01.2008 23:15, [EMAIL PROTECTED] wrote:
> Quoting Carl-Daniel Hailfinger <[EMAIL PRO
On 20.01.2008 02:11, coreboot information wrote:
> Change Log:
> give it 2k more space for abuild. let's look into this anyways, but get rid of
> the impression that the cheetah on fam10 is broken just because we're using a
> too new compiler for abuild. (trivial)
>
> Signed-off-by: Stefan Reinauer
On 20.01.2008 12:48, Ronald Hoogenboom wrote:
> On Sun, 2008-01-20 at 11:59 +0100, Ronald Hoogenboom wrote:
>
>> The read status register will take at least:
>> 16*(2/33) us = about 1 us (excluding the LPC latency, which is?), so
>> assuming that the first read status will show busy and the
New plan:
Scratch all "special" LAR member stuff and simply add a normal file
called "foo" or "placeholder" with the nocompress: parameter to the LAR.
No new code needed, gives us almost everything we need right now.
What do you think?
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@co
ng for the first time.
> We are still failing in
> "Finding PCI configuration type"
>
> Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]>
>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Committed in r558 with one compile warning fixed.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 21.01.2008 01:03, Ronald Hoogenboom wrote:
> Hi,
>
> I'm investigating booting from ROM where the rom is larger than the LPC
> mmapped area of the superio. In the 'stream' methods used by elfboot,
> there is an option to use compressed payloads, where the stream takes
> care of the decompression
3 of 5 targets in v3 fail to compile:
- adl/msm800sev
- amd/norwich
- artecgroup/dbe61
While none of these targets worked on real hardware, we were at least
able to compile them and could keep the code mostly warning-free to give
later porters a good start. Right now the accumulated mess is rather
On 21.01.2008 17:15, Harald Gutmann wrote:
> Hello!
>
> As in the thread "Re: [coreboot] SST25VF016B (2MB) flash on m57sli (IT8716F)"
> there was added support for writing/reading lager SPI chips than 512kB i had
> a look on the current flashrom code, in svn revision 3067.
>
> I recogniced that t
e of the
> natural variance much larger than 10 us...
> Patch follows...
>
> Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>
>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Committed in r3068.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Harald: This patch should fix your problems writing to the chip. Use
either "patch -l" or remove the // before
//while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
Ronald: I need an ack to commit this.
On 20.01.2008 11:59, Ronald Hoogenboom wrote:
> Carl-Daniel
the face of
>>> genericness for other chips, it is indeed more correct to do the check
>>> for the busy bit.
>>>
>> Ronald/Harald, can you please ack the change? It is reproduced below
>> (whichspace-damaged).
>>
>> Regards,
>> Ca
an
IT8716F flash translation chip.
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Index: flashrom-big/flashrom.c
===
--- flashrom-big/flashrom.c (Revision 3069)
+++ flashrom-big/flashrom.c (Arbeitskopie)
On 19.01.2008 07:35, ron minnich wrote:
> On Jan 18, 2008 4:27 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>
>> Is this same situation as before or is it worse? If it is worse, please
>> try to fix before you commit.
>>
>
> Th
On 22.01.2008 03:53, ron minnich wrote:
> Just FYI, some luck writing this chip on the sis board ...
>
> The write had no errors. The -v failed. But on using the -r to read to
> a file, I find
> no differences between the file used for -w and the file used for -v!
>
Yes, very old lingering bug
On 22.01.2008 16:10, Harald Gutmann wrote:
> Am Dienstag, 22. Januar 2008 15:59:28 schrieb Carl-Daniel Hailfinger:
>
>> Flashrom did not use the read function for verifying, it used direct memory
>> access instead. That fails if the flash chip is not mapped completely.
>&
; benchvice flashrom # ls -l test.4mb
> -rw-r--r-- 1 root root 4194304 22. Jan 16:27 test.4mb
> benchvice flashrom #"
>
> Signed-off-by: Harald Gutmann <[EMAIL PROTECTED]>
>
Acked-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
Thanks, r3072.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 22.01.2008 16:59, Uwe Hermann wrote:
> On Tue, Jan 22, 2008 at 03:59:28PM +0100, Carl-Daniel Hailfinger wrote:
>
>> Flashrom did not use the read function for verifying, it used direct memory
>> access instead. That fails if the flash chip is not mapped completely.
>>
Ron?
On 10.01.2008 13:32, Carl-Daniel Hailfinger wrote:
> Btw, the block lock bits are all set, so even if you manage to convince
> the SPI translation to map more than 512 KByte and even if you use
> enable LPC-to-SPI writes, you will still flash nothing. Try this for
> better lock
On 22.01.2008 16:47, Marc Karasek wrote:
> Been away for the weekend. Sun was closed on Monday.
>
> Signed of by Marc Karasek <[EMAIL PROTECTED]>
>
>
> Carl-Daniel Hailfinger wrote:
>
>> On 09.01.2008 16:13, Marc Karasek wrote:
>>
>>
&g
On 22.01.2008 17:37, ron minnich wrote:
> On Jan 22, 2008 8:27 AM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>> Ron?
>>
>
> See my other note, this works but verify did not, which I think you
> also just fixed.
>
Yes, but status regis
On 21.01.2008 17:42, Ed Swierk wrote:
> On Dec 27, 2007 4:25 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>> I'm currently reviewing the rest of the patch. Looks nice so far.
>>
>
> There's no urgency, but I'm wondering if th
On 22.01.2008 18:59, Myles Watson wrote:
> Coreboot v3 refuses to initialize the VGA in QEMU because the PCI device
> ID's are mismatched.
>
> It turns out that the header has been overwritten by a copyright string, so
> that v3 is following a bad pointer into the ROM looking for the PCI device
> I
On 22.01.2008 20:04, ron minnich wrote:
> On Jan 22, 2008 10:46 AM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>
>
>> Small thing; I would prefer something else than a comma after the
>> type, so that it is separated from the real information. Maybe:
>> id="pci:vendor,device";
>>
>> I think that wou
On 23.01.2008 01:41, [EMAIL PROTECTED] wrote:
> Arugh!!! When I tested the patch eveerything worked ok but now with
> the new svn version, when I try abuild it get this:
>
>Creating builddir...ok
>Compiling image ..FAILED after 13s! Log excerpt:
> gcc -m32 -nostd
have to specify entry
point and load address by hand.
The following patch allows us to specify LAR entries like
"entry=33:blobs/vsa" which then have entry point addr 33.
This can be extended to a loadaddr= parameter.
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
In
On 23.01.2008 02:24, [EMAIL PROTECTED] wrote:
> Quoting Carl-Daniel Hailfinger <[EMAIL PROTECTED]>:
>
>
>> On 23.01.2008 01:41, [EMAIL PROTECTED] wrote:
>>
>>> Arugh!!! When I tested the patch eveerything worked ok but now with
>>> the n
On 23.01.2008 17:05, Stefan Reinauer wrote:
> Jordan Crouse wrote:
>> Lets go back to basics on this one - put the blob in the LAR (easy to
>> do),
>> and then the code will know how to use it. Done and done.
>>
> Yes. All we need to know about the VSA binary is its start address in
> the lar. T
On 24.01.2008 13:38, Peter Stuge wrote:
> I put a Spansion chip on a m57sli. This patch lets flashrom read the
> chip successfully. Writing is inconsistent.
>
> I've done two writes so far. Writing takes several minutes and I
> don't get any progress messages from flashrom.
>
> The first run was 4*
On 24.01.2008 17:02, ron minnich wrote:
> On Jan 24, 2008 6:34 AM, Carl-Daniel Hailfinger
>
>> What about compression of the VSA?
>>
>
> On v3, we have the 'use compression' option in the Kconfig dialog.
> Long term, I intend to use the same compression
On 23.01.2008 05:25, ron minnich wrote:
> OK, with 3073, something went worse.
>
r3073 and r3072 did not have any changes affecting you.
> Last night, I was flashing just fine. As of today, it's not id'ing it
> and it is reading 0xff back for that pass.
Maybe the port it reads from gives 0xff
On 23.01.2008 20:19, ron minnich wrote:
> On Jan 23, 2008 11:06 AM, Marc Jones <[EMAIL PROTECTED]> wrote:
>
>> BUT, I don't think that you need them. VSA should default to reasonable
>> settings without the in15 calls. I need to test it in v2 this afternoon.
>> If VSA does require them I would r
On 24.01.2008 20:05, ron minnich wrote:
> On Jan 24, 2008 10:06 AM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
> ===
>
>>> --- northbridge/amd/geodelx/vsmsetup.c(revision 0)
>
On 25.01.2008 02:11, Peter Stuge wrote:
> On Thu, Jan 24, 2008 at 04:57:35PM +0100, Carl-Daniel Hailfinger wrote:
>
>>> Then I wrote rand.bin which is 2MB of /dev/random. This
>>> consistently reads back as something quite different
>>>
>> This loo
On 25.01.2008 20:24, Peter Stuge wrote:
> On Fri, Jan 25, 2008 at 07:21:16PM +0100, Stefan Reinauer wrote:
>
>>> These are very good for distributions. Not all distributions can
>>> deal with svn HEAD and few do it well IMO.
>>>
>> What would be the problem with a version "r3065"? I doubt
On 25.01.2008 19:17, ron minnich wrote:
> On Jan 25, 2008 10:15 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
>
>
>> Hmm - probably the right move, but the changes in buildrom are not
>> trivial for v2. We would need to figure out what the ROM size is (by greping
>> Config.lb, probably), compres
We need to rethink this whole source tree renaming business. It
- messes up svn blame
- causes lots of breakage when you try to go back to versions before the
rename (try it with coreboot v2!)
- introduces inconsistencies in at least half of the patches (some
references to LB are changed, some rema
Hi,
while I agree fully with renaming the project, we need to consider the
point where we stop the renaming, also because some code referencing our
code is outside of our control.
We have LBTABLE structures and can rename them to CBTABLE. But will
Linux kernel folks merge patches renaming the stru
s not correct for all platforms. sc520 will
> + * need some hands on here.
> + */
> + archive->len = *(u32 *)0xfff4;
> + archive->start =(void *)(0UL-archive->len);
> +
> + // FIXME check integrity
> +
> +}
> /* until we get rid o
On 25.01.2008 22:30, Stefan Reinauer wrote:
> ron minnich wrote:
>> how does stage 2 access LAR? The mem_file struct is an auto (local)
>> for stage1.
>>
>> void __attribute__((stdcall)) stage1_main(u32 bist)
>> {
>> int ret;
>> struct mem_file archive, result;
>> int elfboo
On 25.01.2008 18:58, Peter Stuge wrote:
> On Fri, Jan 25, 2008 at 10:55:24AM -0700, Myles Watson wrote:
>
>> I accidentally used an uncompressed payload with v2 when it
>> expected a compressed payload, and it gave me the message:
>>
>>Decoder scratchpad too small!!
>>Decoding er
Sorry Ron, this is not meant as a rant against you. The patch you posted
just fitted a pattern I'm seeing more and more often.
Our problem is that we try to handle copyright issues with perfection.
That sometimes causes us to go overboard with attributions.
On 25.01.2008 18:12, ron minnich wrote:
On 25.01.2008 16:17, Peter Stuge wrote:
> The Call for Projects has been released.
> http://www.linuxtag.org/2008/de/community/projects/cfpro.html
> http://www.linuxtag.org/2008/en/community/projects/cfpro/call-for-projects.html
>
> Applications must be in before February 21st.
>
> I think we did O
Hi Philipp,
On 25.01.2008 12:50, Philipp Marek wrote:
> My question is this. I'd like to secure machines against the
> people that should work with them [1].
>
Ah. Classic DRM.
> In most BIOSes I can set the boot order to "harddisk only".
> (coreboot too, right?). That doesn't help if someone
On 26.01.2008 09:46, Corey Osgood wrote:
> ron minnich wrote:
>> On Jan 25, 2008 11:46 PM, Patrick Georgi <[EMAIL PROTECTED]>
>> wrote:
>>> How about renaming LAR to "lightweight archive(r)" and keep the short
>>> name?
>>
>> Good one. Works for me.
>
> Me too
Same here.
Regards,
Carl-Da
On 27.01.2008 03:01, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [080126 02:28]:
>
>> while I agree fully with renaming the project, we need to consider the
>> point where we stop the renaming, also because some code referencing our
>>
On 27.01.2008 05:28, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [080122 15:59]:
>
>> Flashrom did not use the read function for verifying, it used direct memory
>> access instead. That fails if the flash chip is not mapped completely.
>>
On 27.01.2008 08:08, Peter Stuge wrote:
> On Sun, Jan 27, 2008 at 03:15:58AM +0100, Stefan Reinauer wrote:
>
>>> #define ID is well tested but I'm not adamant in any way. You're
>>> basically asking for less information in source and more at run
>>> time. I like more info at run time but I still
On 27.01.2008 06:55, Peter Stuge wrote:
> On Sun, Jan 27, 2008 at 06:32:42AM +0100, Peter Stuge wrote:
>
>> Hi Andreas,
>>
>
> So, this wasn't really meant for the list. I only saw the list
> address in To just as I hit send. No problem for me, but;
>
> Should we really have a Mail-Followup
On 27.01.2008 13:49, [EMAIL PROTECTED] wrote:
> Quoting Peter Stuge <[EMAIL PROTECTED]>:
>
>
>> On Sat, Jan 26, 2008 at 07:00:43PM -0500, Danny Piccirillo wrote:
>>
>>> Can random people donate money or hardware to coreboot? I'd love to
>>> see a page on the wiki with instructions for peopl
On 27.01.2008 13:55, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>> On 27.01.2008 03:01, Stefan Reinauer wrote:
>>
>>> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [080126
>>> 02:28]:
>>>
>>>> while I agree fully w
On 27.01.2008 16:07, Peter Stuge wrote:
> On Sun, Jan 27, 2008 at 03:01:50PM +0100, Patrick Georgi wrote:
>
>> When that works, we could provide a .jar file with a demo bios
>> image or something like that, for instant experimentation as java
>> applet.
>>
>
> Indeed neat! Do you know if jp
On 27.01.2008 06:35, Peter Stuge wrote:
> On Sat, Jan 26, 2008 at 09:07:23PM -0800, ron minnich wrote:
>
>> OK, VSA is running fine. BUT, after VSA runs, memory at 0x1000 is
>> ZERO'd. This is Bad, as this is where stage2 lives!
>>
>
> Can you confirm it is not zero before calling do_vsmbio
On 27.01.2008 18:44, ron minnich wrote:
> On Jan 26, 2008 9:35 PM, Peter Stuge <[EMAIL PROTECTED]> wrote:
>
>
>> Can you confirm it is not zero before calling do_vsmbios() and zero
>> immediately after returning? That would indicate that the VSA setup
>> empties the area.
>>
>
> Confirmed.
On 27.01.2008 20:19, Tiago Marques wrote:
> Yes, PLCC.
> SuperIO?
>
See http://www.coreboot.org/Superiotool for details.
> The chips are a w39v040B and a Pm49FL004.
>
Which boards? We need exact vendor name, board name and revision.
Regards,
Carl-Daniel
--
coreboot mailing list
coreboot
On 27.01.2008 20:46, [EMAIL PROTECTED] wrote:
> Quoting Peter Stuge <[EMAIL PROTECTED]>:
>
>> On Sun, Jan 27, 2008 at 07:59:33AM -0500, [EMAIL PROTECTED] wrote:
>>
>>> I am pretty fluent in php / html.
>>>
>> Going back to the competition, we will need a database, an entry form
>> an
On 27.01.2008 23:32, Torsten Duwe wrote:
> On Saturday 26 January 2008, Carl-Daniel Hailfinger wrote:
>
>> Hi Philipp,
>>
>> On 25.01.2008 12:50, Philipp Marek wrote:
>>
>>> My question is this. I'd like to secure machines against
On 28.01.2008 04:14, Corey Osgood wrote:
> Corey Osgood wrote:
>> Carl-Daniel Hailfinger wrote:
>>> On 27.01.2008 01:53, Stefan Reinauer wrote:
>>>
>>>> * Carl-Daniel Hailfinger <[EMAIL PROTECTED]>
>>>> [080126 01:50]:
>>>>
On 28.01.2008 14:28, Stefan Reinauer wrote:
> * Marc Jones <[EMAIL PROTECTED]> [080122 00:01]:
>
-/* smbus functions */
-int smbus_read_byte(unsigned device, unsigned address);
>>> hmm. So where does the prototype live then?
>>>
>
> They should not necessarily be i
On 28.01.2008 22:12, Jordan Crouse wrote:
> On 28/01/08 21:38 +0100, Carl-Daniel Hailfinger wrote:
>
>> On 28.01.2008 21:12, coreboot information wrote:
>>
>>> revision 3085
>>>
>>> Build Log:
>>> Compilation of a
On 28.01.2008 21:55, Marc Jones wrote:
>
>
> Carl-Daniel Hailfinger wrote:
>> On 25.01.2008 19:17, ron minnich wrote:
>>> On Jan 25, 2008 10:15 AM, Jordan Crouse <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Hmm - probably the right move,
?revision=3085&device=serengeti_cheetah_fam10&vendor=amd
>
And we need another 2461 bytes increase due to the new compiler. Just in
case anyone wonders which compiler causes continuous size increases:
gcc version 4.3.0 20080117 (experimental) [trunk revision 131592] (SUSE Linux)
Regards,
Carl-Da
1 - 100 of 2739 matches
Mail list logo
