coreboot-gerrit July 2013

coreboot-gerrit@coreboot.org

1 participants
1030 discussions

Patch merged into coreboot/master: fe64060 exynos5250: De-switch-ify the pinmux configuration code.
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit fe6406033fe327d4ae408b02efc060b4b421bc03 Author: Gabe Black <gabeblack(a)google.com> Date: Sat Jun 15 20:33:05 2013 -0700 exynos5250: De-switch-ify the pinmux configuration code. The pinmux code for the exynos5250 was all bundled into a single, large function which contained a switch statement that would set up the pins for different peripherals within the SOC. There was also a "flags" parameter, the meaning of which, if any, depended on which peripheral was being set up. There are several problems with that approach. First, the code is inefficient in both time and space. The caller knows which peripheral it wants to set up, but that information is encoded in a constant which has to be unpacked within the function before any action can be taken. If there were a function per peripheral, that information would be implicit. Also, the compiler and linker are forced to include the entire function with all its cases even if most of them are never called. If each peripheral was a function, the unused ones could be garbage collected. Second, it would be possible to try to set up a peripheral which that function doesn't know about, so there has to be additional error checking/handling. If each peripheral had a function, the fact that there was a function to call at all would imply that the call would be understood. Third, the flags parameter is fairly opaque, usually doesn't do anything, and sometimes has to have multiple values embedded in it. By having separate functions, you can have only the parameters you actually want, give them names that make sense, and pass in values directly. Fourth, having one giant function pretends to be a generic, portable API, but in reality, the only way it's useful is to call it with constants which are specific to a particular implementation of that API. It's highly unlikely that a bit of code will need to set up a peripheral but have no idea what that peripheral actually is. Call sights for the prior pinmux API have been updated. Also, pinmux initialization within the i2c driver was moved to be in the board setup code where it really probably belongs. The function block that implements the I2C controller may be shared between multiple SOCs (and in fact is), and those SOCs may have different pinmuxes (which they do). Other places this same sort of change can be made are the pinmux code for the 5420, and the clock configuration code for both the 5250 and the 5420. Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3673 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3673 for details. -gerrit

1 0

Patch merged into coreboot/master: 001056f ARM: Tell the linker memset and memcpy are functions.
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit 001056f560dfec46aa98659f318819cce7098e5b Author: Gabe Black <gabeblack(a)google.com> Date: Fri Jun 14 15:53:23 2013 -0700 ARM: Tell the linker memset and memcpy are functions. The memset and memcpy functions are assembled as ARM code, likely because that's the default of the assembler. Without special annotation, the assembler and linker don't know that those symbols are functions which need special handling so that ARM/thumb issues are handled properly. This change adds that annotation which gets those functions working in Coreboot which is compiled as thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the annotation since it just works out in ARM mode, but it's the safe thing to do in case we change that in the future. We should explicitly select ARM vs. thumb when assembling assembly files to be consistent across builds and toolchains. Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01 Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3672 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3672 for details. -gerrit

1 0

Patch merged into coreboot/master: fbb11cf ARM: Separate the early console (romstage) from the bootblock console.
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit fbb11cf97937c345a42a45737fc7a95ee7ee3e7e Author: Gabe Black <gabeblack(a)google.com> Date: Thu Jun 6 00:21:20 2013 -0700 ARM: Separate the early console (romstage) from the bootblock console. It might be that you want an early console in romstage before RAM is up, but you can't or don't want to support the console all the way back in the bootblock. By making the console in those two different environments configurable seperately that becomes possible. On the 5250 console output as early as the bootblock works, but on the 5420 it only starts working in the ROM stage after clocks have been initialized. Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8 Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3671 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3671 for details. -gerrit

1 0

Patch merged into coreboot/master: c2c4f84 google/pit: Don't spew output with GPIO config
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit c2c4f84644bf6f20b0a3b5dffb7edb6a47f02023 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Mon May 20 12:51:02 2013 -0700 google/pit: Don't spew output with GPIO config There are hundreds of GPIOs on the Exynos5420. Don't always print all of them per default. Change-Id: I2152ab760e31a335dbcd9d6ad32cd1eaae4b89bc Signed-off-by: Stefan Reinauer <reinauer(a)chromium.org> Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3670 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3670 for details. -gerrit

1 0

