With this patch, USB Command Verifier is happy with our DFU
implementation on Chapter 9 tests.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

instead of only copying if strlen(s) is less than 32 characters, let's
just copy at most 31 characters regardless of the size of
serial#. This will guarantee that we always have a serial number if
serial# environment variable is set to anything.

Note that without a proper serial number, USB Command Verifier fails
our test of Device Descriptor since we will claim to have a serial
number without really providing one when requested.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>

If last packet is short, we shouldn't write req->length bytes to
non-volatile media, we should write only what's available to us, which
is held in req->actual.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

harmonize result with other handle_XXX() functions: return int for size
remove the define RET_STAT_LEN : no more necessary

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>

return the correct size for DFU_GETSTATE result (1 byte in DFU 1.1 spec)
to avoid issue in USB protocol and the variable "value" is propagated
to req->lenght as all the in the other request with answer
- DFU_GETSTATUS
- DFU_DNLOAD
- DFU_UPLOAD
Then the buffer is correctly treated in USB driver

NB: it was the only request witch directly change "req->actual"

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>

The "DFU descriptor set" must contain the "DFU functional descriptor"
but it is missing today in U-Boot code
(cf: DFU spec 1.1, chapter 4.2 DFU Mode Descriptor Set)
This patch only allocate buffer and copy DFU functional descriptor
after interfaces.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>

Remove sys_proto.h inclusion which is not used by the driver.

Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

  - Fix regressions caused by the previous reworks
  - Add pin configuration support
  - Re-work SPL code
  - Update DRAM and PLL setup code
  - Enable needed configs, disable unneeded configs

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Re-use of routines embedded in the Boot ROM requires a function
pointer table for each SoC.  This is not nice in terms of the
maintainability in a long run.

Implement simple eMMC load APIs that are commonly used for LD11,
LD20, and hopefully future SoCs.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This command is useful to see which config options are enabled on
the running U-Boot image.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Enable CONFIG_CMD_GPT, keeping CONFIG_SPL_EFI_PARTITION because the
SPL for UniPhier platform does not recognize any partitions.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The SPL for UniPhier platform does not recognize any partitions.
Do not compile unneeded features.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

For LD11 and LD20 SoCs, the RST_n pin is asserted by default.  If
the EXT_CSD[162], bit[1:0] (RST_n_ENABLE) is fused, the eMMC device
would stay in the reset state until its RST_n pin is deasserted by
software.

Currently, this is cared by an ad-hoc way because the eMMC hardware
reset provider is not supported in U-Boot for now.  This code should
be re-written once the "mmc-pwrseq-emmc" binding is supported.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

If the DRAM clock duty does not meet the allowable tolerance,
it is marked in an efuse register.  If the register is fused,
the boot code should compensate for the DRAM clock duty error.

Signed-off-by: Kotaro Hayashi <hayashi.kotaro@socionext.com>
[masahiro: simplify code, add git-log]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This parameter is redundant because we can know the number of
channels by checking if dram_ch[2].size is zero.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The current implementation has ugly switch statements here and there,
and duplicates similar code.  Rework it using table lookups for SoC
data and reduce code duplication.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The spl_boot_mode() is unrelated to the other code in this file.
Besides, this function is only called from common/spl/spl_mmc.c,
so it is reasonable to guard with CONFIG_SPL_MMC_SUPPORT.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Currently, arch/arm/mach-uniphier/boot-mode/boot-mode.c is messed up
with unrelated code; there is no reason why the "mmcsetn" command
must be placed in this file.

Split out the MMC code into arch/arm/mach-uniphier/mmc-first-dev.c.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

