coreboot June 2008

coreboot@coreboot.org

75 participants
230 discussions

latest legacybios update
by Kevin O'Connor 19 Jun '08

19 Jun '08

Hi, I've made some recent progress with "legacybios". The code will now locate and parse the coreboot table. This means that "legacybios" will now have the correct ram size and will properly populate the e820 map with the info. I've confirmed that my epia-m continues to boot into linux with the recent changes. I've also fixed a few bugs - slave ide drives are now working for me and apm no longer crashes the linux kernel. For those that are interested, the code is in git - see: http://git.linuxtogo.org/ My next step is going to be getting bios tables (pir, acpi) working so that the legacybios payload doesn't overwrite them. I plan on hacking coreboot-v2 so that it deploys the tables to the top of ram instead of 0xf0000. I then plan on having legacybios locate the tables (by looking at the coreboot table) and then copy the subset of tables that must reside in the 0xf0000 segment. For those that remember the discussion at: http://www.coreboot.org/pipermail/coreboot/2008-May/034688.html I'm basically advocating option (c). Finally, I've successfully booted windows xp and windows vista under qemu (without using coreboot). Once I get the standard bios tables working, I'll see if I can get them running too. -Kevin

6 25

Re: [coreboot] The project to support UEFI payload is on the way
by Ken.Fuchs＠bench.com 19 Jun '08

19 Jun '08

> My recent job is aim to let coreboot support UEFI(Unified > Extensible Firmware Interface) payload. Welcome to coreboot! > TianoCore, UEFI implementation from Intel corp., will be adopted. Would you consider using code from previous attempts at open source UEFI such as http://www.gnu.org/software/gnufi/ Sincerely, Ken Fuchs

2 1

Fw: Re: coreboot and embedded controllers, ?for example OLPC and its?OpenEC code
by Jordan Crouse 18 Jun '08

18 Jun '08

This was sent to just me, but I think there is information here that would be interesting to the group. ----- Forwarded message from Frieder Ferlemann <frieder.ferlemann(a)web.de> ----- From: Frieder Ferlemann <frieder.ferlemann(a)web.de> Date: Thu, 19 Jun 2008 01:17:17 +0200 To: Jordan Crouse <jordan.crouse(a)amd.com> Subject: Re: [coreboot] coreboot and embedded controllers, for example OLPC and its OpenEC code Hi, Jordan Crouse schrieb: > On 18/06/08 15:45 -0500, Ken.Fuchs(a)bench.com wrote: >> What happened with the OLPC's OpenEC code? Was that >> ever completed? Did the name change to something else? >> Is it currently being developed? > > I'm not sure what the current status is, you may want to > ask on devel(a)laptop.org. As is often the case with there is currently no active development done on OpenEC I'm afraid. I jumped in to provide a framework which would allow for a GPL'ed firmware for the Embedded controler in the XO of the One-Laptop-per-Child project. But it turned out I was the only one contributing code. And having no access to up to date schematics and only a very terse data sheet of the controller (and still nobody joining) I felt I could not complete within the time-scale that would matter for the OLPC project. So for now OpenEC is not being worked on. But I think the project (while in its early stages) is now adequately positioned as a starting point for an Embedded Controler firmware. Current status is best seen at: http://wiki.laptop.org/go/OpenEC > projects like these, there is no shortage of people > eager to begin reverse engineering closed source firmware but few of > them stick around when they discover > the complexity of the task at hand. I knew before, just speculated on others joining:) > In short, embedded controller code is dark magic. You need > detailed schematics of your board, a clear indication of the > API that the BIOS requires, a JTAG debugger and a lot of time. > If you think that coreboot is too platform specfic, then you haven't > seen anything yet. > > Aas far as coreboot is concerned, we just don't have access to > information for any EC enabled platform that we might otherwise > support. The only platform we would come even close to being > in the ballpark of supporting would be the OLPC, but even then > we are missing the schematics and the hardware bits needed to > flash the ROM. OLPC is slightly better, there is a publically available (but outdated (and only one page out of many)) schematic: http://dev.laptop.org/attachment/ticket/477/SCHEMATIC1%20_%2012%20--%20EC%2… And flashing should not be a problem. At least for early XOs this only requires rather straightforward hardware: http://wiki.laptop.org/go/Image:Serial_adapter.jpg > What we need is a freely available EC chip that we can easily > hack on without complex or expensive hardware. Then the task will > be to come up with a reasonable operating system to provide timers > and provide a general platform for development. Once you get to > that point, then I think there is a real chance that an OpenEC solution > could win. Until then, its going to be black hole that > makes everybody cringe. Yep, let's see what happens. OpenEC is GPL'ed so it is there to stay and it is waiting for a slightly better chance than OLPC turned out to be. And OpenEC was written with portability in mind. While it specifically targets an ENE KB3700 (with its 8051 based core) the source is also compileable with gcc. Greetings, Frieder ----- End forwarded message ----- -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.

