coreboot January 2013

coreboot@coreboot.org

32 participants
607 discussions

Patch merged into coreboot/master: 3d4762d Tyan s8226: change lapic of lapic_cluster 0 to 0x10
by gerrit＠coreboot.org 03 Jan '13

03 Jan '13

the following patch was just integrated into master: commit 3d4762d450f63c32038b4c9c422dc99c98fdee9a Author: Siyuan Wang <wangsiyuanbuaa(a)gmail.com> Date: Fri Jan 4 13:07:49 2013 +0800 Tyan s8226: change lapic of lapic_cluster 0 to 0x10 There are two CPUs on s8226 and each CPU has 8 cores. CPU 0 takes lapic from 0x10 to 0x17 and CPU 1 takes from 0x20 to 0x27. So the first core's lapic is 0x10 rather than 0x20. Change-Id: I925114d44f2f4974eb62c3832d8c9139a2a06c96 Signed-off-by: Siyuan Wang <SiYuan.Wang(a)amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa(a)gmail.com> Reviewed-on: http://review.coreboot.org/2099 Reviewed-by: Zheng Bao <zheng.bao(a)amd.com> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Jan 4 06:15:14 2013, giving +1 Reviewed-By: Zheng Bao <zheng.bao(a)amd.com> at Fri Jan 4 06:10:47 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Fri Jan 4 06:37:18 2013, giving +2 See http://review.coreboot.org/2099 for details. -gerrit

1 0

Patch merged into coreboot/master: 086842a Change "VERSION*" to more determined name "CBFS_HEADER_VERSION*".
by gerrit＠coreboot.org 03 Jan '13

03 Jan '13

the following patch was just integrated into master: commit 086842a13e50d2c870ddf749c036f8c321d2915f Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Jan 4 12:33:03 2013 +0800 Change "VERSION*" to more determined name "CBFS_HEADER_VERSION*". The 'VERSION' in CBFS header file is confusing and may conflict when being used in libpayload. Change-Id: I24cce0cd73540e38d96f222df0a65414b16f6260 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> Reviewed-on: http://review.coreboot.org/2098 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix(a)chromium.org> Build-Tested: build bot (Jenkins) at Fri Jan 4 05:43:05 2013, giving +1 Reviewed-By: David Hendricks <dhendrix(a)chromium.org> at Fri Jan 4 06:27:32 2013, giving +2 See http://review.coreboot.org/2098 for details. -gerrit

1 0

New patch to review for coreboot: ebf80ba Tyan s8226: change lapic of lapic_cluster 0 to 0x10
by Siyuan Wang 03 Jan '13

03 Jan '13

