Hi Łukasz,
* Łukasz Dmitrowski [150314 10:23]:
> My name is Lukasz and I am a Computer Science student at West Pomeranian
> University of Technology in Szczecin. Main area of my interests are embedded
> systems and for me coreboot is the most interesting organization in GSoC
> 2015. Thats why I a
Hi Anthony,
* Anthony Martin [150312 23:27]:
> - Does it use the usual depthcharge payload with an internal
> write-protect switch for flashing the firmware? There's no
> boot guard shenanigans going on, correct?
That is correct. Like all Chrome OS devices, Samus (Pixel2) uses
the SPI flash'
* Peter Stuge [150312 19:29]:
> Stefan Reinauer wrote:
> > I would like to organize a coreboot project meeting in San Jose,
> > California this summer.
> ..
> > If you are interested in joining this summer, if you have ideas, or
> > concerns, please contact m
Hey folks!
the coreboot meeting in Prague last year was a great success, and I
suggest that we have a get together this year.
To alternate between continents, I would like to organize a coreboot
project meeting in San Jose, California this summer. I have talked to a
few people, and it seems that
* Timothy Pearson [150205 19:23]:
> e820: BIOS-provided physical RAM map:
> BIOS-e820: [mem 0x-0x0009fbff] usable
> BIOS-e820: [mem 0x0009fc00-0x0009] reserved
> BIOS-e820: [mem 0x000f-0x000f] reserved
> BIOS-e820: [mem 0x
* Alexandru Gagniuc [150214 01:13]:
> On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote:
> > Hi Everyone,
> >
> Hi,
>
> > Please update the wiki page with project ideas.
> > http://www.coreboot.org/Project_Ideas
> >
> That's the first unlocked page in the coreboot wiki I have seen for
* Alexandru Gagniuc [150214 02:14]:
> It's that time of the year it seems. Last year, there were talks about
> reducing the number of gerrit submitters. I'm certain you remember the anger
> this caused amongst non-commercial members of the community when the proposed
> list contained exclusivel
* Julius Werner [150218 00:12]:
> I'd like to propose an API change/cleanup for a long-standing problem
> with architecture-independent code that people have hit and privately
> discussed/cursed multiple times already, but no one really had time to
> make the big change/fix yet. (Some earlier disc
* Kuzmichev Viktor [150120 14:31]:
> Hello,
>
> I'm trying to load Memtest86+ on the Mohon Peak reference board from
> CBFS and it fails.
> My primary payload is SeaBIOS. Memtest is added using cbfstool, so
> the layout of my ROM file is as follows:
>
> $ ./build/cbfstool build/coreboot.rom prin
* Fred Young [150107 16:46]:
> The last time that I synched my coreboot source was about 2 weeks ago. I just
> tried the latest FSP and I still have the same problem. When I load Linux, I
> do
> see video output.
Your video bios executes, and fails because an int15 handler for 5f35 is
not impl
Dear coreboot community members:
Marc, Ron, Patrick, Aaron and I have been discussing for a while about how
to make coreboot more accessible for businesses. We would like to found a
business organization (a.k.a. a coreboot consortium) that helps commercial
players out there to become a part of the
* Bucsi Andor [141203 19:52]:
> /home/harish/opensource/coreboot/payloads/coreinfo/util/kconfig/lxdialog/
> dialog.h:22:19: fatal error: fcntl.h: No such file or directory
Did you install libc6-dev?
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listin
On 11/19/14 11:36 AM, Gailu Singh wrote:
Hi Experts,
I am using Baytrail SoC board (Bayleybay CRB) and testing
suspend/resume from Linux (kernel 3.10). I can suspend with pm-suspend
and resume with power button; however after resuming I get following
logs in Linux
Corrupted low memory at c00
On 11/20/14 9:40 PM, Scott Duplichan wrote:
The Gluglug [mailto:i...@gluglug.org.uk] wrote:
]-BEGIN PGP SIGNED MESSAGE-
]Hash: SHA1
]
]Hi,
]
]cbfs-mkstage.c: In function ‘is_phdr_ignored’:
]cbfs-mkstage.c:45:84: error: cast to pointer from integer of different
]size [-Werror=int-to-point
On 11/21/14 4:31 AM, Idwer Vollering wrote:
2014-11-21 6:03 GMT+01:00 The Gluglug :
One possible solution is to simply upgrade GCC, which I will, but I
would also like to get cbfstool to build again for this version of
GCC. The patch in the gerrit link works, but is not accepted for
upstream.
* Gailu Singh [141119 20:36]:
> Hi Experts,
>
> I am using Baytrail SoC board (Bayleybay CRB) and testing suspend/resume from
> Linux (kernel 3.10). I can suspend with pm-suspend and resume with power
> button; however after resuming I get following logs in Linux
> Corrupted low memory at c000100
* ron minnich [14 23:23]:
> I have a friend who has a parallel port programmer for a 2764. He needs to
> program it.
>
> Options?
> 1. Get a pin-compatible replacement for a 2764
Any 27C64 should work.
> 2.get a USB to parallel port adapter
As Felix said.
> 3. get something more modern t
Hi,
while this was addressed at AMD, I feel compelled to add my 2ct to some
of this.
* Peter Stuge [141106 16:07]:
> As these contributions started to flow into the community many years
> ago, you may remember that I guessed that such rules would exist and
> asked *literally* what those rules we
* ron minnich [140827 18:43]:
> I need to set up qemu with a 64MiB ROM.
>
> I figure supporting EFI has made QEMU capable of such things, but if
> anyone has direct experience with this, please let me know. I tried it
> a few years back (2008) and it did not work at all ... I guess worst
> case I
* Peter Stuge [140814 23:31]:
> Isaac wrote:
> > The new nvidia/tegra124 support requires a build tool from NVIDIA called
> > cbootimage (https://github.com/NVIDIA/cbootimage). I'm not sure of the best
> > way to add support into coreboot so I'd like to get some feedback.
>
> I would suggest ei
* ron minnich [140809 05:24]:
> Some of furquan's very fine work from -- yegads! -- a year ago is just
> now coming upstream. Take a look.
Ron! If you have a link for us, that would be great!
I want to endorse Furquan's great work, however. Not only did it open up
new ways of making sure we get
* Gregg Levine [140805 21:35]:
> Hello!
> Stefan, by what you posted there, (and correct me if I'm wrong) if I
> were to put together a system who would be running ChromeOS and of
> course using coreboot to bring it up, the OS would be constructed from
> the head of the entire Chromium set?
That
* Patrick Georgi [140805 21:32]:
>
>
> Am 05.08.2014 um 20:36 schrieb Stefan Reinauer:
> > Are you suggesting that the needs have changed here?
>
> My only concern here would be to keep rebase/merge et al more
> functional, but it's probably already too late fo
* Kyösti Mälkki [140731 21:00]:
> Do you plan to upstream all Chromebook coreboot and libpayload
> branches from Chromium git, or just the individual patches Sage
> finds useful and necessary for the boards You currently work on?
No, the plan for now is to only upstream the Chromium HEAD, since
* Paul Menzel [140802 15:07]:
> As already commented on your change sets, I’d prefer if you could avoid
> squashing commits. Kyösti made very good points, so I won’t repeat them.
One of the reasons Isaac has been squashing patches was that some in the
community have been complaining about a vast
* Stefan Berger [140714 12:14]:
> The TPM is successfully detected but sending TPM_Startup(ST_Clear)
> to the TPM fails since either coreboot or some other firmware seems
> to already have initialized the TPM, which is fine, and also
> extended PCR 0 with at least one hash. Ideally there would be
Hi Richard,
* Richard A. Smith [140710 19:45]:
> http://ctl.net/education-chromebook/
>
> Anyone know if these run coreboot and how locked down they are?
All new Chrome OS devices run coreboot and depthcharge, a payload that
implements a verified boot process. Chrome OS devices with an Embedde
* ron minnich [140514 19:22]:
> what's an "EFI OS"?
An OS that implements the UEFI standard, e.g. TianoCore / edk2 ;)
This is under the assumption that every advanced boot loader eventually
turns into an operating system.
SCNR.
Stefan
--
coreboot mailing list: coreboot@coreboot.org
http://ww
* Vitor Augusto [140412 03:04]:
> Hello.
>
> I'm searching for any information about where (memory, IO port, etc.)
> the status (on or off) of the fans of a laptop are stored. Anything is
> very welcome! This is to improve the compatibility of i8kutils package
> at Linux. The site of the developm
* Zoran s [140326 08:17]:
> Hello Ron, Marc (Jones),
>
> I am wondering where IOAPIC code resides (somewhere on SouthBridge) for IVB?
>
> Could you (or anybody) point to me the file where this code exists/lives, so I
> can inspect it and learn more about IOAPIC itself? This one is implemented
>
* Andrew Wu [140327 14:00]:
> Sorry, I checked Vortex86EX CPU datasheet, but it seems there is no
> workaround can do it.
>
> So if I want to get rid of romcc, maybe I have to write DRAM init code
> in assembly, That is not very easy. :(
Don't worry we'll figure something out that's better than
* David Hendricks [140326 20:25]:
> On Wed, Mar 26, 2014 at 9:47 AM, ron minnich wrote:
>
> I think it's good and well written. I'd replace your 'panic levels' with 4
> simple classifications and leave it at that.
>
>
> Yep, good write-up overall.
>
> I never liked the "panic level" r
* mrnuke [140325 19:13]:
> On Tuesday, March 25, 2014 06:56:13 PM Stefan Reinauer wrote:
> > * ron minnich [140325 06:34]:
> > > On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko <
> > >
> > > phco...@gmail.com> wrot
* mrnuke [140325 08:37]:
> > > a branch containing that hash is not available publicly.
> >
> > Baloney. Your not finding it does not mean it's not available. It means you
> > didn't look hard enough.
> >
> I call baloney on this one. I do not have to "look hard enough". Section 3
> defines how
* mrnuke [140325 05:10]:
> * For example, a hardwired boot blob which has been RE'd so that we know
> what
> it does and how it does it, would be acceptable (see Allwinner). Even the
> FSF,
> according to RMS's own essays considers this to essentially be hardware.
> * A non-ISA (a) firmware
* ron minnich [140325 06:34]:
>
>
>
> On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>
> I don't see how this prevents any of my propositions for the bulk of the
> boards. The problem you describe isn't going away with your prop
* Patrick Georgi [140321 18:38]:
> Am Donnerstag, den 20.03.2014, 17:57 -0500 schrieb mrnuke:
> > * Share these drivers between coreboot and libpayload.
> Make them BSD-l, like cbfs-core.
>
> > * libpayload core remains BSD.
> "with strings attached" - I'd like to avoid that.
Nice pun. It's ac
* mrnuke [140320 23:57]:
> Proposal:
> * Share these drivers between coreboot and libpayload.
> * libpayload is BSD. Have a "[ ] Enable GPL features" config option which
> "unlocks" the GPL'd drivers from coreboot.
> * libpayload core remains BSD.
> * coreboot drivers are available t
* Vladimir 'φ-coder/phcoder' Serbinenko [140321 04:13]:
> The boards and chipsets are sufficiently well insulated from each other
> so that it's possible to improve one without breaking the others. With
> board-status the potential users and devs have a good overview which
> revisions work on whic
* Kyösti Mälkki [140322 18:44]:
> Some changes to review process are certainly welcome. I just hope
> Stefan would have included separate section of the current problems
> and more details of the goals his proposal tries to address. Even
> some of the obvious ones are not answered. For example, ar
* Vladimir 'φ-coder/phcoder' Serbinenko [140321 04:31]:
> The proposition of gatekeepers would essentially kill community effort.
> Even in current infrastructure reviewing is a major slowdown. With small
> number of gatekeepers there wouldn't be any significant contributions as
> the gatekeepers
* David Hubbard [140323 20:33]:
> On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
> On 23.03.2014 19:24, ron minnich wrote:
> > So I believe the problem is not the idea of gatekeepers, but the
> > manner in which they are propose
* David Hubbard [140323 10:56]:
> Coreboot can be relevant even if it only supports "obsolete" silicon. Coreboot
> was the first to bring sub-second boot times to laptops. There are more
> examples.
Yes, we worked hard to get to that goal. If it were about obsolete
hardware it would have never ha
* Paul Menzel [140325 00:20]:
> Additionally I heard claims, that the GPLv2 license is violated as it is
> currently impossible to rebuild the exact same image that is shipped
> with the devices as it is not even clear what commit was used to build
> the image and to my knowledge the requests on t
Hi Carl-Daniel,
thank you for your feedback!
* Carl-Daniel Hailfinger [140321 01:39]:
> I see a huge bottleneck in restricting the number of committers to six.
> - Corporate committers will be primarily obliged to get the stuff of
> their own employer committed, but if they are ill or on vacatio
rch 20, 2014 10:55:57 PM Stefan Reinauer wrote:
> > * Build a MAINTAINERS file for common code, and encourage people to keep
> > subsystem maintainers in the loop for changes
> > [...]
> >
> This is somewhat what linux does, and it works well for them.
When we (Ron, M
* Stefan Tauner [140321 01:42]:
> On Thu, 20 Mar 2014 22:33:21 +0100
> Stefan Reinauer wrote:
>
> > dmp/vortex86ex
>
> What's exactly wrong with that one? DMP ported their SoC themselves
> less than half a year ago, and I seriously doubt that dropping that
> a
* ron minnich [140320 22:37]:
> I like this, I just wish we could remove more boards :-)
I was surprised that the number of boards still using ROMCC for romstage
was so low. We could also remove the revF and Fam10 boards because the
use non-standardized cache as ram implementation.
Are any board
consistency, scalability and conformity with the general
coreboot strategy, we need to define a clear committer structure that
defines the original project structure of having a benevolent dictator
aka project leader (Stefan Reinauer) and gatekeepers in place. The
suggested structure will need to
coreboot for the 21st century
setting up the project for the next decade
Purpose: Purge all boards / chipsets / cpus that require ROMCC in
romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades
with ups and downs. During this time we
* Shant Kehyeian [140320 12:12]:
> Hello,
> I have Samsung ARM chromebook series 3 "Snow" and I am trying to flesh it and
> change the boot process.
> So I build a coreboot.rom for that, but before I start to do that I would like
> to ask about the payload. When I did the "make menuconfig" it wasn
> On Mar 15, 2014, at 10:22, Kevin O'Connor wrote:
>
>> On Wed, Mar 12, 2014 at 09:12:05PM +0100, Stefan Reinauer wrote:
>> * Peter Stuge [140312 19:08]:
>>> ron minnich wrote:
>>>> For the base identity map on x86-32, it's one page for 4G.
>
* Peter Stuge [140312 19:08]:
> ron minnich wrote:
> > [on arm]
> >
> > > Why is it helpful or neccessary there?
> >
> > It only matters if you like to have a dcache. Do you want a dcache?
>
> What are the numbers?
Of running with dcache vs without? Beyond 10x speed improvement iirc.
Far too m
* ron minnich [140310 23:24]:
> Which option ROMs? newish ones or 3c509 :-)? Ah well guess I believe you. I
> guess I never needed it because in my main uses we did not use or want option
> roms -- we loaded Linux and there was no need there. Running some option rom
> in
> an 8086 mode was never
* ron minnich [140310 22:43]:
> Now you've just made me sad.
>
> OK, given that in the beginning times we never supplied this little tidbit,
> who
> or what needs it? It looks like another memory turd whose time has gone.
>
> ron
It's needed by some option roms. See void dev_initialize(void) i
* John Lewis [140129 23:16]:
>
> Okay, well I extracted the attached file using:
>
> eval `./fmap_decode bios.bin | grep BOOT_STUB`
> dd if=c720.rom ibs=$((area_offset)) skip=1 | dd bs=$((area_size))
> iflag=fullblock of=c720-coreboot.bin
You should use cbfstool on the whole 8MB image...
> an
* Mono [140124 23:20]:
> Hallo,
> Would you help me on a coreboot port? I just installed coreboot on a Thinkpad
> X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too.
> I read some pages in the wiki and started to collect information about the
> macbook. it seems it has no supe
Hi Alex,
thanks for this effort. Without having looked at the patches yet, I
think moving microcode into 3rdparty / blobs.git is the right way to
go. This is one of the (my) original intentions of having CBFS to begin
with.
Stefan
* mrnuke [131214 00:48]:
> Hi all,
>
> Following some recent di
* Kyösti Mälkki [131213 11:29]:
> Yet we have had commit 032c23db for 5 months:
>
> intel/i945: Use MMCONF_SUPPORT_DEFAULT
>
> Change all PCI configuration accesses to MMIO on all boards
> with i945 chipset. To enable MMIO style access, add explicit
> PCI IO config write in the bootblock
* Kyösti Mälkki [131212 16:02]:
> Hi
>
> After commit 872c922 there is some trouble on PCI configuration
> access with Asus M4A785-M. This could apply to other amdfam10 too,
> although I have not yet received such reports.
>
> As the commit message stated, I had discovered that in the beginning
* Bradley M. Kuhn [131120 17:09]:
> TL;DR: Coreboot applied to the Conservancy and has been offered
>membership. The FSA template should be reviewed by all interested
>parties, and we need your help to draft three specific sections,
>which are discussed in detail at the bo
* Denis 'GNUtoo' Carikli [131109 00:19]:
> On qemu, coreboot is not necessary: some coreboot payloads (like
> seabios) are capable of beeing the full bootstrap firware(because
> qemu is really simple: most of the complex hardware already works).
>
> Then I really wonder what's left for coreboot i
* ron minnich [131107 16:09]:
> Very interesting note. We've never seen this before. Comments?
We did see this before.. We actually had a wbinvd there for a while, at
least in the ChromeOS tree. And removed it because it broke some
hardware.
Stefan
--
coreboot mailing list: coreboot@coreboot.
* Aaron Durbin [131105 18:00]:
> On Tue, Nov 5, 2013 at 10:55 AM, Kyösti Mälkki
> wrote:
> > Hi
> >
> > A recent discussion I had about google/stout suggested that with the sources
> > from coreboot git, this board is unable to resume from S3 suspend.
> > (Argumentation: no EARLY_CBMEM_INIT, no
On 7/29/13 11:43 PM, Eugen Leitl wrote:
On Tue, Jul 30, 2013 at 02:40:16AM +0200, Stefan Reinauer wrote:
I agree with Alex: If you are concerned by this issue, please make an
effort to fix it. It would be great to bring the clear level of
separation that we have on newer systems to older CPU
* Alex G. [130725 22:23]:
> Denis,
>
> We have in place a pretty darn good infrastructure of separating the
> microcode from the coreboot stages. It's very easy to store microcode as
> a _separate_ CBFS file. Not all CPUs use this, but changing this is
> trivial. Patches welcome.
I agree with
* Kyösti Mälkki [130729 17:22]:
>
>
> Did someone change the SPD eeprom address notation in pei_data from
> 7-bit to 8-bit addresses?
>
> samsung/lumpy/romstage.c :
> .spd_addresses = { 0x50, 0x00,0xf0,0x00 },
>
> google/stout/romstage.c :
> spd_addresses: { 0xA0, 0x00,0xA4,0x00 },
* Aaron Durbin [130724 17:16]:
> A couple things to change:
>
> CONFIG_CPU_ADDR_BITS=36
> CONFIG_SPI_FLASH_NO_FAST_READ=y
>
> I *don't* think this is causing you grief, but these are different
> from the chromium repo.
>
> Also, you .config shows a 4MiB cbfs, but that doesn't jive with the
> cb
* Tim Zander [130611 02:50]:
>
> Hardware Preparation
>
> Open the case
> You'll now have to disassemble your device (which most
> likely voids your warranty).
> Disable write protect
> You'll have to locate the Write Protect jumper and enable it.
> This will make
* Tim Zander [130611 00:49]:
These 3 used Insyde H2C. They were all Atom based.
> December 2010 Google Cr-48 Mario
> support unknown/no
>
> June 2011 Samsung Series 5 Chromebook Alex
> support unknown/no
>
> July 2011 AcerAC700 ChromebookZG
* tim zander [130611 16:02]:
>
> >Could we convince you to organize it on a coreboot.org/Chromebook
> >wiki page?
> >
> >
> >
> Sure, if you give me an account...
Done.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
* Aaron Durbin [130509 00:02]:
> >> > Am Mittwoch, den 08.05.2013, 08:18 -0500 schrieb Aaron Durbin:
> >> The reason udelay was put in northbridge was for SMM if I am not
> >> mistaken. How similar are the implementations?
> >
> > Of `udelay.c`? Besides the register differences it is the same. San
* Marc Jones [130502 20:24]:
> On Thu, May 2, 2013 at 12:22 PM, Stefan Reinauer
> wrote:
> > * Aaron Durbin [130502 17:39]:
> >> OK. Thanks for the info. That does make for some huge memory
> >> footprints on the AMD machines with a large number of CONFIG_MAX_CPU
* Patrick Georgi [130502 17:40]:
> Am 02.05.2013 16:32, schrieb Aaron Durbin:
> > I am wondering why the ramstage stack size is so large on a lot of boards:
>
> > Is this just an artifact of copy-n-paste? What is driving the
> > requirement for such large stack sizes?
> Other than for wakeup-from
* Aaron Durbin [130502 17:39]:
> OK. Thanks for the info. That does make for some huge memory
> footprints on the AMD machines with a large number of CONFIG_MAX_CPUS.
> I'd be curious to know why the BSP for the AMD code requires so much
> while in ramstage.
>
> -Aaron
One of the majore things n
* Marc Jones [130502 17:15]:
> Hi Aaron,
>
> On Thu, May 2, 2013 at 8:32 AM, Aaron Durbin wrote:
> > Hi folks,
> >
> > I am wondering why the ramstage stack size is so large on a lot of boards:
> >
> > $ grep -A 3 -r STACK_SIZE src/* | grep Kconfig | grep default | awk '{
> > print $NF }' | sort
* Aaron Durbin [130430 04:27]:
> My only comment is that it would be nice to have the notion that there
> is some sort of free running timer on all the boards. It can simplify
> some of the code as well as what is exposed through CONFIG_*, etc. If
> reality dictates that this isn't possible then
* Kevin O'Connor [130430 03:21]:
> On Sat, Mar 23, 2013 at 07:24:03PM +0100, Stefan Reinauer wrote:
> > I was thinking about completely disabling the trac based tracker for
> > coreboot completely since we are basically not using it anymore.
>
> If you are looking for
* Aaron Durbin [130426 21:29]:
> Question for the masses: does anyone actually use UDELAY_IO? If not,
> can we get rid of it? I'll prepare the patch. With APICs, HPETs, TSCs,
> etc I really don't see the need for such a thing.
UDELAY_IO is the default on all systems that do not explicitly select
You might be seeing an issue with the ram controller setup.
I've seen a very similar issue where RAM just seemed to work
fine until you would set up the MTRRs, creating a higher load
on the RAM controller.
You should compare the registers of MCHBAR (See inteltool)
between coreboot and the original
* Paul Menzel [130422 17:04]:
> could you please test building coreboot for your hardware with GCC 4.7.3
> and report back your results [1]? Make sure to save your build with GCC
> 4.7.2 for comparison beforehand as `make crossgcc` will delete `build/`.
Did you mean to suggest saving the xgcc dir
* CTO of SPCTNC [130410 07:31]:
> Please help me.
>
> - How can I fix the problem.
It sounds like you have a RAM init problem (e.g. your RAM is not
working) because the chipset (945GC) is slightly different than
the other 945 variations that we have supported (just a guess)
> - How can I fix g
* Paul Menzel [130409 00:51]:
> Dear coreboot folks,
>
>
> if somebody is bored ;-), here is the output of Cppcheck for cbfstool to
> fix. :P
Since you already started looking into the issue, maybe you can save the
rest of us some time by following through with it yourself. A smart person
once
* Pradish M P, ERS, HCLTech [130409 10:00]:
> Dear Coreboot Folks
>
> I see that this issues is still not resolved, can you guys give me some steps
> so that I can do those changes in my local copy
> And build libpayload.
>
>
> Regards
> Pradish
Please take a look at http://review.coreboot.or
Hi Paul,
* Paul Menzel [130407 02:30]:
> In #coreboot on irc.freenode.net, phcoder wrote the following.
>
> • possible LZMA bug trigger is that GRUB uses 2 chunks
> • I suppose that some variables aren't reset properly between chunks
Thanks for this analysis. Looking at the code, I found one pr
It looks like grub returns from execution. Probably because it's unhappy about
something ..
Were you able to use the same payload, say, in qemu?
On Apr 5, 2013, at 16:42, Paul Menzel wrote:
> Dear coreboot folks,
>
>
> on the ASRock E350M1 I build coreboot (hash 44af3db) with the VGA ROM
* Paul Menzel [130402 12:16]:
> Dear coreboot folks,
>
>
> for example the patch adding the spkmodem console [1] is currently not
> build tested as it is disabled by default.
>
> Could we put a `.config.jenkins` file into the repository where more
> stuff is enabled so it gets tested too.
Abu
* Patrick Georgi [130403 13:47]:
> Am 02.04.2013 12:11, schrieb Paul Menzel:
> > if I am not mistaken, all programs under `utils/` are currently not
> > built tested. Could that be changed, please? Maybe the following script
> > could be integrated somehow?
> >
> > $ for s in util/*; do c
* Stefan Tauner [130402 16:50]:
> Hi,
>
> please make Patrick and me (or at least him :) a (coreboot) wiki admin
> so that we can delete obsolete pages, thanks.
Hi Stefan!
done.
Stefan, too.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
* Kevin O'Connor [130323 18:21]:
> I definitely appreciate this change. Thanks!
>
> I think moving the automated "coreboot tracker "
> emails off the list would be an improvement as well. :-)
>
> -Kevin
Thanks for you mail, Kevin!
I was thinking about completely disabling the trac based tr
* Peter Stuge [130320 23:15]:
> Stefan Reinauer wrote:
> > > bringing an issues to broader attention or discussion. On what
> > > list should that happen?
> >
> > I think that everybody can make a judgement call on how they would
> > like to implement s
* Paul Menzel [130320 10:13]:
> Dear Stefan,
>
>
> Am Mittwoch, den 20.03.2013, 09:22 +0100 schrieb Stefan Reinauer:
>
> > it has been quite a while since we switched our version control system
> > to git + gerrit, and the incredible amount of emails has alienated o
* Patrick Georgi [130320 11:52]:
> Am 20.03.2013 11:28, schrieb Paul Menzel:
> > 1. Is that even possible for AMD/ATI hardware in their current design
> > with ATOM BIOS and firmware?
> For simply initializing the chip, tracing what the driver does works
> just as well as on Intel chips.
>
> The
Dear coreboot community,
it has been quite a while since we switched our version control system
to git + gerrit, and the incredible amount of emails has alienated one
or another person on this list, unfortunately. But help is finally here:
We switched all gerrit based email traffic over to a new
better and easier for everyone in the
community while maintaining a high quality code base.
--
Stefan Reinauer
Google Inc.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
* Jens Rottmann [130306 17:29]:
> Hi Martin (and all),
>
> I wrote:
> >> You dereference dev in line 132, so if it's really 0,
> >> will you then ever reach this check?? (I don't know if
> >> in romstage *NULL is caught.)
>
> You wrote:
> > yes, if it's 0, we still reach the code. I've changed i
* Vladimir 'φ-coder/phcoder' Serbinenko [130121 15:10]:
> A new version of spkmodem. This one doesn't lose the bit sync even if I
> disconnect the cable for the short time (but, of course data sent when
> no cable is attached is lost)
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko
This i
* Stefan Reinauer [130115 01:25]:
> * Philip Schulz [121211 14:17]:
> > Hi,
> >
> > I'm not subscribed, so please cc: me if you want me to see your email.
> >
> > Peter Stuge wrote:
> > >David Hendricks wrote:
> > >>>> http
* Philip Schulz [121211 14:17]:
> Hi,
>
> I'm not subscribed, so please cc: me if you want me to see your email.
>
> Peter Stuge wrote:
> >David Hendricks wrote:
> http://www.phisch.org/website/efiboot/
Hi Philip,
die Seite scheint nicht mehr verfuegbar zu sein, hast Du sie absichtlich
v
* Rudolf Marek [121105 23:02]:
> Hi
>
> Anyone knows what happen to my attachment?
>
> Trying second time, first time it was also included...
>
> Thanks
> Rudolf
Weird... there does not seem to be an attachment, either time.
Can you upload the patch to gerrit instead?
Stefan
--
coreboot m
101 - 200 of 2491 matches
Mail list logo
