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>
Based on dt-specs fixed-link doesn't require phy-handle to be used.
Fix driver to only read phy related setting when phy-handle is found.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
A lot of goodness in this release. We're *very* close to running the
UEFI Shell and SCT natively. The only missing piece are HII protocols.
- FAT write support (needed for SCT)
- improved FAT directory support (needed for SCT)
- RTC support with QEMU -M virt
- Sandbox support (run UEFI binaries in Linux - yay)
- Proper UTF-16 support
- EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell)
- EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell)
- Fix window size determination
- Fix Tegra by explicitly unmapping RAM
- Clean up handle entanglement
- Lots of generic code cleanup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJbq6+cAAoJECszeR4D/txgV1cP+wZPVsY/kRDwCZ8PODOIyLW/
YWWX0CHOUNIXcvWyrQQVflRKE7IbsoPNU+PxOze/toBZvNGZofCqd/P0sT0kk8UU
/aQ55+Hn8/N4etysKxhk2uszBuEXZsOdprNV3H7tO9vKsMHpImAdLvIyviYK0eCF
WnNsmDVFv/W4M5IWDJrS7KqwTuLPYE5Xli9BW/O2qi8NOvpfyb4EEqdL7OHyHAxe
8zpzyaRXJkPcgPkJ6z3WZ+BmAuXSl5DsLWqfsnZJQzkXatRhT8PneRk787e+xK3A
OEFarj5t/94T1KivxquM9iYi0NzwGWrrCfRzbQh5klV4Z/bRYHbGQ92j6iZyfnpj
0zvWrJCalDaUz310BKZDyzKYQnoDj5/iYaMJHtaG6zmkXCzM41kniGKxuy/3IpTB
ozeFtH2AOwlAFZRIzQiazkyU0bizis2Y/K4xzOQczvVajdLW0DsLXL/hyqaFaGO2
3oVK350FXMHKa1UhpsG05aoQvyYq8N4YVEfOSdBKah8qhhMG8zZ2IaX5oheZJjr4
yPV8iaSj8trX3mI9clsnX9YT7qJdcS188JYSii+8SVpVH4VpgwvUSHfDqznn7JNz
COue6rFo9sg55Le9OsoxUgaQ5GO4oz+5iGmfyBmOtQ3n83JxmP4CJK84Ykw2i9fi
sxJR6aNtktsLhfYhlDO/
=ZuJG
-----END PGP SIGNATURE-----
Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
Patch queue for efi - 2018-09-26
A lot of goodness in this release. We're *very* close to running the
UEFI Shell and SCT natively. The only missing piece are HII protocols.
- FAT write support (needed for SCT)
- improved FAT directory support (needed for SCT)
- RTC support with QEMU -M virt
- Sandbox support (run UEFI binaries in Linux - yay)
- Proper UTF-16 support
- EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell)
- EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell)
- Fix window size determination
- Fix Tegra by explicitly unmapping RAM
- Clean up handle entanglement
- Lots of generic code cleanup
[trini: Fixup merge conflict in include/configs/qemu-arm.h]
Signed-off-by: Tom Rini <trini@konsulko.com>
When running sandbox with the new pointer sanitization we just recently
introduced, we're running into a case with FIT images where we end up
interpreting pointers as addresses.
What happened is that most callers of set_working_fdt_addr() simply
convert pointers into addresses without taking into account that they
might be 2 separate address spaces. Fix the callers up to map their
pointers into addresses.
This makes sandbox tests pass for me again.
Signed-off-by: Alexander Graf <agraf@suse.de>
Only add CONFIG_DISPLAY to defconfig because CONFIG_I2C_EDID
is automatically selected by CONFIG_DISPLAY
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
max-speed property is part of phynode and it has to be
read using ofnode_read_u32_default(). This fixes the issue
of incorrect max-speed read from DT.
Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Tested-by: York Sun <york.sun@nxp.com>
This patch modifies PL bitstream loading sequence as per
latest Xilfpga which supports all variants of bitstream images
generated from vivado and from bootgen. With this new change in
Xilfpga, uboot doesn't need to validate and swap bitstream as it will
be taken care inside Xilfpga. ZynqMP PL driver now checks for supporting
PMUFW version before skipping the validation and swap sequence as there
can be old PMUFW which doesn't supports this feature. In this case, driver
uses old way of PL bitstream loading sequence.
Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Modify the zynqmp_pmufw_version() routine to return PMUFW version so
that it can be reused wherever required. Get PMUFW version from PMU
only once at bootup and later just return stored value.
Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch moves the PM version related macros to .h file so that
they can be reused in other files.
Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Now that we already disable the "strict-aliasing" globally, remove
the duplicates in the nds32/riscv/x86 arch-specific Makefiles.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Rick Chen <rick@andestech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The -fstrict-aliasing option is implicitly enabled at levels -O2,
-O3, -Os by GCC. This option allows the compiler to assume the
strictest aliasing rules applicable to the language being compiled.
For example, the practice of reading from a different union member
than the one most recently written to (called "type-punning") is
common. In this case, "type-punning" only works if the memory is
accessed through the union type, but might not work by taking the
address, casting the resulting pointer and dereferencing the result,
which is an undefined behavior per the "strict aliasing rules".
GCC's -Wstrict-aliasing (included in -Wall) option does not catch
all cases, but does attempt to catch the more common pitfalls. So
there are cases that GCC does not report but the codes are violating
the "strict aliasing rules".
Given lots of codes that may be written to rely on "type-punning",
and Linux kernel disables it by -fno-strict-aliasing globally, since
U-Boot currently does this on nds32/riscv/x86 builds only, extend
this for all architecture builds.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
AM654 uses a UART controller that is compatible (partially) with
existing OMAP UART, Introduce a compatible for adding support
for this controller.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
This option has never been used for anything. Drop it.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
These options are not used or necessary when device model is being used
for SCSI. Just drop them.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
When using device model this sort of hardcoded limits aren't used or
necessary.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
The loop in ahci_start_ports() is looping over the maximum number of
SCSI devices in the system, which can be larger than the amount of ports
a particular AHCI controller has. The extra looping isn't directly
harmful because the link_port_map bitmap won't have the bit set for a
nonexistent port, but it is wasteful. Replace the loop limit with the
port count of the AHCI controller instead.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
