| Age | Commit message (Collapse) | Author |
|---|
|
The pinmux register data structure describes a subset of the control module
registers, but the address which pointed to the base of the pinmux registers
was actually being set to the beginning of all the control module registers,
not just those having to do with the pinmux. With this address fixed, the UART
now works on the beaglebone black.
Change-Id: I7c99b6f37d7da359af074127cd0c1a86fda2d9a0
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3574
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
I was unable to find documentation that said what mode numbers correspond
to what functionality, so I translated over what U-Boot does.
Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3489
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add a struct for referencing UART registers. The layout is quite
strange on this chip, as the entire register space can take on three
different meanings depending on the line control settings (in the LCR
register) And to make things more confusing, some offsets reference
different registers depending on if a read or a write operation is
used.
Change-Id: Ie62af9c0e0edafd01b81686a0fe5c5c1d4fa06c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3319
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The current method will treat hex values as 0 and would calculate the wrong
size. This change switches back to an earlier method which used shell syntax
to add the offset and size.
Change-Id: I9fb2d9b323f113cc56a5ad2e38b47d2d22084f08
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3432
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The bootblock and ROM stages are the only ones that are really required to be
loaded in the quite limited on chip RAM during startup. Rather than load the
whole image which requires everything to be small, load just the bootblock and
the ROM stage, allowing the rest of the image to be arbitrarily large. Loading
a minimal amount of stuff should also improve boot performance a little bit.
Change-Id: I2fede63b8d3d8f0d880e4a692ae423021f8232b6
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3421
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Loading on an OMAP SOC requires that the first sector of the image have a
configuration header, and, when not an execute in place image, an additional
header which describes how big the image is and where it should be loaded.
This change adds some infrastructure to statically build that header using C
code, and to paste the header onto the front of coreboot.rom in a new top
level target file called MLO.
The configuration header we're using is as inert as possible, in line with
what U-Boot is doing. I think it could be used to give additional
configuration parameters to the built-in ROM on the SOC, but we don't need to
do that, and there didn't seem to be any actual documentation how to do that.
Because the header is built from C and is defined per CPU, it would be
possible to include extra settings in other CPUs if desired.
Adding a new top level build target is a bit disruptive, but should be
contained to the am335x directory and not interfere with other mainboards.
Change-Id: I06d346a4050c20963b3c7c6e8a152070bf2d145a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3332
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some settings in the am335x Kconfig weren't actually used for anything, some
where place holders, and some where left over from another CPU. The memory
addresses are in the internal RAM in the SOC as described in the reference
manual. The stack is put where the internal ROM had its stack, and the
bootblock is put at the bottom of that region as the manual suggests. The
ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the
bootblock currently takes up.
Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3327
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
Initial structure of Beaglebone port
Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
