At present these three Kconfigs exist even when bootstage is not enabled.
This is not necessary since bootstage.c is only built if BOOTSTAGE is
enabled.
Make them conditional. Also fix up the overflow message to mention TPL.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present device_bind() does some unnecessary work if a device fails to
bind in SPL. Add the missing conditions.
Also fix a style nit in the same function while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
With of-platdata we always have a dtv struct that holds the platform data
provided by the driver_info record. However, this struct can be empty if
there are no actual devicetree properties provided.
The upshot of empty platform data is that it will end up as a zero-size
member in the BSS section, which is fine. But if the driver specifies
plat_auto then it expects the correct amount of space to be allocated.
At present this does not happen, since device_bind() assumes that the
platform-data size will always be >0. As a result we end up not
allocating the space and just use the BSS region, overwriting whatever
other contents are present.
Fix this by removing the condition that platform data be non-empty, always
allocating space if requested.
This fixes a strange bug that has been lurking since of-platdata was
implemented. It has likely never been noticed since devices normally have
at least some devicetree properties, BSS is seldom used on SPL, the dtv
structs are normally at the end of bss and the overwriting only happens
if a driver changes its platform data.
It was discovered using sandbox_spl, which exercises more features than
a normal board might, and the critical global_data variable 'gd' happened
to be at the end of BSS.
Fixes: 9fa2819009 ("dm: core: Expand platdata for of-platdata devices")
Signed-off-by: Simon Glass <sjg@chromium.org>
Using the internal vs. external pull resistors it is possible to get
27 different combinations from 3 strapping pins. Add an implementation
of this.
This involves updating the sandbox GPIO driver to model external and
(weaker) internal pull resistors. The get_value() method now takes account
of what is driving a pin:
sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
value
outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
external state and we work the final state using those flags and
the internal GPIOD_PULL_UP/DOWN flags
Of course the outside source does not really exist in sandbox. We are just
modelling it for test purpose.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new flag to keep track of whether sandbox is driving the pin, or
whether it is expecting an input signal. If it is driving, then the value
of the pin is the value being driven (0 or 1). If not driving, then we
consider the value 0, since we don't currently handle things like pull-ups
yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
We don't need to implement direction_input() and direction_output()
anymore. Drop them and use update_flags() instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this driver to use the common method of putting the driver
operations in an 'ops' variable install of calling gpio_get_ops()
repeatedly. Make it const since operations do not change.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The new update_flags() method is more flexible since it allows the
driver to see the full flags all at once. Use that in preference to these
two functions. Add comments to that effect.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
It is convenient to be able to adjust some of the flags for a GPIO while
leaving others alone. Add a function for this.
Update dm_gpio_set_dir_flags() to make use of this.
Also update dm_gpio_set_value() to use this also, since this allows the
open-drain / open-source features to be implemented directly in the
driver, rather than using the uclass workaround.
Update the sandbox tests accordingly. This involves a lot of changes to
dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
being reported differently depending on the open drain/open source flags.
Also update the STM32 drivers to let the uclass handle the active low/high
logic.
Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Allow this function to see all flags, including the internal sandbox ones.
This allows the tests to fully control the behaviour of the driver.
To make this work, move the setting of GPIOD_EXT_HIGH -to where the flags
are updated via driver model, rather than the sandbox 'back door'.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
At present we have the concept of a pin's external value. This is what
is used when getting the value of a pin. But we still set the
GPIOD_IS_OUT_ACTIVE flag when changing the value. This is not actually
correct, since if the pin changes from output to input, the external
value need not change. Adjust the logic for this difference.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
At present with the sandbox GPIO driver it is not possible to change the
value of GPIOD_IS_OUT_ACTIVE unless the GPIO is an output. This makes it
hard to test changing the flags since we need to be aware of the internal
workings of the driver.
The feature is designed to aid testing.
Split this feature out into a separate sandbox-specific flag, so that the
flags can change unimpeded. This will make it easier to allow updating the
flags in a future patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the terminology in this driver to reflect that fact that all flags
are handled, not just direction flags.
Create a new access function to get the full GPIO state, not just the
direction flags. Drop the static invalid_dir_flags since we can rely on a
segfault if something is wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
This function can be used to get any flags, not just direction flags.
Rename it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
It is more useful to be able to read all the flags, not just the direction
ones. In fact this is what the STM32 driver does. Update the method name
to reflect this.
Tweak the docs a little and use 'flagsp' as the return argument, as is
common in driver model, to indicate it returns a value.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
The current method is a misnomer since it is also used (e.g. by stm32) to
update pull settings and open source/open drain.
Rename it and expand the documentation to cover a few more details.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
These functions use devicetree and cannot work with of-platdata, which has
no runtime devicetree.
If they are used, the current linker error is confusing, since it talks
about missing functions in the bowels of driver model.
Avoid compiling these functions at all with of-platdata, so that a
straightforward link error points to the problem.
Series-changes; 3
- Fix 'wprl' typo
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
DM_VIDEO migration deadline is already expired, but around
80 Allwinner boards are still using video in a legacy way:
===================== WARNING ======================
This board does not use CONFIG_DM_VIDEO Please update
the board to use CONFIG_DM_VIDEO before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
Convert the legacy video driver over to the DM_VIDEO framework. This is
a minimal conversion: it doesn't use the DT for finding its resources,
nor does it use DM clocks or DM devices for the outputs (LCD, HDMI, CVBS).
Tested in Bananapi M1+ Plus 1920x1200 HDMI out. (Jagan)
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
[Andre: rebase and smaller fixes]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now when usbtty serial console is fixed in U-Boot enable CONFIG_USB_TTY for
Nokia RX-51 board by default.
Fix also USB product id as U-Boot ignores CONFIG_USBD_PRODUCTID macro and
include U-Boot string into USB product name to indicate usage of U-Boot.
CONFIG_CONSOLE_MUX is already used and U-Boot console is available for
all in/out devices. Therefore there is no need to have separate commands
'run sercon', 'run usbcon' and 'run vgacon', so remove them.
As space for U-Boot is limited to 256kB, enable CONFIG_OPTIMIZE_INLINING
and disable some other unused options so CONFIG_USB_TTY can be enabled.
Nokia RX-51 does not have easily accessible UART serial console so the only
option for easy debugging is to use device's keyboard+screen or this usbtty
serial console over USB.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
After removal of MUX configuration there is no need to have extra rx51.h.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
This function is not used and was never called.
This board contains '#define CONFIG_SKIP_LOWLEVEL_INIT' because X-Loader
set everything up, including MUX configuration.
Also this MUX configuration is incorrect and does not match hardware.
So remove this dead, unused and broken code.
This change will decrease size of U-Boot binary.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Function s_init() is called only from lowlevel_init(). So compile it only
when function lowlevel_init() is compiled.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Function lowlevel_init() is called only from cpu_init_crit() and this
function is wrapped into #if .. #endif section. So compile also
lowlevel_init() function under same #if condition.
Function cpy_clk_code() uses lowlevel_init symbol to get address where
go_to_speed code ends. As this symbol is not available anymore when
compiling with CONFIG_SKIP_LOWLEVEL_INIT, defines a new label
go_to_speed_end at the place where go_to_speed code ends.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
All debug messages from ep0.c except a few are printed by dbg_ep0() macro.
So for remaining few exceptions use also dbg_ep0() instead of serial_printf().
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If we do not set FIFO buffer address and size for some endpoint which is in
use then default programmed address 0x0 would be used which is in conflict
with address of FIFO buffer for endpoint 0. Moreover address of FIFO buffer
for endpoint 0 cannot be programmed, it is fixed to 0x0. Sharing address
space between more endpoints cause data loss and unexpected errors.
This patch is fixing transmission of characters over usbtty serial console
and allows using of usbtty for debugging purposes on Nokia N900.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Interrupt for EP0 is indicated in intrtx register via first bit. This bit
is set for both RX and TX despite register has only TX in its name. First
bit in intrrx register is reserved, not used and never set.
So remove calling musb_peri_ep0() function at every iteration of udc_irq()
and musb_peri_rx() and call it only from musb_peri_tx() when correct
interrupt bit in initrtx it set.
Address from SET ADDRESS command must be set to faddr register only after
acknowledging SERV_RXPKTRDY followed by received EP0 interrupt. So prior
calling musb_peri_ep0_set_address() check for EP0 interrupt instead of
(incorrect) MUSB_INTR_SOF interrupt.
This patch fixes issue that host (computer) cannot register U-Boot USB
device and is failing with errors:
usb 1-1: new full-speed USB device number 86 using xhci_hcd
usb 1-1: Device not responding to setup address.
usb 1-1: Device not responding to setup address.
usb 1-1: device not accepting address 86, error -71
U-Boot was writing address to faddr register too early and did not wait for
correct interrupt after which should update address.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If musb_peri_rx_ep() was called to process received HW buffer but U-Boot
cannot read it yet (e.g. because U-Boot SW buffer is full) then interrupt
was marked as processed also when HW buffer stayed unprocessed.
U-Boot tried to process this buffer again when it received interrupt again,
but it can receive it only when sender (host) sends a new data. As sender
(host) is not going to send a new data until U-Boot process current data
this issue caused a deadlock in case sender (host) is emitting data faster
than U-Boot can process it.
Reading musb intrrx register automatically clears this register and marks
interrupt as processed. So to prevent marking interrupt in U-Boot as
processed, adds a new variable pending_intrrx which would contain
unprocessed bits of intrrx register.
For a second step, every time when musb_peri_rx_ep() is called and there
are waiting data to be processed (signaled by MUSB_RXCSR_RXPKTRDY) either
acknowledge sender (via musb_peri_rx_ack()) that whole HW buffer was
processed or set corresponding bit in pending_intrrx that HW buffer was not
fully processed yet and next iteration is required after U-Boot allocates
space for reading HW buffer.
This patch fixes receiving large usb buffers, e.g. file transfer via Kermit
protocol implemented by 'loadb' U-Boot command over usbtty serial console.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
If udc_endpoint_write() was called with bigger payload which does not fit
into one USB packet it is needed to transmit payload in more USB packets.
First packet is transmitted by udc_endpoint_write() call itself and other
packets are put into waiting queue.
Implement function musb_peri_tx() which checks if endpoints are ready for
transmit and continue transmission of waiting queue.
This patch fixes sending big output from printenv command over usbtty
serial console.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>>
PERI_RXCSR is 16bit register so store its value into 16bit local variable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
This patch fixes configuring FIFOs for one-directional endpoints which have
only one queue (either RX or TX, but noth both).
Size of FIFO buffer is 2^(idx+3) bytes and starting address is 2^(addr+3).
Moreover first 64 bytes are reserved for EP0.
Without this patch if FIFO size specified by caller was zero then idx was
incorrectly calculated (expr. ffs(0)-1) and size overflowed in fifosz
register. This register uses has only 4 bits for FIFO size. Moreover
specifying zero buffer size is not possible (with idx=0 is minimal buffer
size 8 bytes).
So even for one-directional endpoints we need to correctly specify both
(RX and TX) FIFO buffer sizes and its addresses.
This patch is fixing calculation of start address and buffer size to
minimal value and ensures that it would not overlap with buffer reserved
for EP0.
This issue caused loose of packets on USB bus in both directions and
basically usbtty was unusable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Without this patch clearing was done only when U-Boot was compiled with
MUSB Host Controller. But clearing of data toggle bit is needed also for
MUSB Device Controller otherwise Device Controller does not work correctly.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
musb udc code depends on usb gadget code provided by CONFIG_USB_DEVICE as
defined in drivers/usb/gadget/Makefile. But this Makefile is not included
into U-Boot build when CONFIG_USB_GADGET is not set. As CONFIG_USB_DEVICE
cannot be enabled together with CONFIG_USB_GADGET it means that dependency
for musb udc code is not compiled during build. Fix it by including
drivers/usb/gadget dependency also when CONFIG_USB_DEVICE is set.
This patch fixes compile errors:
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_rx':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_idle':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_zero_data_request':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_idle':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `ep0_recv_setup'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_ep0_rx':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_rcv_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `musb_peri_rx_ep':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_rcv_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_endpoint_write':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_tx_complete'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_irq':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o:u-boot/drivers/usb/musb/musb_udc.c: more undefined references to `usbd_device_event_irq' follow
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_setup_ep':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_alloc_urb'
arm-linux-gnueabi-ld.bfd: drivers/usb/musb/built-in.o: in function `udc_startup_events':
u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
arm-linux-gnueabi-ld.bfd: u-boot/drivers/usb/musb/musb_udc.c: undefined reference to `usbd_device_event_irq'
make: *** [Makefile:1762: u-boot] Error 1
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Function next_urb() selects the last urb data buffer from linked list to
which next data from usbtty's puts function should be appended.
But to check if TX data still exists it is needed to look at the first urb
data buffer from linked list. So check for endpoint->tx_urb (first from the
linked list) instead of current_urb (the last from the linked list).
Successful call to udc_endpoint_write() may invalidate active urb and
allocate new urb in queue which invalidates pointer returned by next_urb()
function.
So call next_urb() prior putting data into urb buffer and call it every
time after using udc_endpoint_write() function to prevent sending data from
usbtty's puts function in incorrect order.
This patch fixes issue that usbtty code does not transmit data when they
are waiting in the tx queue.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
This function has incorrect implementation of prepending CR prior LF.
Without this patch it prepended CR prior whole string which is going to be
written and let LF without leading CR. Fix this issue by inserting CR at
correct place to make output on usbtty serial console more readable.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
With TPM2 we don't actually lock the TPM once verified boot is finished.
Instead we disable the platform hierarchy which serves the same purpose.
Add an implementation of this so we can safely boot into the kernel.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support for this so that the TPM can be set up for use with
Chromium OS verified boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Update tpm2_clear() and tpm2_pcr_extend() so that the command size
is not repeated twice. Add a small comment to the latter.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add support for TPMv2 versions of API functions. So far this is not
complete as the standard is quite large, but it implements everything
currently available for TPMv2 in U-Boot.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Take over the plain 'tpm_...' functions for use by the new TPM API. Rename
all the TPMv1 functions so they are called from the API.
Update the TPMv1 functions so that they are called from the API. Change
existing users to use the tpm1_ prefix so they don't need to go through
the API, which might introduce uncertainty.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
There are two different TPM standards. U-Boot supports both but each has
its own set of functions. We really need a single TPM API that can call
one or the other. This is not always possible as there are some
differences between the two standards, but it is mostly possible.
Add an API to handle this. So far it is not plumbed into the build and
only supports TPMv1.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
