08 Aug, 2015
3 commits
-
Add alias for the SD/MMC controller, so it can be located by U-Boot OF support.
Signed-off-by: Marek Vasut
Cc: Dinh Nguyen -
The SPI aliases are completely wrong. First, they point to non-existing
/spi@.* nodes instead of the correct /soc/spi@.* nodes. Second, the use
ad-hoc string instead of a handle. Furthermore, they are copied multiple
times in each board DTS.So fix it such that we move these into socfpga.dtsi and make them use
the usual handles.Signed-off-by: Marek Vasut
Cc: Dinh Nguyen -
In case the FPGA bitstream is aligned to 4 bytes, skip the
part of the assembler which handles unaligned bitstream.
Otherwise, that part will loop indefinitelly.Signed-off-by: Marek Vasut
Cc: Dinh Nguyen
07 Aug, 2015
8 commits
-
P2371-0000 is a P2581 or P2530 CPU board married to a P2595 I/O
board. The combination contains SoC, DRAM, eMMC, SD card slot,
HDMI, USB micro-B port, Ethernet via USB3, USB3 host port, SATA,
a GPIO expansion header, and an analog audio jack.Signed-off-by: Stephen Warren
Reviewed-by: Simon Glass
Signed-off-by: Tom Warren -
E2220-1170 is a Tegra210 bringup board with onboard SoC, DRAM,
eMMC, SD card slot, HDMI, USB micro-B port, and sockets for various
expansion modules.Signed-off-by: Stephen Warren
Signed-off-by: Tom Warren -
CONFIG_MAX77620_POWER isn't used anywhere. Don't define it in p2571.h.
Signed-off-by: Stephen Warren
Reviewed-by: Simon Glass
Signed-off-by: Tom Warren -
T124/210 requires some specific configuration (VPR setup) to
be performed by the bootloader before the GPU can be used.
For this reason, the GPU node in the device tree is disabled
by default. This patch enables the node if U-boot has performed
VPR configuration.Boards enabled by this patch are T124's Jetson TK1 and Venice2
and T210's P2571.Signed-off-by: Alexandre Courbot
Cc: Stephen Warren
Cc: Tom Warren
Signed-off-by: Tom Warren -
U-boot is responsible for enabling the GPU DT node after all necessary
configuration (VPR setup for T124) is performed. In order to be able to
check whether this configuration has been performed right before booting
the kernel, make it happen during board_init().Also move VPR configuration into the more generic gpu.c file, which will
also host other GPU-related functions, and let boards specify
individually whether they need VPR setup or not.Signed-off-by: Alexandre Courbot
Cc: Stephen Warren
Cc: Tom Warren
Signed-off-by: Tom Warren -
Add a comment block to the top of each generated Tegra pinmux header file
indicating that the file was auto-generated, should not be manually
edited, and with a pointer to the tool and command used to generate it.Signed-off-by: Stephen Warren
Reviewed-by: Simon Glass
Signed-off-by: Tom Warren -
Additionally, ARM64 devices typically run a secure monitor in EL3 and
U-Boot in EL2, and set up some secure RAM carve-outs to contain the EL3
code and data. These carve-outs are located at the top of 32-bit address
space. Restrict U-Boot's RAM usage to well below the location of those
carve-outs. Ideally, we would the secure monitor would inform U-Boot of
exactly which RAM it could use at run-time. However, I'm not sure how to
do that at present (and even if such a mechanism does exist, it would
likely not be generic across all forms of secure monitor).Signed-off-by: Stephen Warren
Signed-off-by: Tom Warren
06 Aug, 2015
29 commits
-
At present lower case is used for the regulator names in the device tree.
The kernel uses upper case and U-Boot will require this also since it will
move to a case-sensitive name check.Signed-off-by: Simon Glass
-
Enable the debug UART and emit a single 'a' early in the init sequence to
show that it is working.Unfortunately the debug UART implementation needs a stack to work. I cannot
seem to remove this limitation as the absolute 'jmp %eax' instruction goes
off into the weeds.So this means that the character output cannot be any earlier than
car_init_ret, where memory is available for a stack.Signed-off-by: Simon Glass
Reviewed-by: Lukasz Majewski -
This function comment has a typo. Fix it.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng -
Some devices are bound entirely by probing and do not have the benefit of
a device tree to give them a name. This is very common with PCI and USB. In
most cases this is fine, but we should add an official way to set a device
name. This should be called in the device's bind() method.Signed-off-by: Simon Glass
Reviewed-by: Bin Meng -
This should be used for sandbox. We can convert at least one driver to use
it, but in the meantime, enable the feature so that the code is
build-tested.Signed-off-by: Simon Glass
-
This new command can dump all device resources associated to
each device. The fields in every line shows:
- The address of the resource
- The size of the resource
- The name of the release function
- The stage in which the resource has been acquired (BIND/PROBE)Currently, there is no driver using devres, but if such drivers are
implemented, the output of this command should look like this:=> dm devres
- root_driver
- soc
- extbus
- serial@54006800
bfb541e8 (8 byte) devm_kmalloc_release BIND
bfb54440 (4 byte) devm_kmalloc_release PROBE
bfb54460 (4 byte) devm_kmalloc_release PROBE
- serial@54006900
bfb54270 (8 byte) devm_kmalloc_release BIND
- gpio@55000000
- i2c@58780000
bfb5bce8 (12 byte) devm_kmalloc_release PROBE
bfb5bd10 (4 byte) devm_kmalloc_release PROBE
- eeprom
bfb54418 (12 byte) devm_kmalloc_release BINDSigned-off-by: Masahiro Yamada
Acked-by: Simon Glass -
Currently, Devres requires additional 16 byte for each allocation,
which is not so insignificant in some cases.Add CONFIG_DEVRES to make this framework optional.
If the option is disabled, devres functions fall back to
non-managed variants. For example, devres_alloc() to kzalloc(),
devm_kmalloc() to kmalloc(), etc.Because devres_head is also surrounded by an ifdef conditional,
there is no memory overhead when CONFIG_DEVRES is disabled.Signed-off-by: Masahiro Yamada
Suggested-by: Simon Glass
Acked-by: Simon Glass -
devm_kmalloc() is identical to kmalloc() except that the memory
allocated with it is managed and will be automatically released
when the device is removed/unbound.Likewise for the other variants.
Signed-off-by: Masahiro Yamada
Acked-by: Simon Glass -
In U-Boot's driver model, memory is basically allocated and freed
in the core framework. So, low level drivers generally only have
to specify the size of needed memory with .priv_auto_alloc_size,
.platdata_auto_alloc_size, etc. Nevertheless, some drivers still
need to allocate/free memory on their own in case they cannot
statically know the necessary memory size. So, I believe it is
reasonable enough to port Devres into U-boot.Devres, which originates in Linux, manages device resources for each
device and automatically releases them on driver detach. With devres,
device resources are guaranteed to be freed whether initialization
fails half-way or the device gets detached.The basic idea is totally the same to that of Linux, but I tweaked
it a bit so that it fits in U-Boot's driver model.In U-Boot, drivers are activated in two steps: binding and probing.
Binding puts a driver and a device together. It is just data
manipulation on the system memory, so nothing has happened on the
hardware device at this moment. When the device is really used, it
is probed. Probing initializes the real hardware device to make it
really ready for use.So, the resources acquired during the probing process must be freed
when the device is removed. Likewise, what has been allocated in
binding should be released when the device is unbound. The struct
devres has a member "probe" to remember when the resource was
allocated.CONFIG_DEBUG_DEVRES is also supported for easier debugging.
If enabled, debug messages are printed each time a resource is
allocated/freed.Signed-off-by: Masahiro Yamada
Acked-by: Simon Glass -
Currently, we only have DM_FLAG_ACTIVATED to indicate the device
status, but we still cannot know in which stage is in progress,
binding or probing.This commit introduces a new flag, DM_FLAG_BOUND, which is set when
the device is really bound, and cleared when it is unbound.Signed-off-by: Masahiro Yamada
Acked-by: Simon Glass -
The 'ranges' property can be used to specify a translation from the system
address to the bus address. Add support for this using the dev_get_addr()
function, which devices should use to find their address.Signed-off-by: Simon Glass
-
Add support for driver model, so that CONFIG_DM_ETH can be defined and used
with this driver.Signed-off-by: Simon Glass
-
At present struct eth_device is passed around all over the place. This does
not exist with driver model. Add explicit arguments instead, so that with
driver model we can pass the correct things.Signed-off-by: Simon Glass
-
Instead of returning -1 on error, we should use a proper error number. Fix
the code to conform to this.Signed-off-by: Simon Glass
-
The AX_ prefix comes from the Asix driver. Since this is not that, we should
avoid this confusing prefix.Signed-off-by: Simon Glass
-
Tidy up the include file order before adding more.
Signed-off-by: Simon Glass
-
Add driver model support to this driver so it can be used with the new USB
stack.Signed-off-by: Simon Glass
-
Put all global data in a structure and move (what will be) common code into
common functions. This will make the driver-model conversion much easier.Signed-off-by: Simon Glass
-
This is required on some platforms, so add it.
Signed-off-by: Simon Glass
-
Not all boards use garbage collection in their link step, so we should avoid
adding options that rely on this for prevention of code bloat. Add separate
Kconfig options for syscon and regmap uclasses.Signed-off-by: Simon Glass
-
fdt_addr_t is a physical address. It can be either 64-bit or 32-bit,
depending on the architecture. It should be phys_addr_t instead of
u64 or u32. Similarly, fdt_size_t is changed to phys_size_t.Signed-off-by: York Sun
CC: Simon Glass -
fdt_addr_t is changed to phys_addr_t. The format in debug should be updated
to %pa to match the type.Signed-off-by: York Sun
CC: Simon Glass -
Spring is the first ARM-based HP Chromebook 11. It is similar to snow
and it uses the same Samsung Exynos5250 chip. But has some unusual
features. Mainline support for it has lagged snow (both in kernel and
U-Boot). Now that the exynos5 code is common we can support spring just
by adding a device tree and a few lines of configuration.Signed-off-by: Simon Glass
-
We always use device tree on exynos, so remove the unused code.
Signed-off-by: Simon Glass
-
This has moved to driver model so we can drop the fdtdec support.
Signed-off-by: Simon Glass
-
We have a new one which uses driver model and device tree configuration.
Remove the old one.Signed-off-by: Simon Glass
-
This is not needed with driver mode. Remove it.
Signed-off-by: Simon Glass
-
Remove the old drivers (both the normal one and the cros_ec one) now that
we have new drivers that use driver model.Signed-off-by: Simon Glass
-
Now that most exynos5250 boards can use the generic exynos5 code, switch
over to it and remove the old code.Signed-off-by: Simon Glass