1 0

AppleTV development
by Scott D. Davilla 18 Jun '08

18 Jun '08

Hello all, I'm the author of atv-bootloader which enabled booting of standard un-patched Linux kernels on AppleTV hardware. For background, the AppleTV uses a pure EFI bios which uses boot.efi to boot a OSX darwin kernel. The EFI firmware does cert checking which prevents the use of rEFIt as a bootloader so a fake darwin kernel (mach_kernel) was created to act as a secondary bootloader. I've extended this secondary bootloader (my work is atv-bootloader) to remove the nasty kernel patches by translating the EFI memory map into an E820 memory map and relocating ACPI and SMBIOS table pointers to where Linux can find them. In addition, since video is presented as a linear console frame buffer, I setup Linux boot params for a vesafb. A custom Linux kernel/initramfs is embedded into the secondary bootloader. This kernel/initramsfs then finds and loads the real kernel using kexec. The reason for the initial kernel is USB 2.0 support. It was easier to do it this way than add all the required bits to support USB 2.0. This all works pretty well and the nvidia binary driver see and correctly uses the nvidia 7300 chipset for 720p/1080i XvMC hardware decode. So for about $230, the AppleTV is about the least expensive hardware platform for handling 720p/1080i mpeg2 video content. One of the current issues is that since the AppleTV is pure EFI, that means no PC-bios and vbios is not in the typical locations so video resolution changes can only be handled by the nvidia binary driver under X11. I've recently found where vbios is located and have been able to copy it to 0xC0000 and run the standard "nv" X11 driver. When running "nv" I can even POST it using testbios. The plan is to have the secondary bootloader relocate vbios and POST it in prep for Linux. This involves patching in software/hardware interrupt handlers (remember no PC-bios). Since I'm not a pc-bios/vbios expert this is where the fun starts. The other thought is to go all the way and do a PC-bios layer complete with vbios handling. ADLO seems interesting. The secondary bootloader is running in protected mode so it could load the ADLO payload and launch it. Coreboot and it's associated projects is the closest development effort that involved pc-bios/vbios work so I'd like to get some comments or suggestions. Thanks Scott

1 0

GSoC AVATT project
by Cristi Magherusan 18 Jun '08

18 Jun '08

Hello, On Wed, 2008-06-18 at 14:14 +0200, Stefan Reinauer wrote: > ron minnich wrote: > > are you ready to go? We are supposed to have started. > any news? These days I just finished my graduation stuff, so that now I can start working full time on my GSoC project. This is what I have in mind, for anyone who may be interested about this topic and cannot read my GSoC application's discussions: My project (AVATT) involves creating a small KVM-aware Linux payload, integrating in the initrd the tools needed to create and run virtual machines, straight on top of the BIOS. The first part is about making everything as small as possible, aiming it to fit in under 1 MB, but as smaller it gets, as better. The Linux kernel minimization part is quite trivial, there are those tiny patches which can easily make it a few hundreds of kilobites, and some careful drivers selection. Still some work needs to be done on the minimization of the KVM tools. Their dependencies on high-level userspace stuff like SDL must be eliminated, and they must be statically linked with some small libc. I'm thinking about uclibc, but any other ideas are welcome. Then, I was thinking about making some small GNU screen-like tool that would allow the user to quiclky create (wizard?), attach and switch between virtual mahines. This would be great for console-only OS-es, but i guess that more serious ones should be able to use real tty's, if needed, just like X is doing for its display. Xen's tools, dtach and GNU screen may be considered as reference for this kind of tool. Ideally, the system should allow multiplexing any other devices, like sound, USB, etc, but this must be further investigated. I already have a testbed installation that uses qemu to emulate a amd64 box. Latest qemu supports virtualization itself, and I already succeeded to run double emulation with it, as a proof of concept. The performance is awful, but it works. Anyway, the final part will need a powerful amd64 machine that should be used for testing the real stuff. If you have any suggestions and questions to ask, feel free to do it. Best regards, Cristi -- Cristi Magherusan, Universitatea Tehnica din Cluj - Napoca Centrul de Comunicatii "Pusztai Kalman" Tel. 0264/401247 http://cc.utcluj.ro

