david, just keep in mind you can use coccinnelle to 'strip mine' data
structures and turn struct members to global variables (as well as all
uses), change function parameters, delete functions you don't want,
etc. Do the maximum possible amount of changing with coccinnelle and
you have a more repeatable process.
You can see all my scripts in i915tool, and they could do much more.
ron
On Sun, May 26, 2013 at 6:39 AM, Cristian Măgherușan-Stanciu <
cristi.magherusan(a)gmail.com> wrote:
>
> Hi,
>
> Please see the attached files, gathered while running the proprietary
BIOS.
>
> Cheers,
> Cristi
Hi,
Is the W25X64 chip physically accessible with exposed surface-mount pins?
A Bus Pirate may be helpful/necessary to gather additional info and to
reprogram the chip.
Photos from an X201i + Bus Pirate:
http://gchriss.tumblr.com/post/50463745980/a-closer-look
Sincerely,
George
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Hello Students,
Congratulations, your projects have been selected for coreboot GSoC 2013.
We are now in the bonding period where students get to become more
familiar with the community and mentors. Students should feel free to
contact any mentor, student, or the community in general about their
project or general coreboot development. Please start a dialog with
your assigned mentors in IRC and email.
Student - Mentors
----------------------------
Kyösti Mälkki (kmalkki) - Marc (marcj), Aaron (adurbin)
Stefan (stefanct) - Carl-Daniel Hailfinger (carldani), David Hendricks
(dhendrix)
Alex Gagniuc (mrnuke) - Peter Stuge (CareBear\) Josh Roys ()
Alex () - Patrick Georgi (patrickg), Martin Roth (martinr)
Ayush Sagar() - Stefan Reinauer (stepan), Dave Frodin (sage_dave)
Standby mentors:
Ron (rminnich), Jason Wang(), Rodolf Marek (ruik)
Patrick will send you each student a coreboot blog account. By June 7,
You should post an introductory blog post to introduce yourself and
your project. Maybe make some comments on things you have learned
since the application period.
Let me know if you have any questions.
Regards,
Marc
--
http://se-eng.com
On Mon, May 27, 2013 at 9:45 PM, David Hubbard
<david.c.hubbard+coreboot(a)gmail.com> wrote:
> 1. How hard would it be to import the kernel code into coreboot directly?
>
don't. You should do a lot of extraction using coccinelle. And even
then, there's lots of work to do. I hope to start commits next week
and hopefully this will provide some ideas.
> The ACPI init at the end could be skipped for a first attempt.
yeah.
>
> It would be some work to find the kernel APIs used in the radeon code and
> produce suitable glue for coreboot.
yes, do don't do that. The kernel APIs are not right for firmware.
> 2. Do coreboot developers have contact with the radeon driver developers? A
> little nudge from time to time could keep a project like this on track.
anyone?
>
> 3. It feels wrong to add so much code to coreboot.
So, don't add it. The i915 support is slowly boiling down to a few
hundred lines and that should be your goal. Also, the kernel uses
generic code to switch to device specific functions. That makes sense
for a kernel, because it boots on many chipsets and many vga devices.
It makes no sense for firmware, because we have so much we already
know -- what chipset, what vga, etc.. Remove generice code and create
device specific functions with a reasonable API.
> With 20/20 hindsight,
> this could be one of UEFI's downfalls, namely making the pre-boot
> environment into an entire kernel.
I've been saying this for 14 years ... :-)
But they are not listening of course. EFI is basically a not very good
OS that is wanting to be a boot loader. It never made much sense
technically but it seems to have done well politically.
>
> Is a modular approach better? A payload to modeset or some sort of driver
> model would be nice.
No, what's best is a simple set of functions with a simple API. See
superio for example. Or give it 2 more weeks and see what is coming
:-)
ron
Hi all,
I read the kernel sources today, looking for a way of doing native init for
AMD boards like the F2A85-M.
My CPU has a Radeon HD 7660D built in; lspci says
00:01.0 VGA ... Trinity [Radeon HD 7660D]
drivers/gpu/drm/radeon/radeon_asic.c - int radeon_asic_init() handles
Trinity like this:
case CHIP_ARUBA:
rdev->asic = &trinity_asic;
/* set num crtcs */
rdev->num_crtc = 4;
break;
trinity_asic.init = cayman_init(), which can be summarized as
- radeon_get_bios()
- radeon_atombios_init()
- if (!radeon_card_posted()) atom_asic_init()
- bring up device: r600_scratch_init(), radeon_surface_init(),
radeon_get_clock_inf()
- bring up memory: evergreen_mc_init(), radeon_bo_init(), r600_ring_init()
- cayman_startup(): load ucode, ...
Once cayman_init() and radeon_asic_init() are done, control goes back to
drivers/gpu/drm/radeon/radeon_kms.c - int radeon_driver_load_kms(),
with:
r = radeon_modeset_init(rdev);
if (r) dev_err(&dev->pdev->dev, "Fatal error during modeset init\n");
/* Call ACPI methods: require modeset init
* but failure is not fatal
*/
if (!r) {
acpi_status = radeon_acpi_init(rdev);
if (acpi_status) dev_dbg(&dev->pdev->dev, "Error during ACPI methods
call\n");
}
My questions are:
1. How hard would it be to import the kernel code into coreboot directly?
The ACPI init at the end could be skipped for a first attempt.
It would be some work to find the kernel APIs used in the radeon code and
produce suitable glue for coreboot.
Comments welcome on the insanity of this proposal :)
2. Do coreboot developers have contact with the radeon driver developers? A
little nudge from time to time could keep a project like this on track.
3. It feels wrong to add so much code to coreboot. With 20/20 hindsight,
this could be one of UEFI's downfalls, namely making the pre-boot
environment into an entire kernel.
Is a modular approach better? A payload to modeset or some sort of driver
model would be nice.
Regards,
David
Hello,
I have no idea of existing efforts on this board, but there is already
support for the Exynos5 ARM chips from Samsung, done starting from uBoot
support code for the Chromium snow laptop.
A few hours ago the people that ported coreboot on ARM for the Exynos5
acquired some Beaglebone Black boards and will eventually attempt to port
coreboot on those real soon, also starting from the uBoot support code for
that board.
The goal is to iron out any Exynos5-isms from their ARM port. You should
definitely give it a try and join this effort, the most ARM boards out
there are supported, the merrier.
Cheers,
Cristi
On Mon, May 27, 2013 at 1:08 PM, Wolfgang Kamp - datakamp <
wmkamp(a)datakamp.de> wrote:
> Hi,****
>
> ** **
>
> are there any plans in the coreboot community to support the Freescale
> i.MX6 ARM Cortex A8 processor in the near future.****
>
> The new wandboard platform (http://www.wandboard.org) could be
> interesting for this.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Wolfgang Kamp****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Hi,
are there any plans in the coreboot community to support the Freescale i.MX6 ARM Cortex A8 processor in the near future.
The new wandboard platform (http://www.wandboard.org) could be interesting for this.
Regards,
Wolfgang Kamp
Hi,
I am working on a Micros WS4 that's built around the AMD SC3200
(the GX1 and companion chip integrated into one silicon) and boots
Windows CE from ROM. I need to turn it into a generic purpose PC,
so I am trying to extend Coreboot to handle it. The SC3200 datasheet is at
http://www.manualslib.com/manual/5433/Amd-Geode-Sc3200.html
Since Coreboot already supports the GX1, I hope it won't take too much time
to support this board.
The attached patches are the first steps to allow hardware discovery on this machine.
The first patch adds mingw32ce support to superiotool:
- direct inb/outb allowed under WinCE without iopl/ioperm
- to handle I/O, sys/io.h is copied from Fedora, slightly modified and
renamed to mingwce-io.h
- executable suffix support is added to the Makefile
- a script to compile superiotool.exe for WinCE
CONFIG_PCI=yes is also supported with zlib support and I have modified sources
for pciutils-3.1.9 (lspci only) and zlib-1.2.7. Now I can run lspci and superiotool
under Windows CE 4.2 found in the ROM of this machine, superiotool reports
NSC 87360 and the SC3200 on port 0x2e and 0x15c, respectively.
The x86mingw32ce distribution is 0.59.1 from http://cegcc.sourceforge.net/
but it needs an extra symlink libgmp.so.3 -> libgmp.so on my machine,
currently Fedora 19 beta.
The second and third patches add support for the internal SuperI/O chip
built into the AMD SC3200 chip to superiotool and src/superio, respectively.
Best regards,
Zoltán Böszörményi
As I am not subscribed to this mailing list, I ask that all responders
CC me. Please let me know if someone responded and didn't CC me so I
can check the archives; it would be a shame for me not to get that
message.
After searching the mailing list archives, Google,
<http://www.coreboot.org/Supported_Motherboards>, and
<http://www.coreboot.org/Supported_Chipsets_and_Devices>, I was pretty
surprised to find that there isn't a lot of information on newer
motherboards for Coreboot installation. I asked on the #coreboot IRC
channel, and they said that the Supported Motherboards page just isn't
updated as frequently any more, so I went to this list.
>From what I gather, if I want to build a PC with an Intel i7 CPU and
some higher-end NVidia GPU, I'll need a motherboard that supports the
LGA1155 socket, and it seems that none of the boards on the Supported
Motherboards page support that socket.
How is Coreboot support for motherboards that support these sockets?
Would, for example, the AMD FX 4300, AMD FX 6300, or AMD FX 8350 (none
of which are on the list) work with coreboot well? What motherboards
would you recommend to purchase that would support the CPU and GPU
that I would like? Unfortunately I can't really provide specs on these
motherboards because I don't own them yet.
Thanks a lot ahead of time for any advice; although I don't know a lot
about motherboards yet I'm willing to learn.
--
Harry Prevor
