Re: [U-Boot] [PATCH] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT
Hi Eric,
On Thu, Mar 31, 2016 at 01:41:04PM -0700, Eric Nelson wrote:
>Hi Peng,
>
>On 03/28/2016 09:57 PM, Peng Fan wrote:
>> Hi Eric,
>>
>> On Fri, Mar 25, 2016 at 01:12:11PM -0700, Eric Nelson wrote:
>>> Device tree parsing of GPIO nodes is currently ignoring flags.
>>>
>>> Add support for GPIO_ACTIVE_LOW by checking for the presence
>>> of the flag and setting the desc->flags field to the driver
>>> model constant GPIOD_ACTIVE_LOW.
>>
>> You may need to try this: https://patchwork.ozlabs.org/patch/597363/
>>
>Thanks for pointing this out.
>
>This patch also works, but it has me confused.
>
>How/why is parsing the ACTIVE_LOW flag specific to MXC?
>
>This is a general-purpose flag in the kernel, not something machine-
>specific.
>
>It also appears that there are a bunch of other copies
>of this same bit of code in the various mach_xlate() routines:
>
>desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
>
>If it's done in gpio-uclass, this isn't needed and xlate can
>be removed from mxc-gpio and quite a few other architectures.
>
>Please advise,
I saw you have posted a patch set to convert other gpio drivers.
But actually the translation of gpio property should be done by
each gpio driver. Alought we have gpio-cells=<2> for most gpio
drivers, but if there is one case that gpio-cells=<3>, and it have
different meaning for each cell from other most drivers?
So I suggest we follow the linux way,
434 if (!chip->of_xlate) {
435 chip->of_gpio_n_cells = 2;
436 chip->of_xlate = of_gpio_simple_xlate;
437 }
If gpio drivers does not provide xlate function, then use a simple xlate
function. If gpio drivers have their own xlate function, then use their
own way. Also I do no think delete the xlate implementation is not a good idea.
Simon may give more comments on this.
Regards,
Peng.
>
>
>Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 4/4] usb: Change power-on / scanning timeout handling
On 03/15/2016 01:59 PM, Stefan Roese wrote: > This patch changes the USB port scanning procedure and timeout > handling in the following ways: > > a) > The power-on delay in usb_hub_power_on() is now reduced to a value of > max(100ms, "hub->desc.bPwrOn2PwrGood * 2"). The code does not wait > using mdelay, instead usb_hub_power_on() will wait before querying > the device in the scanning loop later. The total timeout for this > hub, which is 1 second + "hub->desc.bPwrOn2PwrGood * 2" is calculated > and will be used in the following per-port scanning loop as the timeout > to detect active USB devices on this hub. > > b) > Don't delay the minimum delay (for power to stabilize) in > usb_hub_power_on(). Instead skip querying these devices in the scannig > loop until the delay time is reached. > > c) > The ports are now scanned in a quasi parallel way. The current code did > wait for each (unconnected) port to reach its timeout and only then > continue with the next port. This patch now changes this to scan all > ports of all USB hubs quasi simultaneously. For this, all ports are added > to a scanning list. This list is scanned until all ports are ready > by either a) reaching the connection timeout (calculated earlier), or > by b) detecting a USB device. This results in a faster USB scan time as > the recursive scanning of USB hubs connected to the hub that's currently > being scanned will start earlier. > > One small functional change to the original code is, that ports with > overcurrent detection will now get rescanned multiple times > (PORT_OVERCURRENT_MAX_SCAN_COUNT). > > Without this patch: > starting USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... 9 USB Device(s) found > > time: 20.163 seconds > > With this patch: > starting USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... 9 USB Device(s) found > > time: 1.822 seconds > > So ~18.3 seconds of USB scanning time reduction. > > Signed-off-by: Stefan Roese > Acked-by: Hans de Goede > Tested-by: Stephen Warren This breaks DWC2 on SoCkit, I can no longer detect any USB device. USB works without this patch though. Ideas? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: rpi: add some missing Kconfig help text
Add notes re: enabling the UART to the RPi 3 32-bit help text. Fully describe the RPi 3 64-bit board option. Signed-off-by: Stephen Warren --- arch/arm/mach-bcm283x/Kconfig | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig index a1ad1a4e0fa8..f4c9502b3f1f 100644 --- a/arch/arm/mach-bcm283x/Kconfig +++ b/arch/arm/mach-bcm283x/Kconfig @@ -63,7 +63,9 @@ config TARGET_RPI_3_32B This option assumes the VideoCore firmware is configured to use the mini UART (rather than PL011) for the serial console. This is the default on the RPi 3. To enable the UART console, the following non- - default option must be present in config.txt: enable_uart=1. + default option must be present in config.txt: enable_uart=1. This is + required for U-Boot to operate correctly, even if you only care + about the HDMI/usbkbd console. This option creates a build targetting the ARMv7/AArch32 ISA. select ARMV7_LPAE @@ -72,6 +74,30 @@ config TARGET_RPI_3_32B config TARGET_RPI_3 bool "Raspberry Pi 3 64-bit build" + help + Support for all BCM2837-based Raspberry Pi variants, such as + the RPi 3 model B, in AArch64 (64-bit) mode. + + This option assumes the VideoCore firmware is configured to use the + mini UART (rather than PL011) for the serial console. This is the + default on the RPi 3. To enable the UART console, the following non- + default option must be present in config.txt: enable_uart=1. This is + required for U-Boot to operate correctly, even if you only care + about the HDMI/usbkbd console. + + At the time of writing, the VC FW requires a non-default option in + config.txt to request the ARM CPU boot in 64-bit mode: + arm_control=0x200 + + The VC FW typically provides ARM "stub" code to set up the CPU and + quiesce secondary SMP CPUs. This is not currently true in 64-bit + mode. In order to boot U-Boot before the VC FW is enhanced, please + see the commit description for the commit which added RPi3 support + for a workaround. Since the instructions are temporary, they are not + duplicated here. The VC FW enhancement is tracked in + https://github.com/raspberrypi/firmware/issues/579. + + This option creates a build targetting the ARMv8/AArch64 ISA. select ARM64 select BCM2837 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: add Raspberry Pi 3 64-bit config
On all Pis so far, the VC FW provides a short stub to set up the ARM CPU
before entering the kernel (a/k/a U-Boot for us). This feature is not
currently supported by the VC FW when booting in 64-bit mode. However,
this feature will likely appear in the near future, and this U-Boot port
assumes that such a feature is in place. Without that feature, or a
temporary workaround described below, U-Boot will not boot.
Once the VC FW does provide the ARM stub, u-boot.bin built for rpi_3 can
be used drectly as kernel7.img, in the same way as any other RPi port. The
following config.txt is required:
# Fix mini UART input frequency, and setup/enable up the UART.
# Without this option, U-Boot will not boot, even if you don't care
# about the serial console. This option will always be required for
# all RPi3 use-cases, unless the PL011 UART is used, which is not
# yet supported by rpi_3* builds of U-Boot.
enable_uart=1
# Boot in AArch64 (64-bit) mode.
# It is possible that a future VC FW will remove the need for this
# option, instead auto-setting 32-/64-bit mode based on the "kernel"
# filename present on the SD card.
arm_control=0x200
Prior to the VC FW providing the ARM boot stub, you can use the following
steps to build an equivalent stub into the U-Boot binary:
git clone https://github.com/swarren/rpi-3-aarch64-demo.git \
../rpi-3-aarch64-demo
(cd ../rpi-3-aarch64-demo && ./build.sh)
Build U-Boot for rpi_3 in the usual way
cat ../rpi-3-aarch64-demo/armstub64.bin u-boot.bin > u-boot.bin.stubbed
Use u-boot.bin.stubbed as kernel7.img on the Pi SD card.
In this case, the following additional entries are required in config.txt:
# Tell the FW to load the kernel image at address 0, the reset vector.
kernel_old=1
Signed-off-by: Stephen Warren
---
arch/arm/mach-bcm283x/Kconfig | 7 +++
board/raspberrypi/rpi/rpi.c | 25 +
board/raspberrypi/rpi_3/MAINTAINERS | 6 ++
board/raspberrypi/rpi_3/Makefile| 7 +++
configs/rpi_3_defconfig | 11 +++
include/configs/rpi-common.h| 3 +++
include/configs/rpi_3.h | 14 ++
7 files changed, 73 insertions(+)
create mode 100644 board/raspberrypi/rpi_3/MAINTAINERS
create mode 100644 board/raspberrypi/rpi_3/Makefile
create mode 100644 configs/rpi_3_defconfig
create mode 100644 include/configs/rpi_3.h
diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
index a4d291d29742..a1ad1a4e0fa8 100644
--- a/arch/arm/mach-bcm283x/Kconfig
+++ b/arch/arm/mach-bcm283x/Kconfig
@@ -70,12 +70,18 @@ config TARGET_RPI_3_32B
select BCM2837
select CPU_V7
+config TARGET_RPI_3
+ bool "Raspberry Pi 3 64-bit build"
+ select ARM64
+ select BCM2837
+
endchoice
config SYS_BOARD
default "rpi" if TARGET_RPI
default "rpi_2" if TARGET_RPI_2
default "rpi_3_32b" if TARGET_RPI_3_32B
+ default "rpi_3" if TARGET_RPI_3
config SYS_VENDOR
default "raspberrypi"
@@ -87,5 +93,6 @@ config SYS_CONFIG_NAME
default "rpi" if TARGET_RPI
default "rpi_2" if TARGET_RPI_2
default "rpi_3_32b" if TARGET_RPI_3_32B
+ default "rpi_3" if TARGET_RPI_3
endmenu
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 20b5cf48f558..c45ddb14aa33 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -19,6 +19,9 @@
#include
#include
#include
+#ifdef CONFIG_ARM64
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -228,6 +231,28 @@ static uint32_t rev_scheme;
static uint32_t rev_type;
static const struct rpi_model *model;
+#ifdef CONFIG_ARM64
+static struct mm_region bcm2837_mem_map[] = {
+ {
+ .base = 0xUL,
+ .size = 0x3f00UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ .base = 0x3f00UL,
+ .size = 0x0100UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = bcm2837_mem_map;
+#endif
+
int dram_init(void)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_arm_mem, msg, 1);
diff --git a/board/raspberrypi/rpi_3/MAINTAINERS
b/board/raspberrypi/rpi_3/MAINTAINERS
new file mode 100644
index ..26ecd99e16fa
--- /dev/null
+++ b/board/raspberrypi/rpi_3/MAINTAINERS
@@ -0,0 +1,6 @@
+RPI_3_BOARD
+M: Stephen Warren
+S: Maintained
+F: board/raspberrypi/rpi_3/
+F: include/configs/rpi_3.h
+F: configs/rpi_3_defconfig
diff --git a/board/raspberrypi/rpi_3/Makefile b/board/raspberrypi/rpi_3/Makefile
new file mode 100644
index ..78e287487cd4
--- /dev/null
+++ b/board/raspberrypi/rpi_3/Makefile
@@
[U-Boot] [PATCH 1/2] ARM: allow CONFIG_GICV* not to be defined
There are ARM SoCs (such as the BCM2837) do not contain an ARM GIC. Fix the ARMv8 CPU startup code to compile in this case. Signed-off-by: Stephen Warren --- arch/arm/cpu/armv8/start.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 67b166c7fd46..dceedd7100ae 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -202,14 +202,14 @@ WEAK(lowlevel_init) mov x29, lr /* Save LR */ #ifndef CONFIG_ARMV8_MULTIENTRY +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) /* * For single-entry systems the lowlevel init is very simple. */ ldr x0, =GICD_BASE bl gic_init_secure - +#endif #else /* CONFIG_ARMV8_MULTIENTRY is set */ - #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) branch_if_slave x0, 1f ldr x0, =GICD_BASE -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache
On 04/01/2016 05:16 PM, Eric Nelson wrote: Hi Stephen, On 04/01/2016 03:57 PM, Stephen Warren wrote: On 03/31/2016 02:24 PM, Eric Nelson wrote: On 03/30/2016 02:57 PM, Stephen Warren wrote: On 03/30/2016 11:34 AM, Eric Nelson wrote: On 03/30/2016 07:36 AM, Stephen Warren wrote: On 03/28/2016 11:05 AM, Eric Nelson wrote: We could allocate the data storage for the block cache at the top of RAM before relocation, like many other things are allocated, and hence not use malloc() for that. Hmmm. We seem to have gone from a discussion about data structures to type of allocation. I'm interested in seeing how that works. Can you provide hints about what's doing this now? Something like common/board_f.c:reserve_mmu() and many other functions there. relocaddr starts at approximately the top of RAM, continually gets adjusted down as many static allocations are reserved, and eventually becomes the address that U-Boot is relocated to. Simply adding another entry into init_sequence_f[] for the disk cache might work. Thanks for the pointer. I'll review that when time permits. This would remove the opportunity to re-configure the cache though, right? Well, it would make it impossible to use less RAM. One could use more by having a mix of the initial static allocation plus some additional dynamic allocation, but that might get a bit painful to manage. It might be interesting to use the MMU more and allow de-fragmentation of VA space. That is, assuming there's much more VA space than RAM, such as is true on current 64-bit architectures. Then I wouldn't dislike dynamic allocation so much:-) I'm not sure whether how important this feature is, and I think only time and use will tell. I'd prefer to keep that ability at least for a cycle or two so that I and others can test. While re-working the code, I also thought more about using an array and still don't see how the implementation doesn't get more complex. The key bit is that the list is implemented in MRU order so invalidating the oldest is trivial. Yes, the MRU logic would make it more complex. Is that particularly useful, i.e. is it an intrinsic part of the speedup? It's not a question of speed with small numbers of entries. The code to handle eviction would just be more complex. My thought was that if the eviction algorithm wasn't important (i.e. most of the speedup comes from have some (any) kind of cache, but the eviction algorithm makes little difference to the gain from having the cache), we could just drop MRU completely. If that's not possible, then indeed a list would make implementing MRU easier. How would we decide which block to discard? I haven't traced enough to know what algorithm(s) might be best, but I can say that there's a preponderance of repeated accesses to the last-accessed block, especially in ext4. Perhaps just keep an index into the array, use that index any time something is written to the cache, and then increment it each time. Probably not anywhere near as optimal as MRU/LRU though. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 19/21] arm: Add support for Qualcomm Snapdragon family
On Thu, Mar 31, 2016 at 11:12:32PM +0200, Mateusz Kulikowski wrote: > First supported chip is APQ8016 (that is compatible with MSM8916). > Drivers in SoC code: > - Reset controller (PSHOLD) > - Clock controller (very simple clock configuration for MMC and UART) > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 20/21] board: Add Qualcomm Dragonboard 410C support
On Thu, Mar 31, 2016 at 11:12:33PM +0200, Mateusz Kulikowski wrote: > This commit add support for 96Boards Dragonboard410C. > It is board based on APQ8016 Qualcomm SoC, complying with > 96boards specification. > Features (present out of the box): > - 4x Cortex A53 (ARMv8) > - 2x USB Host port > - 1x USB Device port > - 4x LEDs > - 1x HDMI connector > - 1x uSD connector > - 3x buttons (Power, Vol+, Vol-/Reset) > - WIFI, Bluetooth with integrated antenna > - 8GiB eMMC > > U-Boot boots chained with fastboot in 64-bit mode. > For detailed build instructions see readme.txt in board directory. > > Signed-off-by: Mateusz Kulikowski > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] post: Remove references to scrapped "netta" board.
On Mon, Mar 28, 2016 at 09:20:40AM -0400, Robert P. J. Day wrote: > Given that README.scrapyard shows scrapping of netta boards: > > netta2 powerpc mpc8xx c51c1c9a2014-07-07 > nettapowerpc mpc8xx c51c1c9a2014-07-07 > > delete netta example from POST tests. > > Signed-off-by: Robert P. J. Day Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 21/21] Add myself as Snapdragon and SPMI maintainer
On Thu, Mar 31, 2016 at 11:12:34PM +0200, Mateusz Kulikowski wrote: > - Update MAINTAINERS > - Update git-mailrc > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 16/21] drivers: spmi: Add support for Qualcomm SPMI bus driver
On Thu, Mar 31, 2016 at 11:12:29PM +0200, Mateusz Kulikowski wrote: > Support SPMI arbiter on Qualcomm Snapdragon devices. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 17/21] pmic: Add support for Qualcomm PM8916 PMIC
On Thu, Mar 31, 2016 at 11:12:30PM +0200, Mateusz Kulikowski wrote: > This PMIC is connected on SPMI bus so needs SPMI support enabled. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 18/21] gpio: Add support for Qualcomm PM8916 gpios
On Thu, Mar 31, 2016 at 11:12:31PM +0200, Mateusz Kulikowski wrote: > This driver supports GPIOs present on PM8916 PMIC. > There are 2 device drivers inside: > - GPIO driver (4 "generic" GPIOs) > - Keypad driver that presents itself as GPIO with 2 inputs (power and reset) > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,15/21] spmi: Add sandbox test driver
On Thu, Mar 31, 2016 at 11:12:28PM +0200, Mateusz Kulikowski wrote: > This patch adds emulated spmi bus controller with part of > pm8916 pmic on it to sandbox and tests validating SPMI uclass. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! ... but note that the tests fail currently, please fix :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,13/21] ehci: Add support for Qualcomm EHCI
On Thu, Mar 31, 2016 at 11:12:26PM +0200, Mateusz Kulikowski wrote: > This driver is able to reconfigure OTG controller into HOST mode. > Board can add board-specific initialization as board_prepare_usb(). > It requires USB_ULPI_VIEWPORT enabled in board configuration. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 12/21] ehci-ci.h: drop generic USBCMD fields
On Thu, Mar 31, 2016 at 11:12:25PM +0200, Mateusz Kulikowski wrote: > Use definitions from ehci.h instead. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,14/21] drivers: Add SPMI bus uclass
On Thu, Mar 31, 2016 at 11:12:27PM +0200, Mateusz Kulikowski wrote: > Qualcom processors use proprietary bus to talk with PMIC devices - > SPMI (System Power Management Interface). > On wiring level it is similar to I2C, but on protocol level, it's > multi-master and has simple autodetection capabilities. > This commit adds simple uclass that provides bus read/write interface. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 09/21] eth: asix88179: Print packet length properly
On Thu, Mar 31, 2016 at 11:12:22PM +0200, Mateusz Kulikowski wrote: > Debug printf used '%u' to print size_t variable. > This caused warnings on 64-bit machines. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 11/21] usb: ehci-ci: Add missing registers.
On Thu, Mar 31, 2016 at 11:12:24PM +0200, Mateusz Kulikowski wrote: > Some registers of usb_ehci were marked as reserved. > This may be true for some variants of Chipidea USB core, but they have > meaning on other devices. > > The following registers were added: > sbusstatus/sbusmode: AHB-related registers > genconfig*: Auxiluary IP core configuration registers. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Marek Vasut > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,10/21] usb: Rename ehci-fsl.h to ehci-ci.h
On Thu, Mar 31, 2016 at 11:12:23PM +0200, Mateusz Kulikowski wrote: > Most of ehci-fsl header describe USB controller > designed by Chipidea and used by various SoC vendors. > > This patch renames it to a generic header: ehci-ci.h > Contents of file are not changed (so it contains several > references to freescale SoCs). > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 05/21] usb: ulpi: Add Kconfig options for ULPI
On Thu, Mar 31, 2016 at 11:12:18PM +0200, Mateusz Kulikowski wrote: > The following options can be now enabled via defconfig: > - CONFIG_USB_ULPI > - CONFIG_USB_ULPI_VIEWPORT > - CONFIG_USB_ULPI_VIEWPORT_OMAP > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Acked-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,07/21] usb: ulpi: Fix viewport_addr type
On Thu, Mar 31, 2016 at 11:12:20PM +0200, Mateusz Kulikowski wrote: > viewport_addr is address of memory mapped ULPI viewport. > It is used only as argument to readl/writel later > causing compile warnings on 64-bit devices. > > This fix changes its type to match pointer size. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 08/21] usb: ulpi: Fix compile warning in read/write on 64-bit machines.
On Thu, Mar 31, 2016 at 11:12:21PM +0200, Mateusz Kulikowski wrote: > ulpi_read and ulpi_write are used to read/write registers via ULPI bus. > Code generates compilation warnings on 64-bit machines where pointer > is cast to u32. > > This patch drops all but last 8 bits of register address. > It is possible, because addresses on ULPI bus are 6- or 8-bit. > > It is not possible (according to ULPI 1.1 spec) to have more > than 8-bit addressing. > > This patch should not cause regressions as all calls to > ulpi_read/write use either structure pointer (@ address 0) or integer > offsets cast to pointer - addresses requested are way below 8-bit range. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,06/21] Migrate CONFIG_ULPI* to Kconfig
On Thu, Mar 31, 2016 at 11:12:19PM +0200, Mateusz Kulikowski wrote: > Move CONFIG_USB_ULPI* from headers to defconfigs for boards that use it. > Also - add CONFIG_USB where necesarry - all boards use it, > but some are not defining it explicitly. > > Affected boards: > colibri_t20, harmony, mcx, mt_ventoux, twister, > zynq_(picozed, zc702, zc706, zed, zybo) > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v4,04/21] ehci-hcd: Add init_after_reset
On Thu, Mar 31, 2016 at 11:12:17PM +0200, Mateusz Kulikowski wrote: > Some host controllers need addidional initialization after ehci_reset() > In non-dm implementation it is possible to use > CONFIG_EHCI_HCD_INIT_AFTER_RESET. > This patch adds similar option to ehci drivers using dm. > > Signed-off-by: Mateusz Kulikowski > Acked-by: Marek Vasut > Reviewed-by: Tom Rini > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 02/21] gpio: Add support for Qualcomm gpio controller
On Thu, Mar 31, 2016 at 11:12:15PM +0200, Mateusz Kulikowski wrote: > Add support for gpio controllers on Qualcomm Snapdragon devices. > This devices are usually called Top Level Mode Multiplexing in > Qualcomm documentation. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 01/21] serial: Add support for Qualcomm serial port
On Thu, Mar 31, 2016 at 11:12:14PM +0200, Mateusz Kulikowski wrote: > This driver works in "new" Data Mover UART mode, so > will be compatible with modern Qualcomm chips only. > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 03/21] mmc: Add support for Qualcomm SDHCI controller
On Thu, Mar 31, 2016 at 11:12:16PM +0200, Mateusz Kulikowski wrote: > Add support for SD/eMMC controller present on some Qualcomm Snapdragon > devices. This controller implements SDHCI 2.0 interface but requires > vendor-specific initialization. > Driver works in PIO mode as ADMA is not supported by U-Boot (yet). > > Signed-off-by: Mateusz Kulikowski > Reviewed-by: Simon Glass > Tested-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board: ti: DRA7: Add DP83867 TI phy for rev c
On Wed, Mar 30, 2016 at 12:58:37PM -0500, Dan Murphy wrote: > Enable the TI DP83867 Giga bit phy on the > dra7 rev c board. The rx and tx internal > delays are need for this board so the usage > of RGMII_ID is required. > > Signed-off-by: Dan Murphy > Acked-by: Mugunthan V N > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 6/7] kc1: Proper reboot mode and boot reason validation
On Tue, Mar 29, 2016 at 02:16:26PM +0200, Paul Kocialkowski wrote: > With the previous implementation, rebooting without registering a recognized > reboot mode would end up with U-Boot checking for a valid power-on reason, > which > might result in the device turning off (e.g. with no USB cable attached and no > buttons pressed). > > Since this approach is not viable (breaks reboot in most cases), the validity > of > the reboot reason is checked (in turn, by checking that a warm reset happened, > as there is no magic) to detect a reboot and the 'o' char is recognized to > indicate that power-off is required. Still, that might be overridden by the > detection of usual power-on reasons, on purpose. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/7] kc1: Add some sysboot and devicetree-related environment variables
On Tue, Mar 29, 2016 at 02:16:24PM +0200, Paul Kocialkowski wrote: > This adds some environment variables for sysboot and devicetree. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 7/7] sniper: Change vendor name from lge to lg, matching devicetree vendor prefix
On Tue, Mar 29, 2016 at 02:16:27PM +0200, Paul Kocialkowski wrote: > This moves the sniper board from the lge to lg, in order to match the > devicetree > vendor prefix already defined in the kernel. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] efi_loader: Always allocate the highest available address
On Wed, Mar 30, 2016 at 04:38:29PM +0200, Alexander Graf wrote: > Some EFI applications (grub2) expect that an allocation always returns > the highest available memory address for the given size. > > Without this, we may run into situations where the initrd gets allocated > at a lower address than the kernel. > > This patch fixes booting in such situations for me. > > Signed-off-by: Alexander Graf Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/7] sniper: Proper reboot mode and boot reason validation
On Tue, Mar 29, 2016 at 02:16:25PM +0200, Paul Kocialkowski wrote: > With the previous implementation, rebooting without registering a recognized > reboot mode (despite registering the magic) would end up with U-Boot checking > for a valid power-on reason, which might result in the device turning off > (e.g. > with no USB cable attached and no buttons pressed). > > This was designed to catch reboots that are actually intended to be power-off, > something that old Android kernels do, instead of properly turning the device > off using the TWL4030. > > However, since this approach is not viable (breaks reboot in most cases), the > validity of the reboot mode magic is checked to detect a reboot and the 'o' > char > is recognized to indicate that power-off is required. Still, that might be > overridden by the detection of usual power-on reasons, on purpose. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/7] kc1: Select libfdt to allow running devicetree-based kernels
On Tue, Mar 29, 2016 at 02:16:23PM +0200, Paul Kocialkowski wrote: > Selecting CONFIG_OF_LIBFDT allows running recent mainline kernels. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm64: booti: add missing unmap_sysmem()
On Tue, Mar 29, 2016 at 07:51:57PM +0900, Masahiro Yamada wrote: > Make sure to call unmap_sysmem() for address allocated by map_sysmem() > before leaving the function; however this patch gives no impact on > the behavior because map_sysmem()/unmap_sysmem() does nothing except > on Sandbox. Sandbox never runs this code because "booti" is a command > for booting ARM64 kernel image. > > Signed-off-by: Masahiro Yamada > Reviewed-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/7] kc1: Include explicit serial baudrate on bootargs
On Tue, Mar 29, 2016 at 02:16:22PM +0200, Paul Kocialkowski wrote: > This makes the baudrate for the kernel command line explicit. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/7] sniper: Include explicit serial baudrate on bootargs
On Tue, Mar 29, 2016 at 02:16:21PM +0200, Paul Kocialkowski wrote: > This makes the baudrate for the kernel command line explicit. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] configs: ti_armv7_keystone2: make SYS_TEXT_BASE configurable at build time
On Mon, Mar 28, 2016 at 03:15:59PM -0400, Vitaly Andrianov wrote: > U-boot for general purpose KS2 devices is loaded to the beginning of the > internal memory (0x0c00). Secure devices uses this memory and > CONFIG_SYS_TEXT_BASE has to be different for those devices. > > This commit make this configurable at build time by giving > CONFIG_SYS_TEXT_BASE as a command line definition to make command. > > Signed-off-by: Vitaly Andrianov Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] common: env_sf: Add exclamation mark
On Mon, Mar 28, 2016 at 05:26:27PM +0800, Peng Fan wrote: > Add exclamation mark to the errmsg, when error and set_default_env. > > Signed-off-by: Peng Fan > Cc: Mario Schuknecht > Cc: Vignesh R > Cc: Jagan Teki > Cc: Ravi Babu > Cc: York Sun > Cc: Tom Rini > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: spl: Align default board_init_f comment with code
On Mon, Mar 28, 2016 at 01:58:03PM -0500, Andreas Dannenberg wrote: > The default board_init_f() implementation performs a call to > board_init_r() as the last step of the sequence. Fix the comment > for this function to reflect the actual execution flow. > > Signed-off-by: Andreas Dannenberg Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/3] sata: use block layer for sata command
On Sun, Mar 27, 2016 at 12:00:15PM -0700, Eric Nelson wrote: > Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is > used if enabled and to remove build breakage when CONFIG_BLK is enabled. > > Signed-off-by: Eric Nelson > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V3, 1/3] drivers: block: add block device cache
On Mon, Mar 28, 2016 at 10:05:44AM -0700, Eric Nelson wrote: > Add a block device cache to speed up repeated reads of block devices by > various filesystems. > > This small amount of cache can dramatically speed up filesystem > operations by skipping repeated reads of common areas of a block > device (typically directory structures). > > This has shown to have some benefit on FAT filesystem operations of > loading a kernel and RAM disk, but more dramatic benefits on ext4 > filesystems when the kernel and/or RAM disk are spread across > multiple extent header structures as described in commit fc0fc50. > > The cache is implemented through a minimal list (block_cache) maintained > in most-recently-used order and count of the current number of entries > (cache_count). It uses a maximum block count setting to prevent copies > of large block reads and an upper bound on the number of cached areas. > > The maximum number of entries in the cache defaults to 32 and the maximum > number of blocks per cache entry has a default of 2, which has shown to > produce the best results on testing of ext4 and FAT filesystems. > > The 'blkcache' command (enabled through CONFIG_CMD_BLOCK_CACHE) allows > changing these values and can be used to tune for a particular filesystem > layout. > > Signed-off-by: Eric Nelson Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] post: Delete unnecessary bitmask of POST_MANUAL from POST_ALWAYS
On Sun, Mar 27, 2016 at 10:18:55AM -0400, Robert P. J. Day wrote: > Since POST_ALWAYS is defined as: > > #define POST_ALWAYS (POST_NORMAL| \ > POST_SLOWTEST | \ > POST_MANUAL| \ > POST_POWERON ) > > there is no need to redundantly bitmask it with POST_MANUAL. > > Signed-off-by: Robert P. J. Day > > diff --git a/post/tests.c b/post/tests.c > index a4d4165..d8ac54e 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] jffs2: Fix set but not used warning
On Sun, Mar 27, 2016 at 02:48:36PM -0400, Tom Rini wrote: > We only use 'ofs' in jffs2_sum_scan_sumnode when debugging as it's part > of a dbg_summary call. Mark this as __maybe_unused. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/3] mmc: use block layer in mmc command
On Sun, Mar 27, 2016 at 12:00:14PM -0700, Eric Nelson wrote: > Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is > used if enabled and to remove build breakage when CONFIG_BLK is enabled. > > Signed-off-by: Eric Nelson > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] lib/physmem.c: Switch to __weak for arch_phys_memset
On Sun, Mar 27, 2016 at 02:06:11PM -0400, Tom Rini wrote: > We normally use __weak rather than calling it out directly as an alias. > Update this function to the normal method. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] post: Remove reference to deleted "lwmon" board from Makefile
On Sun, Mar 27, 2016 at 08:39:15AM -0400, Robert P. J. Day wrote: > POST support for sample lwmon board was removed in commit e5d3078622. > > Signed-off-by: Robert P. J. Day B > > diff --git a/post/Makefile b/post/Makefile > index 2fa6f8a..92024e1 100644 Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Common: SPL: spl_nand: Fixed debug correct NAND ECC type.
On Fri, Mar 25, 2016 at 01:13:17PM +0100, Ahmed Samir Khalil wrote: > In case of #define DEBUG 1 (fordebugging SPL). A bug in > spl_nand_load_image() will be triggered, because it prints > using hw ecc regardless of soft ecc configurations and > initializations. > > Signed-off-by: Ahmed Samir > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2, 2/5] rpi: use constant "unknown board" DT filename
On Thu, Mar 24, 2016 at 10:15:17PM -0600, Stephen Warren wrote: > To simplify support for new SoCs, just use a constant filename > for the unknown case. In practice this case shouldn't be hit anyway, so > the filename isn't relevant, and certainly doesn't need to differentiate > between SoCs. If a user has an as-yet-unknown board, they can override > this value in the environment anyway. > > Signed-off-by: Stephen Warren > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2, 5/5] rpi: BCM2837 and Raspberry Pi 3 32-bit support
On Thu, Mar 24, 2016 at 10:15:20PM -0600, Stephen Warren wrote: > The Raspberry Pi 3 contains a BCM2837 SoC. The BCM2837 is a BCM2836 with > the CPU complex swapped out for a quad-core ARMv8. This can operate in 32- > or 64-bit mode. 32-bit mode is the current default selected by the > VideoCore firmware on the Raspberry Pi 3. This patch adds a 32-bit port of > U-Boot for the Raspberry Pi 3. > > >From U-Boot's perspective, the only delta between the RPi 2 and RPi 3 is a > change in usage of the SoC UARTs. On all previous Pis, the PL011 was the > only UART in use. The Raspberry Pi 3 adds a Bluetooth module which uses a > UART to connect to the SoC. By default, the PL011 is used for this purpose > since it has larger FIFOs than the other "mini" UART. However, this can > be configured via the VideoCore firmware's config.txt file. This patch > hard-codes use of the mini UART in the RPi 3 port. If your system uses the > PL011 UART for the console even on the RPi 3, please use the RPi 2 U-Boot > port instead. A future change might determine which UART to use at > run-time, thus allowing the RPi 2 and RPi 3 (32-bit) ports to be squashed > together. > > The mini UART has some limitations. One externally visible issue in the > BCM2837 integration is that the UART divides the SoC's "core clock" to > generate the baud rate. The core clock is typically variable, and under > control of the VideoCore firmware for thermal management reasons. If the > VC FW does modify the core clock rate, UART communication will be > corrupted since the baud rate will vary from the expected value. This was > not an issue for the PL011 UART, since it is fed by a fixed 3MHz clock. To > work around this, the VideoCore firmware can be told not to modify the SoC > core clock. However, the only way this can happen and be thermally safe is > to limit the core clock to a low/minimum frequency. This leaves > performance on the table for use-cases that don't care about a UART > console. Consequently, use of the mini UART console must be explicitly > requested by entering the following line into config.txt: > > enable_uart=1 > > A recent version of the VC firmware is required to ensure that the mini > UART is fully and correctly initialized by the VC FW; at least > firmware.git 046effa13ebc "firmware: arm_loader: emmc clock depends on > core clock See: https://github.com/raspberrypi/firmware/issues/572";. > > Signed-off-by: Stephen Warren > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,V2,3/5] rpi: add Raspberry Pi 3 board ID
On Thu, Mar 24, 2016 at 10:15:18PM -0600, Stephen Warren wrote: > This allows U-Boot to known the name of the board. > > The existing rpi_2_defconfig can operate correctly on the Raspberry Pi 3 > in 32-bit mode /if/ you have configured the firmware to use the PL011 UART > as the console UART (the default is the mini UART). This requires two > things: > a) config.txt should contain dtoverlay=pi3-miniuart-bt > b) You should run the following to tell the VC FW to process DT when > booting, and copy u-boot.bin.img (rather than u-boot.bin) to the SD card > as the kernel image: > >path/to/kernel/scripts/mkknlimg --dtok u-boot.bin u-boot.bin.img > > This works as of firmware.git commit 046effa13ebc "firmware: arm_loader: > emmc clock depends on core clock See: > https://github.com/raspberrypi/firmware/issues/572";. > > Signed-off-by: Stephen Warren > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2, 4/5] ARM: bcm2835: expand Kconfig target descriptions
On Thu, Mar 24, 2016 at 10:15:19PM -0600, Stephen Warren wrote: > This adds an explanation of which Raspberry Pi models each target option > supports. > > Signed-off-by: Stephen Warren > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V2, 1/5] ARM: bcm2835: move CONFIG_BCM283* to Kconfig
On Thu, Mar 24, 2016 at 10:15:16PM -0600, Stephen Warren wrote: > Signed-off-by: Stephen Warren > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: clarify openssl-based key and certificate generation process
On Wed, Mar 23, 2016 at 06:24:10PM -0500, Andreas Dannenberg wrote: > Add some basic clarification that the dev.key file generated by OpenSSL > contains both the public and private key, and further highlight that > the certificate generated here contains the public key only. > > Signed-off-by: Andreas Dannenberg Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] doc: fix file extension for flattened image tree blob
On Wed, Mar 23, 2016 at 05:44:17PM -0500, Andreas Dannenberg wrote: > Different sections in the document suggest flattened image tree blob > files have a file name extension of .itb. Fix the list of file extensions > to reflect that. > > Signed-off-by: Andreas Dannenberg Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] ARM: keystone2: Add missing privilege ID settings
On Wed, Mar 23, 2016 at 10:14:19AM -0500, Nishanth Menon wrote: > Add missing Privilege ID settings for KS2 SoCs. > > Based on: > K2H/K: Table 6-7. Privilege ID Settings from SPRS866E (Nov 2013) > http://www.ti.com/lit/ds/symlink/66ak2h14.pdf (page 99) > K2L: Table 7-7. Privilege ID Settings from SPRS930 (April 2015) > http://www.ti.com/lit/ds/symlink/66ak2l06.pdf (page 71) > K2E: Table 7-7. Privilege ID Settings from SPRS865D (Mar 2015) > http://www.ti.com/lit/ds/symlink/66ak2e05.pdf (page 75) > K2G: Table 3-16. PrivIDs from SPRUHY8 (Jan 2016) > http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf (page 238) > > Overall mapping: Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] README: Specify the full path for README.displaying-bmps
On Wed, Mar 23, 2016 at 12:46:12PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > It is clearer to specify the full path to access the > doc/README.displaying-bmps file. > > Signed-off-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] ARM: keystone2: Refactor MSMC macros to avoid #ifdeffery
On Wed, Mar 23, 2016 at 10:14:18AM -0500, Nishanth Menon wrote: > MSMC segment Privilege ID is not consistent accross the keystone2 SoCs. > As the first step to ensure complete SoC wide coherency setup, lets > refactor the macros to remove the #if-deffery around the code which > obfuscates which IDs are actually enabled for which SoC. > > As a result of this change the PCIe configuration is moved after the > msmc configuration is complete, but that should ideally have no > functional impact. > > Signed-off-by: Nishanth Menon > Reviewed-by: Lokesh Vutla > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] smsc95xx: fix operation on 64-bit systems
On Tue, Mar 22, 2016 at 10:28:16PM -0600, Stephen Warren wrote: > smsc95xx_read_reg() should calculate sizeof(*data) not sizeof(data) since > data is a pointer, and the value pointed at is being transferred over USB, > not the value of the pointer. This fixes operation of the driver in 64-bit > builds, such as the Raspberry Pi 3. > > Reported-by: Eric Anholt > Signed-off-by: Stephen Warren > Acked-by: Marek Vasut > Acked-by: Joe Hershberger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fastboot: allow retrieving fastboot variables from env
On Thu, Mar 17, 2016 at 05:21:23PM +0100, Boris BREZILLON wrote: > From: Rob Herring > > Some boards need to expose device specific variable through fastboot > (to adpat the flashing script depending on hardware revision for > example). > > Provide a way to expose custom fastboot variables. Note that all > variables meant to be exposed through fastboot should be be prefixed > with 'fastboot.', the variable should not exceed 32 bytes (including > the prefix and the trailing '\0') and the variable content should > fit in the response buffer (60 bytes excluding the 'OKAY' prefix and > the trailing '\0'). > > Signed-off-by: Rob Herring > [Boris Brezillon: add a commit message] > Signed-off-by: Boris Brezillon > > Signed-off-by: Boris Brezillon > Acked-by: Steve Rae Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: clang: Update support slightly
On Wed, Mar 16, 2016 at 07:55:55PM -0400, Tom Rini wrote: > - Move most of the flags required into LLVM_RELFLAGS to test at build > time instead of requiring them to be passed in. > - Update doc/README.clang to reflect this > - Switch to rpi_2 as the example as it's closer to working out of the > box than rpi is. > > Cc: Jeroen Hofstee > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: Update Scott Wood's email address
On Fri, Apr 01, 2016 at 06:49:57PM -0500, Scott Wood wrote: > Freescale is now NXP. I still work there, but I won't be using their > mail system for U-Boot development. > > Signed-off-by: Scott Wood Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v3, 5/9] Drop command-processing code when CONFIG_CMDLINE is disabled
On Sat, Mar 19, 2016 at 02:18:38AM -0600, Simon Glass wrote: > Command parsing and processing code is not needed when the command line is > disabled. Remove this code in that case. > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, Apr 01, 2016 at 06:45:03PM -0500, Scott Wood wrote: > On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > > On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > > > > > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > > > > > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > > > > using menuconfig or defconfig. > > > > > > > > > > Signed-off-by: Mugunthan V N > > > > > > > > Good but you need to update configs/ to remove NAND from > > > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > > > > > NACK > > > > > > That CONFIG_NAND is a target-local option used by some boards to indicate > > > boot > > > source. It is not equivalent to CONFIG_CMD_NAND which is what enables the > > > NAND subsystem. > > > > Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and > > into a real Kconfig entry. That said, I think this might have forgotten > > to enable it in other places too but just 'NAND' needs to migrate out of > > where it is. > > If we must start using NAND rather than CMD_NAND to enable the NAND subsystem > (which is what this patch does), then a lot more than that needs to change. > We'll need a new name for the boot source selection, and we'll need to > kconfigize all the boards that enable CONFIG_CMD_NAND via the board config > header. OK, I see your point now too. Yes, we need to tackle NAND/CMD_NAND Kconfig stuff (including the tangled web of CMD_NAND being how we toggle NAND the functionality) as a pre-patch series to this. But it needs doing :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mx6slevk: imximage.cfg: update to fix tINIT3 and tIH-CA violations
On Fri, Apr 1, 2016 at 6:54 PM, Tom Rini wrote: > Having had a similar board and memory part under logic analyzer, a > tINIT3 violation was measured. The fix was involved keeping tXPR and > SDE_to_RST at the power-on defaults and setting RST_to_CKE the JEDEC > value for LPDDR2. There was also a tIH-CA violation and this was > resolved by writing the default value in rather than what the script > here uses. > > Cc: Fabio Estevam > Cc: Peng Fan > Signed-off-by: Tom Rini Good fix! Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: Update Scott Wood's email address
Freescale is now NXP. I still work there, but I won't be using their mail system for U-Boot development. Signed-off-by: Scott Wood --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 32f97b2..8f371fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -348,7 +348,7 @@ F: drivers/net/ F: net/ NAND FLASH -M: Scott Wood +M: Scott Wood S: Maintained T: git git://git.denx.de/u-boot-nand-flash.git F: drivers/mtd/nand/ -- 2.5.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, 2016-04-01 at 19:41 -0400, Tom Rini wrote: > On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > > > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > > > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > > > using menuconfig or defconfig. > > > > > > > > Signed-off-by: Mugunthan V N > > > > > > Good but you need to update configs/ to remove NAND from > > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > > > NACK > > > > That CONFIG_NAND is a target-local option used by some boards to indicate > > boot > > source. It is not equivalent to CONFIG_CMD_NAND which is what enables the > > NAND subsystem. > > Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and > into a real Kconfig entry. That said, I think this might have forgotten > to enable it in other places too but just 'NAND' needs to migrate out of > where it is. If we must start using NAND rather than CMD_NAND to enable the NAND subsystem (which is what this patch does), then a lot more than that needs to change. We'll need a new name for the boot source selection, and we'll need to kconfigize all the boards that enable CONFIG_CMD_NAND via the board config header. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache
On Fri, Apr 01, 2016 at 04:16:42PM -0700, Eric Nelson wrote: > Hi Stephen, > > On 04/01/2016 03:57 PM, Stephen Warren wrote: > > On 03/31/2016 02:24 PM, Eric Nelson wrote: > >> On 03/30/2016 02:57 PM, Stephen Warren wrote: > >>> On 03/30/2016 11:34 AM, Eric Nelson wrote: > On 03/30/2016 07:36 AM, Stephen Warren wrote: > > On 03/28/2016 11:05 AM, Eric Nelson wrote: > > > > >>> > >>> We could allocate the data storage for the block cache at the top of RAM > >>> before relocation, like many other things are allocated, and hence not > >>> use malloc() for that. > >> > >> Hmmm. We seem to have gone from a discussion about data structures to > >> type of allocation. > >> > >> I'm interested in seeing how that works. Can you provide hints about > >> what's doing this now? > > > > Something like common/board_f.c:reserve_mmu() and many other functions > > there. relocaddr starts at approximately the top of RAM, continually > > gets adjusted down as many static allocations are reserved, and > > eventually becomes the address that U-Boot is relocated to. Simply > > adding another entry into init_sequence_f[] for the disk cache might work. > > > > Thanks for the pointer. I'll review that when time permits. > > This would remove the opportunity to re-configure the cache though, right? > > I'm not sure whether how important this feature is, and I think > only time and use will tell. > > I'd prefer to keep that ability at least for a cycle or two so that > I and others can test. > > While re-working the code, I also thought more about using an array and > still don't see how the implementation doesn't get more complex. > > The key bit is that the list is implemented in MRU order so > invalidating the oldest is trivial. > >>> > >>> Yes, the MRU logic would make it more complex. Is that particularly > >>> useful, i.e. is it an intrinsic part of the speedup? > >> > >> It's not a question of speed with small numbers of entries. The code > >> to handle eviction would just be more complex. > > > > My thought was that if the eviction algorithm wasn't important (i.e. > > most of the speedup comes from have some (any) kind of cache, but the > > eviction algorithm makes little difference to the gain from having the > > cache), we could just drop MRU completely. If that's not possible, then > > indeed a list would make implementing MRU easier. > > > > How would we decide which block to discard? I haven't traced enough > to know what algorithm(s) might be best, but I can say that there's > a preponderance of repeated accesses to the last-accessed block, > especially in ext4. > > > You could still do a list with a statically allocated set of list nodes, > > especially since the length of the list is bounded. > > > > Sure. A pooled allocator (pool of free nodes) works well with > array-based allocation. > > Having a fixed upper limit on the number of blocks would require > additional checking unless we just sized it for (max entries * max > blocks/entry). > > >> Given that the command "blkcache configure 0 0" will discard all > >> cache and since both dfu and ums should properly have the cache > >> disabled, I'd like to proceed as-is with the list and heap approach. > > > > I don't understand "since both dfu and ums should properly have the > > cache disabled"; I didn't see anything that did that. Perhaps you're > > referring to the fact that writes invalidate the cache? > > > > Yes, but also that the host will cache blocks in the ums case, so > having the cache enabled will only slow things down slightly by > lots of memcpy's to cached blocks that won't be helpful. > > I think I was a bit flippant by including dfu in this statement, > since I haven't used it to access anything except SPI-NOR. > > > Eventually it seems better to keep the cache enabled for at least DFU to > > a filesystem (rather than raw block device) since presumably parsing the > > directory structure to write to a file for DFU would benefit from the > > cache just like anything else. > > I'm not in a position to comment about dfu. For the record, I think this discussion is good and important, but not a blocker for getting the initial functionality in. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, Apr 01, 2016 at 06:07:18PM -0500, Scott Wood wrote: > On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > > using menuconfig or defconfig. > > > > > > Signed-off-by: Mugunthan V N > > > > Good but you need to update configs/ to remove NAND from > > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > NACK > > That CONFIG_NAND is a target-local option used by some boards to indicate boot > source. It is not equivalent to CONFIG_CMD_NAND which is what enables the > NAND subsystem. Exactly! We need to have 'NAND' moved from CONFIG_SYS_EXTRA_OPTIONS and into a real Kconfig entry. That said, I think this might have forgotten to enable it in other places too but just 'NAND' needs to migrate out of where it is. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass
On Fri, 2016-04-01 at 18:25 -0500, Scott Wood wrote:
> On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> > +static int nand_child_pre_probe(struct udevice *dev)
> > +{
> > + nand_info_t *nand = dev_get_uclass_priv(dev);
> > + void *priv = dev_get_priv(dev);
> > +
> > + /*
> > +* Store nand device priv pointer in nand_info so that
> > +* it can be used by nand command
> > +*/
> > + nand->priv = priv;
>
> Wouldn't it make more sense to have a pointer to the device in the NAND
> struct, and let the driver manage both privs as it chooses?
This makes even less sense after seeing patch 5/9, which assumes dev priv is
nand_info_t, and stores its own data in nand->priv. Won't this overwrite
that?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass
On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> +static int nand_child_pre_probe(struct udevice *dev)
> +{
> + nand_info_t *nand = dev_get_uclass_priv(dev);
> + void *priv = dev_get_priv(dev);
> +
> + /*
> + * Store nand device priv pointer in nand_info so that
> + * it can be used by nand command
> + */
> + nand->priv = priv;
Wouldn't it make more sense to have a pointer to the device in the NAND
struct, and let the driver manage both privs as it chooses?
> +
> + return 0;
> +}
> +
> +UCLASS_DRIVER(nand) = {
> + .id = UCLASS_NAND,
> + .name = "nand",
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> + .post_probe = nand_child_pre_probe,
> + .per_device_auto_alloc_size = sizeof(nand_info_t),
> +};
Post probe = pre probe?
> @@ -63,8 +63,10 @@ int nand_register(int devnum)
> static void nand_init_chip(int i)
> {
> struct mtd_info *mtd;
> +#ifndef CONFIG_DM_NAND
> struct nand_chip *nand = &nand_chip[i];
> ulong base_addr = base_address[i];
> +#endif
> int maxchips = CONFIG_SYS_NAND_MAX_CHIPS;
>
> if (maxchips < 1)
> @@ -74,11 +76,13 @@ static void nand_init_chip(int i)
> if (!mtd)
> return;
>
> +#ifndef CONFIG_DM_NAND
> mtd->priv = nand;
> nand->IO_ADDR_R = nand->IO_ADDR_W = (void __iomem *)base_addr;
>
> if (board_nand_init(nand))
> return;
> +#endif
>
> if (nand_scan(mtd, maxchips))
> return;
Please do not use this code for DM. Have drivers' probe functions call
nand_scan (split into ident and tail if necessary) as is done with
CONFIG_SYS_NAND_SELF_INIT.
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 37c4176..6a88d39 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -49,6 +49,7 @@ enum uclass_id {
> UCLASS_MMC, /* SD / MMC card or chip */
> UCLASS_MOD_EXP, /* RSA Mod Exp device */
> UCLASS_MTD, /* Memory Technology Device (MTD) device
> */
> + UCLASS_NAND,/* NAND bus */
NAND is not a bus.
> +#ifndef CONFIG_DM_NAND
> static inline nand_info_t *get_nand_dev_by_index(int dev)
> {
> if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> @@ -154,5 +156,8 @@ static inline nand_info_t *get_nand_dev_by_index(int
> dev)
>
> return &nand_info[dev];
> }
> +#else
> +nand_info_t *get_nand_dev_by_index(int idx);
> +#endif
Please use "if X/else", not "if !X/else".
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache
Hi Stephen, On 04/01/2016 03:57 PM, Stephen Warren wrote: > On 03/31/2016 02:24 PM, Eric Nelson wrote: >> On 03/30/2016 02:57 PM, Stephen Warren wrote: >>> On 03/30/2016 11:34 AM, Eric Nelson wrote: On 03/30/2016 07:36 AM, Stephen Warren wrote: > On 03/28/2016 11:05 AM, Eric Nelson wrote: >>> >>> We could allocate the data storage for the block cache at the top of RAM >>> before relocation, like many other things are allocated, and hence not >>> use malloc() for that. >> >> Hmmm. We seem to have gone from a discussion about data structures to >> type of allocation. >> >> I'm interested in seeing how that works. Can you provide hints about >> what's doing this now? > > Something like common/board_f.c:reserve_mmu() and many other functions > there. relocaddr starts at approximately the top of RAM, continually > gets adjusted down as many static allocations are reserved, and > eventually becomes the address that U-Boot is relocated to. Simply > adding another entry into init_sequence_f[] for the disk cache might work. > Thanks for the pointer. I'll review that when time permits. This would remove the opportunity to re-configure the cache though, right? I'm not sure whether how important this feature is, and I think only time and use will tell. I'd prefer to keep that ability at least for a cycle or two so that I and others can test. While re-working the code, I also thought more about using an array and still don't see how the implementation doesn't get more complex. The key bit is that the list is implemented in MRU order so invalidating the oldest is trivial. >>> >>> Yes, the MRU logic would make it more complex. Is that particularly >>> useful, i.e. is it an intrinsic part of the speedup? >> >> It's not a question of speed with small numbers of entries. The code >> to handle eviction would just be more complex. > > My thought was that if the eviction algorithm wasn't important (i.e. > most of the speedup comes from have some (any) kind of cache, but the > eviction algorithm makes little difference to the gain from having the > cache), we could just drop MRU completely. If that's not possible, then > indeed a list would make implementing MRU easier. > How would we decide which block to discard? I haven't traced enough to know what algorithm(s) might be best, but I can say that there's a preponderance of repeated accesses to the last-accessed block, especially in ext4. > You could still do a list with a statically allocated set of list nodes, > especially since the length of the list is bounded. > Sure. A pooled allocator (pool of free nodes) works well with array-based allocation. Having a fixed upper limit on the number of blocks would require additional checking unless we just sized it for (max entries * max blocks/entry). >> Given that the command "blkcache configure 0 0" will discard all >> cache and since both dfu and ums should properly have the cache >> disabled, I'd like to proceed as-is with the list and heap approach. > > I don't understand "since both dfu and ums should properly have the > cache disabled"; I didn't see anything that did that. Perhaps you're > referring to the fact that writes invalidate the cache? > Yes, but also that the host will cache blocks in the ums case, so having the cache enabled will only slow things down slightly by lots of memcpy's to cached blocks that won't be helpful. I think I was a bit flippant by including dfu in this statement, since I haven't used it to access anything except SPI-NOR. > Eventually it seems better to keep the cache enabled for at least DFU to > a filesystem (rather than raw block device) since presumably parsing the > directory structure to write to a file for DFU would benefit from the > cache just like anything else. I'm not in a position to comment about dfu. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Fri, 2016-04-01 at 08:51 -0400, Tom Rini wrote: > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > > > Add CONFIG_NAND as a Kconfig option so that it can be selected > > using menuconfig or defconfig. > > > > Signed-off-by: Mugunthan V N > > Good but you need to update configs/ to remove NAND from > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y NACK That CONFIG_NAND is a target-local option used by some boards to indicate boot source. It is not equivalent to CONFIG_CMD_NAND which is what enables the NAND subsystem. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] drivers: block: add block device cache
On 03/31/2016 02:24 PM, Eric Nelson wrote:
Hi Stephen,
On 03/30/2016 02:57 PM, Stephen Warren wrote:
On 03/30/2016 11:34 AM, Eric Nelson wrote:
Thanks again for the detailed review, Stephen.
On 03/30/2016 07:36 AM, Stephen Warren wrote:
On 03/28/2016 11:05 AM, Eric Nelson wrote:
Add a block device cache to speed up repeated reads of block devices by
various filesystems.
diff --git a/disk/part.c b/disk/part.c
@@ -268,6 +268,8 @@ void part_init(struct blk_desc *dev_desc)
const int n_ents = ll_entry_count(struct part_driver,
part_driver);
struct part_driver *entry;
+blkcache_invalidate(dev_desc->if_type, dev_desc->devnum);
Doesn't this invalidate the cache far too often? I expect that function
is called for command the user executes from the command-line, whereas
it'd be nice if the cache persisted across commands. I suppose this is a
reasonable (and very safe) first implementation though, and saves having
to go through each storage provider type and find out the right place to
detect media changes.
I'm not sure it does. I traced through the mmc initialization and it's
only called when the card itself is initialized.
I don't believe U-Boot caches the partition structure across user
commands. Doesn't each user command (e.g. part list, ls, load, save)
first look up the block device, then scan the partition table, then
"mount" the filesystem, then perform its action, then throw all that
state away? Conversely, "mmc rescan" only happens under explicit user
control. Still as I said, the current implementation is probably fine to
start with, and at least is safe.
At least for MMC, this isn't the case. Various filesystem commands
operate without calling part_init.
Interesting; that step is indeed only performed when the device is first
probed for MMC and USB.
diff --git a/drivers/block/blkcache.c b/drivers/block/blkcache.c
+struct block_cache_node {
+struct list_head lh;
+int iftype;
+int devnum;
+lbaint_t start;
+lbaint_t blkcnt;
+unsigned long blksz;
+char *cache;
+};
+
+static LIST_HEAD(block_cache);
+
+static struct block_cache_stats _stats = {
+.max_blocks_per_entry = 2,
+.max_entries = 32
+};
Now is a good time to mention another reason why I don't like using a
dynamically allocated linked list for this: Memory fragmentation. By
dynamically allocating the cache, we could easily run into a situation
where the user runs a command that allocates memory and also adds to the
block cache, then most of that memory gets freed when U-Boot returns to
the command prompt, then the user runs the command again but it fails
since it can't allocate the memory due to fragmentation of the heap.
This is a real problem I've seen e.g. with the "ums" and "dfu" commands,
since they might initialize the USB controller the first time they're
run, which allocates some new memory. Statically allocation would avoid
this.
We're going to allocate a block or set of blocks every time we allocate
a new node for the list, so having the list in an array doesn't fix the
problem.
We could allocate the data storage for the block cache at the top of RAM
before relocation, like many other things are allocated, and hence not
use malloc() for that.
Hmmm. We seem to have gone from a discussion about data structures to
type of allocation.
I'm interested in seeing how that works. Can you provide hints about
what's doing this now?
Something like common/board_f.c:reserve_mmu() and many other functions
there. relocaddr starts at approximately the top of RAM, continually
gets adjusted down as many static allocations are reserved, and
eventually becomes the address that U-Boot is relocated to. Simply
adding another entry into init_sequence_f[] for the disk cache might work.
While re-working the code, I also thought more about using an array and
still don't see how the implementation doesn't get more complex.
The key bit is that the list is implemented in MRU order so
invalidating the oldest is trivial.
Yes, the MRU logic would make it more complex. Is that particularly
useful, i.e. is it an intrinsic part of the speedup?
It's not a question of speed with small numbers of entries. The code
to handle eviction would just be more complex.
My thought was that if the eviction algorithm wasn't important (i.e.
most of the speedup comes from have some (any) kind of cache, but the
eviction algorithm makes little difference to the gain from having the
cache), we could just drop MRU completely. If that's not possible, then
indeed a list would make implementing MRU easier.
You could still do a list with a statically allocated set of list nodes,
especially since the length of the list is bounded.
Given that the command "blkcache configure 0 0" will discard all
cache and since both dfu and ums should properly have the cache
disabled, I'd like to proceed as-is with the list and heap approach.
I don't understand "since both dfu and ums should properly hav
Re: [U-Boot] [PATCH 2/9] cmd: nand: abstract global variable usage for dm conversion
[Please CC me at this address rather than my NXP address]
On Fri, 2016-04-01 at 16:59 +0530, Mugunthan V N wrote:
> @@ -432,12 +435,7 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>* one before these commands can run, even if a partition specifier
>* for another device is to be used.
>*/
> - if (dev < 0 || dev >= CONFIG_SYS_MAX_NAND_DEVICE ||
> - !nand_info[dev].name) {
> - puts("\nno devices available\n");
> - return 1;
> - }
> - nand = &nand_info[dev];
> + nand = get_nand_dev_by_index(dev);
>
> if (strcmp(cmd, "bad") == 0) {
You eliminated the error check -- now a NULL deref is likely if a bad dev is
requested. Even if it's checked elsewhere when setting nand_curr_device, it's
possible that the initial default is bad (no NAND devices present, or device 0
failed).
> printf("\nDevice %d bad blocks:\n", dev);
> @@ -496,13 +494,13 @@ static int do_nand(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> /* skip first two or three arguments, look for offset and
> size */
> if (mtd_arg_off_size(argc - o, argv + o, &dev, &off, &size,
>&maxsize, MTD_DEV_TYPE_NAND,
> - nand_info[dev].size) != 0)
> + nand->size) != 0)
> return 1;
>
> if (set_dev(dev))
> return 1;
>
> - nand = &nand_info[dev];
> + nand = get_nand_dev_by_index(dev);
Maybe have set_dev return the dev pointer?
Or have a global for the pointer rather than just the index, saving a bunch of
these calls.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx6qarm2: imximage_mx6dl.cfg update to fix tINIT3 violation
Having had a similar board and memory part under logic analyzer, a tINIT3 violation was measured. The fix was involved keeping tXPR and SDE_to_RST at the power-on defaults and setting RST_to_CKE the JEDEC value for LPDDR2. Cc: Jason Liu Cc: Ye Li Signed-off-by: Tom Rini --- board/freescale/mx6qarm2/imximage_mx6dl.cfg |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/mx6qarm2/imximage_mx6dl.cfg b/board/freescale/mx6qarm2/imximage_mx6dl.cfg index ae8dcc6..1f5a0a5 100644 --- a/board/freescale/mx6qarm2/imximage_mx6dl.cfg +++ b/board/freescale/mx6qarm2/imximage_mx6dl.cfg @@ -234,7 +234,7 @@ DATA 4 0x021b0018 0x174C /* MMDC0_MDRWD;*/ DATA 4 0x021b002c 0x0f9f26d2 /* MMDC0_MDOR */ -DATA 4 0x021b0030 0x020e +DATA 4 0x021b0030 0x009f0e10 /* MMDC0_MDCFG3LP */ DATA 4 0x021b0038 0x00190778 /* MMDC0_MDOTC */ @@ -263,7 +263,7 @@ DATA 4 0x021b4018 0x174C /* MMDC1_MDRWD;*/ DATA 4 0x021b402c 0x0f9f26d2 /* MMDC1_MDOR */ -DATA 4 0x021b4030 0x020e +DATA 4 0x021b4030 0x009f0e10 /* MMDC1_MDCFG3LP */ DATA 4 0x021b4038 0x00190778 /* MMDC1_MDOTC */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx6slevk: imximage.cfg: update to fix tINIT3 and tIH-CA violations
Having had a similar board and memory part under logic analyzer, a tINIT3 violation was measured. The fix was involved keeping tXPR and SDE_to_RST at the power-on defaults and setting RST_to_CKE the JEDEC value for LPDDR2. There was also a tIH-CA violation and this was resolved by writing the default value in rather than what the script here uses. Cc: Fabio Estevam Cc: Peng Fan Signed-off-by: Tom Rini --- board/freescale/mx6slevk/imximage.cfg |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/freescale/mx6slevk/imximage.cfg b/board/freescale/mx6slevk/imximage.cfg index 16ea597..c77bbde 100644 --- a/board/freescale/mx6slevk/imximage.cfg +++ b/board/freescale/mx6slevk/imximage.cfg @@ -70,7 +70,7 @@ DATA 4 0x020e05d0 0x0008 DATA 4 0x021b001c 0x8000 DATA 4 0x021b085c 0x1b4700c7 DATA 4 0x021b0800 0xa1390003 -DATA 4 0x021b0890 0x0030 +DATA 4 0x021b0890 0x0040 DATA 4 0x021b08b8 0x0800 DATA 4 0x021b081c 0x DATA 4 0x021b0820 0x @@ -92,7 +92,7 @@ DATA 4 0x021b0010 0x00100A82 DATA 4 0x021b0014 0x0093 DATA 4 0x021b0018 0x1688 DATA 4 0x021b002c 0x0f9f26d2 -DATA 4 0x021b0030 0x020e +DATA 4 0x021b0030 0x009f0e10 DATA 4 0x021b0038 0x00190778 DATA 4 0x021b0008 0x DATA 4 0x021b0040 0x004f -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] i.MX6 LPDDR2 fixes
Hey all, The following two patches fix JEDEC violations that were observed when I was working on a board similar to the MX6SL EVK. Based on talking with Micron and reading up on what the code here is (and isn't) doing, I'm certain these issues exist on the reference platforms here. I'm publishing these for correctness. I'm also not updating the the SPL code as I haven't tested that (and only could for EVK anyhow) but would suggest it's worth a follow-up from tha maintainers. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image-fit: Change FIT prefix for configurations
On Thu, Mar 17, 2016 at 02:05:59PM +, Sáreník Ján wrote:
> Instead of `bootm ${loadaddr}#conf@1`
> one uses `bootm ${loadaddr}_conf@1`
>
> This fixes the bug with using just `bootm #conf@2`
> without $loadaddr where text starting with # is
> interpreted as a comment.
[snip]
> diff --git a/doc/uImage.FIT/command_syntax_extensions.txt
> b/doc/uImage.FIT/command_syntax_extensions.txt
> index 6c99b1c..ef4db80 100644
> --- a/doc/uImage.FIT/command_syntax_extensions.txt
> +++ b/doc/uImage.FIT/command_syntax_extensions.txt
> @@ -36,7 +36,7 @@ Old uImage:
> New uImage:
> 8. bootm
> 9. bootm []:
> -10. bootm []#
> +10. bootm []_
> 11. bootm []: []:
> 12. bootm []: []: []:
> 13. bootm []: []:
So the bug you've found is that we don't parse "bootm #conf@2"
correctly. We cannot change what has been working and is likely in the
wild of "bootm ${loadaddr}#conf@2". I think what we have to do here is
correct the syntax file here to note that addr1 is not optional in that
case and add a new form. I would first suggest seeing how it looks in
code to have "bootm conf@2" just work. If it ends up being too tricky
or complex, "bootm _conf@" is OK as the new one.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] Disable USB options for SPL build
Hi All, Since we are moving config options from include/configs/* to Kconfigs and defconfigs, we can't do #ifdefs anymore. Example: in include/configs/am43xx_evm.h you can see next code: #if !defined(CONFIG_SPL_BUILD) || \ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_USBETH_SUPPORT)) #define CONFIG_USB_GADGET ... #endif So USB GADGET builds only for U-Boot, but doesn't builds for SPL. But when defining the same CONFIG_USB_GADGET option in defconfig, we can't do #ifdef code. My question is, should we hardcode this in corresponding drivers instead? Or perhaps it should be done in some more elegant way? Or we can just forget about this and let it be built for both U-Boot and SPL? Please share your thoughts on this matter. Thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] setenv() and variable flags, especially "read-only"
Hi everybody! I'm wondering what the correct / official way of setting a "read-only" environment variable is. It's simple enough to declare some #define CONFIG_ENV_FLAGS_LIST_STATIC "myvar:sr" to begin with, but this backfires - i.e. prevents write access - as soon as I try to set a value programmatically via setenv() (from within U-Boot code). A workaround is to use the "write-once" flag instead, but this leaves an undesired loop-hole in case "myvar" is supposed to remain empty/unset - where "write-once" would still allow the user to set a value interactively. U-Boot already has a clear distinction between programmatic access via setenv(), resulting in _do_env_set(..., H_PROGRAMMATIC), and user interaction (from U-Boot prompt or scripts) ending up as _do_env_set(..., H_INTERACTIVE). Looking at env_flags_validate() in env_flags.c I notice that it handles H_FORCE, but doesn't make any use of H_PROGRAMMATIC. The second (and more basic) question therefore is: Is programmatic access from within U-Boot via setenv() supposed to always respect the flags of variables (when even the user might possibly circumvent them with "setenv -f" resulting in H_FORCE), or might it be more sensible to allow all 'internal' setenv() access, disregarding any flags (treating H_PROGRAMMATIC as "always force")? I'm aware that changing this behaviour might have broad consequences. The use case I have in mind is "locking down" (user) access to the fel_* variables used by sunxi - see http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=2d5335f9531c27da59b8b4f9311ccf2a0199859a;hb=HEAD#l568 . The questions/discussion in http://lists.denx.de/pipermail/u-boot/2015-September/227611.html might also be relevant. Regards, B. Nortmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: sr1500: Remove USB_GADGET
From: Sam Protsenko "buildman" tool revealed that USB_GADGET was enabled by mistake for this board in process of moving that option to Kconfig. Remove it to bring things back to correct state. Signed-off-by: Sam Protsenko --- configs/socfpga_sr1500_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/configs/socfpga_sr1500_defconfig b/configs/socfpga_sr1500_defconfig index 2842fba..d499a14 100644 --- a/configs/socfpga_sr1500_defconfig +++ b/configs/socfpga_sr1500_defconfig @@ -21,5 +21,3 @@ CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_SYS_NS16550=y CONFIG_CADENCE_QSPI=y -CONFIG_USB=y -CONFIG_USB_GADGET=y -- 2.8.0.rc3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] mpc85xx: Enable pre-relocation malloc for MPC85xx
On 04/01/2016 01:13 AM, Mario Six wrote:
> To enable DM on MPC85xx, we need pre-relocation malloc, which is
> implemented in this patch.
>
> We also make sure that the IVORs are always 4-aligned on e500 to prevent
> alignment exceptions caused by code changes in start.S.
>
> Signed-off-by: Mario Six
> Cc: York Sun
> Cc: Simon Glass
> ---
>
> v2:
> - Correct IVOR alignment and remove nop hack
> - Add sanity check for length of malloc area
>
>
> arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 8
> arch/powerpc/cpu/mpc85xx/start.S | 28
> include/ppc_asm.tmpl | 3 +++
> 3 files changed, 31 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> index 235a635..e6e1688 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> @@ -82,7 +82,6 @@ void setup_ifc(void)
> void cpu_init_early_f(void *fdt)
> {
> u32 mas0, mas1, mas2, mas3, mas7;
> - int i;
> #ifdef CONFIG_SYS_FSL_ERRATUM_P1010_A003549
> ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> #endif
> @@ -95,13 +94,6 @@ void cpu_init_early_f(void *fdt)
> /* Pointer is writable since we allocated a register for it */
> gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
>
> - /*
> - * Clear initial global data
> - * we don't use memset so we can share this code with NAND_SPL
> - */
> - for (i = 0; i < sizeof(gd_t); i++)
> - ((char *)gd)[i] = 0;
> -
I would appreciate a comment here to explain GD had been zeroed by ...
> #ifdef CONFIG_QEMU_E500
> /*
>* CONFIG_SYS_CCSRBAR_PHYS below may use gd->fdt_blob on ePAPR systems,
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S
> b/arch/powerpc/cpu/mpc85xx/start.S
> index d867e2a..cc4cf5f 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -1152,6 +1152,34 @@ _start_cont:
> /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
> lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
> ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> +
> +#ifdef CONFIG_SYS_MALLOC_F_LEN
> +
> +#if CONFIG_SYS_MALLOC_F_LEN + GENERATED_GBL_DATA_SIZE >
> CONFIG_SYS_INIT_RAM_SIZE
> +#error "CONFIG_SYS_MALLOC_F_LEN too large to fit into initial RAM."
> +#endif
I am not an expert on linking. I wonder if there can be a way to determine the
max depth of stack. If we can, a check here would be great. If we can't, we have
to live with it.
> +
> + /* Leave 16+ byte for back chain termination and NULL return address */
> + subir3,r3,((CONFIG_SYS_MALLOC_F_LEN+16+15)&~0xf)
> +
> + /* End of RAM */
> + lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
> + ori r4,r4,(CONFIG_SYS_INIT_RAM_SIZE)@l
> +
> + li r0,0
> +
> +1: subir4,r4,4
> + stw r0,0(r4)
> + cmplw r4,r3
> + bne 1b
> +
> + lis r4,(CONFIG_SYS_INIT_RAM_ADDR)@h
> + ori r4,r4,(CONFIG_SYS_GBL_DATA_OFFSET)@l
> +
> + addir3,r3,16/* Pre-relocation malloc area */
> + stw r3,GD_MALLOC_BASE(r4)
> + subir3,r3,16
> +#endif
> li r0,0
> stw r0,0(r3)/* Terminate Back Chain */
> stw r0,+4(r3) /* NULL return address. */
I was thinking to add .align 4 before the start of exception vectors.
York
> diff --git a/include/ppc_asm.tmpl b/include/ppc_asm.tmpl
> index ba166eb..379c493 100644
> --- a/include/ppc_asm.tmpl
> +++ b/include/ppc_asm.tmpl
> @@ -263,12 +263,14 @@
> b transfer_to_handler
>
> #define STD_EXCEPTION(n, label, hdlr)\
> +.align 4;\
> label: \
> EXCEPTION_PROLOG(SRR0, SRR1); \
> addir3,r1,STACK_FRAME_OVERHEAD; \
> EXC_XFER_TEMPLATE(n, label, hdlr, MSR_KERNEL, NOCOPY) \
>
> #define CRIT_EXCEPTION(n, label, hdlr) \
> +.align 4;\
> label: \
> EXCEPTION_PROLOG(CSRR0, CSRR1); \
> addir3,r1,STACK_FRAME_OVERHEAD; \
> @@ -276,6 +278,7 @@ label:
> \
> MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE), NOCOPY) \
>
> #define MCK_EXCEPTION(n, label, hdlr)\
> +.align 4;\
> label: \
> EXCEPTION_PROLOG(MCSRR0, MCSRR1); \
> addir3,r1,STACK_FRAME_OVERHEAD; \
> --
> 2.7.
Re: [U-Boot] pull request: u-boot-uniphier/master
On Fri, Apr 01, 2016 at 01:25:13AM +0900, Masahiro Yamada wrote: > Hi Tom, > > > Please pull u-boot-uniphier once again for u-boot-2016.05-rc1. > Mostly driver updates for UniPhier ARMv8 SoC support, > plus misc fixes. > > > The following changes since commit 080c499df689e8c42df70de44502c0d71533dda8: > > Merge branch 'master' of git://git.denx.de/u-boot-tegra (2016-03-29 > 13:33:13 -0400) > > are available in the git repository at: > > > git://git.denx.de/u-boot-uniphier.git master > > for you to fetch changes up to 7f5b1e9bd952ebdac917264f03522371a473b60c: > > ARM: uniphier: remove CONFIG_ARP_TIMEOUT define (2016-04-01 00:59:47 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] block: Add support for Ceva sata
On Thu, Mar 31, 2016 at 10:44:55AM +0200, Michal Simek wrote: > Initial Ceva Sata init code. > > Signed-off-by: Michal Simek Reviewed-by: Tom Rini ... so you can bring this along in your tree along with boards using it, thanks. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
On Fri, Apr 01, 2016 at 01:38:13PM +0200, Hans de Goede wrote: > Hi Tom, > > Here is a sunxi pull-req for v2016.05, it contains: > > - A few bugfixes, including a fix for the gigabit > ethernet problems on the Lime2 ! > - Support for USB on the A83t SoC > - Support for A64 SoCs (u-boot.bin only, no SPL) > > The A64 support involves moving a bunch of files > from arch/arm/cpu/armv7/sunxi to /arch/arm/mach-sunxi. > > The following changes since commit 080c499df689e8c42df70de44502c0d71533dda8: > > Merge branch 'master' of git://git.denx.de/u-boot-tegra (2016-03-29 > 13:33:13 -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 3ffe39ed2b66af71c7271d0cef2a248b5bf7dfdb: > > sunxi: Reserve ATF memory space on A64 (2016-04-01 09:52:28 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Nuke useless include
On 04/01/2016 03:36 PM, Chin Liang See wrote: > On Thu, 2016-03-31 at 23:07 +0200, Marek Vasut wrote: >> The dwmmc.h include was forgotten during the migration of dwmmc >> probing to DM. Since the shiny DM is in place now, remove this >> relic of the past. >> >> Signed-off-by: Marek Vasut >> Cc: Dinh Nguyen >> Cc: Chin Liang See >> --- >> arch/arm/mach-socfpga/misc.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach >> -socfpga/misc.c >> index ce3ff0a..ebaa736 100644 >> --- a/arch/arm/mach-socfpga/misc.c >> +++ b/arch/arm/mach-socfpga/misc.c >> @@ -16,7 +16,6 @@ >> #include >> #include >> #include >> -#include > > You might want to delete the header file itself. Good catch, thanks! >> #include >> #include >> #include > > Acked-by: Chin Liang See -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] gpio: tegra: remove flags parsing in xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass, it is no longer necessary for the tegra-specific xlate function to do this. Signed-off-by: Eric Nelson --- drivers/gpio/tegra_gpio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpio/tegra_gpio.c b/drivers/gpio/tegra_gpio.c index 5a03115..7ae1509 100644 --- a/drivers/gpio/tegra_gpio.c +++ b/drivers/gpio/tegra_gpio.c @@ -246,7 +246,6 @@ static int tegra_gpio_xlate(struct udevice *dev, struct gpio_desc *desc, if (ret) return ret; desc->offset = gpio % TEGRA_GPIOS_PER_PORT; - desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0; return 0; } -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7] dm: gpio: handle GPIO_ACTIVE_LOW flag in DT
Device tree parsing of GPIO nodes is currently ignoring flags
and architecture-specific xlate routines are handling the
parsing of GPIO_ACTIVE_LOW.
Since GPIO_ACTIVE_LOW isn't specific to a particular device
type, this patch adds support at a global level and removes
the need for many of the driver-specific xlate routines.
Signed-off-by: Eric Nelson
---
drivers/gpio/gpio-uclass.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index b58d4e6..a3cbb83 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -118,12 +119,15 @@ static int gpio_find_and_xlate(struct gpio_desc *desc,
{
struct dm_gpio_ops *ops = gpio_get_ops(desc->dev);
+ desc->offset = -1;
+ desc->flags = 0;
/* Use the first argument as the offset by default */
- if (args->args_count > 0)
+ if (args->args_count > 0) {
desc->offset = args->args[0];
- else
- desc->offset = -1;
- desc->flags = 0;
+ if ((args->args_count > 1) &&
+ (args->args[1] & GPIO_ACTIVE_LOW))
+ desc->flags = GPIOD_ACTIVE_LOW;
+ }
return ops->xlate ? ops->xlate(desc->dev, desc, args) : 0;
}
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7] Handle GPIO_ACTIVE_LOW in gpio-uclass
As Peng pointed out in [1], GPIO_ACTIVE_LOW is currently being parsed by driver-specific xlate routines, and an NXP/mxc-specific patch ([2]) to do the same on those processors is pending. Upon further inspection, I found that many arch-specific xlate routines were present only to parse either or both offset and the GPIO_ACTIVE_LOW flag, both of which can be handled at a global level. This series adds global support for GPIO_ACTIVE_LOW and removes the architecture-specific gpio xlate routine from five drivers. It also removes the handling of flags in the tegra gpio driver, though a custom xlate is still needed. [1] - http://lists.denx.de/pipermail/u-boot/2016-March/thread.html#249946 [2] - https://patchwork.ozlabs.org/patch/597363/ Eric Nelson (7): dm: gpio: handle GPIO_ACTIVE_LOW flag in DT gpio: intel_broadwell: remove gpio_xlate routine gpio: omap: remove gpio_xlate routine gpio: pic32: remove gpio_xlate routine gpio: rk: remove gpio_xlate routine gpio: exynos(s5p): remove gpio_xlate routine gpio: tegra: remove flags parsing in xlate routine drivers/gpio/gpio-uclass.c | 12 drivers/gpio/intel_broadwell_gpio.c | 10 -- drivers/gpio/omap_gpio.c| 10 -- drivers/gpio/pic32_gpio.c | 9 - drivers/gpio/rk_gpio.c | 10 -- drivers/gpio/s5p_gpio.c | 10 -- drivers/gpio/tegra_gpio.c | 1 - 7 files changed, 8 insertions(+), 54 deletions(-) -- 2.6.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7] gpio: omap: remove gpio_xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the omap gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson
---
drivers/gpio/omap_gpio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpio/omap_gpio.c b/drivers/gpio/omap_gpio.c
index 93d18e4..5ab53bc 100644
--- a/drivers/gpio/omap_gpio.c
+++ b/drivers/gpio/omap_gpio.c
@@ -277,22 +277,12 @@ static int omap_gpio_get_function(struct udevice *dev,
unsigned offset)
return GPIOF_INPUT;
}
-static int omap_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
- struct fdtdec_phandle_args *args)
-{
- desc->offset = args->args[0];
- desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
-
- return 0;
-}
-
static const struct dm_gpio_ops gpio_omap_ops = {
.direction_input= omap_gpio_direction_input,
.direction_output = omap_gpio_direction_output,
.get_value = omap_gpio_get_value,
.set_value = omap_gpio_set_value,
.get_function = omap_gpio_get_function,
- .xlate = omap_gpio_xlate,
};
static int omap_gpio_probe(struct udevice *dev)
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7] gpio: exynos(s5p): remove gpio_xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Exynos/S5P gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson
---
drivers/gpio/s5p_gpio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 0f22b23..591c036 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -276,22 +276,12 @@ static int exynos_gpio_get_function(struct udevice *dev,
unsigned offset)
return GPIOF_FUNC;
}
-static int exynos_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
-struct fdtdec_phandle_args *args)
-{
- desc->offset = args->args[0];
- desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
-
- return 0;
-}
-
static const struct dm_gpio_ops gpio_exynos_ops = {
.direction_input= exynos_gpio_direction_input,
.direction_output = exynos_gpio_direction_output,
.get_value = exynos_gpio_get_value,
.set_value = exynos_gpio_set_value,
.get_function = exynos_gpio_get_function,
- .xlate = exynos_gpio_xlate,
};
static int gpio_exynos_probe(struct udevice *dev)
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/7] gpio: pic32: remove gpio_xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the pic32 gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson
---
drivers/gpio/pic32_gpio.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpio/pic32_gpio.c b/drivers/gpio/pic32_gpio.c
index 499b4fa..6999bc0 100644
--- a/drivers/gpio/pic32_gpio.c
+++ b/drivers/gpio/pic32_gpio.c
@@ -99,14 +99,6 @@ static int pic32_gpio_direction_output(struct udevice *dev,
return 0;
}
-static int pic32_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
- struct fdtdec_phandle_args *args)
-{
- desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
-
- return 0;
-}
-
static int pic32_gpio_get_function(struct udevice *dev, unsigned offset)
{
int ret = GPIOF_UNUSED;
@@ -131,7 +123,6 @@ static const struct dm_gpio_ops gpio_pic32_ops = {
.get_value = pic32_gpio_get_value,
.set_value = pic32_gpio_set_value,
.get_function = pic32_gpio_get_function,
- .xlate = pic32_gpio_xlate,
};
static int pic32_gpio_probe(struct udevice *dev)
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7] gpio: intel_broadwell: remove gpio_xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the intel_broadwell driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson
---
drivers/gpio/intel_broadwell_gpio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpio/intel_broadwell_gpio.c
b/drivers/gpio/intel_broadwell_gpio.c
index 8cf76f9..81ce446 100644
--- a/drivers/gpio/intel_broadwell_gpio.c
+++ b/drivers/gpio/intel_broadwell_gpio.c
@@ -162,15 +162,6 @@ static int broadwell_gpio_ofdata_to_platdata(struct
udevice *dev)
return 0;
}
-static int broadwell_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
- struct fdtdec_phandle_args *args)
-{
- desc->offset = args->args[0];
- desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
-
- return 0;
-}
-
static const struct dm_gpio_ops gpio_broadwell_ops = {
.request= broadwell_gpio_request,
.direction_input= broadwell_gpio_direction_input,
@@ -178,7 +169,6 @@ static const struct dm_gpio_ops gpio_broadwell_ops = {
.get_value = broadwell_gpio_get_value,
.set_value = broadwell_gpio_set_value,
.get_function = broadwell_gpio_get_function,
- .xlate = broadwell_gpio_xlate,
};
static const struct udevice_id intel_broadwell_gpio_ids[] = {
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7] gpio: rk: remove gpio_xlate routine
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Rockchip gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson
---
drivers/gpio/rk_gpio.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index 40e87bd..253ccec 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -98,15 +98,6 @@ static int rockchip_gpio_get_function(struct udevice *dev,
unsigned offset)
#endif
}
-static int rockchip_gpio_xlate(struct udevice *dev, struct gpio_desc *desc,
- struct fdtdec_phandle_args *args)
-{
- desc->offset = args->args[0];
- desc->flags = args->args[1] & GPIO_ACTIVE_LOW ? GPIOD_ACTIVE_LOW : 0;
-
- return 0;
-}
-
static int rockchip_gpio_probe(struct udevice *dev)
{
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
@@ -135,7 +126,6 @@ static const struct dm_gpio_ops gpio_rockchip_ops = {
.get_value = rockchip_gpio_get_value,
.set_value = rockchip_gpio_set_value,
.get_function = rockchip_gpio_get_function,
- .xlate = rockchip_gpio_xlate,
};
static const struct udevice_id rockchip_gpio_ids[] = {
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] arm: socfpga: Nuke useless include
The dwmmc.h include was forgotten during the migration of dwmmc probing to DM. Since the shiny DM is in place now, remove this relic of the past. Signed-off-by: Marek Vasut Cc: Dinh Nguyen Cc: Chin Liang See --- arch/arm/mach-socfpga/include/mach/dwmmc.h | 12 arch/arm/mach-socfpga/misc.c | 1 - 2 files changed, 13 deletions(-) delete mode 100644 arch/arm/mach-socfpga/include/mach/dwmmc.h V2: Remove the header file itself diff --git a/arch/arm/mach-socfpga/include/mach/dwmmc.h b/arch/arm/mach-socfpga/include/mach/dwmmc.h deleted file mode 100644 index e8ba901..000 --- a/arch/arm/mach-socfpga/include/mach/dwmmc.h +++ /dev/null @@ -1,12 +0,0 @@ -/* - * (C) Copyright 2013 Altera Corporation - * - * SPDX-License-Identifier:GPL-2.0+ - */ - -#ifndef_SOCFPGA_DWMMC_H_ -#define_SOCFPGA_DWMMC_H_ - -int socfpga_dwmmc_init(const void *blob); - -#endif /* _SOCFPGA_SDMMC_H_ */ diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c index 5f988e3..dd05e14 100644 --- a/arch/arm/mach-socfpga/misc.c +++ b/arch/arm/mach-socfpga/misc.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include #include -- 2.7.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] drivers: nand: Kconfig: add NAND as Kconfig option
On Friday 01 April 2016 06:21 PM, Tom Rini wrote: > On Fri, Apr 01, 2016 at 04:59:44PM +0530, Mugunthan V N wrote: > >> Add CONFIG_NAND as a Kconfig option so that it can be selected >> using menuconfig or defconfig. >> >> Signed-off-by: Mugunthan V N > > Good but you need to update configs/ to remove NAND from > CONFIG_SYS_EXTRA_OPTIONS and add CONFIG_NAND=y > > Doing: > $ for F in `git grep -lE SYS_EXTRA.*NAND configs/`;do sed -i -e \ > 's/,NAND//' $F && echo CONFIG_NAND=y >> $F;done > will get you most of the way there, then just a: > $ for C in `git status configs/ | grep modified: | cut -d / -f 2`;do \ > make O=$C $C savedefconfig && cp $C/defconfig configs/$C;done > > To get it in the right spot, git add -p only the bits you really wanted, > done. Thanks! > Will fix it in v2 Regards Mugunthan V N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] drivers: nand: implement a NAND uclass
On Friday 01 April 2016 06:21 PM, Tom Rini wrote: > On Fri, Apr 01, 2016 at 04:59:45PM +0530, Mugunthan V N wrote: > >> Implement a NAND uclass so that the NAND devices can be >> accessed via the DM framework. >> >> Signed-off-by: Mugunthan V N > > Minor: > >> @@ -0,0 +1,62 @@ >> +/* >> + * NAND uclass driver for NAND bus. >> + * >> + * (C) Copyright 2012-2016 >> + * Texas Instruments Incorporated, > > The code isn't that old. > Copy paste, will fix in v2 Regards Mugunthan V N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: Nuke useless include
On Thu, 2016-03-31 at 23:07 +0200, Marek Vasut wrote: > The dwmmc.h include was forgotten during the migration of dwmmc > probing to DM. Since the shiny DM is in place now, remove this > relic of the past. > > Signed-off-by: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > --- > arch/arm/mach-socfpga/misc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach > -socfpga/misc.c > index ce3ff0a..ebaa736 100644 > --- a/arch/arm/mach-socfpga/misc.c > +++ b/arch/arm/mach-socfpga/misc.c > @@ -16,7 +16,6 @@ > #include > #include > #include > -#include You might want to delete the header file itself. > #include > #include > #include Acked-by: Chin Liang See Thanks Chin Liang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
