The simple pinctrl driver currently available works with the omap3.
Enabling this will use the device tree to automatically set the
pin-muxing for various drivers.
Signed-off-by: Adam Ford <aford173@gmail.com>
Previously poweroff was located under boot. It seems to make more
sense to have it located under the Device access commands.
Signed-off-by: Adam Ford <aford173@gmail.com>
With the omap_mmc driver no longer supporting cd-inverted, this
patch removes all these references since they are not needed.
Signed-off-by: Adam Ford <aford173@gmail.com>
With DM_GPIO and DM_MMC translating GPIO_ACTIVE_LOW, any boards
using the 'cd-invert' option will no longer need to do this. This
patch removes the support for 'invert' from the MMC driver.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Fix warning over when !DM_GPIO]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add commands for fdt overlay merging. This is required for the boot scripts
that detect PDAs and apply specific overlays to the DTB passed on to kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add commands for fdt overlay merging. This is required for the boot scripts
that detect PDAs and apply specific overlays to the DTB passed on to kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add commands for fdt overlay merging. This is required for the boot scripts
that detect PDAs and apply specific overlays to the DTB passed on to kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add commands for fdt overlay merging. This is required for the boot scripts
that detect PDAs and apply specific overlays to the DTB passed on to kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add commands for fdt overlay merging. This is required for the boot scripts
that detect PDAs and apply specific overlays to the DTB passed on to kernel.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Call the PDA detection mechanism at boot time so we can have
the pda environment variable ready for use.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Call the PDA detection mechanism at boot time so we can have
the pda environment variable ready for use.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Call the PDA detection mechanism at boot time so we can have
the pda environment variable ready for use.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Call the PDA detection mechanism at boot time so we can have
the pda environment variable ready for use.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Call the PDA detection mechanism at boot time so we can have
the pda environment variable ready for use.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
This adds the support for PDA detection as common code for
Atmel boards.
Using the one wire interface over GPIO , an EEPROM memory is read
and compared to preprogrammed values for PDA screens TM4300, TM7000
and TM7000B.
Once the PDA is detected, an environment variable is set accordingly.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
SAMA5D4 SoC can have extra clip boards (PDAs) connected, which have
an EEPROM memory for identification. A special GPIO can be used to read
this memory over 1wire protocol.
Enabling one wire and eeprom drivers for this memory.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
SAMA5D2 SoC can have extra clip boards (PDAs) connected, which have
an EEPROM memory for identification. A special GPIO can be used to read
this memory over 1wire protocol.
Enabling one wire and eeprom drivers for this memory.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
SAMA5D2 SoC can have extra clip boards (PDAs) connected, which have
an EEPROM memory for identification. A special GPIO can be used to read
this memory over 1wire protocol.
Enabling one wire and eeprom drivers for this memory.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
SAMA5D3 SoC can have extra clip boards (PDAs) connected, which have
an EEPROM memory for identification. A special GPIO can be used to read
this memory over 1wire protocol.
Enabling one wire and eeprom drivers for this memory.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
SAMA5D2 SoC can have extra clip boards (PDAs) connected, which have
an EEPROM memory for identification. A special GPIO can be used to read
this memory over 1wire protocol.
Enabling one wire and eeprom drivers for this memory.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
To be able to test Dallas onewire protocol and one wire eeproms driver
and subsystem, add in sandbox defconfig the drivers' config.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add basic command for bus information and read for onewire
bus using Dallas 1-Wire protocol.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add a driver that supports Maxim 1 wire EEPROMs families
DS24B33 and DS2431.
Can be extended for other families as well.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: reworked driver]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
When a new device is discovered, this may be a w1 eeprom device.
Attempt to find the proper node and driver from the w1-eeprom subsystem.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
We might want to access data stored onto one wire EEPROMs.
Create a framework to provide a consistent API.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: reworked patch]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: fixed some issues]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
We might want to use 1-Wire devices connected on boards such as EEPROMs in
U-Boot.
Provide a framework to be able to do that.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[eugen.hristev@microchip.com: reworked]
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
This is file system generic loader which can be used to load
the file image from the storage into target such as memory.
The consumer driver would then use this loader to program whatever,
ie. the FPGA device.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Add a document to describe file system firmware loader binding
information.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Provide information about
- overview of file system firmware loader driver model
- describe storage device and partition in device tree source
- describe fie system firmware loader API
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a function to find the block device descriptor of the parent
device.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
[trini: Move function declaration to avoid warning]
Signed-off-by: Tom Rini <trini@konsulko.com>
cmd_ubifs_mount() function would be called directly instead of
involving whole command machinery for mounting ubifs in
generic firmware loader, so some checking codes need to be factored out
into cmd_ubifs_mount() without breaking original functionality design.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
cmd_ubifs_umount() function would be called directly instead of involving
whole command machinery in generic firmware loader, so checking on
ubifs_initialized status need to be done in cmd_ubifs_umount() without
breaking original functionality design.
Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
[trini: Fix conflicting type error in cmd/ubi.c]
Signed-off-by: Tom Rini <trini@konsulko.com>
Add support for Arm Mali Display Processors DP500, DP550 and DP650.
Only one layer is being used to display the console or boot logo,
even if more layers are supported in the hardware.
Signed-off-by: Liviu Dudau <liviu.dudau@foss.arm.com>
When tools are needed but not present, at present we just get an error
which can be confusing for the user. Try to be helpful by reporting the
tool as missing and suggesting a possible remedy.
Also update the Run() method to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Binman currently supports updating the main device tree with things like
the position of each entry. Extend this support to SPL and TPL as well,
since they may need (a subset of) this information.
Also adjust DTB output files to have a .out extension since this seems
clearer than having a .dtb extension with 'out' in the name somwhere.
Also add a few missing comments and update the DT setup code to use
ReadFile and WriteFile().
Signed-off-by: Simon Glass <sjg@chromium.org>
We use a fake device tree in tests most of the time since tests don't
normally care about the actual data. For example, for U-Boot proper we use
U_BOOT_DTB_DATA which is just a four-character string. This makes testing
the image output against an expected value very easy.
However in some cases, such as when the test wants to check that the DT
output containing particular nodes, we do actually need the real DT. Add
support for this, along with a command-line option to select 'test mode'.
Signed-off-by: Simon Glass <sjg@chromium.org>
We always have a device tree for U-Boot proper. But we may also have one
for SPL and TPL. Add a new Entry method to find out what DTs an entry
has, and use that list when updating DTs.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we have a few calls to device-tree functions in binman and plan
to add more as we add new entry types which need to report their results.
It makes sense to put this code in a central place so that we can make
sure all device trees are updated. At present we only have U-Boot proper,
but plan to add SPL and TPL too.
Signed-off-by: Simon Glass <sjg@chromium.org>