2 2

The project to support UEFI payload is on the way
by zhanyi liu 18 Jun '08

18 Jun '08

Hi, all I am Joey Liu, a new member of coreboot project. Many thanks to stefan and ron, I am very glad to join in the coreboot big family. My recent job is aim to let coreboot support UEFI(Unified Extensible Firmware Interface) payload. TianoCore, UEFI implementation from Intel corp., will be adopted. This is excellent project, I will try hard to finish. I am just starting it. if who is interested in it or has some wonderful idea, don't hesitate to tell me what you think. All of it will help me a lot. ^__^ Joey Liu

4 3

Newbee patch for A49LF040A (Alix2c2) please have a look.
by Jens Kuehnel 18 Jun '08

18 Jun '08

Hi coreboot list, I visited the coreboot/flashrom talk during linuxtag, and was really impressed how "easy" it is can help/to hack. My target is to let coreboot run on my alix2c2 (the one with only 2 network cards). The advantage for me is, its similar to an existing target (not too hard), but far enough to learn something. My first problem it that flashrom does not support my flashchip. But I hope I can fix this. :-) Patch attached. But before I break my flash. Is it possible to destroy the chip, by using the wrong method? The chip is a AMIC A49LF040A. It look like a SST 49LF040 replacement, I found the IDs @ http://www.amictechnology.com/pdf/A49LF040A.pdf. I have a "LPC.1A", which means I can recover from bad flashes. But I don't like to solder SMD. Can someone with more experience look over it, before I test it? Thanks a lot! Greetings from Frankfurt/M (Germany) CU Jens diff -u flashrom/flashchips.c flashrom-jk/flashchips.c --- flashrom/flashchips.c 2008-06-05 18:06:52.000000000 +0200 +++ flashrom-jk/flashchips.c 2008-06-06 20:31:53.000000000 +0200 @@ -44,6 +44,7 @@ {"Atmel", "AT49F002(N)", ATMEL_ID, AT_49F002N, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, {"Atmel", "AT25DF321", ATMEL_ID, AT_25DF321, 4096, 256, TEST_OK_PREW, probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, + {"Amic Technology","A49LF040A", AMIC_ID, AMIC_A49LF040A, 512, 4096, TEST_UNTESTED, probe_jedec, erase_49lf040, write_49lf040}, {"Amic Technology","A25L40P", AMIC_ID, AMIC_A25L40P, 512, 256, TEST_UNTESTED, probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, diff -u flashrom/flash.h flashrom-jk/flash.h --- flashrom/flash.h 2008-06-05 18:06:52.000000000 +0200 +++ flashrom-jk/flash.h 2008-06-06 20:32:19.000000000 +0200 @@ -119,6 +119,7 @@ #define AMIC_ID 0x7F37 /* AMIC */ #define AMIC_ID_NOPREFIX 0x37 /* AMIC */ #define AMIC_A25L40P 0x2013 +#define AMIC_A49LF040A 0x379D #define ASD_ID 0x25 /* ASD, not listed in JEP106W */ #define ASD_AE49F2008 0x52

6 27

r3368 - trunk/util/flashrom
by svn＠coreboot.org 18 Jun '08

18 Jun '08