Siyuan Wang (wangsiyuanbuaa(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2099 -gerrit commit ebf80ba8cf29cf28ce37e06d82458cab61095af6 Author: Siyuan Wang <wangsiyuanbuaa(a)gmail.com> Date: Fri Jan 4 13:07:49 2013 +0800 Tyan s8226: change lapic of lapic_cluster 0 to 0x10 There are two CPUs on s8226 and each CPU has 8 cores. CPU 0 takes lapic from 0x10 to 0x17 and CPU 1 takes from 0x20 to 0x27. So the first core's lapic is 0x10 rather than 0x20. Change-Id: I925114d44f2f4974eb62c3832d8c9139a2a06c96 Signed-off-by: Siyuan Wang <SiYuan.Wang(a)amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa(a)gmail.com> --- src/mainboard/tyan/s8226/devicetree.cb | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/mainboard/tyan/s8226/devicetree.cb b/src/mainboard/tyan/s8226/devicetree.cb index 4459019..a057f02 100644 --- a/src/mainboard/tyan/s8226/devicetree.cb +++ b/src/mainboard/tyan/s8226/devicetree.cb @@ -19,8 +19,7 @@ chip northbridge/amd/agesa/family15/root_complex device lapic_cluster 0 on chip cpu/amd/agesa/family15 - device lapic 0x20 on end #f15 - #device lapic 0x10 on end #f10 + device lapic 0x10 on end end end device pci_domain 0 on

1 0

New patch to review for coreboot: 1c862b0 Change "VERSION*" to more determined name "CBFS_HEADER_VERSION*".
by Hung-Te Lin 03 Jan '13

03 Jan '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2098 -gerrit commit 1c862b03e4f8602090679001ee18a684f16fec37 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Fri Jan 4 12:33:03 2013 +0800 Change "VERSION*" to more determined name "CBFS_HEADER_VERSION*". The 'VERSION' in CBFS header file is confusing and may conflict when being used in libpayload. Change-Id: I24cce0cd73540e38d96f222df0a65414b16f6260 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- payloads/libpayload/include/cbfs_core.h | 6 +++--- src/include/cbfs_core.h | 6 +++--- util/cbfstool/cbfs.h | 6 +++--- util/cbfstool/common.c | 6 +++--- util/nvramtool/cbfs.h | 2 +- 5 files changed, 13 insertions(+), 13 deletions(-) diff --git a/payloads/libpayload/include/cbfs_core.h b/payloads/libpayload/include/cbfs_core.h index 9a21a78..a3c54b1 100644 --- a/payloads/libpayload/include/cbfs_core.h +++ b/payloads/libpayload/include/cbfs_core.h @@ -88,9 +88,9 @@ /* FIXME: This could also be 0xFFFF0000 with HIVECS enabled */ #define CBFS_HEADPTR_ADDR 0x0000000C #endif -#define VERSION1 0x31313131 -#define VERSION2 0x31313132 -#define VERSION VERSION2 +#define CBFS_HEADER_VERSION1 0x31313131 +#define CBFS_HEADER_VERSION2 0x31313132 +#define CBFS_HEADER_VERSION CBFS_HEADER_VERSION2 struct cbfs_header { uint32_t magic; diff --git a/src/include/cbfs_core.h b/src/include/cbfs_core.h index 9a21a78..a3c54b1 100644 --- a/src/include/cbfs_core.h +++ b/src/include/cbfs_core.h @@ -88,9 +88,9 @@ /* FIXME: This could also be 0xFFFF0000 with HIVECS enabled */ #define CBFS_HEADPTR_ADDR 0x0000000C #endif -#define VERSION1 0x31313131 -#define VERSION2 0x31313132 -#define VERSION VERSION2 +#define CBFS_HEADER_VERSION1 0x31313131 +#define CBFS_HEADER_VERSION2 0x31313132 +#define CBFS_HEADER_VERSION CBFS_HEADER_VERSION2 struct cbfs_header { uint32_t magic; diff --git a/util/cbfstool/cbfs.h b/util/cbfstool/cbfs.h index 5251d65..617eeee 100644 --- a/util/cbfstool/cbfs.h +++ b/util/cbfstool/cbfs.h @@ -23,9 +23,9 @@ #define CBFS_HEADER_MAGIC 0x4F524243 #define CBFS_HEADPTR_ADDR_X86 0xFFFFFFFC -#define VERSION1 0x31313131 -#define VERSION2 0x31313132 -#define VERSION VERSION2 +#define CBFS_HEADER_VERSION1 0x31313131 +#define CBFS_HEADER_VERSION2 0x31313132 +#define CBFS_HEADER_VERSION CBFS_HEADER_VERSION2 struct cbfs_header { uint32_t magic; diff --git a/util/cbfstool/common.c b/util/cbfstool/common.c index befdc3f..3b63e54 100644 --- a/util/cbfstool/common.c +++ b/util/cbfstool/common.c @@ -143,7 +143,7 @@ void recalculate_rom_geometry(void *romarea) } /* Update old headers */ - if (master_header->version == VERSION1 && + if (master_header->version == CBFS_HEADER_VERSION1 && ntohl(master_header->architecture) == CBFS_ARCHITECTURE_UNKNOWN) { dprintf("Updating CBFS master header to version 2\n"); master_header->architecture = htonl(CBFS_ARCHITECTURE_X86); @@ -583,7 +583,7 @@ int create_cbfs_image(const char *romfile, uint32_t _romsize, arm_vec[0] = htonl(0x0e0000ea); // branch to . + 64 bytes master_header->magic = ntohl(CBFS_HEADER_MAGIC); - master_header->version = ntohl(VERSION); + master_header->version = ntohl(CBFS_HEADER_VERSION); master_header->romsize = htonl(romsize); master_header->bootblocksize = htonl(bootblocksize); master_header->align = htonl(align); @@ -612,7 +612,7 @@ int create_cbfs_image(const char *romfile, uint32_t _romsize, bootblocksize - sizeof(struct cbfs_header)); master_header->magic = ntohl(CBFS_HEADER_MAGIC); - master_header->version = ntohl(VERSION); + master_header->version = ntohl(CBFS_HEADER_VERSION); master_header->romsize = htonl(romsize); master_header->bootblocksize = htonl(bootblocksize); master_header->align = htonl(align); diff --git a/util/nvramtool/cbfs.h b/util/nvramtool/cbfs.h index 5f9db8d..bf5ca95 100644 --- a/util/nvramtool/cbfs.h +++ b/util/nvramtool/cbfs.h @@ -89,7 +89,7 @@ typedef uint8_t u8; #define CBFS_HEADER_MAGIC 0x4F524243 #define CBFS_HEADPTR_ADDR 0xFFFFFFFc -#define VERSION1 0x31313131 +#define CBFS_HEADER_VERSION1 0x31313131 struct cbfs_header { u32 magic;

1 0

Re: [coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco
by David Hubbard 03 Jan '13

03 Jan '13

On Thu, Jan 3, 2013 at 4:23 PM, gary sheppard <rhyotte(a)gmail.com> wrote: > I very much wish people would listen to what Ron just said! > > As for why they are lining up behind it? Personally I think they are > afraid to be seen as "reactionary" and against "progress". After all > "everyone" knows secureboot will make life in computing land *Perfect*! The > way it has been dressed up and loudly presented to World_+_Dog makes it > seem as though anyone against it is against "progress"! > > Numerous security experts have already said it is anything but secure, and > it will never be secure. They have only said this quietly, and that "voice" > has been minimalized, while "PROGRESS" is shouted to the heavens. Hey, look > at android and how phone makers "lock" it down. Does it stay locked? No! > Come on people, put your heads out of... ;) > > Gary > When the FSF has been right and "everyone in the open source community" opposed them, they didn't back down. I put "everyone..." in quotes because it hasn't always been the same community, but I do feel that the term open source isn't used by the FSF for a good reason. I'm not trying to attack people for talking about the open source community -- rather, I believe the FSF was successful for example in establishing the GPL as a popular license specifically because they had the right approach. I think they did what Mahatma Gandhi did, which was to carefully evaluate what response would *work* and then keep executing on that, basically flawlessly, until it did work. A counterexample would have been the Hurd kernel, because it apparently wasn't executed right (again, not trying to pick on something) -- but if the idea is sound, it could still be pulled off. The FSF has taken lots of dings over the years for standing up for what they believed, but they have still succeeded. If Secure Boot is a bad idea (I believe it is) -- no need to attack corporate-sponsored efforts to line up behind it. I personally use Gentoo Linux which means my kernels are compiled right on my own box. Secure Boot will never work for that (specifically, getting each kernel signed for each user would never scale). Sure, I could use a shim but for me that's equivalent to accepting defeat. I suppose we could thank the corporate-sponsored bootloaders that will make an easy path to boot and install linux during this period of uncertainty. However, Ron, let me buy you a drink sometime: we need a better solution. Coreboot could do that. "Never give in. Never give in. Never, never, never, never—in nothing, great or small, large or petty—never give in, except to convictions of honour and good sense. Never yield to force. Never yield to the apparently overwhelming might of the enemy." David

1 0

Patch merged into coreboot/master: 858b650 cleanup some exynos5250 uart code
by gerrit＠coreboot.org 03 Jan '13

03 Jan '13

the following patch was just integrated into master: commit 858b65028e02d4e2460a9f6033aec570006b9d0b Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:56:22 2012 -0800 cleanup some exynos5250 uart code This just cleans out some unused headers and tidies up the early serial code. TODO: Clean-up or replace FDT code, make "base_port" easier to configure. A bit of cleanup based on earlier patches. Change-Id: Ie77ee6d4935346e0053c09252055662f1a45d5f5 Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Reviewed-on: http://review.coreboot.org/2084 Tested-by: build bot (Jenkins) Build-Tested: build bot (Jenkins) at Fri Jan 4 01:43:41 2013, giving +1 Reviewed-By: David Hendricks <dhendrix(a)chromium.org> at Fri Jan 4 01:38:27 2013, giving +2 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Fri Jan 4 01:45:26 2013, giving +2 See http://review.coreboot.org/2084 for details. -gerrit

1 0

Patch set updated for coreboot: 1310fe8 cleanup some exynos5250 uart code
by Ronald G. Minnich 03 Jan '13

03 Jan '13

Ronald G. Minnich (rminnich(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2084 -gerrit commit 1310fe8fb95be9c33952e4873bc8cd7eb93de9d8 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:56:22 2012 -0800 cleanup some exynos5250 uart code This just cleans out some unused headers and tidies up the early serial code. TODO: Clean-up or replace FDT code, make "base_port" easier to configure. A bit of cleanup based on earlier patches. Change-Id: Ie77ee6d4935346e0053c09252055662f1a45d5f5 Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/cpu/samsung/exynos5250/uart.c | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/src/cpu/samsung/exynos5250/uart.c b/src/cpu/samsung/exynos5250/uart.c index 2d7bf38..b219f48 100644 --- a/src/cpu/samsung/exynos5250/uart.c +++ b/src/cpu/samsung/exynos5250/uart.c @@ -21,15 +21,9 @@ * */ -//#include <common.h> -//#include <linux/compiler.h> #include <types.h> #include <uart.h> #include <arch/io.h> -//#include <asm/arch-exynos/spl.h> -//#include <asm/global_data.h> -//#include <fdtdec.h> -//#include <serial.h> #include <console/console.h> /* for __console definition */ @@ -180,8 +174,6 @@ static unsigned char exynos5_uart_rx_byte(void) /* * Output a single byte to the serial port. */ -/* FIXME: ordering of arguments for coreboot v. u-boot for tx_byte */ -//static void exynos5_tx_byte(const char c, const int dev_index) static void exynos5_uart_tx_byte(unsigned char data) { // struct s5p_uart *const uart = s5p_get_base_uart(dev_index); @@ -198,14 +190,6 @@ static void exynos5_uart_tx_byte(unsigned char data) #ifndef __PRE_RAM__ static const struct console_driver exynos5_uart_console __console = { -//static const struct console_driver exynos5_uart_console __console = { -#if 0 - void (*init)(void); - void (*tx_byte)(unsigned char byte); - void (*tx_flush)(void); - unsigned char (*rx_byte)(void); - int (*tst_byte)(void); -#endif .init = exynos5_init_dev, .tx_byte = exynos5_uart_tx_byte, // .tx_flush = exynos5_uart_tx_flush, @@ -213,11 +197,6 @@ static const struct console_driver exynos5_uart_console __console = { // .tst_byte = exynos5_uart_tst_byte, }; #else -/* for romstage_console... */ -//void (*uart_init)(void) = exynos5_init_dev; -//unsigned char (*uart_rx_byte)(unsigned base_port) = exynos5_uart_rx_byte; -//void (*uart_tx_byte)(unsigned base_port, unsigned char data) = exynos5_uart_tx_byte; -/* FIXME: trivial wrappers */ void uart_init(void) { exynos5_init_dev();

1 0

Patch merged into coreboot/master: 801467f enable early serial console on exynos5250
by gerrit＠coreboot.org 03 Jan '13

03 Jan '13

the following patch was just integrated into master: commit 801467f30ad08a69fa4a1ce84b5aeddabecd1185 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:55:29 2012 -0800 enable early serial console on exynos5250 Change-Id: Ib16308c72b86860e80caec96202c42991a7b1d1a Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Reviewed-on: http://review.coreboot.org/2085 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Jan 3 20:08:02 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Fri Jan 4 01:36:48 2013, giving +2 See http://review.coreboot.org/2085 for details. -gerrit

1 0

Patch merged into coreboot/master: 6a503b6 make early serial console support more generic
by gerrit＠coreboot.org 03 Jan '13

03 Jan '13

the following patch was just integrated into master: commit 6a503b6a0f08bf4236c4c37d75c67182a7af4b02 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:28:43 2012 -0800 make early serial console support more generic This patch makes pre-RAM serial init more generic, particularly for platforms which do not necessarily need cache-as-RAM in order to use the serial console and do not have a standard 8250 serial port. This adds a Kconfig variable to set romstage-* for very early serial console init. The current method assumes that cache-as-RAM should enable this, so to maintain compatibility selecting CACHE_AS_RAM will also select EARLY_SERIAL_CONSOLE. The UART code structure needs some rework, but the use of ROMCC, romstage, and then ramstage makes things complex. uart.h now includes all .h files for all uarts. All 2 of them. This is actually a simplifying change. Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Reviewed-on: http://review.coreboot.org/2086 Tested-by: build bot (Jenkins) Build-Tested: build bot (Jenkins) at Fri Jan 4 01:30:21 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Fri Jan 4 01:36:27 2013, giving +2 See http://review.coreboot.org/2086 for details. -gerrit

1 0

Patch set updated for coreboot: 28ed5e7 make early serial console support more generic
by David Hendricks 03 Jan '13

03 Jan '13

David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2086 -gerrit commit 28ed5e78f6d195ea63755a457b962620a2603467 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:28:43 2012 -0800 make early serial console support more generic This patch makes pre-RAM serial init more generic, particularly for platforms which do not necessarily need cache-as-RAM in order to use the serial console and do not have a standard 8250 serial port. This adds a Kconfig variable to set romstage-* for very early serial console init. The current method assumes that cache-as-RAM should enable this, so to maintain compatibility selecting CACHE_AS_RAM will also select EARLY_SERIAL_CONSOLE. The UART code structure needs some rework, but the use of ROMCC, romstage, and then ramstage makes things complex. uart.h now includes all .h files for all uarts. All 2 of them. This is actually a simplifying change. Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce Signed-off-by: David Hendricks <dhendrix(a)chromium.org> Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/console/Kconfig | 7 +++++++ src/console/Makefile.inc | 2 +- src/console/console.c | 4 +++- src/cpu/Kconfig | 1 + src/cpu/samsung/Kconfig | 1 + src/cpu/samsung/exynos5250/uart.c | 6 +++--- src/cpu/samsung/exynos5250/uart.h | 1 + src/include/uart.h | 22 ++++++++++++++++------ src/include/uart8250.h | 1 - 9 files changed, 33 insertions(+), 12 deletions(-) diff --git a/src/console/Kconfig b/src/console/Kconfig index 117fdb8..b1f41de 100644 --- a/src/console/Kconfig +++ b/src/console/Kconfig @@ -5,6 +5,13 @@ config SERIAL_CONSOLE help Send coreboot debug output to a serial port +config EARLY_SERIAL_CONSOLE + bool + depends on SERIAL_CONSOLE + default n + help + Use serial console during early (pre-RAM) boot stages + config CONSOLE_SERIAL8250 bool "Serial port console output (I/O mapped, 8250-compatible)" depends on SERIAL_CONSOLE diff --git a/src/console/Makefile.inc b/src/console/Makefile.inc index a712486..3c4777f 100644 --- a/src/console/Makefile.inc +++ b/src/console/Makefile.inc @@ -10,7 +10,7 @@ smm-y += vtxprintf.c smm-$(CONFIG_SMM_TSEG) += die.c romstage-y += vtxprintf.c -romstage-$(CONFIG_CACHE_AS_RAM) += console.c +romstage-$(CONFIG_EARLY_SERIAL_CONSOLE) += console.c romstage-y += post.c romstage-y += die.c diff --git a/src/console/console.c b/src/console/console.c index d5f25a5..ad8f217 100644 --- a/src/console/console.c +++ b/src/console/console.c @@ -99,13 +99,15 @@ int console_tst_byte(void) #else // __PRE_RAM__ ^^^ NOT defined vvv defined +#include <uart.h> + void console_init(void) { #if CONFIG_USBDEBUG enable_usbdebug(CONFIG_USBDEBUG_DEFAULT_PORT); early_usbdebug_init(); #endif -#if CONFIG_CONSOLE_SERIAL8250 +#if CONFIG_HAVE_UART_IO_MAPPED || CONFIG_HAVE_UART_MEMORY_MAPPED uart_init(); #endif #if CONFIG_DRIVERS_OXFORD_OXPCIE && CONFIG_CONSOLE_SERIAL8250MEM diff --git a/src/cpu/Kconfig b/src/cpu/Kconfig index 383ba79..ddc46cf 100644 --- a/src/cpu/Kconfig +++ b/src/cpu/Kconfig @@ -16,6 +16,7 @@ source src/cpu/x86/Kconfig config CACHE_AS_RAM bool + select EARLY_SERIAL_CONSOLE default !ROMCC config DCACHE_RAM_BASE diff --git a/src/cpu/samsung/Kconfig b/src/cpu/samsung/Kconfig index 4a09ca3..abfc049 100644 --- a/src/cpu/samsung/Kconfig +++ b/src/cpu/samsung/Kconfig @@ -5,6 +5,7 @@ config CPU_SAMSUNG_EXYNOS config CPU_SAMSUNG_EXYNOS5 depends on ARCH_ARMV7 select CPU_SAMSUNG_EXYNOS + select EARLY_SERIAL_CONSOLE bool default n diff --git a/src/cpu/samsung/exynos5250/uart.c b/src/cpu/samsung/exynos5250/uart.c index 3d43976..2d7bf38 100644 --- a/src/cpu/samsung/exynos5250/uart.c +++ b/src/cpu/samsung/exynos5250/uart.c @@ -23,6 +23,7 @@ //#include <common.h> //#include <linux/compiler.h> +#include <types.h> #include <uart.h> #include <arch/io.h> //#include <asm/arch-exynos/spl.h> @@ -34,7 +35,6 @@ #include <cpu/samsung/exynos5-common/exynos5-common.h> #include <cpu/samsung/exynos5250/clk.h> -#include <cpu/samsung/exynos5250/uart.h> #define RX_FIFO_COUNT_MASK 0xff #define RX_FIFO_FULL_MASK (1 << 8) @@ -218,12 +218,12 @@ static const struct console_driver exynos5_uart_console __console = { //unsigned char (*uart_rx_byte)(unsigned base_port) = exynos5_uart_rx_byte; //void (*uart_tx_byte)(unsigned base_port, unsigned char data) = exynos5_uart_tx_byte; /* FIXME: trivial wrappers */ -void uart_init() +void uart_init(void) { exynos5_init_dev(); } -unsigned char uart_rx_byte() +unsigned char uart_rx_byte(void) { return exynos5_uart_rx_byte(); } diff --git a/src/cpu/samsung/exynos5250/uart.h b/src/cpu/samsung/exynos5250/uart.h index 8190c67..033d605 100644 --- a/src/cpu/samsung/exynos5250/uart.h +++ b/src/cpu/samsung/exynos5250/uart.h @@ -68,4 +68,5 @@ static inline int s5p_uart_divslot(void) return 0; } +void uart_init(void); #endif diff --git a/src/include/uart.h b/src/include/uart.h index 931d6dc..6628314 100644 --- a/src/include/uart.h +++ b/src/include/uart.h @@ -15,19 +15,29 @@ * 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., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - * - * FIXME(dhendrix): This file contains generic prototypes for UART functions. - * The existing headers are too specific to the 8250, so we need a better - * abstraction for use with non-8250 UARTs. */ +/* madness. Uarts are a mess. If you include this file, it + * includes ALL uart implementations which may be needed. + * No need to include them separately, and include this file FIRST. + * At least one (but at most one) of the files needs to define + * uart_init(). + */ #ifndef UART_H #define UART_H +#if CONFIG_CONSOLE_SERIAL8250 +#include <uart8250.h> +#endif + +#if CONFIG_CPU_SAMSUNG_EXYNOS5 +#include <cpu/samsung/exynos5250/uart.h> +#endif + +#ifndef __ROMCC__ unsigned char uart_rx_byte(void); void uart_tx_byte(unsigned char data); void uart_tx_flush(void); - -void uart_init(void); +#endif #endif /* UART_H */ diff --git a/src/include/uart8250.h b/src/include/uart8250.h index b00ff48..9af43f2 100644 --- a/src/include/uart8250.h +++ b/src/include/uart8250.h @@ -120,7 +120,6 @@ unsigned char uart8250_rx_byte(unsigned base_port); int uart8250_can_rx_byte(unsigned base_port); void uart8250_tx_byte(unsigned base_port, unsigned char data); void uart8250_tx_flush(unsigned base_port); - /* Yes it is silly to have three different uart init functions. But we used to * have three different sets of uart code, so it's an improvement. */

1 0

← Newer
1
...
52
53
54
55
56
57
58
...
61
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 January 2013