Ah, that's what I meant by persistent. Let's take your name and get
rid of mine, and we're still at 2 axes?
ron
On Wed, Mar 26, 2014 at 12:40 PM, David Hendricks <dhendrix(a)google.com> wrote:
> On Wed, Mar 26, 2014 at 12:29 PM, ron minnich <rminnich(a)gmail.com> wrote:
>>
>> I agree with david.
>>
>> Simple classifications are better. I think I found two axes.
>>
>> persistent
>
>
> Add to that "always on" versus "boot/resume path".
>
>>
>> replacable
>>
>> persistent and not replaceable --> this system may not be usable
>> non-persistent and not replaceable --> requires a close look
>>
>> replaceable --> we're ok with enough effort
>>
>> are there more?
>>
>> ron
>
>
>
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
On Wed, Mar 26, 2014 at 12:29 PM, ron minnich <rminnich(a)gmail.com> wrote:
> I agree with david.
>
> Simple classifications are better. I think I found two axes.
>
> persistent
>
Add to that "always on" versus "boot/resume path".
> replacable
>
> persistent and not replaceable --> this system may not be usable
> non-persistent and not replaceable --> requires a close look
>
> replaceable --> we're ok with enough effort
>
> are there more?
>
> ron
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
I agree with david.
Simple classifications are better. I think I found two axes.
persistent
replacable
persistent and not replaceable --> this system may not be usable
non-persistent and not replaceable --> requires a close look
replaceable --> we're ok with enough effort
are there more?
ron
On Wed, Mar 26, 2014 at 9:47 AM, ron minnich <rminnich(a)gmail.com> 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" rating, or at least the numbers. It seems
rather arbitrary. As much as folks dislike binary MRC, for example, I
wouldn't even put it in the same ballpark as the management engine since
the ME is an always-on, persistent, non-ISA blob with similar access
capabilities. Scoring them one point apart at the top of a scale from 1 to
"9000+" seems to diminish those important distinctions.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
In the search for a good LTS (long term support) laptop, I've had to think
hard of which blobs could be consider acceptable, and which would disqualify
candidates. I've made a write-up about this classification here[1].
The idea is simple: find out which blobs would disqualify the machine from
being Respects Your Freedom (RYF) certifiable. RYF capability, in my opinion,
is a very important feature of any laptop which we plan to support for a long
while. A machine as old as the x60 has seen a steady increase in its user base
since the GluGlug has received RYF certification. Almost every week, I see a
few people asking on IRC about how to flash coreboot on the X60, or how to
unbrick it. A number of those people are using the pre-built images supplied
by libreboot. Did I convince you RYF is essential? Maybe not. Is it definitely
desireable. For an LTS candidate, it's pretty darn important.
And while you may not give much importance to RYF, the X60's desirability is
something we want to continue to repeat in the future. There is a niche market
thirsty for this king of thing. That means we must start caring about RYF,
whether you like it or not.
With RYF, there are a number of elements that need to come together in
harmony. I have tried to understand how we, as firmware hackers, could better
accommodate the situation. There is a lot we can do to make sure that a
machine can take the path to RYF certification. I will call that RYF-capable.
Note that "capable" does not necessarily mean "certifiable".
What I mean by "RYF capable" is that it is reasonable for a group of community
hackers to get together and eliminate any offending blobs. This is where the
classification comes in. We need to be able to talk about blobs in terms of
simple criteria. With this classification, all essential blobs must be
reasonably removable.
So, while the RYF-certified machine may have reduced functionality than the
same RYF-capable machine, a machine will never be RYF-certified, if it is not
RYF-capable.
Anyhow, I wanted to ask what you guys think about the classification.
Alex
[1] http://www.coreboot.org/Binary_situation#Classification_of_blobs
Not so long ago, Stefan announced some pretty drastic changes to the project
structure. While I believe he wanted to discuss the direction and find a
mutually agreeable direction, his email still raised the aneurysm level to
over nine thousand.
So, how about we take the good ideas out of there and start putting them in
practice. Today, I'll be focusing on the idea of MAINTAINERS. While it's nice
to jump straight to maintainer trees, that's a long ways away, and I'm not
even sure we reached consensus on it. Couple that with the changes needed to
be done to _both_ gerrit configuration, _and_ gerrit workflow, this matter is
better left for another day.
What we can do, however, is to start assigning maintainership of different
sub-directories. Two ways to do it:
(i) One big MAINTARES file in top-level directory
(ii) One small MAINTAINER file in each directory with an assigned maintainer
Number (i) is human friendly, while (ii) is parser-friendly (I would hope).
Now comes the fun part:
For directories with a maintainer, gerrit implements a MMA criteria. That's
short for "Maintainer Must Approve". People are still welcome to do reviews,
bikeshed, etc, but the maintainer has veto power. For directories without a
maintainer, the old workflow applies (no MMA).
This should reduce confusion from conflicting reviews, and definitely reduce
number of incidents where a patch gets merged with a review from a person who
is not fully qualified to, well, do the review.
Masters, of Gerrit, the pleasure of training gerrit to implement this change
is left entirely to you.
Alex
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is focussed on users (non-developers).
Most coreboot users only have perhaps a few machines that they are
building for.
Maybe even just one.
Yet they are downloading the entire coreboot source tree and selecting
which board they want, configuring it, etc.
My idea:
--> a small set of source files (such as from src/mainboard/vendor/board)
--> a script (perhaps a simple git checkout) which fetches the needed
parts of the source from the main branch, for building that board
--> default/"sane" configurations pre-defined for that board.
Advantages:
--> less headache for developers (user already has most of what they
need, less likely to request support)
--> less to download (less waiting required, especially for people
with slow connections)
Essentially, I have in mind a more "modular" coreboot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTMhFiAAoJEP9Ft0z50c+UTjYIAMXvzhJFEcrNACgqssRfZpzf
Xa3C1WaAI/EByzVl11i2eSFaKipqqzCD/DkHwqroXbszNATqgKXMoYGTy/lSM7zr
j/254QlxMEwd5MA6hmzrJEFFRUW2t/wYGsS48NP5R3YSJlE9Fga1ogvQJg4qgduP
pFmy1i48R+I5O7/SRmaPz1Tprw+q0KaaSF5+elh8Ymq5Zq6zJTu/DSI/mNM6FUjs
VOP+bmq2Yiik8DmgVUjhKKpShd2GIhXatRYSjD5otnBgO9kOss+HXvNnGmRd01YU
I9Fbne1VhOruI3qS8tMmKWcLvbipyoaQ9QgpL+OuotiBdAqufMjvfT7cC9idv0g=
=5YKe
-----END PGP SIGNATURE-----
Allen Yan [mailto:lexkde@gmail.com] wrote:
]Oh, sorry, incorrect address!
]http://www.google-]melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120
]
]TianoCore as Coreboot payload
]JinyiYan
]
]Short description: The combination of coreboot + TianoCore
]is the most straightforward option to provide a complete,
]opensource UEFI environment.
This proposal should mention that only x86 systems will
be supported if that is the case.
To provide a complete, opensource x86 UEFI some items not
listed in this project proposal are needed:
1) UEFI support for writing to flash memory. The UEFI name is
Firmware Volume Block protocol. One module for Intel systems and
another module for AMD systems would probably cover most x86
motherboards. All current open source UEFI solutions use a
substitute that either fails to capture OS writes to UEFI NVRAM
variables, or does not preserve these writes through a power down.
The most visible effect of the substitute firmware volume block
driver is loss of the NVRAM variable that points to the boot
device. When this variable is lost, Linux will no longer boot.
Windows can still boot due to an automatic repair mechanism.
In all cases, the boot order in a multiboot system will be lost.
The use of the substitute firmware volume block driver causes
other limitations such as such as loss of configuration settings.
2) USB OHCI support. Without this the USB keyboard on AMD systems
will not work until after the OS boots.
3) Another missing item is UEFI MP Services. This one might not
be essential. It is needed if UEFI code needs to launch the AP for
such things as gathering SMBIOS data or for setting the SMM base
address register. There is a discussion on the EDK2 Devel mailing
list about the possibility of an open source solution:
https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg06354.html
]Based on coreboot-pkg, the project intends to implement
]some new features like UEFI CBFS driver and a GOP driver
]based on pre-initialized framebuffer.
How will the CBFS Driver be used?
Will the GOP driver support multiple video solutions?
If so, how? If I use a brand XYZ video card how will the
GOP driver find the details of the frame buffer? I know
it is possible because operating systems do it. But the
proposal should explain it for those of us who are not
graphics experts.
]Please complete the standard Google SoC application and project
]proposal. Prospective coreboot GSoC student should provide the
]following information as part of their application. If you are
]applying for a flashrom or SerialICE project use common sense
]when using the template below, this is part of the test. ;)
]
]Name: Jinyi Yan
]Email: lexkde(a)gmail.com
]IM/IRC/Skype/other contact:irc.freenode.net:
] #coreboot, #flashrom nick: Jinyi-Yan
]Web Page / Blog / Microblog / Portfolio:
]Country/Timezone:China/UTC+08
]Normal working hours(UTC): 10:00~16:00
]School:University of Chinese Academy of Sciences
]Expected graduation date: 2015
]
]
]coreboot welcomes students from all backgrounds and levels
]of experience. To be seriously considered for coreboot GSoC,
]we recommend joining the mailing list and IRC channel.
]Introduce yourself and mention that you are a prospective
]GSoC student. Ask questions and discuss the project that
]you are considering. Community involvement is a key
]component of coreboot development. By the time you have
]submitted your application, you should have downloaded,
]built a and booted coreboot in QEMU, SimNow, or on real
]hardware. Please, email your serial output results to
]the mailing list.
]
]The following information will help coreboot match students
]with mentors and projects.
]
]
] Please comment on your software and firmware experience.
]
] I used to be a mainboard BIOS engineer in ASUS Technology
]Suzhou Co., Ltd for about two years (2007.7~2009.2). When at
]AsusTek Suzhou, my work is mainly responsible for bios porting
]and fixing bug. There were four mainboards P5KPL-S, P5QL-E,
]P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core.
] In the second half year of 2008, I worked on pre-development
]of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module
]and added NTFS support(read only) for AutoRecovery module using
]AMI Apito platform (based on EFI).
]
] The most important is that I still have plenty training
]materials(EFI training and hardware initialization,
]kinds of intel chipset datasheet before 2009) from the company.
If the intel chipset documents are not publically available
you should not list them in your proposal. The reason is that
companies sometimes ask engineers to destroy non-public documents
once they leave the company or finish the project.
]They can let me grasp the concepts that I‘ve forgot quickly and
]do proper choice.
]
]
] Have you participated in the coreboot community before?
]
] No.
]
] Have you contributed to an open source project? Which one?
] What was your experience?
]
] Not happened before.
]
] Have you built and run coreboot? Did you have problems?
]
] Yes. With SeaBIOS as payload, It's a easy job.
]
] Did you find and fix a coreboot bug? Did you send a patch to
] Gerrit? Please provide a link to the Gerrit page.
]
] Not now!
]
] Please provide an overview of your project (in your own words).
]
] Coreboot-pkg provides a nice start. In the project idea
]webpage, there lists two possible tasks, one is a minimal
]GOP driver, the other is a CBFS EFI driver. I consider the
]“minimal GOP driver” is more hardware related but “CBFS EFI
]driver” is less hardware related or simpler.
]Considering the GOP driver can be workaround by integrating
]SeaBIOS as CSM in Tianocore payload,
A much simpler INT10h video solution is:
DuetPkg/BiosVideoThunkDxe/BiosVideo.inf
(with some available bug fixes and enhancements applied)
There is no need for full CSM.
]then maybe I should work out the simpler tasks “CBFS” driver first.
]
] As mentioned in webpage “www.coreboot.org/TianoCore”,
]the GOP driver piggybacks on the coreboot framebuffer.
]So, it's based on the VGA BIOS, but provide a new interface
]other than int 10h.
So it sounds like coreboot will install the legacy video
option rom and then make INT10h calls to get the frame
buffer info. If the day ever comes where legacy video
option roms are no longer shipped, this GOP driver will
no longer work. Yet that will be the time when a GOP
driver is most needed. Why not extract and use the OEM
GOP driver? What problem will writing the piggyback
GOP driver solve?
] In my view, this project may suffer less issues caused
]by SB chips, CPU and MRC code because coreboot would run
]well in supported mainboard.
] That is very nice. In my mind, the Tianocore payload
]should be start execution from DXE phase. For now, I don't
]know exactly the details that how coreboot pass control to
]Tianocore DXE phase. In my mind, in Tiano, the original
]PPI phase will send proper information to DXE through hand
]off block (HOB) in the system memory.
]
] Provide break down of your project in small specific
]weekly goals. Think about the potential timeline.
]
] 1. How will you accomplish this goal? What is your
]working style?
] a) building a test enviroment.
Consider stating if the build will work from Linux,
Windows, or both.
] Both emulator and real mainboard are needed.
It is good you specifically mention real mainboard.
It is usually more work than an emulation only boot.
But then the question becomes which mainboard(s)?
For example, AMD mainboards use OHCI for the low speed
USB used with keyboards. Intel uses UHCI. Open source
EDK2 UEFI supports UHCI but not OHCI. As a result,
open source UEFI does not support the USB keyboard on
AMD systems unless you pass it through a USB2.0 hub
as a work around. There are also some relatively easy
to fix problems when EDK2 is used on AMD boards.
]As Vladimir's suggestion, I'd better
]use GRUB's ability to chainload payloads for testing. So,
]the coreboot and the tianocore payload are separated.
]Maybe I should use EFI shell AP to test the drivers.
] b) bonding with the cooreboot communities. Patrick
]Georgi, Stefan Reinauer, David Woodhouse and Vladimir
]Serbinenko seems main contributor to coreboot-pkg.
]
] c) Grasp the code base of Coreboot interface to
]payload, CBFS and the knowledge of UEFI in the community
]bonding period.
]
] d) coding, testing, coding... get CBFS driver worked
]on the emulator before mid-term evaluations.
]
] e) get the code worked on a real coreboot mainboard.
]If everything goes well, the GOP driver would be checked.
]
] I think continuous working time is important for me,
]because I want to grasp the whole image of the project
]at first, then begin to read corresponding datasheets
]and code base carefully and write some test at the same
]time. I'd like to work from 6 p. m.(UTC 10) to 12 p. m.
](UTC 16) for GSoC 2014 from Monday to Saturday and go on
]programming in the day on Sunday.
]
] 2. Explain what risks or potential problems your
]project might experience.
] I concern about the proper debug method and test
]environment. Debug information output from serial port
]is nice. Maybe the debug card is also needed. About
]test environment, I need to purchase a coreboot
]mainboard and a few flash chips. As suggestion from
]IRC(phcoder-1creen), I should run in simulator first.
] The potential problem is lack of document if I
]failed to test the project on the real hardware. I
]also notice that there's little training materials
]for coreboot, but not a serious problem.
]
] 3. What would you expect as a minimum level of
]success?
] 1) get a worked CBFS driver on emulator. 2) Make
]windows load with tianocore.
There is already a coreboot UEFI payload that boots
Windows and Linux:
http://notabs.org/coreboot/duet-payload/index.htm
So goal 2 doesn't break any new ground.
] 4. Do you have a stretch goal?
] Implementing a GOP driver that piggybacks on the
]coreboot framebuffer or writing some training
]materials for coreboot.
]
] What are your other time commitments? Do you have
]a job, classes, vacations? When and how long?
]
] I have a three weeks vacations. During that I
]could contribute more then 8 hours a day.
On Tuesday, March 25, 2014 02:14:12 PM ron minnich wrote:
> On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks <dhendrix(a)google.com>wrote:
> > On Tue, Mar 25, 2014 at 12:17 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
> >> On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote:
> >> > On Tue, Mar 25, 2014 at 10:57 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
> >> Construction quality?
> >
> > Subjective. IMO it's nice.
>
> It's wonderful IMHO.
>
This is turning interesting. Any chance a handful of non-commercial coreboot
entities could get a few early samples?
> I understand the ARM limitations but the EC on those AMD platforms bothers
> me.
>
If it's usable as a day-to-day laptop, the ARM limitations are irrelevant.
Alex
On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks <dhendrix(a)google.com>wrote:
> On Tue, Mar 25, 2014 at 12:17 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
>
>> On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote:
>> > On Tue, Mar 25, 2014 at 10:57 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
>>
>> I'm assuming BLO is not persistent.
>>
>
> It's been a while since I've looked closely at it, but I think it does
> remain persistent in the resume path.
>
I think you're right.
>
>> Construction quality?
>
>
> Subjective. IMO it's nice.
>
It's wonderful IMHO.
I understand the ARM limitations but the EC on those AMD platforms bothers
me.
ron
