Excellent advice from Ron.
ron minnich wrote:
> The timing is extremely tricky sometimes.
Just to clarify - I think Ron also refers to the timing for software
(coreboot) interacting with hardware (GPU registers) above, and not
so much to timing for how GPU hardware interacts with the panel.
The
Charlotte Plusplus wrote:
> The number match, the EDID is correct, and the panel is properly detected.
> But the internal display still shows a garbled picture with stretched
> letters. I'm out of ideas to get native video init working.
Correct timing/sequencing is just as important as correct
Hi Tobias,
Tobias Wegner wrote:
> 'badusb'
> One of our main security targets is to stop boot sector attacks.
Then use a payload which ignores MBR, such as FILO, Linux or GRUB.
Almost anything except SeaBIOS.
Given your focus on USB, a Linux payload with custom initramfs is
especially
Martin Roth wrote:
> mumble
..
> but it doesn't seem to have any web client or way to work around that.
Are you saying that people with interest in firmware development can
only use web services? I don't understand.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
eche...@free.fr wrote:
> Is it still relevant?
It's still relevant. Registration page is in the works.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Trammell Hudson wrote:
> it makes no sense to me why Intel has it shrouded in such secrecy.
> There is no reason that I can see for it to be undocumented.
Please do read the book. It's quick, you'll need at most three hours.
http://www.apress.com/9781430265719
//Peter
--
coreboot mailing
Trammell Hudson wrote:
> I've experimented with clearing additional bits, from 0x3000 to 0x1
> with the same results. If I were really motivated I might binary search
> how much of the firmware it needs...
That would be interesting.
> > > ME: Current Working State : Recovery
> > > ME:
Trammell Hudson wrote:
> > > My Linux payload initializes without any complaints.
> >
> > Does it stay operational for more than 30 minutes? [...]
> > Does it resume after more than 30 minutes from power-on? And from suspend?
>
> Yes, it has been operational for the past few hours
That's
ron minnich wrote:
> I was thinking that the x230 was so old it would just keep running,
> is that possible? I know that on newer platforms you only get the
> 30 minutes.
AFAIK the very last platform where the ME does not shut down the
platform is Core 2 Duo + GM45 chipset.
>From Nehalem, ie.
Trammell Hudson wrote:
> I'm experimenting with what happens if I remove the ME firmware from
> from the lower SPI flash chip on my Thinkpad x230.
AFAIK the ME will allow the platform to stay on for 30 minutes, and
will then shut it down hard.
This has been observed by people in the coreboot
Paul Kocialkowski wrote:
> I don't expect that end users know what board they should use:
> instead, they know what device they have.
IMO end users aren't the primary target demographic for coreboot.
I think it makes most sense to have the board name in Kconfig and not
a device name if they
Trammell Hudson wrote:
> I'm worried that this introduces a minor, but potential security
> issue for the build process.
Yes, it certainly does.
Noone has spent time on solving the problem so far. Distributing and
using some trust anchors is difficult without adding many dependencies
to the
Mayuri Tendulkar wrote:
> serial is still having some issue and keeps giving out some garbage,
> not sure what is the problem.
Please share an oscilloscope capture image of the very first
character sent out on the TX pin after power-on.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Zoran Stojsavljevic wrote:
> (with Intel BIOS Vendors - IBVs helping you)
As far as I know the 'I' in IBV stands for Independent.
Regarding the original problem that the serial port output is
garbled, please share a scope capture of the UART TX pin from
power-on to get further help with
Anthony Martin wrote:
> what's the best way to attach to the WSON without desoldering it?
> I don't really want to remove it but I will if necessary.
Try soldering wires to the pads on the mainboard, but be prepared that it
might not really work out.
The WSON packages usually have an exposed
Patrick Rudolph wrote:
> The easy way is to use 2G.
Do this now.
> The preferred way would be to mimic mrc behaviour and reboot after
> finding the correct size.
As Ron writes, I don't think it's neccessarily preferable to do
something significantly more complex, if it isn't actually
Hi Arthur,
Arthur Heymans wrote:
> modifying cmos.default and the northbridge code
This is not so easy because it is probably important to ensure
backwards compatibility and there is no infrastructure in place
to do so.
Expect a few man-months of work and another few man-months of
work with
David Griffith wrote:
> Is there any interest in having the Coreboot build process downliad
In general I think it's important to reduce the number of downloads
during coreboot builds to zero.
Downloading needs to be managed separately from building.
//Peter
--
coreboot mailing list:
Hi,
David Griffith wrote:
> > The first flash was successful, as you are clearly using coreboot. :)
> >
> > It's important that you flash again. Now that you have coreboot just
> > run flashrom to write the coreboot.rom. Set the BUC.TS bit
> > appropriately, otherwise your machine will not boot
David Griffith wrote:
> lenovobios_firstflash and lenovobios_secondflash scripts
Please do not confuse coreboot with libreboot. Instructions for/about
libreboot are specific to that project, and nothing that the coreboot
community can support you with.
> Did I actually succeed in flashing my
Daniel Kulesz via coreboot wrote:
> my X60 supports C4 although it also seems to consume way too much power.
That platform has at least one significant power saving issue open,
which I think is no longer too well understood by the active folks.
It also involves power saving states, but I don't
Aaron Durbin via coreboot wrote:
> I feel like we likely want to define a ACPI table which has the
> coreboot specific data we care about:
> 1. coreboot tables base address and size.
Yes, unless the kernel absolutely can not find them any other way.
> 2. console base address and size.
> 3.
Paul Menzel wrote:
> If it is not documented, where should it be?
I think it's up to Stefan to decide if it should be at all, and how.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Hi guys,
(I have a server problem but am sortof recovering.)
ron minnich wrote:
> Do we have any record as to how uniform, e.g., the x220 experience
> has been?
This is an important question. It comes down to the mainboard of course.
Judging from the schematics and hardware in the wild there's
benoit wrote:
> FYI, I activated the SERIRQ in file
> src/soc/intel/fsp_baytrail/southcluster.c by defining SETUPSERIQ and
> CONFIG_SERIRQ_CONTINUOUS_MODE in my Kconfig in my mainboard folder.
>
> I can confirm that all the LPC stuffs are working well. (Accesses + IRQs)
Good news! Thanks for the
Rafael Machado wrote:
> I'm trying to understand the boot processo of an old computer I have,
How old? Which processor does it have?
> Does this mean the first instrucion on the firmware image is at BIOS
> top - reset vector ? (0x - 0xfff0)
Did you disassemble a coreboot.rom file
KR Tejeda wrote:
> since I wiped the hard drive and since I no longer have DVD support
> via coreboot
Why do you say that? If you are using SeaBIOS as payload it should be
happy to boot from optical media.
> I cannot seem to restore the stock bios rom from the HP site in any
> reasonable way.
Alex G. wrote:
> Gerrit is open for business 24/7
Yes. And consistently making our codebase better rather than worse is
the responsibility of every developer and reviewer. So fun!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ron minnich wrote:
> > > nobody cared enough to really do the work
> >
> > That's the problem - not the solution. Don't build infrastructure to
> > support complacency, build infrastructure to support desirable activity.
>
> I'm not even sure what this means :-)
It means that code needs to be
ron minnich wrote:
> nobody cared enough to really do the work
That's the problem - not the solution. Don't build infrastructure to
support complacency, build infrastructure to support desirable activity.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Julius Werner wrote:
> > When designing CBFS we definitely did have fixed locations in mind.
>
> Sure, I'm definitely not trying to argue that... I'm just saying that
> I think this should change if we have a cleaner option. The old CBFS
> has done a good job for a long time, but it was designed
Patrick Georgi wrote:
> I'm looking for an approach to make building Chrome OS style coreboot
> images easier to do with regular coreboot tools, instead of the rather
> large post-processing pipeline we have in the Chrome OS build system.
When designing CBFS we definitely did have fixed locations
Kevin O'Connor wrote:
> The 1.9.0 version of SeaBIOS has now been released.
Do we want to bump the coreboot stable version? Maybe someone already did..
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Please don't post disassembly of code from outside the project. Thanks.
panic wrote:
> I have some difficulties to understand what is done
Welcome to x86 firmware. Some day you may even grow to appreciate
that feeling.
> Is there a way to find out what these addresses are used for?
You have
Carl-Daniel Hailfinger wrote:
> Who else is coming?
I'll be at FOSDEM but will be running around like crazy most of the
time, probably only stopping by the coreboot+flashrom table(s) to
deliver some beverages. :)
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Iru Cai wrote:
> Can I use proprietary vendor tools like winflash or a vendor BIOS
> update disk to flash coreboot?
In general no.
> I don't think it possible but I can't find a reason to explain,
Vendor tools try to ensure that you will only flash an image which is
known by the vendor to be
Martin Roth wrote:
> Trac and Apache Bloodhound were also initially on my list, but I
> removed them due to Patrick's comments.
FWIW I'd be happy to host a Trac instance for coreboot. But I'd
rather that lynxis runs a redmine, so that I don't have to. ;)
//Peter
--
coreboot mailing list:
Alex G. wrote:
> >> users of AGESA can continue to contribute and work on the codebase.
> > ... and diverge...
>
> And that's expected. Convergence is a dream.
I disagree. I think it's a goal rather than a dream.
> AGESA boards use BuildOpts for configuration, and not much
>
Alex G. wrote:
> >> branches are where commits are pushed to die.
> >
> > Yes, this is a very important point, and is why I don't support Alex'
> > proposal of moving some things to live only on a branch, and not on master.
>
> So, tagging and removing is better than a branch where people can
>
Patrick Georgi wrote:
> we carry the SPD data in coreboot.
..
> Currently, they're stored in a hexdump format
..
> I see essentially two ways out of this
..
> We could build our own tool to parse hex files and dump binary,
If we create a tool for this process I think we can find a better
"source"
ron minnich wrote:
> Build the tool in go.
I have to disagree with that. We want to keep dependencies few and small,
neither of which is really true for Go.
Hammer and nail..
> It's trivial.
I think that's true regardless of which tool we use.
//Peter
--
coreboot mailing list:
Aaron Durbin wrote:
> > I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)
>
> I don't believe JEDEC has a format. And the one thing missing here is
> that there is no standard way of distributing these files. In fact,
> I've mainly seen spreadsheets as a form of distribution
Patrick Georgi wrote:
> 2015-10-23 17:48 GMT+02:00 Peter Stuge <pe...@stuge.se>:
> > Code and data in mainboard directories for components which are not
> > the mainboard.
> In this case, they _are_ "the mainboard" just like magic numbers for
> USB trac
Aaron Durbin wrote:
> This one's for Ron.
En guard!
$ wc -c -l spd.*
81 1462 spd.c
100 1629 spd.go
$
//Peter
#include
#include
#include
static unsigned char spd[256];
int readhex(const char *filename) {
int pos = 0, i, end;
unsigned int n;
char buf[128], *hex;
Martin Roth wrote:
> I like what I understand Nico's proposal to be: Store the SPD data as
> a c struct with all of the different JEDEC fields broken out.
Yes, fun and games aside, this is definitely the way to go.
Thanks Nico for showing us the forest behind all the trees.
//Peter
--
Patrick Georgi wrote:
> The paragraph in question is:
>
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc.
>
>
> Since the GPL is fairly well-known (incl where to find it), and our
> tree
Hi,
Iru Cai wrote:
> I've been testing the Lenovo T420 port recently, and now I can
> install an Ivy Bridge processor and run fine on Linux(except some
> thermal issues).
That's pretty nice I think.
> However, the native graphics initialization doesn't work properly
..
> I don't know if
Hi all,
Timothy Pearson wrote:
> Raptor Engineering is pleased to announce the public release of the ASUS
> KGPE-D16 support code, including support for Family 15h processors!
..
> Raptor Engineering would also like to thank Minifree Ltd. for sponsoring
> this release.
I would like to take this
Vladimir 'phcoder' Serbinenko wrote:
> Reminder, please write me if you want any of this. Right now only
> Ron Minnich and echelon have ordered. I've added pictures at
> http://coreboot.org/Coreboot_conference_Bonn_2015
The goodies look really great! :) How many cups, plates and magnets
are
Vladimir 'phcoder' Serbinenko wrote:
> > The goodies look really great! :) How many cups, plates and magnets
> > are there?
>
> Other than the ones already spoken for, I have:
> 8 L T-shirts
> 1 XL
> 3 white cups
> 1 x Black, yellow, orange and pink cup
> 6 x plates
> 3 x baseball cap
> 9 x
Hi,
Iru Cai wrote:
> So can some one give me some instruction on devicetree.cb file?
It sounds like it has to be hand-crafted in your case.
> And another thing, how can I submit the code to the coreboot repository?
By creating an account at http://review.coreboot.org/ and pushing
commits
Hello,
蝈蝈 wrote:
Now I have a problem about how to build a gerrit plugin to display
all the projects' name. Could you help me?
Sorry, I don't think anyone here can help. I suggest to search for a
group with focus specifically on Gerrit and to try asking there.
//Peter
--
coreboot mailing
Ron,
ron minnich wrote:
I think this could prove to be a very important new direction for coreboot,
I agree.
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a
subdirectory lost somewhere in the already too big coreboot
ron minnich wrote:
If people feel strongly enough about this then we can do an
external repo for now.
Nico, do you want to set up a github repo
There are more options than the coreboot repository and github.
If Nico is willing to push the code to coreboot.org then I think a
separate
Danny Milosavljevic wrote:
6DET64WW/$01B9000.FL2 (47 Byte differ
Is that a blob?
want to .. use libreboot
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Paul Menzel wrote:
this week the Gerrit review score -2 was discussed again in
#coreb...@irc.freenode.net.
Several times, during the last two years, a review score of -2 was
given and dealing with it caused a lot of discussion and friction.
..
To formalize that a little bit
I think the
Patrick Georgi wrote:
I decided to take a random commit and call it ‘4.1’.
Well done. Thanks!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Nico Rikken wrote:
- Intel
- Management Engine
- Advanced Management Technology
I think you are confusing these two terms. Please read the book
http://www.apress.com/9781430265719 to learn about Intel's platform
security technology.
//Peter
--
coreboot mailing list:
Bill Toner wrote:
options .. for bringup and lowlevel firmware and os driver debug?
printf() over the channel of your choice (there are a few) and bus
analyzers.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Francis Rowe wrote:
Thoughts?
The last thing coreboot needs is random people putting random stuff
into the wiki. Knowledgeable developers who can create the most
useful content are very busy all days of the week.
//PEter
--
coreboot mailing list: coreboot@coreboot.org
Xan wrote:
I think that, as a customer
This is the problem. You have already spent your money, which as a
customer is the only leverage you have.
I could express my concern and my opinions about the fact
Doing that after you have already paid will not do much good.
I have a problem to
eche...@free.fr wrote:
Tank you Peter for trying to find some space for coreboot at CCC2015
(I remeber that you were involved in the organisation of OHM2013, is
it also the case for CCC2015?)
I'm helping set up an event GSM network like I did at OHM2013.
I hope that many corebooters could
eche...@free.fr wrote:
Quick question : does someone from the coreboot community plan to
come to the Chaos Communication Camp 2015?
I plan to go there, I guess a few others will also go.
do you think that we can piggyback this event to organise some kind
of mini-hackaton for coreboot?
I
black...@crimson.ua.edu wrote:
While executing “make crossgcc-i386” within the coreboot folder,
the make throws this error:
configure:3602:
/home/juan/fsp_coreboot/coreboot/util/crossgcc/build-i386-elf-gcc/./gcc/xgcc
Julius Werner wrote:
I'd also like the interface to be friendlier. What granularity is
actually supported for the option? I doubt that it's single bytes?
Maybe make it decimal kb? The default value depends on ROM_SIZE, right?
I would very much prefer it to stay byte sized. This makes
Julius Werner wrote:
What section should
(0x40) Size of CBFS filesystem in ROM
be moved to?
The option is closely related to ROM_SIZE, so maybe put it under
'Mainboard --' with that?
Sounds good.
Furthermore, should it even be visible or be hidden as an expert
L.R. D.S. wrote:
There any coreboot VIA notebook?
No.
The VIA website [3] list some models, many with supported specs
(CPU C7-M ULV and Chipset VIA VX800).
So someone with an interest (you) could get one and submit a patch to Gerrit.
//Peter
--
coreboot mailing list:
pub...@autistici.org wrote:
Can support be added for Hewlett-Packard's Pavilion dv7-6025eo laptop
computer? Details:
Probably yes, but nobody will do it for you. You'll need good
development and debugging tools and 6-60 man-months of work
depending on your background.
//Peter
--
coreboot
Alexandru Gagniuc wrote:
figured out how to fuse the PCH to disable ME
Please read ISBN 9781430265719.
The ME firmware controls the host CPU reset.
//Peter
pgpoayzdluEOZ.pgp
Description: PGP signature
--
coreboot mailing list: coreboot@coreboot.org
FWIW, I dislike GRUB for several reasons; it does far too much to be
an improvement over a minimal payload and it does far too little te
be an improvement over a Linux payload.
It duplicates lots of work already exists in other places and it has
probably also duplicated some of the bugs.
Not to
Iru Cai wrote:
I read previous config files from board status, and configured my Lenovo
ThinkPad X220 with CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT and
CONFIG_VGA_ROM_RUN.
Unless you know why exactly you should do things any other way, always
let SeaBIOS run option ROMs, never coreboot.
//Peter
Kuzmichev Viktor wrote:
Yes, I do. With the vendor BIOS it looks as follows:
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 1
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root Port 2
Berth-Olof Bergman wrote:
Personally I don’t understand why boot loaders insist on writing
the code the way they do. There is BIOS services
I'm afraid you've missed the whole point of coreboot; to break away
from the extremely limited and technically nonsensical legacy BIOS.
//Peter
--
Hej Berth-Olof,
Berth-Olof Bergman wrote:
How about making flashrom available for Bay Trail architecture?
I think there is interest in that.
You can go ahead and send the neccessary patches.
Thanks
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Kevin O'Connor wrote:
I can see this being a source of usability issues. Is there any way
to reasonably generate the message from the scan code?
It's a pain to attempt to auto-generate the message.
Could an incorrect message at least be avoided?
How about crowdsourcing scan code
Mario Goljak wrote:
I've been following coreboots official guide
http://www.coreboot.org/Board:lenovo/x230 but I'm unable to read bios chip
content with the buspirate and flashrom. I've connected it according to
this datasheet
Paul,
Paul Menzel wrote:
I don’t think Google has understood how much power they have over
Intel with their Chromebook and Chromebox success.
It's inapppropriate to speak on behalf of others, please don't do that.
The facts are that neither you nor I know anything about what Google
might or
eche...@free.fr wrote:
So we don't have the right to even ask or wonder why is this so secret?..
Everyone has the right to ask and wonder anything in the free world.
We are all curious to learn, but there are always better ways to learn,
and worse ways.
I think the engineering that Google puts
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 me
I think many individual contributors can't afford cross continent travel.
Even if
Hi,
Marc Jones wrote:
I recently tried running coreboot + SeaBIOS + SYSLINUX under QEMU (as
suggested on the Easy tasks page [5]), and it seems to work alright -
but is it possible to find a SYSLINUX ELF image so I can eliminate
SeaBIOS?
I don't know if anyone has made a SYSLINUX elf.
ron minnich wrote:
IANAL (I'm not giving legal advice, yada yada), but I don't think that is
how this works. Companies you don't work for can't force you to do X or
prevent you to do Y with their files.
Copyright statements are pretty complicated, and I am not sure you are
right. I am
ron minnich wrote:
In the past Ron also disagreed on changing headers by Samsung – taken
from U-Boot I think – saying their lawyers drafted those and therefore
it should stay that way.
That's right, you don't get to change other people's headers, especially
when the headers are created
Emilian Bold wrote:
It seems that Coreboot doesn't have reproducible builds yet.
That is correct.
Ideally
Yep.
Is there anyone willing to help me with this (or already working on this)?
Yes, I am willing to help you review your patches when they are in
Gerrit.
//Peter
--
coreboot
Stefan Tauner wrote:
logo with half of the rotation attached (15° instead of 30° backwards).
I really like this one. Nice!
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ron minnich wrote:
logo with half of the rotation attached (15° instead of 30° backwards).
I really like this one. Nice!
Very nice. I like the one on the left best.
Same here.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Carl-Daniel Hailfinger wrote:
two logos
I'd recommend avoiding that. It becomes confusing for people.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Stefan Tauner wrote:
soic8_30degrees is really good. I would only suggest to perhaps
rotate
clockwise
around the X axis a little bit,
to view the chip more from the side, rather than from above.
I am not sure where your X axis and origin is, but I have rotated
it 30° back
Stefan Tauner wrote:
What do you think about my suggestions and the whole matter?
soic8_30degrees is really good. I would only suggest to perhaps
rotate around the X axis a little bit, and to either make the
lightning bolt smaller or perhaps just remove it, because the
connection between
Peter Stuge wrote:
Stefan Tauner wrote:
What do you think about my suggestions and the whole matter?
soic8_30degrees is really good. I would only suggest to perhaps
rotate
clockwise
around the X axis a little bit,
to view the chip more from the side, rather than from above.
//Peter
Julius Werner wrote:
We maybe can expand it to have informations like time-out or
retry count for a given segment.
One word of caution I'd like to add here is that making this API more
complex/powerful requires significant effort, now and in the future.
Not if the architecture is any
Werner Zeh wrote:
We already have my approach with the new interface.
We maybe can expand it to have informations like time-out or retry
count for a given segment.
I think this is a really good idea.
I also think that this structure applies to SPI as well.
//Peter
--
coreboot mailing
Carl-Daniel Hailfinger wrote:
fork?
..
I hope this explains why quoting without context should not be done.
Did you just hijack (or fork, as Alex likes to call it) the thread?
No, I was just replying to you, and by selectively quoting you I even
kept the topic you were talking about.
Carl-Daniel Hailfinger wrote:
fork?
a fork would be a good thing
Hey look, I can quote without context, too!
I hope this explains why quoting without context should not be done.
Did you just hijack (or fork, as Alex likes to call it) the thread?
//Peter
--
coreboot mailing list:
Alexandru Gagniuc wrote:
fork?
If you feel that it would be good then please do not waste any more time.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Anthony Martin wrote:
Peter Stuge pe...@stuge.se once said:
Alexandru Gagniuc wrote:
fork?
If you feel that it would be good then please do not waste any more time.
At least we know malefic goading is permitted by the code of conduct.
That's confusing to me. I'm not being
Alexander Couzens wrote:
- refactoring amd code
I think this is an interesting project! As I understand it, the idea
is to refactor the AMD-contributed AGESA trees into our own code.
- create an opensource firmware for some Thinkpad (H8S based)
EC firmware, just to clarify.
- building a
Alexandru Gagniuc wrote:
Alexandru Gagniuc wrote:
fork?
Peter, you misquote me.
That *is* the last line of your mail. It's just one word though, so
there's no context.
If you feel that it would be good then please do not waste any more time.
And then you misinterpret what I say.
benny windolph wrote:
Thanks for the clarification, but is it possible that the coreboot-team
will put this device on its agenda to bring coreboot to the dell sputnik?
It's not likely. If you care about something in open source you have
to do the work. There's nothing wrong with asking someone
benny windolph wrote:
Its absolutely fine if the team wont do it. I am not a developer, i
would rather donate or something. But its okay.
Donations are difficult, but still much appreciated! The scarce
resource is (as always?) development time, unfortunately neither
money nor hardware.
Benny wrote:
is there a chance coreboot comes to the Dell Sputnik (XPS13, L322X1Y1)?
On its own? No, not really. It takes fairly significant development
work, which will not happen by itself. There exists code in coreboot
for similar platforms which may or may not be reusable, beyond that
you're
301 - 400 of 2826 matches
Mail list logo