This feature is seldom used these days on UniPhier boards.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Since commit 26b09c02 ("ARM: uniphier: move SBC and Support Card
init code to U-Boot proper"), SPL does not need pin-mux settings for
the System Bus.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

For the memory footprint reason, the Boot ROM can not load the ARM
Trusted Firmware BL1 directly when Trusted Board Boot is enabled.
The second stage loader is Socionext's own firmware, so rename it
for clarification.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Support the following DT properties:
  "bias-disable"
  "bias-pull-up"
  "bias-pull-down"
  "bias-pull-pin-default"
  "input-enable"
  "input-disable"

My main motivation is to support pull up/down biasing.  For Pro5 and
later SoCs, the pupdctrl register number is the same as the pinmux
number, so this feature can be supported without having big pin
tables.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The LD11 SoC is equipped with USB EHCI controllers.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The base address of each DRAM channel can be calculated from other
parameters, so does not need hard-coding.  What we need is the size
of each DRAM channel and DRAM_SPARSE flag to decide the start address
of DRAM channel 1.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Since commit c0efc314 ("ARM: uniphier: change CONFIG_SPL_PAD_TO
to 128KB"), the u-boot.bin should be burned at the offset 0x20000.
I missed to update README.uniphier in that commit.  Now updating.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Since commit 26b09c02 ("ARM: uniphier: move SBC and Support Card
init code to U-Boot proper"), the System Bus is initialized by
board_init().  The show_board_info() is called from board_init_f()
by default, so the revision register of the Micro Support Card may
not be accessed at this point.  Show its revision after the System
Bus is initialized.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Now the "for" loop here iterates on the detected memory banks.
It must skip unused DRAM banks.

Fixes: c995f3a3 ("ARM: uniphier: use gd->bd->bi_dram for memory reserve on LD20 SoC")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

If SG_MEMCONF_CH2_DISABLE bit is set, the DRAM channel 2 is unused.
The register settings for the ch2 should be ignored.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Commit a8e6300d ("ARM: uniphier: refactor spl_init_board()")
accidentally dropped dcache_disable() call.  Since then, the SPL of
LD11 and LD20 failed to load U-Boot proper.

Fixes: a8e6300d ("ARM: uniphier: refactor spl_init_board()")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Currently the system hangs when the 'videomode' variable is not present
and a reset command is issued:

=> setenv videomode
=> saveenv
=> reset

(Board hangs)

lcdif_power_down() assumes that the LCDIF controller has been properly
configured and enabled, which may not be true.

To fix this issue check whether panel.frameAdrs has been initialized and
in case it has not been initialized, do not continue with the LCDIF
powerdown sequence.

Tested on a imx7dsabresd board.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Anatolij Gustschin <agust@denx.de>

There is no microcode update available for SoCs used on Intel MID
platforms.

Use conditional to bypass it.

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Intel MID platform boards have special treatment, such as boot parameter
setting.

Assign hardware_subarch accordingly if CONFIG_INTEL_MID is set.

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vincent Tinelli <vincent.tinelli@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Intel Mobile Internet Device (MID) platforms have special treatment in
some cases, such as CPU enumeration or boot parameters configuration.

Besides that several drivers are specifically developed for the IP
blocks found on Intel MID platforms. Those drivers will be dependent to
this option.

Here we introduce specific quirk option for such cases.

It is supposed to be selected by Intel MID platform boards, for example,
Intel Edison.

Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Depending upon the compiler used, IRQ entries could vary in sizes. With
GCC 5.x, the code generator will use short jumps for some IRQ entries
but near jumps for others. For example, GCC 5.4.0 generates the
following:

$ objdump -d interrupt.o
<snip>
00000207 <irq_18>:
207:   6a 12                   push   $0x12
209:   eb 85                   jmp    190 <irq_common_entry>

0000020b <irq_19>:
20b:   6a 13                   push   $0x13
20d:   eb 81                   jmp    190 <irq_common_entry>

0000020f <irq_20>:
20f:   6a 14                   push   $0x14
211:   e9 7a ff ff ff          jmp    190 <irq_common_entry>

00000216 <irq_21>:
216:   6a 15                   push   $0x15
218:   e9 73 ff ff ff          jmp    190 <irq_common_entry>

This causes a problem in cpu_init_interrupts(), because the IDT setup
assumed same sizes for all IRQ entries. GCC 4.x always generated 32-bit
jumps, so this previously was not a problem.

The fix is to force 32-bit near jumps for all entries within the
inline assembly. This works for GCC 5.x, and 4.x was already using
that form of jumping.

Signed-off-by: Jason Tang <tang@jtang.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

This is no longer used anywhere.

Signed-off-by: Tom Rini <trini@konsulko.com>

When using early malloc the allocated memory can overflow into the SRAM
scratch space, move NON_SECURE_SRAM_IMG_END down a bit to allow more
dynamic allocation at the expense of a slightly smaller maximum image
size.

Signed-off-by: Andrew F. Davis <afd@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>