[coreboot] Regarding contribution for coreboot
Hi, I am new and interested to work on coreboot.I have gone through the coreboot website. I am trying to do patch review.. But I am taking more time to come up with the solution compared to others.. So,Please let me know any other ways to contribute for coreboot apart from patch review?? Thanks, Manasa -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Potential development funding.
Hi everyone, My name is Nick Bowes and I'm looking to create a small (got to start somewhere) Foss-only computer build and supply business. To make that viable, I need a free bios implementation for one or two new mobos, and coreboot seems to hold the most promise. I'm interested in doing this in the hope that I can help the foss community get away from the emerging and likely pervasive UEFI stupidness thats coming. As you probably know better then I do, creating alternatives to the things that cause us all problems is the only way to truely solve them. Having heard recently that Google released coreboot updates for both Sandy Bridge and Ivy Bridge chipsets, I thought now would be a good time to ask this mailing list a few questions about the viability of funding some development. As a future small distributor of foss-only computers and likely a one man band to start with, I would need to keep things very simple. That means creating a product line (if you can call it that) of perhaps only 3-5 different desktops/laptops in total. Idealy I'd like to offer a range of 3 itx desktops, Ivy Bridge i3 i5 i7, or, Trinity A6 A8 A10, and one or two laptops, one budget, one highend. So, if you don't mind, and this is the right place(if it isn't, please point me in the right direction) I'd like to ask you all... 1. What do you all think the requirements will be for replacing UEFI on future mobos. Will it likely be a case of switching out the bios chip or just flashing it? 2. What % of flashes resulted in bricked mobos? Do most new boards come with a backup chip which can restore life after a failure? 3. Can anyone reccomend a possible target ivy bridge or Trinity itx mobo for coreboot development? Perhaps one that's already being worked on? 4. If we can identify a good itx mobo for the desktop line-up, would someone here be able to asses how much time a fairly full featured and reliable implementation of coreboot would take to develop? note: to me fairly full featured would be to have all the fundamentals up and avaliable for the OS to pick up, such as pci-e usb 3.0, hdmi, sata 3, wifi, and working reliably. 5. Is there any special requirement for getting amd/nvidia gfx cards working with coreboot? 6. Which hardware have you found to be the simplist to fully implement coreboot on, and which hardware (if any) should be considered a no go? 7. What type of computer would most on this list be interested to develop coreboot for. As in, if you were going to buy a desktop or laptop today, or in the near future, what combination of hardware would you go for? 8. What do you think about the viability of a kickstarter campaign to raise development funds. Has anyone tried this yet? I would truely love to distribute computers which run entirely on free software. Unfortunately, I'm no developer so If funding some development is the only way I can achieve this, I will find a way to do it. I look forward to any insights you provide. Thanks Nick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Trac reminder: list of new ticket(s)
Ticket Owner Status Description #186 ste...@coresystems.de new 3com 3c905tx / gpxe boot problem #185 ste...@coresystems.de new Vtech partial success #184 ste...@coresystems.de new Asus p2b with aty128 fails #183 ste...@coresystems.de new SeaBIOS: test-gcc.sh executed multiple times, also during make clean #182 u...@hermann-uwe.de new superiotool installs man page with +x perms #181 ste...@coresystems.de new Tyan S2885 (and other K8 boards) won't boot with TINY_BOOTBLOCK #180 ste...@coresystems.de new ASRock E350M1 Gigabit Ethernet Problem #178 ste...@coresystems.de new linux kernel hang while boot from SATA SSD on EPIA CN #176 ste...@coresystems.de new inteltool: added PCI_DEVICE_ID_INTEL_X44 0x29e0 #174 ste...@coresystems.de new Unable to boot from qemu-kvm -- seems to be a cbfs problem #168 ste...@coresystems.de new USBDEBUG might slow down coreboot #162 oxygene new Move SYSTEM_TYPE to Kconfig #160 oxygene new Build system: There's no convincing CFLAGS management for util/* #158 w...@gnu.org new buildrom svn error #156 hailfinger new Add Layout File capability to v3 and LAR tool #154 hailfinger new Flashing BIOSes from Fujitsu/Siemens is not supported #150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock #147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690 #145 somebody new Fix CMOS handling #143 oxygene new unify intel car for model_6[ef]x #135 ward new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) #129 stepan new etherboot payload does not work with HIGH_TABLES #128 somebody new Improve email user interface for trac #125 somebody new BCM5785 / HT1000 reset functions #111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo #110 somebody new Allow for per-device subsystem IDs #77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 rminnich new coreboot messages should be accessible in dmesg #18 oxygene new autoprobe apic cluster and application processors on K8 systems #17 stepan new clean up coreboot table handling #16 ollie new I2C driver and mainboard Config.lb #11 yhlu new pirq table automation #5 uwe new Add license header to all source files #2 somebody new Complete tables of supported motherboards -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Potential development funding.
Am 04.06.2012 14:42, schrieb mailinglists: 1. What do you all think the requirements will be for replacing UEFI on future mobos. Will it likely be a case of switching out the bios chip or just flashing it? We generally reuse the chips. If you're doing business, you should be able to afford an external flasher, so getting rid of the original BIOS is no problem, even if vendor BIOS locks down the chip on boot. Some chip types are easier to flash externally than others, but that's from a hobbyist perspective. As a business, investing some money in the right adapter for a large number of boards isn't too bad, it's just hard to justify spending $50 (to pick some upper bound) on a single-use item when it's just a hobby. 2. What % of flashes resulted in bricked mobos? Do most new boards come with a backup chip which can restore life after a failure? With external flashing you can recover by just writing again. bricked means wrong content and thus unable to boot, not destroyed chip (usually - I've seen the latter case, but it's very rare). 3. Can anyone reccomend a possible target ivy bridge or Trinity itx mobo for coreboot development? Perhaps one that's already being worked on? As yet, Trinity is only released for notebooks, at least that's what I gathered from the tech media. Desktop and server Trinity are scheduled for summer and fall releases (AFAIK). As for Ivybridge, please note that it requires a couple of binary-only components (beyond those we usually need, see below): RAM init is done with the Intel reference code, and to turn on the system in the first place, the Management Engine (some embedded controller in the chipset) requires a binary-only component as well. It's remotely feasible to replace the RAM init with source (multimonth effort, after obtaining access to the documentation), but the ME code will remain a requirement (if only because it's said to be signed by Intel, so replacing it requires cracking their signature scheme - good luck). 4. If we can identify a good itx mobo for the desktop line-up, would someone here be able to asses how much time a fairly full featured and reliable implementation of coreboot would take to develop? note: to me fairly full featured would be to have all the fundamentals up and avaliable for the OS to pick up, such as pci-e usb 3.0, hdmi, sata 3, wifi, and working reliably. This depends (among other things) on the kind of OS support you desire. OSS systems are generally more forgiving for incomplete configuration than Windows - but with FOSS-only computers Windows might not be a priority. 5. Is there any special requirement for getting amd/nvidia gfx cards working with coreboot? Minor hacks might be necessary to get the IGD/GFX switch to work right. On systems with integrated graphics we generally expect IGD to manage the primary display. Details on that vary by chipset and/or vendor. 6. Which hardware have you found to be the simplist to fully implement coreboot on, and which hardware (if any) should be considered a no go? nVidia chipsets are no-go (there was a lucky strike once that gave us the nVidia support we have - I don't expect that to happen again). Intel chipsets are complicated. AMD is the best choice for coreboot support these days. We don't have to care about many other things (eg. the Wifi card - we don't handle Wifi, we just have to make sure the card is found on the bus) 8.What do you think about the viability of a kickstarter campaign to raise development funds. Has anyone tried this yet? Last I heard Kickstarter has a backlog of several thousand projects. Kickstarter seems to be first and foremost a social media popularity contest at the moment, for which coreboot is probably not a fancy enough topic. I'd assume the same for FOSS Hardware, but feel free to try, if you feel like it. Make clear that you're not collecting funds for the coreboot project - our situation is that we can't accept donations of any kind (nor take money with any other designation). I would truely love to distribute computers which run entirely on free software. Unfortunately, I'm no developer so If funding some development is the only way I can achieve this, I will find a way to do it. run entirely on free software: We usually reuse the VGABIOS image delivered by the hardware vendor, which comes in binary-only form. There are a couple of ways around it, but they're only appropriate for systems where you control the OS that's used (eg. not doing VGA init at all and defer things to Linux KMS), or they're still experimental (see i915tool - it's an attempt to create a coreboot-level driver from KMS sources). This means that for a generic box you're still bound to the VGABIOS to some degree (you can't rely on KMS being available in the OS when using a bootloader menu). The other aspect is that you generally have an embedded controller on notebooks (in addition to the
[coreboot] Patch merged into coreboot/master: a786a68 Improve parsing of --cpu parameter in abuild script.
the following patch was just integrated into master: commit a786a680476fd605f78b11ff60cd074d03f2b57f Author: Raymond Danks ray.da...@se-eng.com Date: Wed May 30 16:03:48 2012 -0600 Improve parsing of --cpu parameter in abuild script. * -c need never be tested if getopt params are handled; fail abuild script when getopt parsing fails * use expr to resolve numeric test fails with -c max * cpus variable may be being passed in the environment. Don't overwrite MAKEFLAGS if it is not. Change-Id: I96236ef719a1a9f942b8e15bfcf015d60068e58a Signed-off-by: Raymond Danks ray.da...@se-eng.com Reviewed-By: Patrick Georgi patr...@georgi-clan.de at Mon Jun 4 16:19:34 2012, giving +2 See http://review.coreboot.org/1068 for details. -gerrit -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 4, 2012 at 8:43 AM, Bob Ham r...@settrans.net wrote: This doesn't really answer Gary's question. I would like to build a silent PC for music production. The chromebox is not an option as firstly, it has a fan inside and secondly, it has no PCI slots for my sound cards. I did not see those requirements in Gary's note, just in your note; on rereading his note, they did not appear :-) For you, no, it won't work. For his case, I guess Gary can tell us. what kind of pci slots do your sound cards need? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, 2012-06-04 at 08:45 -0700, ron minnich wrote:
what kind of pci slots do your sound cards need?
Not PCI-E or PCI-X, just normal PCI.
--
Bob Ham r...@settrans.net
for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 4, 2012 at 9:10 AM, Bob Ham r...@settrans.net wrote: Not PCI-E or PCI-X, just normal PCI. Wow. More than one? How many? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Sun, 2012-06-03 at 12:27 -0700, ron minnich wrote:
Get a chromebox. It's quite well supported and it's a very fine machine.
This doesn't really answer Gary's question. I would like to build a
silent PC for music production. The chromebox is not an option as
firstly, it has a fan inside and secondly, it has no PCI slots for my
sound cards.
--
Bob Ham r...@settrans.net
for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, 2012-06-04 at 09:15 -0700, ron minnich wrote:
On Mon, Jun 4, 2012 at 9:10 AM, Bob Ham r...@settrans.net wrote:
Not PCI-E or PCI-X, just normal PCI.
Wow. More than one? How many?
Two; I have two identical M-Audio Delta 1010s.
--
Bob Ham r...@settrans.net
for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, 2012-06-04 at 13:01 -0400, Ward Vandewege wrote:
On Mon, Jun 04, 2012 at 05:29:23PM +0100, Bob Ham wrote:
On Mon, 2012-06-04 at 09:15 -0700, ron minnich wrote:
On Mon, Jun 4, 2012 at 9:10 AM, Bob Ham r...@settrans.net wrote:
Not PCI-E or PCI-X, just normal PCI.
Wow. More than one? How many?
Two; I have two identical M-Audio Delta 1010s.
Finding a modern board with two 'old' PCI slots may be difficult, regardless
of coreboot... Have you seen any at all?
There are loads of new boards with at least two PCI slots; I've seen
many.
--
Bob Ham r...@settrans.net
for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 4, 2012 at 10:15 AM, Bob Ham r...@settrans.net wrote: There are loads of new boards with at least two PCI slots; I've seen many. got some pointers? In my world PCI has been an endangered species for years. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, 2012-06-04 at 10:22 -0700, ron minnich wrote:
On Mon, Jun 4, 2012 at 10:15 AM, Bob Ham r...@settrans.net wrote:
There are loads of new boards with at least two PCI slots; I've seen
many.
got some pointers? In my world PCI has been an endangered species for years.
http://www.scan.co.uk/products/gigabyte-ga-990xa-ud3-amd-990x-s-am3plus-ddr3-sata-iii-6gb-s-raid-sata-pcie-20-%28x16%29-atx
http://www.scan.co.uk/products/asus-m5a97-pro-amd-970-s-am3plus-ddr3-sata-iii-6gb-s-raid-sata-pcie-20-%28x16%29-atx
http://www.scan.co.uk/products/gigabyte-ga-970a-ds3-amd-970-s-am3plus-ddr3-sata-iii-6gb-s-sata-raid-pcie-20-%28x16%29-atx
http://www.scan.co.uk/products/msi-760gm-e51-%28fx%29-am3plus-cpu-amd-760g-plus-sb710-16gb-max-1xpcix16-1xpcix1-2-pci-dviplusvgaplushdm
http://www.scan.co.uk/products/asus-m5a78l-amd-760g-s-am3plus-ddr3-sata-ii-3gb-s-raid-sata-pcie-20-%28x16%29-atx
http://www.scan.co.uk/products/asus-e35m1-m-amd-hudson-m1-amd-e-350-dual-core-cpu-pci-e-20-%28x16%29-ddr3-1066-sata-6gb-s-matx
--
Bob Ham r...@settrans.net
for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
so that answers your question, I guess: match the chipsets on those boards up, see what kind of flash, etc. and you maybe one will work? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 4, 2012 at 11:26 AM, Bob Ham r...@settrans.net wrote: Though it sounds like the answer is: you don't know. I know about some. It is not possible to know about all. In general, it's not possible to know *even if you have a part number* because vendors change things on these boards all the time without changing the board number. I've bought boards in the past that were supported and a the board arrives and it has enough changes to qualify as a new board -- and the original part number. In general, the best bet is to buy a board which has vendor-supported coreboot -- such as the chromebox. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New patch to review for coreboot: 0672250 userspace coreboot support
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit,
which you can find at http://review.coreboot.org/1089
-gerrit
commit 0672250797641683cab727784362d1d4be9ffb28
Author: Rudolf Marek r.ma...@assembler.cz
Date: Tue Jun 5 00:15:56 2012 +0200
userspace coreboot support
Add the basic linux userspace support. Avoid the priviledge ops
and map low mem area to 64KB (which is normally mappable)
Provide the linux sycall console.
Change-Id: Iaeef5c159a1e8871ea24f57b4fd161f979a4ed77
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
---
src/Kconfig| 20
src/arch/x86/boot/gdt.c|5 +-
src/arch/x86/boot/tables.c |6 +
src/arch/x86/include/arch/io.h | 76 ++
src/arch/x86/lib/c_start.S | 36 ++-
src/arch/x86/lib/ebda.c|3 +
src/boot/hardwaremain.c| 11 ++
src/console/Makefile.inc |1 +
src/console/ulinux_console.c | 18
src/include/cpu/x86/lapic.h| 12 ++
src/include/termios.h | 219
src/include/ulinux.h | 36 +++
src/lib/Makefile.inc |3 +
src/lib/ulinux.c | 160 +
14 files changed, 602 insertions(+), 4 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index a5a0f00..21efe56 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -193,6 +193,26 @@ config REQUIRES_BLOB
coreboot build for such a board can override this manually, but
this option serves as warning that it might fail.
+config ULINUX
+ bool Compile and run coreboot as Linux userspace process
+ default n
+ help
+ This option enables to run coreboot as Linux process which
+ communicates with hardware using SerialICE.
+
+config ULINUX_VALGRIND
+ bool Add valgrind instrumentation
+ default n
+ depends on ULINUX
+ help
+ This option enables to track heap using valgrind.
+
+config SERIALICE_HOST_DEV
+ string SerialICE host device
+ default /dev/ttyUSB0
+ depends on ULINUX
+ help
+ Selects the serial port to which is connected your remote target.
endmenu
source src/mainboard/Kconfig
diff --git a/src/arch/x86/boot/gdt.c b/src/arch/x86/boot/gdt.c
index b425ade..407cfe2 100644
--- a/src/arch/x86/boot/gdt.c
+++ b/src/arch/x86/boot/gdt.c
@@ -38,7 +38,9 @@ void move_gdt(void)
{
void *newgdt;
u16 num_gdt_bytes = gdt_end - gdt;
+#if CONFIG_ULINUX == 0
struct gdtarg gdtarg;
+#endif
newgdt = cbmem_find(CBMEM_ID_GDT);
if (!newgdt) {
@@ -50,11 +52,12 @@ void move_gdt(void)
printk(BIOS_DEBUG, Moving GDT to %p..., newgdt);
memcpy((void*)newgdt, gdt, num_gdt_bytes);
}
-
+#if CONFIG_ULINUX == 0
gdtarg.base = (u32)newgdt;
gdtarg.limit = num_gdt_bytes - 1;
__asm__ __volatile__ (lgdt %0\n\t : : m (gdtarg));
+#endif
printk(BIOS_DEBUG, ok\n);
}
diff --git a/src/arch/x86/boot/tables.c b/src/arch/x86/boot/tables.c
index 72aa979..456f161 100644
--- a/src/arch/x86/boot/tables.c
+++ b/src/arch/x86/boot/tables.c
@@ -32,6 +32,7 @@
#include cbmem.h
#include lib.h
#include smbios.h
+#include ulinux.h
uint64_t high_tables_base = 0;
uint64_t high_tables_size;
@@ -69,7 +70,12 @@ struct lb_memory *write_tables(void)
* and the coreboot table use low_tables.
*/
low_table_start = 0;
+#if CONFIG_ULINUX
+ low_table_end = 0x1;
+ ulinux_mmap(low_table_end, 0x1000);
+#else
low_table_end = 0x500;
+#endif
#if CONFIG_GENERATE_PIRQ_TABLE
#define MAX_PIRQ_TABLE_SIZE (4 * 1024)
diff --git a/src/arch/x86/include/arch/io.h b/src/arch/x86/include/arch/io.h
index f4c6967..88338e1 100644
--- a/src/arch/x86/include/arch/io.h
+++ b/src/arch/x86/include/arch/io.h
@@ -9,6 +9,7 @@
* (insb/insw/insl/outsb/outsw/outsl).
*/
#if defined(__ROMCC__)
+
static inline void outb(uint8_t value, uint16_t port)
{
__builtin_outb(value, port);
@@ -41,6 +42,9 @@ static inline uint32_t inl(uint16_t port)
return __builtin_inl(port);
}
#else
+
+#if defined(__PRE_RAM__) || defined(__SMM__) || CONFIG_ULINUX == 0
+
static inline void outb(uint8_t value, uint16_t port)
{
__asm__ __volatile__ (outb %b0, %w1 : : a (value), Nd (port));
@@ -76,6 +80,43 @@ static inline uint32_t inl(uint16_t port)
__asm__ __volatile__ (inl %w1, %0 : =a(value) : Nd (port));
return value;
}
+
+#else /* CONFIG_ULINUX == 1 */
+
+#include console/console.h
+#include serialice_host.h
+
+static inline void outb(uint8_t value, uint16_t port)
+{
+ serialice_outb(value, port);
+}
+
+static inline void outw(uint16_t value, uint16_t port)
+{
+ serialice_outw(value, port);
+}
+
+static inline void outl(uint32_t value, uint16_t port)
+{
+ serialice_outl(value, port);
+}
+
+static inline uint8_t inb(uint16_t port)
+{
+
[coreboot] New patch to review for coreboot: c804366 Do not use CBFS while in userspace coreboot, fake 64KB chip.
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1090 -gerrit commit c804366903fb035c75a7d07fa72874a6e1c27a29 Author: Rudolf Marek r.ma...@assembler.cz Date: Tue Jun 5 00:18:37 2012 +0200 Do not use CBFS while in userspace coreboot, fake 64KB chip. Avoid CBFS, it could be mmaped as file in the future. Change-Id: I3cf7e8504e216eef7f88e14a3a2906f91fe3abb4 Signed-off-by: Rudolf Marek r.ma...@assembler.cz --- src/arch/x86/boot/smbios.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/arch/x86/boot/smbios.c b/src/arch/x86/boot/smbios.c index f39bf04..78e4e04 100644 --- a/src/arch/x86/boot/smbios.c +++ b/src/arch/x86/boot/smbios.c @@ -142,8 +142,14 @@ static int smbios_write_type0(unsigned long *current, int handle) vboot_data-vbt10 = (u32)t-eos + (version_offset - 1); #endif +#if CONFIG_ULINUX + /* No CBFS mapped yet */ + t-bios_rom_size = 64; + hdr = NULL; +#else if ((hdr = get_cbfs_header()) != (struct cbfs_header *)0x) t-bios_rom_size = (ntohl(hdr-romsize) / 65535) - 1; +#endif t-system_bios_major_release = 4; t-bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED | -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New patch to review for coreboot: 922b3c6 leave frame pointers
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1092 -gerrit commit 922b3c627bd573513b26fcb47197b01e77bfee0b Author: Rudolf Marek r.ma...@assembler.cz Date: Tue Jun 5 00:22:39 2012 +0200 leave frame pointers Do not strip out frame pointer, handy for debugging (this needs to be somehow more polished but one gets the idea). Change-Id: I4f96ca321a175c941c55846fd2471ef5cc4897af Signed-off-by: Rudolf Marek r.ma...@assembler.cz --- Makefile.inc | 16 +++- src/arch/x86/Makefile.inc |5 + 2 files changed, 20 insertions(+), 1 deletions(-) diff --git a/Makefile.inc b/Makefile.inc index 176ff67..f3e87cc 100644 --- a/Makefile.inc +++ b/Makefile.inc @@ -61,8 +61,15 @@ subdirs-y += site-local # Add source classes and their build options classes-y := ramstage romstage driver smm -romstage-c-ccopts:=-D__PRE_RAM__ + +ifeq ($(CONFIG_ULINUX),y) +stack_opt := -fomit-frame-pointer +ramstage-c-ccopts:= -fstack-protector-all +endif + +romstage-c-ccopts:=-D__PRE_RAM__ $(stack_opt) romstage-S-ccopts:=-D__PRE_RAM__ + ifeq ($(CONFIG_TRACE),y) ramstage-c-ccopts:= -finstrument-functions endif @@ -163,7 +170,14 @@ CFLAGS += -Wstrict-aliasing -Wshadow ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y) CFLAGS += -Werror endif + +ifeq ($(CONFIG_ULINUX),n) CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer +endif + +ifeq ($(CONFIG_ULINUX),y) +CFLAGS += -fno-common -ffreestanding -fno-builtin +endif additional-dirs := $(objutil)/cbfstool $(objutil)/romcc $(objutil)/options diff --git a/src/arch/x86/Makefile.inc b/src/arch/x86/Makefile.inc index 9739555..dc7a7a0 100644 --- a/src/arch/x86/Makefile.inc +++ b/src/arch/x86/Makefile.inc @@ -208,7 +208,12 @@ else $(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc: $(src)/mainboard/$(MAINBOARDDIR)/romstage.c $(OPTION_TABLE_H) $(obj)/build.h $(obj)/config.h @printf CC romstage.inc\n +ifeq ($(CONFIG_ULINUX),y) + $(CC) -MMD $(CFLAGS) -D__PRE_RAM__ -fomit-frame-pointer -I$(src) -I. -I$(obj) -c -S $ -o $@ +endif +ifeq ($(CONFIG_ULINUX),n) $(CC) -MMD $(CFLAGS) -D__PRE_RAM__ -I$(src) -I. -I$(obj) -c -S $ -o $@ +endif $(obj)/mainboard/$(MAINBOARDDIR)/romstage.inc: $(obj)/mainboard/$(MAINBOARDDIR)/romstage.pre.inc @printf POST romstage.inc\n -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New patch to review for coreboot: a4e7fb1 random hack in qemu target
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/1093 -gerrit commit a4e7fb13b611d5d3f14b3a21f34d19939e5e62ed Author: Rudolf Marek r.ma...@assembler.cz Date: Tue Jun 5 00:24:14 2012 +0200 random hack in qemu target Not for merge, just simple hack to use userspace coreboot even without serialice (comment out serialice_init). if serialice_init is commented all IO will fail but one can test the memory access/workflow more faster. Change-Id: I0c8f8619fa054af72cca76a0825fd00a4d301c3d Signed-off-by: Rudolf Marek r.ma...@assembler.cz --- src/mainboard/emulation/qemu-x86/northbridge.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mainboard/emulation/qemu-x86/northbridge.c b/src/mainboard/emulation/qemu-x86/northbridge.c index f1669bb..d701b8c 100644 --- a/src/mainboard/emulation/qemu-x86/northbridge.c +++ b/src/mainboard/emulation/qemu-x86/northbridge.c @@ -11,6 +11,7 @@ #include chip.h #include delay.h #include smbios.h +#include ulinux.h #if CONFIG_WRITE_HIGH_TABLES #include cbmem.h @@ -38,7 +39,8 @@ static void cpu_pci_domain_set_resources(device_t dev) unsigned long tomk = 0, tolmk; int idx; - tomk = qemu_get_memory_size(); +// tomk = qemu_get_memory_size(); + tomk = 16*1024; printk(BIOS_DEBUG, Detected %lu Kbytes (%lu MiB) RAM.\n, tomk, tomk / 1024); @@ -58,8 +60,10 @@ static void cpu_pci_domain_set_resources(device_t dev) /* Leave some space for ACPI, PIRQ and MP tables */ high_tables_base = (tomk * 1024) - HIGH_MEMORY_SIZE; high_tables_size = HIGH_MEMORY_SIZE; +#if CONFIG_ULINUX + ulinux_mmap(high_tables_base, high_tables_size); +#endif #endif - assign_resources(dev-link_list); } -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] New patch to review for coreboot: d602fc7 Add host side of serialICE which uses ulinux.
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit,
which you can find at http://review.coreboot.org/1094
-gerrit
commit d602fc79e963057e4db00a4e2dca38d48ad6b484
Author: Rudolf Marek r.ma...@assembler.cz
Date: Tue Jun 5 00:26:06 2012 +0200
Add host side of serialICE which uses ulinux.
This is copied from serialICE qemu and strtoul is from libpayload. this
must be fixed
maybe into string.h?
Change-Id: If71737e6866c5c4dd62b9c26c676686ebfd20bcc
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
---
src/include/serialice_host.h | 66
src/lib/serialice_host.c | 676 ++
2 files changed, 742 insertions(+), 0 deletions(-)
diff --git a/src/include/serialice_host.h b/src/include/serialice_host.h
new file mode 100644
index 000..f099325
--- /dev/null
+++ b/src/include/serialice_host.h
@@ -0,0 +1,66 @@
+/*
+ * QEMU PC System Emulator
+ *
+ * Copyright (c) 2009 coresystems GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef SERIALICE_HH
+#define SERIALICE_HH
+#include stdint.h
+extern const char *serialice_device;
+extern int serialice_active;
+
+void serialice_init(void);
+void serialice_exit(void);
+const char *serialice_lua_execute(const char *cmd);
+
+uint8_t serialice_inb(uint16_t port);
+uint16_t serialice_inw(uint16_t port);
+uint32_t serialice_inl(uint16_t port);
+
+void serialice_outb(uint8_t data, uint16_t port);
+void serialice_outw(uint16_t data, uint16_t port);
+void serialice_outl(uint32_t data, uint16_t port);
+
+uint8_t serialice_readb(uint32_t addr);
+uint16_t serialice_readw(uint32_t addr);
+uint32_t serialice_readl(uint32_t addr);
+
+void serialice_writeb(uint8_t data, uint32_t addr);
+void serialice_writew(uint16_t data, uint32_t addr);
+void serialice_writel(uint32_t data, uint32_t addr);
+
+uint64_t serialice_rdmsr(uint32_t addr, uint32_t key);
+void serialice_wrmsr(uint64_t data, uint32_t addr, uint32_t key);
+
+typedef struct {
+uint32_t eax, ebx, ecx, edx;
+} cpuid_regs_t;
+
+cpuid_regs_t serialice_cpuid(uint32_t eax, uint32_t ecx);
+
+int serialice_handle_load(uint32_t addr, uint32_t * result,
+ unsigned int data_size);
+void serialice_log_load(int caught, uint32_t addr, uint32_t result,
+unsigned int data_size);
+int serialice_handle_store(uint32_t addr, uint32_t val, unsigned int
data_size);
+
+#endif
diff --git a/src/lib/serialice_host.c b/src/lib/serialice_host.c
new file mode 100644
index 000..4d318b2
--- /dev/null
+++ b/src/lib/serialice_host.c
@@ -0,0 +1,676 @@
+/*
+ * QEMU PC System Emulator
+ *
+ * Copyright (c) 2009 coresystems GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/* Indented with:
+ * gnuindent -npro -kr -i4 -nut -bap -sob -l80 -ss -ncs serialice.*
+ */
+
+/* System includes */
+#include stdlib.h
+#include stdint.h
+
[coreboot] New patch to review for coreboot: dd11f54 Add MSR support for serialICE.
Rudolf Marek (r.ma...@assembler.cz) just uploaded a new patch set to gerrit,
which you can find at http://review.coreboot.org/1095
-gerrit
commit dd11f547bb130790fbe1d0f8b17591be50faf6ec
Author: Rudolf Marek r.ma...@assembler.cz
Date: Tue Jun 5 00:27:54 2012 +0200
Add MSR support for serialICE.
Adds MSR support forwarding, no password key yet, cpuid is missing.
Change-Id: Ib33f91839d2a1b07314dc4b0f6aead00c47f1b08
Signed-off-by: Rudolf Marek r.ma...@assembler.cz
---
src/include/cpu/x86/msr.h | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/src/include/cpu/x86/msr.h b/src/include/cpu/x86/msr.h
index 40926df..0ba3910 100644
--- a/src/include/cpu/x86/msr.h
+++ b/src/include/cpu/x86/msr.h
@@ -16,7 +16,7 @@ static void wrmsr(unsigned long index, msr_t msr)
}
#else
-
+#include serialice_host.h
typedef struct msr_struct
{
unsigned lo;
@@ -42,21 +42,34 @@ typedef struct msrinit_struct
static inline __attribute__((always_inline)) msr_t rdmsr(unsigned index)
{
msr_t result;
+#if defined(__PRE_RAM__)
__asm__ __volatile__ (
rdmsr
: =a (result.lo), =d (result.hi)
: c (index)
);
return result;
+
+#else
+ int64_t ret = serialice_rdmsr(index, 0);
+ result.lo = ret 0x;
+ result.hi = (ret 32) 0x;
+ return result;
+#endif
}
static inline __attribute__((always_inline)) void wrmsr(unsigned index, msr_t
msr)
{
+
+#if defined(__PRE_RAM__) || CONFIG_ULINUX == 0
__asm__ __volatile__ (
wrmsr
: /* No outputs */
: c (index), a (msr.lo), d (msr.hi)
);
+#else
+ serialice_wrmsr uint64_t) msr.hi) 32) | msr.lo, index, 0);
+#endif
}
#endif /* __ROMCC__ */
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot runs in linux userspace
Hi all, I had this long in mind, now it works, coreboot can be run as Linux process and IO is done through a serialICE. This is handy for debugging and valgrinding, or maybe handy for zillions of other reasons. How it works: ruik@ruik:~/coreboot$ gdb ./build/cbfs/fallback/coreboot_ram.elf (gdb) run Starting program: /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf POST: 0x80 IO WRITE: [0080] 0080 size 1 SerialICE not ready yet (ignoring) POST: 0x39 IO WRITE: [0080] 0039 size 1 SerialICE not ready yet (ignoring) coreboot-4.0-2408-gad422c0-dirty Tue Jun 5 00:04:52 CEST 2012 booting... POST: 0x40 IO WRITE: [0080] 0040 size 1 SerialICE not ready yet (ignoring) Enumerating buses... Show all devs...Before device enumeration. Root Device: enabled 1 PCI_DOMAIN: : enabled 1 Or when it crashes: Root Device init APIC_CLUSTER: 0 init MSR WRITE: [001b] fee00900 MSR READ: [001b] fee00900 MEM READ: [fee00020] size 4 ==13541== Invalid read of size 1 ==13541==at 0x106C0E: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x10991B: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x10AD0B: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x10BA3F: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x10C232: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x106F99: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x10003D: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541==by 0x127347: ??? (in /home/ruik/coreboot/build/cbfs/fallback/coreboot_ram.elf) ==13541== Address 0xa000 is not stack'd, malloc'd or (recently) free'd ==13541== ==13541== ==13541== Process terminating with default action of signal 11 (SIGSEGV) ==13541== Access not within mapped region at address 0xA000 Please note that valgrind is confused with our debug symbols, but gdb works fine. In general, the real coreboot jumps to hacked version of serial ICE and waits. The userspace program is run as any process and hacked version serialICE host from qemu talks normally to linux kernel (this is done via custom 0x80 calls) no libc is used, even the memory layout is same. The only memory mapped is what ELF has and also highmem/lowmem bits (check ulinux_mmap calls). It is still very experimental but works fine. I put together quickly some patches which may be found here: emote: New Changes: remote: http://review.coreboot.org/1089 remote: http://review.coreboot.org/1090 remote: http://review.coreboot.org/1091 remote: http://review.coreboot.org/1092 remote: http://review.coreboot.org/1093 remote: http://review.coreboot.org/1094 remote: http://review.coreboot.org/1095 remote: http://review.coreboot.org/1096 remote: http://review.coreboot.org/1097 Thanks Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Motherboards?
On Mon, Jun 04, 2012 at 05:29:23PM +0100, Bob Ham wrote: On Mon, 2012-06-04 at 09:15 -0700, ron minnich wrote: On Mon, Jun 4, 2012 at 9:10 AM, Bob Ham r...@settrans.net wrote: Not PCI-E or PCI-X, just normal PCI. Wow. More than one? How many? Two; I have two identical M-Audio Delta 1010s. Finding a modern board with two 'old' PCI slots may be difficult, regardless of coreboot... Have you seen any at all? Thanks, Ward. -- Ward Vandewege | CTO, Free Software Foundation GPG Key: 25F774AB | http://identi.ca/cure | http://fsf.org/blogs/RSS Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
