| Age | Commit message (Collapse) | Author |
|---|
|
This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline yet) with
a quite large and complex USB hub infrastructure.
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 28.415 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 24.003 seconds
So ~4.5 seconds of USB scanning time reduction.
Signed-off-by: Stefan Roese <[email protected]>
Cc: Simon Glass <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Tested-by: Stephen Warren <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
Start with a short USB hub reset delay of 20ms. This can be enough for
some configurations.
The 2nd delay at the end of the loop is completely removed. Since the
delay hasn't been long enough, a longer delay time of 200ms is assigned
and will be used in the next loop round.
This hub reset handling is also used in the v4.4 Linux USB driver,
hub_port_reset().
Signed-off-by: Stefan Roese <[email protected]>
Cc: Simon Glass <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Tested-by: Stephen Warren <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
Add some tests to check that block devices work as expected.
Signed-off-by: Simon Glass <[email protected]>
Tested-by: Stephen Warren <[email protected]>
|
|
Driver model is used for host device block devices now, so we don't need the
old code. Remove it.
Signed-off-by: Simon Glass <[email protected]>
Tested-by: Stephen Warren <[email protected]>
|
|
Now that the drivers used by sandbox support CONFIG_BLK, we can switch
sandbox over to use driver model for block devices.
Signed-off-by: Simon Glass <[email protected]>
Tested-by: Stephen Warren <[email protected]>
|
|
When 'usb start' is used, block devices are created for any USB flash sticks
and disks, etc. When 'usb stop' is used, these block devices are currently
not removed.
We don't want old block devices hanging around since they can still be
visible to U-Boot. Therefore, when USB is shut down, remove and unbind all
the block devices created by the USB subsystem.
Possibly we should unbind all devices which don't cause problems by being
unbound. Most likely we can remove everything except USB controllers, hubs
and emulators. We can consider that later.
Signed-off-by: Simon Glass <[email protected]>
Tested-by: Stephen Warren <[email protected]>
|
|
This option outputs to the log file, not to the terminal. Clarify that in
the help, and add a mention of it in the README.
Signed-off-by: Simon Glass <[email protected]>
Reported-by: Stephen Warren <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
|
|
At present buildman allows you to specify the directory containing the
toolchain, but not the actual toolchain prefix. If there are multiple
toolchains in a single directory, this can be inconvenient.
Add a new 'toolchain-prefix' setting to the settings file, which allows
the full prefix (or path to the C compiler) to be specified.
Update the documentation to match.
Suggested-by: Stephen Warren <[email protected]>
Reviewed-by: Joe Hershberger <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
Tested-by: Stephen Warren <[email protected]>
|
|
At present if you try to use buildman with the branch 'test' it will
complain that it is unsure whether you mean the branch or the directory.
This is a feature of the 'git log' command that buildman uses. Fix it
by resolving the ambiguity.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Joe Hershberger <[email protected]>
|
|
reg-offset is the part of standard 8250 binding in the kernel.
It is shifting start of address space by reg-offset.
On Xilinx platform this offset is typically 0x1000.
Signed-off-by: Michal Simek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Moved the new field to the end of the struct to avoid problems:
Signed-off-by: Simon Glass <[email protected]>
|
|
This reverts commit 71105f50fedddfa5b0535d102c3d5078671721ad.
The reverted commit was applied for a temporary to unbreak
few Exynos boards on the release.
After the discussion about the change, this commit should be avoided.
Fixed device-tree for Exynos, allows reverting it without any issues.
Signed-off-by: Przemyslaw Marczak <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Stephen Warren <[email protected]>
Cc: Stephen Warren <[email protected]>
Tested-by: Simon Glass <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
This change is required to avoid warnings about invalid
size-cells defined in device-tree pinctrl nodes for Exynos.
Tested on:
- Odroid U3
- Odroid XU3
Signed-off-by: Przemyslaw Marczak <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Stephen Warren <[email protected]>
Cc: Stephen Warren <[email protected]>
Tested-by: Simon Glass <[email protected]>
Acked-by: Simon Glass <[email protected]>
Acked-by: Minkyu Kang <[email protected]>
|
|
Some controllers do not allow the output value to be read. Detect this and
report the error in that case.
Signed-off-by: Simon Glass <[email protected]>
|
|
Since dhry_per_sec is a u64 we must also use lldiv here when working
with it. Otherwise:
../lib/dhry/cmd_dhry.c:(.text.do_dhry+0xd8): undefined reference to `__udivdi3'
On some platforms.
Signed-off-by: Tom Rini <[email protected]>
|
|
This patch adds support for the congatec conga-QA3/E3845-4G eMMC8 SoM,
installed on the congatec Qseven 2.0 evaluation carrier board
(conga-QEVAL).
Its port is very similar to the MinnowboardMAX port and also uses
the Intel FSP as described in doc/README.x86.
Currently supported are the following interfaces / devices:
- UART (via Winbond legacy SuperIO chip on carrier board)
- Ethernet (PCIe Intel I210 / E1000)
- SPI including SPI NOR as boot-device
- USB 2.0
- SATA via U-Boot SCSI IF
- eMMC
- Video (HDMI output @ 800x600)
- PCIe
Not supported yet is:
- I2C
- USB 3.0
Signed-off-by: Stefan Roese <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Bin Meng <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
This adds basic support for chromebook_samus. This is the 2015 Pixel and
is based on an Intel broadwell platform.
Supported so far are:
- Serial
- SPI flash
- SDRAM init (with MRC cache)
- SATA
- Video (on the internal LCD panel)
- Keyboard
Various less-visible drivers are provided to make the above work (e.g. PCH,
power control and LPC).
The platform requires various binary blobs which are documented in the
README. The major missing feature is USB3 since the existing U-Boot support
does not work correctly with Intel XHCI controllers.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Sometimes it is useful to jump into U-Boot directly from coreboot or UEFI
without any 16-bit init. This can help during development by allowing U-Boot
to avoid doing all the init required by the platform.
U-Boot expects its GDT to be set up correctly by its 16-bit code. If
coreboot doesn't do this (because it hasn't run the payload setup code yet)
then this won't happen.
In this case we cannot rely on the GDT settings. U-Boot will hang or crash
if these are wrong. Provide a development-only option to set up the GDT
correctly. This is just a hack so you can jump to U-Boot from any stage of
coreboot, not just at the end.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
This is not needed now that the memory controller driver has the SPD data
in its own node.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Adjust the existing implementation to use the new common SDRAM init code.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
The code to call the memory reference code is common to several Intel CPUs.
Add common code for performing this init. Intel calls this 'Pre-EFI-Init'
(PEI), where EFI stands for Extensible Firmware Interface.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
The SATA indexed register write functions are common to several Intel PCHs.
Move this into a common location.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
At present samus reports about 5600 DMIPS. With the default iteration count
this is OK, but if 10 million runs are performed it overflows. Fix it.
Signed-off-by: Simon Glass <[email protected]>
|
|
This is missing, with causes lldiv() to fail on boards with use the private
libgcc. Add the missing routine.
Code is available for using the CLZ instruction but it is not enabled at
present.
This comes from coreboot version 4.0.
Signed-off-by: Simon Glass <[email protected]>
|
|
There is an extra line in the comment in the header. Remove it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add a function to set the ID in the IOAPIC.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Update a few points which have become out-of-date.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
This is a little easier on the eyes, particularly when the backlight is set
to maximum.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add an address which can be used for loading and running the reference code
when needed.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add a video driver for Intel's broadwell integrated graphics controller.
This uses a binary blob for most init, with the driver just performing a few
basic tasks.
This driver supports VESA as the mode-setting mechanism. Since most boards
don't support driver model yet with VESA, a special case is added to the
Kconfig for broadwell. Eventually all boards will use driver model and this
can be removed.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Provide a way to determine the HSIO (high-speed I/O) version supported by
the Intel Management Engine (ME) implementation on the platform.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Add a GPIO driver for the GPIO peripheral found on broadwell devices.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Broadwell uses a binary blob called the memory reference code (MRC) to start
up its SDRAM. This is similar to ivybridge so we can mostly use common code
for running this blob.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Broadwell requires quite a bit of power-management setup. Add code to set
this up correctly.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
[squashed in http://patchwork.ozlabs.org/patch/598373/]
Signed-off-by: Bin Meng <[email protected]>
|
|
Broadwell needs a special binary blob to set up the PCH. Add code to run
this on start-up.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Add a driver for the broadwell LPC (low-pin-count peripheral). This mostly
uses common code.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Add a driver for the broadwell northbridge. This sets up the location of
several blocks of registers.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Add a SATA driver for broadwell. This supports connecting an SSD and the
usual U-Boot commands to read and write data.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
GPIO pins need to be set up on start-up. Add a driver to provide this,
configured from the device tree.
The binding is slightly different from the existing ICH6 binding, since that
is quite verbose. The new binding should be just as extensible.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Add a driver for the broadwell low-power platform controller hub.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
This adds the broadwell architecture, with the CPU driver and some useful
header files.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Bin Meng <[email protected]>
|
|
Make a few minor updates to make the meaning clearer.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Intel has invented yet another binary blob which firmware is required to
run. This is run after SDRAM is ready. It is linked to load at a particular
address, typically 0, but is a relocatable ELF so can be moved if required.
Add support for this in the build system. The file should be placed in the
board directory, and called refcode.elf.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
We don't need this anymore - we can use device tree and the new pinconfig
driver instead.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Rather than setting up the pin configuration in the GPIO driver, use the
new pinctrl driver to do it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Add a driver which sets up the pin configuration on x86 devices with an ICH6
(or later) Platform Controller Hub.
The driver is not in the pinctrl uclass due to some oddities of the way x86
devices work:
- The GPIO controller is not present in I/O space until it is set up
- This is done by writing a register in the PCH
- The PCH has a driver which itself uses PCI, another driver
- The pinctrl uclass requires that a pinctrl device be available before any
other device can be probed
It would be possible to work around the limitations by:
- Hard-coding the GPIO address rather than reading it from the PCH
- Using special x86 PCI access to set the GPIO address in the PCH
However it is not clear that this is better, since the pin configuration
driver does not actually provide normal pin configuration services - it
simply sets up all the pins statically when probed. While this remains the
case, it seems better to use a syscon uclass instead. This can be probed
whenever it is needed, without any limitations.
Also add an 'invert' property to support inverting the input.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
At present pin configuration on link does not use the standard mechanism,
but some rather ugly custom code. As a first step to resolving this, add the
pin configuration to the device tree.
Four of the GPIOs must be available before relocation (for SDRAM pin
strapping).
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Each CPU needs to have its microcode loaded. Add support for this so that
all CPUs will have the same version.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Enable the microcode feature so that the microcode version is shown with the
'cpu detail' command.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
As each core starts up, record its microcode version and CPU ID so these can
be presented with the 'cpu detail' command.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
At present the MRC options are private to ivybridge. Other Intel CPUs also
use these settings. Move them to a common place.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