Author: stuge Date: 2008-06-18 15:36:34 +0200 (Wed, 18 Jun 2008) New Revision: 3368 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c trunk/util/flashrom/w29ee011.c Log: flashrom: Add support for AMIC Technology A49LF040A and do not probe W29EE011 anymore Jens sent the first patch that added A49LF040A to flash.h and flashchips.c using _jedec and _49lf040 functions. An issue was found with probe_w29ee011() for the Winbond W29EE011, which caused the A49LF040A to no longer respond to any commands. Ward made a patch to disable probing by default for the W29EE011 following some discussion. Using -c W29EE011 will make flashrom probe for the chip. Peter did some more datasheet diving and found that the Pm49FL00x functions suited this chip quite well because of the block locking registers in A49LF040A, and finally tested PROBE READ ERASE WRITE to work on ALIX.3c3. Ward confirmed that this works on alix.2c3 too. Signed-off-by: Jens Kuehnel <coreboot(a)jens.kuehnel.org> Signed-off-by: Ward Vandewege <ward(a)gnu.org> Signed-off-by: Peter Stuge <peter(a)stuge.se> Acked-by: Ward Vandewege <ward(a)gnu.org> Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-06-18 02:08:40 UTC (rev 3367) +++ trunk/util/flashrom/flash.h 2008-06-18 13:36:34 UTC (rev 3368) @@ -120,6 +120,7 @@ #define AMIC_ID_NOPREFIX 0x37 /* AMIC */ #define AMIC_A25L40P 0x2013 #define AMIC_A29040B 0x86 +#define AMIC_A49LF040A 0x9d #define ASD_ID 0x25 /* ASD, not listed in JEP106W */ #define ASD_AE49F2008 0x52 Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-06-18 02:08:40 UTC (rev 3367) +++ trunk/util/flashrom/flashchips.c 2008-06-18 13:36:34 UTC (rev 3368) @@ -45,6 +45,7 @@ {"Atmel", "AT49F002(N)T", ATMEL_ID, AT_49F002NT, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, {"Atmel", "AT25DF321", ATMEL_ID, AT_25DF321, 4096, 256, TEST_OK_PREW, probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Amic Technology","A25L40P", AMIC_ID, AMIC_A25L40P, 512, 256, TEST_UNTESTED, probe_spi_rdid, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, + {"AMIC Technology","A49LF040A", AMIC_ID_NOPREFIX, AMIC_A49LF040A, 512, 64 * 1024, TEST_OK_PREW, probe_49fl00x, erase_49fl00x, write_49fl00x}, {"Amic Technology","A29040B", AMIC_ID_NOPREFIX, AMIC_A29040B, 512, 64 * 1024, TEST_OK_PR, probe_29f040b, erase_29f040b, write_29f040b}, {"EMST", "F49B002UA", EMST_ID, EMST_F49B002UA, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, {"EON", "EN29F002(A)(N)B", EON_ID, EN_29F002B, 256, 256, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, Modified: trunk/util/flashrom/w29ee011.c =================================================================== --- trunk/util/flashrom/w29ee011.c 2008-06-18 02:08:40 UTC (rev 3367) +++ trunk/util/flashrom/w29ee011.c 2008-06-18 13:36:34 UTC (rev 3368) @@ -18,13 +18,24 @@ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ +#include <string.h> #include "flash.h" int probe_w29ee011(struct flashchip *flash) { volatile uint8_t *bios = flash->virtual_memory; uint8_t id1, id2; + extern char *chip_to_probe; + if (!chip_to_probe || strcmp(chip_to_probe,"W29EE011")) { + printf_debug("\n===\n"); + printf_debug(" Probing disabled for Winbond W29EE011 because the probing sequence puts the\n"); + printf_debug(" AMIC A49LF040A in a funky state.\n"); + printf_debug(" Use 'flashrom -c W29EE011' if you have a board with this chip."); + printf_debug("\n===\n"); + return 0; + } + /* Issue JEDEC Product ID Entry command */ *(volatile uint8_t *)(bios + 0x5555) = 0xAA; myusec_delay(10);

1 0

Firmware hub flash addressing [off-topic]
by llandre 18 Jun '08

18 Jun '08

Sorry for posting a message that is a little bit off-topic. I'm working with a SST 8 Mbit Firmware Hub SST49LF008A flash connected to Geode LX LPC bus. I need to understand where flash registers are mapped in case the flash ID is set to 1 (this flash is not the boot flash that has ID=0). The datasheet just says about identification registers (same thing applies for other registers too): JEDEC ID Registers The JEDEC ID registers for the boot device appear at FFBC0000H and FFBC0001H in the 4 GByte system memory map, and will appear ***elsewhere*** if the device is not the boot device. Anybody can tell me what does "elsewhere" stand for in this sentence? TIA, llandre DAVE Electronics System House - R&D Department web: http://www.dave.eu email: r&d2(a)dave-tech.it

2 3

memtest
by ron minnich 18 Jun '08

18 Jun '08

OK, bulit memtest 3.3 from scratch and it's running. interesting problem. The memtest built by buildrom won't boot on dbe62, the 3.3. version I built is fine and loads via etherboot just fine. Anyway, it gets a depressingly large # of errors. We are definitely not doing something right :-) For anyone who wants eboot for dbe62, my .config for linuxbios, a working memtest for all this, my scripts to build images, etc ... let me know. thanks ron

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2008