Commit graph

9 commits

Author SHA1 Message Date
Tom Rini
f23f1b5307 MAINTAINERS: Add a number of "common" directories
A number of platforms have "common" directories that are in turn not
listed by the board MAINTAINERS file.  Add these directories in many
cases.

Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2023-07-25 12:44:47 -04:00
Hannes Schmelzer
04b26c9896 board/BuR/*: replace maintainer of BuR boards
Since I'm leaving the company with end of June, the maintainership will
be transferred to Wolfgang Wallner.

Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Signed-off-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
2022-07-01 16:00:36 -04:00
Harald Seiler
35b65dd8ef reset: Remove addr parameter from reset_cpu()
Historically, the reset_cpu() function had an `addr` parameter which was
meant to pass in an address of the reset vector location, where the CPU
should reset to.  This feature is no longer used anywhere in U-Boot as
all reset_cpu() implementations now ignore the passed value.  Generic
code has been added which always calls reset_cpu() with `0` which means
this feature can no longer be used easily anyway.

Over time, many implementations seem to have "misunderstood" the
existence of this parameter as a way to customize/parameterize the reset
(e.g.  COLD vs WARM resets).  As this is not properly supported, the
code will almost always not do what it is intended to (because all
call-sites just call reset_cpu() with 0).

To avoid confusion and to clean up the codebase from unused left-overs
of the past, remove the `addr` parameter entirely.  Code which intends
to support different kinds of resets should be rewritten as a sysreset
driver instead.

This transformation was done with the following coccinelle patch:

    @@
    expression argvalue;
    @@
    - reset_cpu(argvalue)
    + reset_cpu()

    @@
    identifier argname;
    type argtype;
    @@
    - reset_cpu(argtype argname)
    + reset_cpu(void)
    { ... }

Signed-off-by: Harald Seiler <hws@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2021-03-02 14:03:02 -05:00
Simon Glass
401d1c4f5d common: Drop asm/global_data.h from common header
Move this out of the common header and include it only where needed.  In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly.   Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.

Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
2021-02-02 15:33:42 -05:00
Simon Glass
e6385c7e9c Makefile: Rename ALL-y to INPUTS-y
When binman is in use, most of the targets built by the Makefile are
inputs to binman. We then need a final rule to run binman to produce the
final outputs.

Rename the variable to indicate this, and add a new 'inputs' target.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2020-07-28 19:30:39 -06:00
Simon Glass
691d719db7 common: Drop init.h from common header
Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-05-18 17:33:33 -04:00
Simon Glass
db41d65a97 common: Move hang() to the same header as panic()
At present panic() is in the vsprintf.h header file. That does not seem
like an obvious choice for hang(), even though it relates to panic(). So
let's put hang() in its own header.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Migrate a few more files]
Signed-off-by: Tom Rini <trini@konsulko.com>
2020-01-17 17:53:40 -05:00
Simon Glass
9a3b4ceb37 common: Move reset_cpu() to the CPU header
Move this function out of common.h and into a relevant header file.

Signed-off-by: Simon Glass <sjg@chromium.org>
2020-01-17 14:02:31 -05:00
Hannes Schmelzer
c04ac5bd40 board/BuR/brppt2: initial commit
This commit adds support for the brppt2 board. The board is based on the
i.mx6 dual-lite SoC.

Signed-off-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
2019-11-03 21:17:55 +01:00