Patch merged into coreboot/master: 37332b6 arch: clean up Kconfig and Makefile
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit 37332b66fa1911144dc2c7cd0bda77f7dbbcfb3b Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Wed May 29 13:10:56 2013 -0700 arch: clean up Kconfig and Makefile remove some unused code Change-Id: I41602fb391c1910c588a4f9dcc7c2edefe8ab5bc Signed-off-by: Stefan Reinauer <reinauer(a)chromium.org> Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3669 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3669 for details. -gerrit

1 0

Patch merged into coreboot/master: 2d81125 exynos5420: Clear the framebuffer before making it uncacheable
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit 2d8112523aa04bca3f4d56d6ba1660082bf279b5 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Mon May 20 15:24:13 2013 -0700 exynos5420: Clear the framebuffer before making it uncacheable If we clear the framebuffer and then flush it back to memory using cache operations, the writes are going to be full cachelines at a time. If we make it uncacheable first, the writes will be serialized writes of whatever sized chunks memset uses, probably 4 bytes or less. Change-Id: I960f87a370e97f9e91236ad796d931573bb3dbb8 Signed-off-by: Stefan Reinauer <reinauer(a)chromium.org> Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3668 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3668 for details. -gerrit

1 0

Patch merged into coreboot/master: 6c184d6 exynos5420: Don't disable and re-enable the MMU when uncaching the framebuffer
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit 6c184d6855a11d42f9d77bc9ddb8dfeb608072b6 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Mon May 20 15:21:48 2013 -0700 exynos5420: Don't disable and re-enable the MMU when uncaching the framebuffer At one time it seemed to be necessary to disable and then re-enable the MMU when setting the framebuffer to be uncache-able due to bugs in the MMU management code. Since those bugs have been fixed, this is no longer necessary. Change-Id: I7ce825cf5eaaa95119364d780cba0935752e4632 Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Signed-off-by: Stefan Reinauer <reinauer(a)chromium.org> Reviewed-on: http://review.coreboot.org/3667 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3667 for details. -gerrit

1 0

Patch merged into coreboot/master: f175191 exynos5420: Simplify the graphics code by eliminating the unused color map
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit f17519120a4d76cd18d12e94987b65b336f32f59 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Mon May 20 15:17:44 2013 -0700 exynos5420: Simplify the graphics code by eliminating the unused color map The code that allocated space for the framebuffer was adding space for a vestigial color map which was never used. It was also passing around a structure which was used to calculate a single value which was already known when that structure was put together. Eliminate the extra space, and pass the single value instead of the structure. Change-Id: I29bc17488539dbe695908e47f0b80c07e102e17d Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Signed-off-by: Stefan Reinauer <reinauer(a)chromium.org> Reviewed-on: http://review.coreboot.org/3666 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3666 for details. -gerrit

1 0

Patch merged into coreboot/master: 1162103 exynos5420: Fix some problems with the clock management code.
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit 1162103958fad815e10b90524560b3b81f2c0b18 Author: Gabe Black <gabeblack(a)google.com> Date: Thu Jun 6 00:14:08 2013 -0700 exynos5420: Fix some problems with the clock management code. The code which figured out the rate of the input clock to a peripheral was doing several things wrong. First, it was using the wrong values when determing what the source of a clock was set to. Second, it was using the wrong offset into that register to find the current source setting. This change fixes the constants which select a clock source which get some more things working, but doesn't attempt to fix the bit position table. Change-Id: Id7482ee1c78cec274353bae3ce2dccb84705c66a Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3665 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3665 for details. -gerrit

1 0

Patch merged into coreboot/master: d63bddc armv7: Reserve space BL1 and checksum header by specifying bootblock offset.
by gerrit＠coreboot.org 10 Jul '13

10 Jul '13

the following patch was just integrated into master: commit d63bddc4991d9ace037fd716b29c3f7253e9ac94 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Tue Jun 11 21:55:58 2013 -0700 armv7: Reserve space BL1 and checksum header by specifying bootblock offset. Not all ARM systems need "BL1", and the layout of BL* and bootblock may be different (ex, Exynos 5250 may use a new BL1 with variable length checksum header). To support that better, define the real base address (and ROM offset) of boot block, and then we can post-processing ROM image file by filling data / checksum and any other information. Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> Signed-off-by: Gabe Black <gabeblack(a)chromium.org> Reviewed-on: http://review.coreboot.org/3664 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org> See http://review.coreboot.org/3664 for details. -gerrit

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit July 2013