Re: [U-Boot] Disable tftp and access
Thanks for answer, according to http://www.denx.de/wiki/view/DULG/UBootEnvVariables if I set bootdelay=0, then will not be possible to tftp image by dhcp or by push? I can't find information about possible options for stdin. Thanks. -- S pozdravom Jakub Janco 2015-01-21 8:11 GMT+01:00 Albert ARIBAUD albert.u.b...@aribaud.net: Hello Jakub, On Tue, 20 Jan 2015 20:09:21 +0100, Jakub Jančo kub...@gmail.com wrote: Hello, I want to disable uboot tftp on my device and if uboot allow some login/access(eg. by console) then disable it too. My aim is to lock uboot except booting image(OS), I want manage it only from OS(changing env variables only from OS) I want to ask what env variables I should change to disable tftp functions and access? Basically, you should look into the bootdelay and stdin variables. Thanks, Kubco Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] add README.distro file
On Mon, Jan 12, 2015 at 11:57 AM, Ian Campbell i...@hellion.org.uk wrote: On Mon, 2015-01-12 at 10:34 -0700, Stephen Warren wrote: On 01/11/2015 11:15 AM, Tom Rini wrote: On Sun, Jan 11, 2015 at 10:54:03AM -0700, Stephen Warren wrote: On 01/11/2015 02:45 AM, Ian Campbell wrote: On Sun, 2014-12-28 at 09:26 +, Ian Campbell wrote: +boot_scripts: + + The name of U-Boot style boot.scr files that $bootcmd searches for. + + Example: boot.scr.uimg boot.scr + + (Typically we expect extlinux.conf to be used, but execution of boot.scr is + maintained for backwards-compatibility.) I'm slightly concerned by the implied deprecation of the boot.scr method here, since at least Debian uses boot.scr exclusively and not the extlinux stuff. Will boot.scr be maintained going forward or are there plans to eventually remove it? Can someone confirm that there is no long term plan to drop boot.scr support? extlinux.conf *is* the standard Linux boot process that config_distro_bootcmd.h enables. boot.scr is *not*. The whole point is to introduce a new simple standard that works the same everywhere (for Linux: across boards, across distros, across bootloaders). Well, the only problem I see with this statement is that, uh, do we have buy-in from Debian? Well, there was some discussion about standard boot setups on the cross-distro mailing list. I believe someone from Debian is at least familiar with Dennis's proposal to use extlinux.conf as the standard. There was certainly no definitive agreement in those discussions though I hadn't appreciated that that this proposal was so heavily geared towards the extlinux.conf aspect, as opposed to standardising a bunch of useful env variables, which is what I thought it was mainly doing. That said, I don't think there's much choice but to standardize on /something/ other than boot.scr. boot.scr really isn't scalable for generic distros (as opposed to board-specific BSPs): * boot.scr works differently on different boards, since the set of environment variables and U-Boot commands/features available to the script are different. This leads to extremely complex boot.scr implementations that distros each have to maintain. A side effect (which I actually thought was part of the purpose until now) of config_distro_bootcmd.h was to standardize these variables. Debian now ships a common boot.scr which should work on any config_distro_bootcmd-enabled system. I suppose we could fix this by standardizing the boot.scr execution environment; providing a consistent set of variables indicating where to load kernel/DTB/..., the board name (to auto-generate DTB filename), etc. However, standardizing this is more complex that standardizing on extlinux.conf AFAICT you've already done it ;-) and still doesn't solve: * boot.scr doesn't work across different bootloaders. There's no reason generic distros should know anything much about bootloaders, other than how to generate a config file so the bootloader knows which kernel/initrd/DTB binaries to load. The distro needs to know enough about the bootloader to know it speaks extlinux.conf, which means in practice it needs to know if it is u-boot or not. From Debian's PoV the usual default bootloader is grub, which is pretty much a no-go on top of u-boot in practice. So whether it's extlinux.conf or boot.scr we have to treat things specially at the distro level and have some firmware awareness, and boot.scr is there and working today. * boot.scr must be generated (to boot.scr.uimg) using bootloader-specific tools, rather than extlinux.conf, grub.conf, ... all just need the generation of a text file. Debian already has the tooling (and has for years) to reproduce boot.scr automatically on upgrades of various relevant components, the user never needs to see the mkimage stuff (that tooling also handles various legacy non-config_distro_bootcmd systems, so it's going to have to remain for the time being either way). Currently the extlinux.conf generating stuff is tied to the x86 syslinux packages, it could be reworked and pulled out into arch indep packages, but there doesn't seem to be all that much benefit compared with what we have now which is working fairly well for us (not to imply that it's perfect). I had a patch for syslinux doing just this sometime back. My mistake was giving it to Canonical to do something with. I could dig this up. It is pretty straightforward moving of files into the syslinux-common package. There were also some settings controlling generating the menu files needed on the target rootfs to get it to work with u-boot's limited syslinux. It wasn't something we could work-around or add support for in u-boot IIRC. Rob ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] fastboot: handle flash write to GPT partitions
On Fri, Dec 12, 2014 at 5:51 PM, Steve Rae s...@broadcom.com wrote:
Implement a feature to allow fastboot to write the downloaded image
to the space reserved for the Protective MBR and the Primary GUID
Partition Table.
Additionally, prepare and write the Backup GUID Partition Table.
I've been looking at how to do the same thing here. This is an area
that suffers from each vendor doing whatever they want. Using vendor
download/flash tools here is painful. They are all different because
that is where the value add is. ;) What tool do you use on the host
side to create the image? I have seen some vendor code to do it, or
you could use parted plus a disk file and extract the partition table
from it. I find either method a bit fragile and non-standard IMHO.
The 2 options I've come up with are 1) enable USB MS and use whatever
host side tool you like or 2) use the existing gpt write command in
u-boot and tie that into fastboot oem format command. The advantage
and disadvantage of the latter is that it hides the partitioning
details in u-boot from the user, but requires changing the u-boot env
to change partition layout. The partitioning requirements are pretty
SOC specific it seems.
I'm not saying we can't support both, but having some standardization
here would be good.
Rob
Signed-off-by: Steve Rae s...@broadcom.com
---
Changes in v4:
fix bug with partition_entry_lba in Backup GPT
use common static functions
Changes in v3:
- prefer leXX_to_cpu() over cpu_to_leXX()
- enhance calculation of pointer to GPT Entries
- prepare and write the Backup GPT
(requested by: Lukasz Majewski l.majew...@samsung.com)
Changes in v2:
add validation of the GPT before writing to flash
(suggested by: Lukasz Majewski l.majew...@samsung.com)
README | 9 ++
common/fb_mmc.c | 26 ++--
disk/part_efi.c | 93
+
include/part.h | 20 +
4 files changed, 145 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 4ca04d0..42ece99 100644
--- a/README
+++ b/README
@@ -1773,6 +1773,15 @@ The following options need to be configured:
regarding the non-volatile storage device. Define this to
the eMMC device that fastboot should use to store the image.
+ CONFIG_FASTBOOT_GPT_NAME
+ The fastboot flash command supports writing the downloaded
+ image to the Protective MBR and the Primary GUID Partition
+ Table. (Additionally, this downloaded image is post-processed
+ to generate and write the Backup GUID Partition Table.)
+ This occurs when the specified partition name on the
+ fastboot flash command line matches this value.
+ Default is GPT_ENTRY_NAME (currently gpt) if undefined.
+
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
diff --git a/common/fb_mmc.c b/common/fb_mmc.c
index fb06d8a..6ea3938 100644
--- a/common/fb_mmc.c
+++ b/common/fb_mmc.c
@@ -4,12 +4,17 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include config.h
#include common.h
#include fb_mmc.h
#include part.h
#include aboot.h
#include sparse_format.h
+#ifndef CONFIG_FASTBOOT_GPT_NAME
+#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
+#endif
+
/* The 64 defined bytes plus the '\0' */
#define RESPONSE_LEN (64 + 1)
@@ -62,7 +67,6 @@ static void write_raw_image(block_dev_desc_t *dev_desc,
disk_partition_t *info,
void fb_mmc_flash_write(const char *cmd, void *download_buffer,
unsigned int download_bytes, char *response)
{
- int ret;
block_dev_desc_t *dev_desc;
disk_partition_t info;
@@ -76,8 +80,24 @@ void fb_mmc_flash_write(const char *cmd, void
*download_buffer,
return;
}
- ret = get_partition_info_efi_by_name(dev_desc, cmd, info);
- if (ret) {
+ if (strcmp(cmd, CONFIG_FASTBOOT_GPT_NAME) == 0) {
+ printf(%s: updating MBR, Primary and Backup GPT(s)\n,
+ __func__);
+ if (is_valid_gpt_buf(dev_desc, download_buffer)) {
+ printf(%s: invalid GPT - refusing to write to
flash\n,
+ __func__);
+ fastboot_fail(invalid GPT partition);
+ return;
+ }
+ if (write_mbr_and_gpt_partitions(dev_desc, download_buffer)) {
+ printf(%s: writing GPT partitions failed\n,
__func__);
+ fastboot_fail(writing GPT partitions failed);
+ return;
+ }
+ printf( success\n);
+ fastboot_okay();
+ return;
+ } else if
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
On 01/23/2015 03:19 AM, Thierry Reding wrote:
On Thu, Jan 22, 2015 at 12:04:06AM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 5:40 PM, Thierry Reding tred...@nvidia.com wrote:
On Wed, Jan 21, 2015 at 05:15:42PM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 4:24 PM, Thierry Reding tred...@nvidia.com wrote:
On Wed, Jan 21, 2015 at 10:37:07AM +0800, Bin Meng wrote:
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code to the
new fdtdec pci helpers. To get the device index of the root port, the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel this
patch is doing correctly.
It's in the U-Boot tree, look at arch/arm/dts/tegra124.dtsi for an
example.
Got it. I see:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x0100 0
0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
nvidia,num-lanes = 2;
};
So I would read this 'reg = 0x000800 0 0 0 0' as this is a
downstream port with device number 1 of the root complex.
Correct. Note that these root ports don't appear on the bus using the
regular configuration space accesses, so the definition here is
arbitrary, though in a way to mirror what PCI would typically look like
(host bridge 00:00.0, root ports 00:01.0..00:0N.0).
The Linux kernel driver (and the U-Boot driver for that matter) rely on
this numbering, though, for some aspects of configuration of the root
ports.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const void *fdt, int
node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const void *fdt,
int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
I do like how 0 actually transports the meaning of don't care here.
The reg property encodes only the BDF, whereas the configuration space
region for the root ports is encoded in the assigned-addresses property.
Looking at the fdtdec_get_pci_addr() implementation I notice that it
uses the type parameter to match on the type of region. Devices can have
more than one region of the same type. How is that supposed to work with
this function. Perhaps it's nothing we care about for the fdtdec API
since we don't access those regions anyway from FDT code?
Ah, yes, some devices may have multiple regions of the same type.
Perhaps we need another parameter bar_index for this api? So far this
API is not used by FDT codes. It is used by the ns16550 driver where
pci ns16550 normally has two bars, one memory and one i/o.
Why not use the BARs directly in the ns16550 driver rather than looking
it up from the device tree? I assume the device will have to be
enumerated anyway to make it work properly, at which point addresses
should've been assigned to the memory and I/O BARs.
It is because we cannot predict which bar to look up if we hardcod
that in the generic ns16550 driver. Normally PCI ns16550 registers can
be memory-mapped or I/O mapped and it could use any of the 6 BARs.
What's more, on x86 for memory-mapped and I/O mapped they use
different instructions to access the registers, and there is one build
time macro (CONFIG_SYS_NS16550_PORT_MAPPED) to control this.
Surely the vendor/device ID (or perhaps subvendor/device ID) directly
imply which BAR is used for this purpose? It's really part of the
specification of the interface to HW, so a particular bit of HW
shouldn't be randomly deciding to use a different BAR register each
power-on.
That sounds like pretty arbitrary restrictions. For one you can detect
invalid BARs, so selecting the right one should be easy. Also it seems
like adding support for both I/O and memory BARs in the same binary
should be
Re: [U-Boot] [PATCH] mmc: Implement SD/MMC versioning properly
On 01/23/2015 03:12 AM, Pantelis Antoniou wrote: The SD/MMC version scheme was buggy when dealing with standard major.minor.change cases. Fix it my using something similar to linux's kernel versioning method. Reported-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com (With an eMMC 4.5 device, and some random SD card) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] board: tbs2910: Gate clock when switching async clock muxes
According to the i.MX6Q Reference Manual, clocks must be gated when switching input clocks of async clock muxes. So use clock gates. Avoid ldb_di0_ipu clock, because there is no clock gate for this signal. There have never been any complaints about problems with the old code, but the new approach is in line with the recommendations in the manual. Signed-off-by: Soeren Moch sm...@web.de -- Cc: Stefano Babic sba...@denx.de --- board/tbs/tbs2910/tbs2910.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/board/tbs/tbs2910/tbs2910.c b/board/tbs/tbs2910/tbs2910.c index dfa430e..42b166d 100644 --- a/board/tbs/tbs2910/tbs2910.c +++ b/board/tbs/tbs2910/tbs2910.c @@ -326,21 +326,25 @@ static void setup_display(void) reg = ~BM_ANADIG_PLL_VIDEO_BYPASS; writel(reg, ccm-analog_pll_video); - /* select video pll for ldb_di0_clk */ - reg = readl(ccm-cs2cdr); - reg = ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK); - writel(reg, ccm-cs2cdr); + /* gate ipu1_di0_clk */ + reg = readl(ccm-CCGR3); + reg = ~MXC_CCM_CCGR3_LDB_DI0_MASK; + writel(reg, ccm-CCGR3); - /* select ldb_di0_clk / 7 for ldb_di0_ipu_clk */ - reg = readl(ccm-cscmr2); - reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV; - writel(reg, ccm-cscmr2); - - /* select ldb_di0_ipu_clk for ipu1_di0_clk - 65MHz pixclock */ + /* select video_pll clock / 7 for ipu1_di0_clk - 65MHz pixclock */ reg = readl(ccm-chsccdr); - reg |= (CHSCCDR_CLK_SEL_LDB_DI0 -MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET); + reg = ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK | +MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK | +MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK); + reg |= (2 MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_OFFSET) | + (6 MXC_CCM_CHSCCDR_IPU1_DI0_PODF_OFFSET) | + (0 MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET); writel(reg, ccm-chsccdr); + + /* enable ipu1_di0_clk */ + reg = readl(ccm-CCGR3); + reg |= MXC_CCM_CCGR3_LDB_DI0_MASK; + writel(reg, ccm-CCGR3); } #endif /* CONFIG_VIDEO_IPUV3 */ -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] fastboot: handle flash write to GPT partitions
On Fri, Jan 23, 2015 at 11:38:04AM -0600, Rob Herring wrote: On Fri, Dec 12, 2014 at 5:51 PM, Steve Rae s...@broadcom.com wrote: Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. I've been looking at how to do the same thing here. This is an area that suffers from each vendor doing whatever they want. Using vendor download/flash tools here is painful. They are all different because that is where the value add is. ;) What tool do you use on the host side to create the image? I have seen some vendor code to do it, or you could use parted plus a disk file and extract the partition table from it. I find either method a bit fragile and non-standard IMHO. The 2 options I've come up with are 1) enable USB MS and use whatever host side tool you like or 2) use the existing gpt write command in u-boot and tie that into fastboot oem format command. The advantage and disadvantage of the latter is that it hides the partitioning details in u-boot from the user, but requires changing the u-boot env to change partition layout. The partitioning requirements are pretty SOC specific it seems. I'm not saying we can't support both, but having some standardization here would be good. Option two seems good from a not firewalling off the details point of view which means that there'll be a subset that wants to go with one anyhow. -- 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] [RFC] m68k: generic board
On Thu, Jan 15, 2015 at 04:08:40PM +0100, Angelo Dureghello wrote: Dear all, i would like to post a patch with the m68k generic board support, tested and working here, but of course not tested for all the other m68k boards except mine. My coldfire board is the amcore board not yet accepted. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193661 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193660 I need some suggestions on how to proceed now. I already modified my board config to work with generic board support. So my thought is to post 2 separate patches: 1 - add generic board (1/1). Each board maintainer should then test it and report for feedbacks. 2 Re-post a 2/2 patch (v8) of amcore using generic board: - amcore board (1), - mcf5307 support (2), This amcore board is the coldfire base i use here for all the general m68k tests. With your help commenting on this patch until it is conformant to the last recent coding guidelines could help me and Alison to know what has to be purged / changed, (eventually, if needed) in all other m68k boards code. What do you think ? Lets go with #2 and we'll purge the rest of the boards that you don't want to convert and compile test after -rc1. 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/8] powerpc: mpc85xx: remove P2020COME board support
On Fri, Jan 23, 2015 at 12:24:17AM +0900, Masahiro Yamada wrote: This board is still a non-generic board. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Ira W. Snyder i...@ovro.caltech.edu 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 2/8] powerpc: mpc85xx: remove P1_P2_RDB boards
On Fri, Jan 23, 2015 at 12:24:16AM +0900, Masahiro Yamada wrote: These boards are still non-generic boards: P1011RDB, P1022RDB, P2010RDB, P2020RDB Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Poonam Aggrwal poonam.aggr...@freescale.com 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] [GIT PULL] u-boot-mips/master
On Wed, Jan 21, 2015 at 02:14:53PM +0100, Daniel Schwierzeck wrote: The following changes since commit 768f6096f9c389b5ed36bee2957bee16b085fc4a: Merge git://git.denx.de/u-boot-arc (2015-01-20 16:41:11 -0500) are available in the git repository at: git://git.denx.de/u-boot-mips.git master for you to fetch changes up to e520023882c7187a7cbaecfea0726ea158440aef: MIPS: add support for pre-relocation malloc (2015-01-21 14:07:23 +0100) 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] Pull request: u-boot-uniphier/master
On Fri, Jan 23, 2015 at 01:16:15AM +0900, Masahiro YAMADA wrote: 2015-01-23 1:14 GMT+09:00 Masahiro YAMADA yamad...@jp.panasonic.com: Hi Tom, The following changes since commit b56f6e2b4e0291efbe1b50f082dec73272ad7ab3: sunxi: Restore lowlevel_init usage (2015-01-21 10:46:28 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to 0ba924a4ecfe056ab637bfa207fc26cd0248e9ac: ARM: UniPhier: add SG_MEMCONF macros for DDR channel 2 (2015-01-23 00:52:16 +0900) Masahiro Yamada (9): ARM: UniPhier: remove __packed that causes a problem on GCC 4.9 ARM: UniPhier: fix comments in SoC Glue init function ARM: UniPhier: describe init_page_table shorter ARM: UniPhier: fix IECTRL set code for PH1-Pro4 ARM: UniPhier: add static to local functions ARM: UniPhier: remove non-sense inline directives ARM: UniPhier: use linux/sizes.h for readability ARM: UniPhier: rename SG_MEMCONF_* macros for readability ARM: UniPhier: add SG_MEMCONF macros for DDR channel 2 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 1/8] powerpc: mpc83xx: remove MPC8360ERDK, EMPC8360EMDS support
On Fri, Jan 23, 2015 at 12:24:15AM +0900, Masahiro Yamada wrote: These boards are still non-generic boards. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Dave Liu dave...@freescale.com Cc: Anton Vorontsov avoront...@ru.mvista.com 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] Please pull u-boot-mpc85xx master
On Thu, Jan 22, 2015 at 06:49:43PM -0600, York Sun wrote: The following changes since commit ab77f24119e80257de4ab017b877f92f96980562: Merge branch 'master' of git://git.denx.de/u-boot-ti (2015-01-16 10:25:01 -0500) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master for you to fetch changes up to db4a1767c09a4696792204d1cac33631cb38424e: board/T1040rdb: Add VSC9953 support for T1040rdb board (2015-01-21 09:23:36 -0600) 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 v3 0/12] Add support for caching Memory Reference Code data
Hi Bin, On 19 January 2015 at 22:16, Simon Glass s...@chromium.org wrote: Since the memory reference code is so slow on x86, add a feature to bypass this, storing the previous parameters in SPI flash. This saves around 500ms on each boot. Also enable a SPI flash environment. Changes in v3: - Add new patch to move checksum to its own file in net/ - Adjust net/ code to use the new checksum functions - Use checksum code that is now in net/checksum.c - Adjust functions to remain compatible with other RTC drivers - Drop accidental creation of link.dts due to bad rebase - Use checksum code from net/checksum.c - Add misc_init_r() call for link now that it is shared with chromebook_link I'd like to get this applied. Do you have any comments on the new checksum approach? I will need to get an Ack from Joe before I apply the net/ patch (which changes over to the new function). But the rest can come through the x86 tree. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] powerpc: mpc5xxx: remove Total5200 board support
On Fri, Jan 23, 2015 at 12:24:20AM +0900, Masahiro Yamada wrote: This board is still a non-generic board. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com 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 8/8] powerpc: remove icecube_5200, Lite5200, cpci5200, mecp5200, pf5200
On Fri, Jan 23, 2015 at 12:24:22AM +0900, Masahiro Yamada wrote: These boards are still non-generic boards. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Wolfgang Denk w...@denx.de Cc: Reinhard Arlt reinhard.a...@esd-electronics.com 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 7/8] powerpc: mpc5xxx: PM520 board support
On Fri, Jan 23, 2015 at 12:24:21AM +0900, Masahiro Yamada wrote: This board is still a non-generic board. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Josef Wagner wag...@microsys.de 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 4/8] powerpc: mpc85xx: remove P2020DS board support
On Fri, Jan 23, 2015 at 12:24:18AM +0900, Masahiro Yamada wrote: This board is still a non-generic board. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com 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 5/8] powerpc: ppc4xx: remove PPChameleonEVB, CATcenter boards
On Fri, Jan 23, 2015 at 12:24:19AM +0900, Masahiro Yamada wrote: These boards are still non-generic boards. It is a good thing that we can drop board-specific hack code from drivers/mtd/nand/nand_base.c Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Andrea llandre Marson andrea.mar...@dave-tech.it 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 v4 2/2] fastboot: handle flash write to GPT partitions
On 15-01-23 09:38 AM, Rob Herring wrote: On Fri, Dec 12, 2014 at 5:51 PM, Steve Rae s...@broadcom.com wrote: Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. I've been looking at how to do the same thing here. This is an area that suffers from each vendor doing whatever they want. Using vendor download/flash tools here is painful. They are all different because that is where the value add is. ;) What tool do you use on the host side to create the image? I have seen some vendor code to do it, or you could use parted plus a disk file and extract the partition table from it. I find either method a bit fragile and non-standard IMHO. We use an internal tool -- however, I also note that ALL of the source code for our tool is GPL-2.0+ (expect for one file which is Public Domain) Is U-Boot (Denx) interested in supporting a host tool? The 2 options I've come up with are 1) enable USB MS and use whatever host side tool you like or 2) use the existing gpt write command in u-boot and tie that into fastboot oem format command. The advantage and disadvantage of the latter is that it hides the partitioning details in u-boot from the user, but requires changing the u-boot env to change partition layout. The partitioning requirements are pretty SOC specific it seems. We also have code which creates the GPT tables from a fastboot oem format command, and (if I understand correctly) we have code that implements a gpt command line, which creates the GPT tables from env variables... If there is interest here, I could investigate further. I'm not saying we can't support both, but having some standardization here would be good. Rob I wasn't trying to promote an exclusive solution with this patch (which has been accepted - Thanks!). I was just trying to have an incremental change to the existing fastboot flash command (to handle the GPT Tables). Thanks, Steve [... snip ...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Microblaze changes
On Wed, Jan 21, 2015 at 10:34:39AM +0100, Michal Simek wrote: Hi Tom, please pull these two microblaze fixes to your tree. Thanks, Michal The following changes since commit 768f6096f9c389b5ed36bee2957bee16b085fc4a: Merge git://git.denx.de/u-boot-arc (2015-01-20 16:41:11 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git next for you to fetch changes up to da931af1b5eaae36dd9e3fb2eaf6b62201ed3a43: microblaze: Support stack protection feature (2015-01-21 10:33:07 +0100) Applied to u-boot/master, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- 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, Jan 23, 2015 at 03:49:25PM +0100, Hans de Goede wrote: Hi Tom, We've once again build-up a nice collection of patches for sunxi. Please pull u-boot-sunxi/master into master, highlights: 1) A80 support preparation (non-SPL support is ready, but waiting for the start.S cleanup) 2) Cleanup sun4i sun7i dram configuration 3) Support for some LCD panels which have a controller which requires some extra poking 4) Enable OTG support, allowing interaction with u-boot on tablets 5) Support for 8 new boards The following changes since commit b56f6e2b4e0291efbe1b50f082dec73272ad7ab3: sunxi: Restore lowlevel_init usage (2015-01-21 10:46:28 -0500) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 4e7c892d15e2aa98086aaacdb979821d011b7db2: sunxi: Use a common CONFIG_SYS_PROMPT (2015-01-23 15:15:51 +0100) 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] [GIT PULL] fpga changes
On Wed, Jan 21, 2015 at 10:28:21AM +0100, Michal Simek wrote: Hi Tom, please pull these fpga patches to your tree. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git fpga for you to fetch changes up to b9103809eb9052f40479d2d741e980832b75ebba: fpga: zynqpl: Add support for zc7035 (2015-01-21 10:25:53 +0100) Applied to u-boot/master, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- 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] [GIT PULL] Zynq SoC changes
On 01/23/2015 12:59 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 10:02:04AM +0100, Michal Simek wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. And we have a _really_ good reason for using FPU instructions, yes? The description for doing that is in the patch but to be honest the biggest problem is that xilinx toolchain has FPU instructions enabled by default. Based on that fpu instructions can be used. For standard xilinx flow FSBL/u-boot - fsbl does that setting. For debug flow TCL + u-boot we are reaching this issue. Maybe the second option can be to disable FPU instructions for u-boot compilation but then the problem is moved to next software which is designed to have FPU instructions enabled. That's why I think it is just better to enable it in u-boot. Siva: Feel free to correct me if my understanding is not correct. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: Implement SD/MMC versioning properly
Tested-by: Jaehoon Chung jh80.ch...@samsung.com (with eMMC4.5,eMMC5.0,SD2.0,SD3.0 cards) Best Regards, Jaehoon Chung On 01/23/2015 07:12 PM, Pantelis Antoniou wrote: The SD/MMC version scheme was buggy when dealing with standard major.minor.change cases. Fix it my using something similar to linux's kernel versioning method. Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com --- common/cmd_mmc.c | 8 ++-- include/mmc.h| 56 +--- 2 files changed, 43 insertions(+), 21 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 4e28c9d..1335e3d 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -85,8 +85,12 @@ static void print_mmcinfo(struct mmc *mmc) printf(Tran Speed: %d\n, mmc-tran_speed); printf(Rd Block Len: %d\n, mmc-read_bl_len); - printf(%s version %d.%d\n, IS_SD(mmc) ? SD : MMC, - (mmc-version 8) 0xf, mmc-version 0xff); + printf(%s version %d.%d, IS_SD(mmc) ? SD : MMC, + EXTRACT_SDMMC_MAJOR_VERSION(mmc-version), + EXTRACT_SDMMC_MINOR_VERSION(mmc-version)); + if (EXTRACT_SDMMC_CHANGE_VERSION(mmc-version) != 0) + printf(.%d, EXTRACT_SDMMC_CHANGE_VERSION(mmc-version)); + printf(\n); printf(High Capacity: %s\n, mmc-high_capacity ? Yes : No); puts(Capacity: ); diff --git a/include/mmc.h b/include/mmc.h index 09101e2..0fd7517 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -14,24 +14,41 @@ #include linux/compiler.h #include part.h -#define SD_VERSION_SD0x2 -#define SD_VERSION_3 (SD_VERSION_SD | 0x300) -#define SD_VERSION_2 (SD_VERSION_SD | 0x200) -#define SD_VERSION_1_0 (SD_VERSION_SD | 0x100) -#define SD_VERSION_1_10 (SD_VERSION_SD | 0x10a) -#define MMC_VERSION_MMC 0x1 -#define MMC_VERSION_UNKNOWN (MMC_VERSION_MMC) -#define MMC_VERSION_1_2 (MMC_VERSION_MMC | 0x102) -#define MMC_VERSION_1_4 (MMC_VERSION_MMC | 0x104) -#define MMC_VERSION_2_2 (MMC_VERSION_MMC | 0x202) -#define MMC_VERSION_3(MMC_VERSION_MMC | 0x300) -#define MMC_VERSION_4(MMC_VERSION_MMC | 0x400) -#define MMC_VERSION_4_1 (MMC_VERSION_MMC | 0x401) -#define MMC_VERSION_4_2 (MMC_VERSION_MMC | 0x402) -#define MMC_VERSION_4_3 (MMC_VERSION_MMC | 0x403) -#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429) -#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405) -#define MMC_VERSION_5_0 (MMC_VERSION_MMC | 0x500) +/* SD/MMC version bits; 8 flags, 8 major, 8 minor, 8 change */ +#define SD_VERSION_SD(1U 31) +#define MMC_VERSION_MMC (1U 30) + +#define MAKE_SDMMC_VERSION(a, b, c) \ + u32)(a)) 16) | ((u32)(b) 8) | (u32)(c)) +#define MAKE_SD_VERSION(a, b, c) \ + (SD_VERSION_SD | MAKE_SDMMC_VERSION(a, b, c)) +#define MAKE_MMC_VERSION(a, b, c)\ + (MMC_VERSION_MMC | MAKE_SDMMC_VERSION(a, b, c)) + +#define EXTRACT_SDMMC_MAJOR_VERSION(x) \ + (((u32)(x) 16) 0xff) +#define EXTRACT_SDMMC_MINOR_VERSION(x) \ + (((u32)(x) 8) 0xff) +#define EXTRACT_SDMMC_CHANGE_VERSION(x) \ + ((u32)(x) 0xff) + +#define SD_VERSION_3 MAKE_SD_VERSION(3, 0, 0) +#define SD_VERSION_2 MAKE_SD_VERSION(2, 0, 0) +#define SD_VERSION_1_0 MAKE_SD_VERSION(1, 0, 0) +#define SD_VERSION_1_10 MAKE_SD_VERSION(1, 10, 0) + +#define MMC_VERSION_UNKNOWN MAKE_MMC_VERSION(0, 0, 0) +#define MMC_VERSION_1_2 MAKE_MMC_VERSION(1, 2, 0) +#define MMC_VERSION_1_4 MAKE_MMC_VERSION(1, 4, 0) +#define MMC_VERSION_2_2 MAKE_MMC_VERSION(2, 2, 0) +#define MMC_VERSION_3MAKE_MMC_VERSION(3, 0, 0) +#define MMC_VERSION_4MAKE_MMC_VERSION(4, 0, 0) +#define MMC_VERSION_4_1 MAKE_MMC_VERSION(4, 1, 0) +#define MMC_VERSION_4_2 MAKE_MMC_VERSION(4, 2, 0) +#define MMC_VERSION_4_3 MAKE_MMC_VERSION(4, 3, 0) +#define MMC_VERSION_4_41 MAKE_MMC_VERSION(4, 4, 1) +#define MMC_VERSION_4_5 MAKE_MMC_VERSION(4, 5, 0) +#define MMC_VERSION_5_0 MAKE_MMC_VERSION(5, 0, 0) #define MMC_MODE_HS (1 0) #define MMC_MODE_HS_52MHz(1 1) @@ -43,7 +60,8 @@ #define SD_DATA_4BIT 0x0004 -#define IS_SD(x) (x-version SD_VERSION_SD) +#define IS_SD(x) ((x)-version SD_VERSION_SD) +#define IS_MMC(x)((x)-version SD_VERSION_MMC) #define MMC_DATA_READ1 #define MMC_DATA_WRITE 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4 v2] vexpress64: support the Juno Development Platform
The Juno Development Platform is a physical Versatile Express
device with some differences from the emulated semihosting
models. The main difference is that the system is split in
a SoC and an FPGA where the SoC hosts the serial ports at
totally different adresses.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Remove a dangling C99 comment.
---
arch/arm/Kconfig | 4
board/armltd/vexpress64/Kconfig| 13 +
board/armltd/vexpress64/MAINTAINERS| 5 +
configs/vexpress_aemv8a_juno_defconfig | 5 +
include/configs/vexpress_aemv8a.h | 19 ++-
5 files changed, 45 insertions(+), 1 deletion(-)
create mode 100644 configs/vexpress_aemv8a_juno_defconfig
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d5399f162d57..986b4c5d81db 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -736,6 +736,10 @@ config TARGET_VEXPRESS64_BASE_FVP
select ARM64
select SEMIHOSTING
+config TARGET_VEXPRESS64_JUNO
+ bool Support Versatile Express Juno Development Platform
+ select ARM64
+
config TARGET_LS2085A_EMU
bool Support ls2085a_emu
select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index 80eaa3d3ab08..7d5e7bee8b9a 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -23,3 +23,16 @@ config SYS_CONFIG_NAME
default vexpress_aemv8a
endif
+
+if TARGET_VEXPRESS64_JUNO
+
+config SYS_BOARD
+ default vexpress64
+
+config SYS_VENDOR
+ default armltd
+
+config SYS_CONFIG_NAME
+ default vexpress_aemv8a
+
+endif
diff --git a/board/armltd/vexpress64/MAINTAINERS
b/board/armltd/vexpress64/MAINTAINERS
index 66c8dffa1634..0ba044d7ff87 100644
--- a/board/armltd/vexpress64/MAINTAINERS
+++ b/board/armltd/vexpress64/MAINTAINERS
@@ -9,3 +9,8 @@ VEXPRESS_AEMV8A_SEMI BOARD
M: Linus Walleij linus.wall...@linaro.org
S: Maintained
F: configs/vexpress_aemv8a_semi_defconfig
+
+JUNO DEVELOPMENT PLATFORM BOARD
+M: Linus Walleij linus.wall...@linaro.org
+S: Maintained
+F: configs/vexpress_aemv8a_juno_defconfig
diff --git a/configs/vexpress_aemv8a_juno_defconfig
b/configs/vexpress_aemv8a_juno_defconfig
new file mode 100644
index ..d28a4286e5af
--- /dev/null
+++ b/configs/vexpress_aemv8a_juno_defconfig
@@ -0,0 +1,5 @@
+# ARM Ltd. Juno Board Reference Design
+CONFIG_ARM=y
+CONFIG_TARGET_VEXPRESS64_JUNO=y
+CONFIG_DEFAULT_DEVICE_TREE=vexpress64
+CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/include/configs/vexpress_aemv8a.h
b/include/configs/vexpress_aemv8a.h
index 85894bedf8bd..7fb28a54ba17 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -21,7 +21,8 @@
#define CONFIG_REMAKE_ELF
-#ifndef CONFIG_TARGET_VEXPRESS64_BASE_FVP
+#if !defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) \
+!defined(CONFIG_TARGET_VEXPRESS64_JUNO)
/* Base FVP and Juno not using GICv3 yet */
#define CONFIG_GICV3
#endif
@@ -44,6 +45,9 @@
/* ATF loads u-boot here for BASE_FVP model */
#define CONFIG_SYS_TEXT_BASE 0x8800
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0)
+#elif CONFIG_TARGET_VEXPRESS64_JUNO
+#define CONFIG_SYS_TEXT_BASE 0xe000
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
#else
#define CONFIG_SYS_TEXT_BASE 0x8000
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
@@ -88,10 +92,15 @@
#define V2M_KMI0 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(6))
#define V2M_KMI1 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(7))
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
+#define V2M_UART0 0x7ff8
+#define V2M_UART1 0x7ff7
+#else /* Not Juno */
#define V2M_UART0 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(9))
#define V2M_UART1 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(10))
#define V2M_UART2 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(11))
#define V2M_UART3 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(12))
+#endif
#define V2M_WDT(V2M_PA_CS3 +
V2M_PERIPH_OFFSET(15))
@@ -122,6 +131,9 @@
#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
#define GICD_BASE (0x2f00)
#define GICC_BASE (0x2c00)
+#elif CONFIG_TARGET_VEXPRESS64_JUNO
+#define GICD_BASE (0x2C01)
+#define GICC_BASE (0x2C02f000)
#else
#define GICD_BASE (0x2C001000)
#define GICC_BASE (0x2C002000)
@@ -140,7 +152,11 @@
/* PL011 Serial Configuration */
#define CONFIG_PL011_SERIAL
+#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
+#define CONFIG_PL011_CLOCK 7273800
+#else
#define CONFIG_PL011_CLOCK 2400
+#endif
#define CONFIG_PL01x_PORTS {(void *)CONFIG_SYS_SERIAL0, \
Re: [U-Boot] [PATCH] mmc: dw_mmc: fixed the wrong bit control
Hi Could you check this patch? Best Regards, Jaehoon Chung On 01/14/2015 05:37 PM, Jaehoon Chung wrote: If mode is not DDR-mode, then it needs to clear it. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index b18c75d..76fa0b0 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -321,7 +321,7 @@ static void dwmci_set_ios(struct mmc *mmc) if (mmc-ddr_mode) regs |= DWMCI_DDR_MODE; else - regs = DWMCI_DDR_MODE; + regs = ~DWMCI_DDR_MODE; dwmci_writel(host, DWMCI_UHS_REG, regs); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: fixed the wrong bit control
Hi Jaehoon, On Jan 23, 2015, at 15:43 , Jaehoon Chung jh80.ch...@gmail.com wrote: Hi Could you check this patch? Ugh, sorry missed this; did it end up assigned at patchwork to me? The patch is obviously correct. Best Regards, Jaehoon Chung Regards — Pantelis On 01/14/2015 05:37 PM, Jaehoon Chung wrote: If mode is not DDR-mode, then it needs to clear it. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index b18c75d..76fa0b0 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -321,7 +321,7 @@ static void dwmci_set_ios(struct mmc *mmc) if (mmc-ddr_mode) regs |= DWMCI_DDR_MODE; else -regs = DWMCI_DDR_MODE; +regs = ~DWMCI_DDR_MODE; dwmci_writel(host, DWMCI_UHS_REG, regs); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: fixed the wrong bit control
Dear Pantelis. On 01/23/2015 10:44 PM, Pantelis Antoniou wrote: Hi Jaehoon, On Jan 23, 2015, at 15:43 , Jaehoon Chung jh80.ch...@gmail.com wrote: Hi Could you check this patch? Ugh, sorry missed this; did it end up assigned at patchwork to me? Updated. :) Best Regards, Jaehoon Chung The patch is obviously correct. Best Regards, Jaehoon Chung Regards — Pantelis On 01/14/2015 05:37 PM, Jaehoon Chung wrote: If mode is not DDR-mode, then it needs to clear it. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/dw_mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c index b18c75d..76fa0b0 100644 --- a/drivers/mmc/dw_mmc.c +++ b/drivers/mmc/dw_mmc.c @@ -321,7 +321,7 @@ static void dwmci_set_ios(struct mmc *mmc) if (mmc-ddr_mode) regs |= DWMCI_DDR_MODE; else - regs = DWMCI_DDR_MODE; + regs = ~DWMCI_DDR_MODE; dwmci_writel(host, DWMCI_UHS_REG, regs); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/22] x86: video: Add support for CONFIG_CONSOLE_SCROLL_LINES
On 20 January 2015 at 00:44, Anatolij Gustschin ag...@denx.de wrote: Hi Simon, On Mon, 19 Jan 2015 17:33:08 -0700 Simon Glass s...@chromium.org wrote: Hi Anatolij, On 1 January 2015 at 16:17, Simon Glass s...@chromium.org wrote: Some machines are very slow to scroll their displays. To cope with this, support the CONFIG_CONSOLE_SCROLL_LINES option. Setting this to 5 allows the display to operate at an acceptable speed by scrolling 5 lines at a time. This same option is available for LCDs so when these systems are unified this code can be unified also. Signed-off-by: Simon Glass s...@chromium.org Are you happy with this patch? If so, is it OK for me to pick it up via x86? yes, it is OK for me. Thanks. Applied to u-boot-x86. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/22] x86: config: Always scroll the display by 5 lines, for speed
On 1 January 2015 at 16:17, Simon Glass s...@chromium.org wrote: Scrolling a line at a time is very slow for reasons that I don't understand. It seems to take about 100ms to copy 4MB of RAM in the frame buffer. To cope with this, scroll 5 lines each time. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None include/configs/x86-common.h | 1 + 1 file changed, 1 insertion(+) Applied to u-boot-x86. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/19] powerpc: Introduce device tree control and driver model
+Tom Hi, On 15 December 2014 at 07:19, Simon Glass s...@chromium.org wrote: This series does a small amount of tweaking to support device tree control (CONFIG_OF_CONTROL) on PowerPC platforms. It also adds support for driver model. In both cases the main effort is to set things up correctly before calling board_init_f(). A new generic function, board_init_f_mem() is introduced. This does the various memory calculations in C code, since they are messy in assembler and every architecture should in fact be the same. A later series will adjust ARM and x86 to use this function. As an example, the Canyonlands boards are converted over to use device tree control and driver model for their serial console. It should be fairly straightforward to convert over other boards. Simon Glass (18): Introduce board_init_f_mem() to handle early memory layout powerpc: Permit device tree control of U-Boot (CONFIG_OF_CONTROL) powerpc: ppc4xx: canyonlands: config: Tidy up CONFIGs and config.mk powerpc: ppc4xx: Move CANYONLANDS/GLACIER/ARCHES to Kconfig powerpc: ppc4xx: Add ramboot config for glacier powerpc: ppc4xx: canyonlands: Move to generic board powerpc: ppc4xx: dts: Bring in canyonlands device tree files powerpc: ppc4xx: Call board_init_f_mem() for generic board powerpc: ppc4xx: Add a gpio.h header file powerpc: ppc4xx: Allow the end of u-boot.bin to be found powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards ppc: amcc: Omit unneeded ns16550 CONFIG if using driver model powerpc: Add serial driver for driver model dm: powerpc: ppc4xx: Move glacier to use driver model for serial powerpc: Add linkage.h file serial: Support an early UART for debugging serial: ns16550: Support debug UART powerpc: ppc4xx: Provide early debug UART defaults Stefan Roese (1): WIP: powerpc: ppc4xx: Somehow BSS is not cleared in RAMBOOT case Are there any comments on this series? How should I go about getting it applied? arch/Kconfig| 1 + arch/powerpc/cpu/ppc4xx/44x_spd_ddr2.c | 8 + arch/powerpc/cpu/ppc4xx/config.mk | 5 +- arch/powerpc/cpu/ppc4xx/cpu_init.c | 2 + arch/powerpc/cpu/ppc4xx/start.S | 18 +- arch/powerpc/cpu/ppc4xx/u-boot.lds | 8 +- arch/powerpc/dts/Makefile | 11 + arch/powerpc/dts/arches.dts | 339 arch/powerpc/dts/canyonlands.dts| 555 ++ arch/powerpc/dts/glacier.dts| 579 arch/powerpc/include/asm/arch-ppc4xx/gpio.h | 7 + arch/powerpc/include/asm/linkage.h | 7 + arch/powerpc/include/asm/ppc460ex_gt.h | 2 + arch/powerpc/lib/board.c| 3 + board/amcc/canyonlands/Kconfig | 35 ++ board/amcc/canyonlands/MAINTAINERS | 1 + board/amcc/canyonlands/config.mk| 2 - board/amcc/canyonlands/u-boot-ram.lds | 85 common/board_f.c| 18 + common/board_r.c| 8 +- configs/arches_defconfig| 5 +- configs/canyonlands_defconfig | 5 +- configs/glacier_defconfig | 5 +- configs/glacier_ramboot_defconfig | 8 + drivers/serial/Kconfig | 59 +++ drivers/serial/Makefile | 1 + drivers/serial/ns16550.c| 42 +- drivers/serial/serial_ppc.c | 40 ++ include/configs/amcc-common.h | 2 + include/configs/canyonlands.h | 38 +- include/debug_uart.h| 139 +++ 31 files changed, 2006 insertions(+), 32 deletions(-) create mode 100644 arch/powerpc/dts/Makefile create mode 100644 arch/powerpc/dts/arches.dts create mode 100644 arch/powerpc/dts/canyonlands.dts create mode 100644 arch/powerpc/dts/glacier.dts create mode 100644 arch/powerpc/include/asm/arch-ppc4xx/gpio.h create mode 100644 arch/powerpc/include/asm/linkage.h create mode 100644 board/amcc/canyonlands/u-boot-ram.lds create mode 100644 configs/glacier_ramboot_defconfig create mode 100644 drivers/serial/serial_ppc.c create mode 100644 include/debug_uart.h -- 2.2.0.rc0.207.ga3a616c Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 2/3] arm: mxs: Enable booting of mx28 without battery
Section 4.1.2 of Freescale Application Note AN4199 describes the configuration required to operate the mx28 from a 5V source without a battery. This patch implements the changes to the Freescale bootlets which allow this configuration to properly boot the mx28 processor Signed-off-by: Graeme Russ gr...@tss-engineering.com Signed-off-by: Damien Gotfroi dgotf...@greenwatch.be --- Changes in v2 - Implemented Damien Gotfroi's simplified version --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index 7fb734e..0634c81 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -14,6 +14,12 @@ #include mxs_init.h +#ifdef CONFIG_SYS_MXS_VDD5V_ONLY +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV +#else +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV | \ + POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL +#endif /** * mxs_power_clock2xtal() - Switch CPU core clock source to 24MHz XTAL * @@ -303,8 +309,7 @@ static void mxs_power_init_4p2_params(void) clrsetbits_le32(power_regs-hw_power_dcdc4p2, POWER_DCDC4P2_DROPOUT_CTRL_MASK, - POWER_DCDC4P2_DROPOUT_CTRL_100MV | - POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL); + DCDC4P2_DROPOUT_CONFIG); clrsetbits_le32(power_regs-hw_power_5vctrl, POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK, -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 1/3] arm: mxs: Add debug outputs and comments to mxs SPL source files
It is difficult to track down fail to boot issues in the mxs SPL.
Implement the following to make it easier:
- Add debug outputs to allow tracing of SPL progress in order to track
where failure to boot occurs. DEUBUG and CONFIG_SPL_SERIAL_SUPPORT must
be defined to enable debug output in SPL
- Add TODO comments where it is not clear if the code is doing what it
is meant to be doing, even tough the board boots properly (these comments
refer to existing code, not to any code added by this patch)
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Add missing newlines
- Add commit message
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 1 +
arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++-
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 100 +++-
4 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index d29b9aa..2a5f817 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -147,6 +147,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t
*resptr,
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mxs_spl_console_init();
+ debug(SPL: Serial Console Initialised\n);
mxs_power_init();
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
index cdfcddd..96bd32f 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
@@ -18,6 +18,8 @@ void mxs_lradc_init(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Initialisating LRADC\n);
+
writel(LRADC_CTRL0_SFTRST, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_CLKGATE, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_ONCHIP_GROUNDREF, regs-hw_lradc_ctrl0_clr);
@@ -37,9 +39,15 @@ void mxs_lradc_enable_batt_measurement(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Enabling LRADC battery measurement\n);
+
/* Check if the channel is present at all. */
- if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT))
+ if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT)) {
+ debug(SPL: LRADC channel 7 is not present - aborting\n);
return;
+ }
+
+ debug(SPL: LRADC channel 7 is present - configuring\n);
writel(LRADC_CTRL1_LRADC7_IRQ_EN, regs-hw_lradc_ctrl1_clr);
writel(LRADC_CTRL1_LRADC7_IRQ, regs-hw_lradc_ctrl1_clr);
@@ -65,6 +73,7 @@ void mxs_lradc_enable_batt_measurement(void)
100, regs-hw_lradc_delay3);
writel(0x, regs-hw_lradc_ch7_clr);
-
writel(LRADC_DELAY_KICK, regs-hw_lradc_delay3_set);
+
+ debug(SPL: LRADC channel 7 configuration complete\n);
}
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 97ef67d..a744e5d 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -92,6 +92,7 @@ static uint32_t dram_vals[] = {
__weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
+ debug(SPL: Using default SDRAM parameters\n);
}
#ifdef CONFIG_MX28
@@ -99,8 +100,10 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx28 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
}
@@ -109,6 +112,7 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx23 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
/*
@@ -120,6 +124,7 @@ static void initialize_dram_values(void)
* HW_DRAM_CTL8 is setup as the last element.
* So skip the initialization of these HW_DRAM_CTL registers.
*/
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
if (i == 8 || i == 27 || i == 28 || i == 35)
continue;
@@ -146,6 +151,8 @@ static void mxs_mem_init_clock(void)
const unsigned char divider = 21;
#endif
+ debug(SPL: Initialising FRAC0\n);
+
/* Gate EMI clock */
writeb(CLKCTRL_FRAC_CLKGATE,
clkctrl_regs-hw_clkctrl_frac0_set[CLKCTRL_FRAC0_EMI]);
@@ -170,6 +177,7 @@ static void mxs_mem_init_clock(void)
clkctrl_regs-hw_clkctrl_clkseq_clr);
early_delay(1);
+ debug(SPL: FRAC0 Initialised\n);
}
static void mxs_mem_setup_cpu_and_hbus(void)
@@ -177,6 +185,8 @@ static void mxs_mem_setup_cpu_and_hbus(void)
struct
[U-Boot] [v2 PATCH 0/3] Add support for booting mx28 boards without a battery
This series adds support for booting mx28 based boards which do not include a battery as per Freescale application note AN4199 Patch 1 adds SPL debug output to help track down where early init of the power block and SDRAM fails (define DEBUG and CONFIG_SPL_SERIAL_SUPPORT in order to enable) Patch 2 (which implements booting without a battery) is based on a patch submitted to the Freescale community forums by Damien Gotfroi (define CONFIG_SYS_MXS_VDD5V_ONLY to enable) Patch 3 adds a useful halt upon completion of SPL in the case that the board is booted in JTAG mode. If SPL debug is enabled, 'Waiting for JTAG user' will be printed to the console when SPL has completed Changes in v2 - Dropped patch which adds Reachtech G2C1 board in order to allow the 'no battery' functionality to be mainlined as soon as possible - Removed the patch which moved the PLL power up from spl_power_init.c to spl_mem_init.c - This patch will be considered in future rework of the power block and SDRAM initialisation code Graeme Russ (3): arm: mxs: Add debug outputs and comments to mxs SPL source files arm: mxs: Enable booting of mx28 without battery arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 7 ++ arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 + arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 109 ++-- arch/arm/include/asm/arch-mxs/sys_proto.h | 17 + 5 files changed, 157 insertions(+), 7 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/12] Add support for caching Memory Reference Code data
Hi Simon, On Sat, Jan 24, 2015 at 5:17 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 19 January 2015 at 22:16, Simon Glass s...@chromium.org wrote: Since the memory reference code is so slow on x86, add a feature to bypass this, storing the previous parameters in SPI flash. This saves around 500ms on each boot. Also enable a SPI flash environment. Changes in v3: - Add new patch to move checksum to its own file in net/ - Adjust net/ code to use the new checksum functions - Use checksum code that is now in net/checksum.c - Adjust functions to remain compatible with other RTC drivers - Drop accidental creation of link.dts due to bad rebase - Use checksum code from net/checksum.c - Add misc_init_r() call for link now that it is shared with chromebook_link I'd like to get this applied. Do you have any comments on the new checksum approach? I did not perform a thorough review to the new checksum thus did not offer a 'Reviewed-by', but generally it looks good to me. Please go ahead. I will need to get an Ack from Joe before I apply the net/ patch (which changes over to the new function). But the rest can come through the x86 tree. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: Test mtrr support flag before accessing mtrr msr
On 22 January 2015 at 08:06, Simon Glass s...@chromium.org wrote: On 21 January 2015 at 20:29, Bin Meng bmeng...@gmail.com wrote: On some x86 processors (like Intel Quark) the MTRR registers are not supported. This is reflected by the CPUID (EAX 01H) result EDX[12]. Accessing the MTRR registers on such processors will cause #GP so we must test the support flag before accessing MTRR MSRs. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Return -ENOSYS in mtrr_commit() and mtrr_add_request() when MTRR MSR is not implemented in the processor - Add return value description of mtrr_commit() and mtrr_add_request() - Ignore -ENOSYS in init_cache_f_r() in arch/x86/lib/init_helpers.c arch/x86/cpu/mtrr.c | 12 arch/x86/include/asm/mtrr.h | 5 - arch/x86/lib/init_helpers.c | 4 +++- 3 files changed, 19 insertions(+), 2 deletions(-) Acked-by: Simon Glass s...@chromium.org Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support
On 15-01-21 11:05 PM, Marek Vasut wrote: On Tuesday, January 20, 2015 at 11:42:08 PM, Steve Rae wrote: Implement the UDC support for the USB OTG interface. Signed-off-by: Steve Rae s...@broadcom.com --- General question -- this bcm controller you're adding here isn't by any chance a DWC2 controller, or is it ? There's already a driver for DWC2 in drivers/usb/gadget/s3c_udc_otg.c . This driver should really be properly renamed though ;-/ If this is not DWC2, do you know what controller this is please ? yes -- it is a DWC2 So, I have had a quick look at the s3c_udc_otg*.c code First observation is that there is a completely different philosophy in the implementation. For example, the the interrupt handler routine(s), Broadcom is using #defines (sysmap.h which BTW are autogenerated by our Device Team) whereas S3C is using a s3c_usbotg_reg structure for the 'address' and #defines for the 'data/masks'. I'm not suggesting that one is better than the other, they are just different. So, how do we proceed? - is the ultimate goal to get to a proper gadget driver for DWC2? (I don't really know enough about this yet, so I apologize for these questions) - is the S3C code a proper 'gadget' driver and/or is it a better starting point to get to a gadget driver? - I don't have enough time right now to really investigate the existing S3C and implement it on our board(s); they are significantly different and it looks like it will take a lot of effort - is there someone (Denx or community) that could assist me? - Could we continue to review this patchset and accept it; then establish a team to provide a DWC2 gadget that could be used going forward? Note: this patchset is relatively small: 6938ae5 usb: fastboot: implement fastboot M drivers/usb/gadget/Makefile A drivers/usb/gadget/bcm_usb_gadget.c M include/configs/bcm28155_ap.h b85657d usb: update 'sysmap.h' M arch/arm/include/asm/arch-bcm281xx/sysmap.h d590d41 usb: add 'bcm_udc_otg' support A drivers/usb/gadget/bcm_udc_otg.c A drivers/usb/gadget/bcm_udc_otg.h 5f1d857 usb: gadget: fastboot: add CONFIG_FASTBOOT_NO_GADGET support M drivers/usb/gadget/f_fastboot.c Thanks in advance, Steve [...] [... snip ...] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: Add missing DECLARE_GLOBAL_DATA_PTR for mtrr.c
On 21 January 2015 at 20:29, Bin Meng bmeng...@gmail.com wrote: arch/x86/cpu/mtrr.c has access to the U-Boot global data thus DECLARE_GLOBAL_DATA_PTR is needed. Signed-off-by: Bin Meng bmeng...@gmail.com Acked-by: Simon Glass s...@chromium.org --- Changes in v2: None Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: Fix various code format issues in start16.S
On 21 January 2015 at 09:03, Simon Glass s...@chromium.org wrote: On 19 January 2015 at 20:25, Bin Meng bmeng...@gmail.com wrote: Various minor code format issues are fixed in start16.S: - U-boot - U-Boot - 32bit - 32-bit - Use TAB instead of SPACE to indent - Move the indention location of the GDT comment block Signed-off-by: Bin Meng bmeng...@gmail.com --- arch/x86/cpu/start16.S | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) Acked-by: Simon Glass s...@chromium.org Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: Save mtrr support flag in global data
On 22 January 2015 at 08:05, Simon Glass s...@chromium.org wrote: On 21 January 2015 at 20:29, Bin Meng bmeng...@gmail.com wrote: CPUID (EAX 01H) returns MTRR support flag in EDX bit 12. Probe this flag in x86_cpu_init_f() and save it in global data. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - Use space instead of tab to indent in arch_global_data arch/x86/cpu/cpu.c | 7 +++ arch/x86/include/asm/global_data.h | 13 +++-- 2 files changed, 14 insertions(+), 6 deletions(-) Acked-by: Simon Glass s...@chromium.org (for reference, normally we would do this sort of clean-up in a separate patch) Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
On 22 January 2015 at 09:37, Simon Glass s...@chromium.org wrote: Hi, On 21 January 2015 at 09:07, Bin Meng bmeng...@gmail.com wrote: Hi Thierry, On Wed, Jan 21, 2015 at 5:50 PM, Thierry Reding tred...@nvidia.com wrote: On Tue, Jan 20, 2015 at 06:06:53PM +0100, Sjoerd Simons wrote: commit a62e84d7b1824a202dd incorrectly changed the tegra pci code to the new fdtdec pci helpers. To get the device index of the root port, the reg property should be parsed from the dtb (as was previously the case). With this patch i can successfully network boot my jetson tk1 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- drivers/pci/pci_tegra.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) Given the discussion here and in http://patchwork.ozlabs.org/patch/430815/ I agree with Bin that this is a more appropriate fix. The documentation of the fdtdec_get_pci_bdf() function could be improved, in my opinion, to mention how the compatible property is involved. That should clarify that any value in reg can be overridden by looking up the allocated bus number after enumeration. I can prepare a patch to improve the doc. So this patch: Tested-by: Thierry Reding tred...@nvidia.com Acked-by: Thierry Reding tred...@nvidia.com Since this patch seems OK, I'd like to pick it up for the x86 tree (where the breakage happens). Any objections? Applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 3/3] arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode
When booting in JTAG mode, there is no way to use soft break-points, and
no way of knowing when SPL has finished executing (so the user can issue
a 'halt' command to load u-boot.bin for example)
Add a debug output and simple loop to stop execution at the completion of
the SPL initialisation as a pseudo break-point when booting in JTAG mode
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Added and used boot mode #defines
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 ++
arch/arm/include/asm/arch-mxs/sys_proto.h | 17 +
2 files changed, 23 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 2a5f817..d1457e0 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -157,6 +157,12 @@ void mxs_common_spl_init(const uint32_t arg, const
uint32_t *resptr,
data-boot_mode_idx = bootmode;
mxs_power_wait_pswitch();
+
+
+ if (mxs_boot_modes[data-boot_mode_idx].boot_pads == MXS_BM_JTAG) {
+ debug(SPL: Waiting for JTAG user\n);
+ asm volatile (x: b x);
+ }
}
/* Support aparatus */
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 062f3de..4678723 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -74,6 +74,23 @@ static const struct mxs_pair mxs_boot_modes[] = {
#endif
};
+#define MXS_BM_USB 0x00
+#define MXS_BM_I2C_MASTER_3V3 0x01
+#define MXS_BM_I2C_MASTER_1V8 0x11
+#define MXS_BM_SPI2_MASTER_3V3_NOR 0x02
+#define MXS_BM_SPI2_MASTER_1V8_NOR 0x12
+#define MXS_BM_SPI3_MASTER_3V3_NOR 0x03
+#define MXS_BM_SPI3_MASTER_1V8_NOR 0x13
+#define MXS_BM_NAND_3V30x04
+#define MXS_BM_NAND_1V80x14
+#define MXS_BM_JTAG0x06
+#define MXS_BM_SPI3_MASTER_3V3_EEPROM 0x08
+#define MXS_BM_SPI3_MASTER_1V8_EEPROM 0x18
+#define MXS_BM_SDMMC0_3V3 0x09
+#define MXS_BM_SDMMC0_1V8 0x19
+#define MXS_BM_SDMMC1_3V3 0x0a
+#define MXS_BM_SDMMC1_1V8 0x1a
+
struct mxs_spl_data {
uint8_t boot_mode_idx;
uint32_tmem_dram_size;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in mmcinfo output
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Thursday, January 22, 2015 8:59 PM
To: Pantelis Antoniou
Cc: Diego Santa Cruz; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in
mmcinfo output
On 01/22/2015 12:45 PM, Pantelis Antoniou wrote:
Hi Stephen,
On Jan 22, 2015, at 20:42 , Stephen Warren swar...@wwwdotorg.org wrote:
On 12/23/2014 02:50 AM, Diego Santa Cruz wrote:
There is currently no command that will provide an overview of the
hardware
partitions present on an eMMC device, one has to switch to every partition
via mmc dev and run mmcinfo for each to get the partition's capacity.
This commit adds a few lines of output to mmcinfo with the sizes of the
present partitions, like this:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
User Capacity: 13.8 GiB
Boot Capacity: 16 MiB
RPMB Capacity: 128 KiB
GP1 Capacity: 64 MiB
GP2 Capacity: 64 MiB
I have an MMC device which has at least boot HW partitions, yet with the
very latest code in u-boot.git, I don't see the additional lines mentioned
above. My HW partitions are still working fine, since I can select a boot
partition and mmcinfo shows the correct Capacity for it:
Any ideas why?
Tegra124 (Jetson TK1) # mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 14.7 GiB Sounds right for a 16GB device with partitions
Bus Width: 8-bit
Erase Group Size: 512 KiB
No HW partition information is printed here
Tegra124 (Jetson TK1) # mmc dev 0 1 select boot0 HW partition
switch to partitions #1, OK
mmc0(part 1) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 4 MiB boot0 partition size correctly reported
Bus Width: 8-bit
Erase Group Size: 512 KiB
That is really weird; are you sure you got the latest version of u-boot
containing those patches?
if (!IS_SD(mmc) mmc-version = MMC_VERSION_4_41) {
Ah, my device is MMC 4.5, and the version numbers aren't monotonic:
#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405)
Should that be 0x450, or do we need some more complex version comparison
logic?
FWIW, if I hack the test you quoted to always pass, then the data that's
printed looks plausible. At the very least, the boot capacity agrees
with Linux.
Thanks for spotting this, looking at all the defines in mmc.h they are
#define MMC_VERSION_UNKNOWN (MMC_VERSION_MMC)
#define MMC_VERSION_1_2 (MMC_VERSION_MMC | 0x102)
#define MMC_VERSION_1_4 (MMC_VERSION_MMC | 0x104)
#define MMC_VERSION_2_2 (MMC_VERSION_MMC | 0x202)
#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x300)
#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x400)
#define MMC_VERSION_4_1 (MMC_VERSION_MMC | 0x401)
#define MMC_VERSION_4_2 (MMC_VERSION_MMC | 0x402)
#define MMC_VERSION_4_3 (MMC_VERSION_MMC | 0x403)
#define MMC_VERSION_4_41(MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405)
#define MMC_VERSION_5_0 (MMC_VERSION_MMC | 0x500)
I do not get it why MMC_VERSION_4_41 is 0x429, it should be 0x404 to follow the
sequence.
Wouldn't it be sane to change it to be
#define MMC_VERSION_4_41(MMC_VERSION_MMC | 0x404)
I checked mmc_startup() and these defines are not matching bitfields in CSD nor
EXT_CSD, so I think it should be safe to change them.
Best,
Diego
--
Diego Santa Cruz, PhD
Technology Architect
T +41 21 341 15 50
diego.santac...@spinetix.com
spinetix.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in mmcinfo output
Hi Diego,
On Jan 23, 2015, at 10:30 , Diego Santa Cruz diego.santac...@spinetix.com
wrote:
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Thursday, January 22, 2015 8:59 PM
To: Pantelis Antoniou
Cc: Diego Santa Cruz; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in
mmcinfo output
On 01/22/2015 12:45 PM, Pantelis Antoniou wrote:
Hi Stephen,
On Jan 22, 2015, at 20:42 , Stephen Warren swar...@wwwdotorg.org wrote:
On 12/23/2014 02:50 AM, Diego Santa Cruz wrote:
There is currently no command that will provide an overview of the
hardware
partitions present on an eMMC device, one has to switch to every partition
via mmc dev and run mmcinfo for each to get the partition's capacity.
This commit adds a few lines of output to mmcinfo with the sizes of the
present partitions, like this:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
User Capacity: 13.8 GiB
Boot Capacity: 16 MiB
RPMB Capacity: 128 KiB
GP1 Capacity: 64 MiB
GP2 Capacity: 64 MiB
I have an MMC device which has at least boot HW partitions, yet with the
very latest code in u-boot.git, I don't see the additional lines mentioned
above. My HW partitions are still working fine, since I can select a boot
partition and mmcinfo shows the correct Capacity for it:
Any ideas why?
Tegra124 (Jetson TK1) # mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 14.7 GiB Sounds right for a 16GB device with partitions
Bus Width: 8-bit
Erase Group Size: 512 KiB
No HW partition information is printed here
Tegra124 (Jetson TK1) # mmc dev 0 1 select boot0 HW partition
switch to partitions #1, OK
mmc0(part 1) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 4 MiB boot0 partition size correctly reported
Bus Width: 8-bit
Erase Group Size: 512 KiB
That is really weird; are you sure you got the latest version of u-boot
containing those patches?
if (!IS_SD(mmc) mmc-version = MMC_VERSION_4_41) {
Ah, my device is MMC 4.5, and the version numbers aren't monotonic:
#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405)
Should that be 0x450, or do we need some more complex version comparison
logic?
FWIW, if I hack the test you quoted to always pass, then the data that's
printed looks plausible. At the very least, the boot capacity agrees
with Linux.
Thanks for spotting this, looking at all the defines in mmc.h they are
#define MMC_VERSION_UNKNOWN (MMC_VERSION_MMC)
#define MMC_VERSION_1_2 (MMC_VERSION_MMC | 0x102)
#define MMC_VERSION_1_4 (MMC_VERSION_MMC | 0x104)
#define MMC_VERSION_2_2 (MMC_VERSION_MMC | 0x202)
#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x300)
#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x400)
#define MMC_VERSION_4_1 (MMC_VERSION_MMC | 0x401)
#define MMC_VERSION_4_2 (MMC_VERSION_MMC | 0x402)
#define MMC_VERSION_4_3 (MMC_VERSION_MMC | 0x403)
#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405)
#define MMC_VERSION_5_0 (MMC_VERSION_MMC | 0x500)
I do not get it why MMC_VERSION_4_41 is 0x429, it should be 0x404 to follow
the sequence.
Wouldn't it be sane to change it to be
#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x404)
I checked mmc_startup() and these defines are not matching bitfields in CSD
nor EXT_CSD, so I think it should be safe to change them.
Changing them is one thing; we have to change the version printout too.
Best,
Diego
Regards
— Pantelis
--
Diego Santa Cruz, PhD
Technology Architect
T +41 21 341 15 50
diego.santac...@spinetix.com
spinetix.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in mmcinfo output
-Original Message-
From: Pantelis Antoniou [mailto:pa...@antoniou-consulting.com]
Sent: Friday, January 23, 2015 9:35 AM
To: Diego Santa Cruz
Cc: Stephen Warren; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes in
mmcinfo output
Hi Diego,
On Jan 23, 2015, at 10:30 , Diego Santa Cruz diego.santac...@spinetix.com
wrote:
-Original Message-
From: Stephen Warren [mailto:swar...@wwwdotorg.org]
Sent: Thursday, January 22, 2015 8:59 PM
To: Pantelis Antoniou
Cc: Diego Santa Cruz; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v4 01/18] mmc: show hardware partition sizes
in
mmcinfo output
On 01/22/2015 12:45 PM, Pantelis Antoniou wrote:
Hi Stephen,
On Jan 22, 2015, at 20:42 , Stephen Warren swar...@wwwdotorg.org wrote:
On 12/23/2014 02:50 AM, Diego Santa Cruz wrote:
There is currently no command that will provide an overview of the
hardware
partitions present on an eMMC device, one has to switch to every
partition
via mmc dev and run mmcinfo for each to get the partition's capacity.
This commit adds a few lines of output to mmcinfo with the sizes of the
present partitions, like this:
Device: OMAP SD/MMC
Manufacturer ID: fe
OEM: 14e
Name: MMC16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.41
High Capacity: Yes
Capacity: 13.8 GiB
Bus Width: 4-bit
User Capacity: 13.8 GiB
Boot Capacity: 16 MiB
RPMB Capacity: 128 KiB
GP1 Capacity: 64 MiB
GP2 Capacity: 64 MiB
I have an MMC device which has at least boot HW partitions, yet with the
very latest code in u-boot.git, I don't see the additional lines mentioned
above. My HW partitions are still working fine, since I can select a boot
partition and mmcinfo shows the correct Capacity for it:
Any ideas why?
Tegra124 (Jetson TK1) # mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 14.7 GiB Sounds right for a 16GB device with partitions
Bus Width: 8-bit
Erase Group Size: 512 KiB
No HW partition information is printed here
Tegra124 (Jetson TK1) # mmc dev 0 1 select boot0 HW partition
switch to partitions #1, OK
mmc0(part 1) is current device
Tegra124 (Jetson TK1) # mmcinfo
Device: Tegra SD/MMC
Manufacturer ID: 45
OEM: 100
Name: SEM16
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.5
High Capacity: Yes
Capacity: 4 MiB boot0 partition size correctly reported
Bus Width: 8-bit
Erase Group Size: 512 KiB
That is really weird; are you sure you got the latest version of u-boot
containing those patches?
if (!IS_SD(mmc) mmc-version = MMC_VERSION_4_41) {
Ah, my device is MMC 4.5, and the version numbers aren't monotonic:
#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5(MMC_VERSION_MMC | 0x405)
Should that be 0x450, or do we need some more complex version comparison
logic?
FWIW, if I hack the test you quoted to always pass, then the data that's
printed looks plausible. At the very least, the boot capacity agrees
with Linux.
Thanks for spotting this, looking at all the defines in mmc.h they are
#define MMC_VERSION_UNKNOWN (MMC_VERSION_MMC)
#define MMC_VERSION_1_2 (MMC_VERSION_MMC | 0x102)
#define MMC_VERSION_1_4 (MMC_VERSION_MMC | 0x104)
#define MMC_VERSION_2_2 (MMC_VERSION_MMC | 0x202)
#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x300)
#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x400)
#define MMC_VERSION_4_1 (MMC_VERSION_MMC | 0x401)
#define MMC_VERSION_4_2 (MMC_VERSION_MMC | 0x402)
#define MMC_VERSION_4_3 (MMC_VERSION_MMC | 0x403)
#define MMC_VERSION_4_41(MMC_VERSION_MMC | 0x429)
#define MMC_VERSION_4_5 (MMC_VERSION_MMC | 0x405)
#define MMC_VERSION_5_0 (MMC_VERSION_MMC | 0x500)
I do not get it why MMC_VERSION_4_41 is 0x429, it should be 0x404 to follow
the sequence.
Wouldn't it be sane to change it to be
#define MMC_VERSION_4_41(MMC_VERSION_MMC | 0x404)
I checked mmc_startup() and these defines are not matching bitfields in CSD
nor EXT_CSD, so I think it should be safe to change them.
Changing them is one thing; we have to change the version printout too.
Of course, dumb me..., forget my idea. So changing the others to 0x410, 0x420,
... 0x450, etc., as you propose, would keep version comparisons as they are and
the version printout would be easier to handle.
Thanks for volunteering to fix it.
Regards,
Diego
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S
Hi, On 22-01-15 22:03, Tom Rini wrote: On Thu, Jan 22, 2015 at 08:10:06PM +0100, Hans de Goede wrote: Hi, On 22-01-15 17:20, Tom Rini wrote: On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote: On some SoCs / ARMv7 CPU cores we need to do some setup before enabling the icache, etc. Add a soc_init hook with a weak default which just calls cpu_init_cp15. This way different implementations can be provided to do some extra work before or after cpu_init_cp15, or completely replacing cpu_init_cp15. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/cpu/armv7/start.S | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index fdc05b9..9882b20 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -64,7 +64,7 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT - bl cpu_init_cp15 + bl soc_init bl cpu_init_crit #endif I like the direction here. And I want to make sure I get the sunxi direction right here too (as I agree with the need / desire for boot0 + U-Boot to be a valid combination). I think we can take this a step farther. cpu_init_crit (on armv7) is basically a call to s_init(). For am33xx (and I bet but need to do and test omap3+) we can, with Simon's patch to let us move stack to DDR a tiny bit later, in the SPL case make s_init empty, which just leaves us with (with your patch) soc_init. Is there some way we can put all of this together in a function? You mean essentially call s_init here and have s_init call cpu_init_cp15 I guess we could do that, but it would require auditing all existing armv7 users of s_init. This may require me to rethink how / when I do timer gpio init etc. for u-boot.bin on sunxi, but that should not be a (big) problem. Basically. From my first pass audit of s_init, it's either empty (Kona), sunxi, or omap/etc so I get to deal with it. And the default soc_init would just be the call to cpu_init_cp15 as you have it and we drop the lowlevel_init hurdles. Ok, so what you're suggesting is a patch which: 1) Changes: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 bl cpu_init_crit #endif Into: #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl lowlevel_init #endif Which will setup the stack and then call the s_init C function 2) Adds a weak default s_init which calls cpu_init_cp15 3) Patch all existing s_init functions to call cpu_init_cp15 before doing anything else. And then in follow up patches we can: 4) Drop cpu_init_crit 5) Cleanup some s_init functions (this will be left to the individual SoC maintainers) I think that is a good idea, Albert what do you think about this ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/26] dm: core: Allocate platform data when binding a device
Hi Simon, On Mon, 19 Jan 2015 20:12:35 -0700 Simon Glass s...@chromium.org wrote: When using allocated platform data, allocate it when we bind the device. This makes it possible to fill in this information before the device is probed. This fits with the platform data model (when not using device tree), since platform data exists at bind-time. Signed-off-by: Simon Glass s...@chromium.org Looks like you have changed your mind to allocate platdata in device_bind() rather than device_probe(). Could you explain why you think this should be done? I might have missed something, but your motivation is still unclear to me. I thought one reason is consistency with platform data. But drv-ofdata_to_platdata() is still called from device_probe(), i.e. it is just like zero-filled memory is allocated at the binding stage. Filling it with real device properties is delayed until the device is probed. What is the difference from the before and what does it buy us? Its disadvantage are clear: - We need more malloc memory for devices that may or may not be used. - The boot sequence becomes slower. I want good reasons to compensate these disadvantages. BTW, you missed to fix the comment in device_probe_child(): /* Allocate private data and platdata if requested */ Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On Fri, Jan 23, 2015 at 10:02:04AM +0100, Michal Simek wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. And we have a _really_ good reason for using FPU instructions, yes? -- 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] pci: tegra: Fix port information parsing
Hi Thierry,
On Fri, Jan 23, 2015 at 6:19 PM, Thierry Reding tred...@nvidia.com wrote:
On Thu, Jan 22, 2015 at 12:04:06AM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 5:40 PM, Thierry Reding tred...@nvidia.com wrote:
On Wed, Jan 21, 2015 at 05:15:42PM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 4:24 PM, Thierry Reding tred...@nvidia.com
wrote:
On Wed, Jan 21, 2015 at 10:37:07AM +0800, Bin Meng wrote:
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code
to the
new fdtdec pci helpers. To get the device index of the root port,
the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel this
patch is doing correctly.
It's in the U-Boot tree, look at arch/arm/dts/tegra124.dtsi for an
example.
Got it. I see:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x0100 0
0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
nvidia,num-lanes = 2;
};
So I would read this 'reg = 0x000800 0 0 0 0' as this is a
downstream port with device number 1 of the root complex.
Correct. Note that these root ports don't appear on the bus using the
regular configuration space accesses, so the definition here is
arbitrary, though in a way to mirror what PCI would typically look like
(host bridge 00:00.0, root ports 00:01.0..00:0N.0).
The Linux kernel driver (and the U-Boot driver for that matter) rely on
this numbering, though, for some aspects of configuration of the root
ports.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
I do like how 0 actually transports the meaning of don't care here.
The reg property encodes only the BDF, whereas the configuration space
region for the root ports is encoded in the assigned-addresses property.
Looking at the fdtdec_get_pci_addr() implementation I notice that it
uses the type parameter to match on the type of region. Devices can have
more than one region of the same type. How is that supposed to work with
this function. Perhaps it's nothing we care about for the fdtdec API
since we don't access those regions anyway from FDT code?
Ah, yes, some devices may have multiple regions of the same type.
Perhaps we need another parameter bar_index for this api? So far this
API is not used by FDT codes. It is used by the ns16550 driver where
pci ns16550 normally has two bars, one memory and one i/o.
Why not use the BARs directly in the ns16550 driver rather than looking
it up from the device tree? I assume the device will have to be
enumerated anyway to make it work properly, at which point addresses
should've been assigned to the memory and I/O BARs.
It is because we cannot predict which bar to look up if we hardcod
that in the generic ns16550 driver. Normally PCI ns16550 registers can
be memory-mapped or I/O mapped and it could use any of the 6 BARs.
What's more, on x86 for memory-mapped and I/O mapped they use
different instructions to access the registers, and there is one build
time macro (CONFIG_SYS_NS16550_PORT_MAPPED) to control this.
That sounds like pretty arbitrary restrictions. For one you can detect
invalid BARs, so selecting the right one should be easy. Also it seems
like adding support for both I/O and memory BARs
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
Hi Stephen,
On Sat, Jan 24, 2015 at 12:49 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/23/2015 03:19 AM, Thierry Reding wrote:
On Thu, Jan 22, 2015 at 12:04:06AM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 5:40 PM, Thierry Reding tred...@nvidia.com
wrote:
On Wed, Jan 21, 2015 at 05:15:42PM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 4:24 PM, Thierry Reding tred...@nvidia.com
wrote:
On Wed, Jan 21, 2015 at 10:37:07AM +0800, Bin Meng wrote:
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org
wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code
to the
new fdtdec pci helpers. To get the device index of the root port,
the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel
this
patch is doing correctly.
It's in the U-Boot tree, look at arch/arm/dts/tegra124.dtsi for an
example.
Got it. I see:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x0100
0 0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
nvidia,num-lanes = 2;
};
So I would read this 'reg = 0x000800 0 0 0 0' as this is a
downstream port with device number 1 of the root complex.
Correct. Note that these root ports don't appear on the bus using the
regular configuration space accesses, so the definition here is
arbitrary, though in a way to mirror what PCI would typically look like
(host bridge 00:00.0, root ports 00:01.0..00:0N.0).
The Linux kernel driver (and the U-Boot driver for that matter) rely on
this numbering, though, for some aspects of configuration of the root
ports.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
I do like how 0 actually transports the meaning of don't care here.
The reg property encodes only the BDF, whereas the configuration space
region for the root ports is encoded in the assigned-addresses
property.
Looking at the fdtdec_get_pci_addr() implementation I notice that it
uses the type parameter to match on the type of region. Devices can
have
more than one region of the same type. How is that supposed to work
with
this function. Perhaps it's nothing we care about for the fdtdec API
since we don't access those regions anyway from FDT code?
Ah, yes, some devices may have multiple regions of the same type.
Perhaps we need another parameter bar_index for this api? So far this
API is not used by FDT codes. It is used by the ns16550 driver where
pci ns16550 normally has two bars, one memory and one i/o.
Why not use the BARs directly in the ns16550 driver rather than looking
it up from the device tree? I assume the device will have to be
enumerated anyway to make it work properly, at which point addresses
should've been assigned to the memory and I/O BARs.
It is because we cannot predict which bar to look up if we hardcod
that in the generic ns16550 driver. Normally PCI ns16550 registers can
be memory-mapped or I/O mapped and it could use any of the 6 BARs.
What's more, on x86 for memory-mapped and I/O mapped they use
different instructions to access the registers, and there is one build
time macro (CONFIG_SYS_NS16550_PORT_MAPPED) to control this.
Surely the vendor/device ID (or perhaps subvendor/device ID) directly imply
which BAR is used for this purpose? It's really part of the specification of
the interface to HW, so a particular bit of HW shouldn't be randomly
deciding to use a different BAR register each power-on.
Yes, the vendor/device ID should be
Re: [U-Boot] [PATCH v2 06/26] dm: core: Allocate platform data when binding a device
Hi Simon, 2015-01-24 0:50 GMT+09:00 Simon Glass s...@chromium.org: I tried to document the reasoning in the patches, but let me try to expand a bit. Hopefully this can provoke further comments / improvements. The main motivation for me was that buses want to set up the platform data for their children before they are probed. In fact some children may never be probed. For example a SPI bus wants to know the chip select for each of its children. At present we have to hunt around in the device tree to figure out which child is the right one, so we can probe it. Worse, the children's drivers (e.g. cros_ec on a SPI bus) have to be involved in setting themselves up. The device_probe_child() function was my attempt to make this fit better, and it did work, but I was not happy with it. You can see that from my unhappy comments in cros_ec, or SPI flash probe, for example. The new approach makes buses easier to deal with as I hope you can see. The 'bind' step is supposed to set up the entire basic framework of the drivers at start-up. Everything should be visible in the tree (the exception being buses which must be probed at run-time) but nothing should be probed. Now, we are following that approach for buses also. OK. I understand that this concept makes things much simpler, so Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com Perhaps, we can have a flag like DM_FLAG_ALLOC_PLATDATA_LATE: If this flag is set, platdata is allocated in device_probe(), not device_bind(). But, I think it might make things much more complicated and probably make you unhappy. I do not have a strong option about this. Let's go with your idea! If something does not go well, then we can come back here. Re the disadvantages: - the per-child platform data for a bus is small, and we need not bind devices which are disabled. So, a board should avoid having a lot of enabled devices which are never used - malloc() is very fast, it is the platform data setup that takes time. I agree this slows things down. But currently it only affects bus children, and only their basic information such as chip select. The use of ofdata_to_platdata() is stil confined to when the device is actually probed. This helps to keep things fast in the common case where we don't need the platform data earlier. I think we can refine this further, but what I have now feels a lot cleaner to me. OK! I have done with a quick review of this series. I left some comments on some patches,but they are all minor issues. If you agree to fix them, please send v3. I am OK with the whole concept, so I guess we can get it in during this MW. Thanks! -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
On 01/23/2015 09:37 PM, Bin Meng wrote:
Hi Stephen,
On Sat, Jan 24, 2015 at 12:49 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 01/23/2015 03:19 AM, Thierry Reding wrote:
On Thu, Jan 22, 2015 at 12:04:06AM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 5:40 PM, Thierry Reding tred...@nvidia.com
wrote:
On Wed, Jan 21, 2015 at 05:15:42PM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 4:24 PM, Thierry Reding tred...@nvidia.com
wrote:
On Wed, Jan 21, 2015 at 10:37:07AM +0800, Bin Meng wrote:
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org
wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code
to the
new fdtdec pci helpers. To get the device index of the root port,
the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel
this
patch is doing correctly.
It's in the U-Boot tree, look at arch/arm/dts/tegra124.dtsi for an
example.
Got it. I see:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x0100
0 0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
nvidia,num-lanes = 2;
};
So I would read this 'reg = 0x000800 0 0 0 0' as this is a
downstream port with device number 1 of the root complex.
Correct. Note that these root ports don't appear on the bus using the
regular configuration space accesses, so the definition here is
arbitrary, though in a way to mirror what PCI would typically look like
(host bridge 00:00.0, root ports 00:01.0..00:0N.0).
The Linux kernel driver (and the U-Boot driver for that matter) rely on
this numbering, though, for some aspects of configuration of the root
ports.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
I do like how 0 actually transports the meaning of don't care here.
The reg property encodes only the BDF, whereas the configuration space
region for the root ports is encoded in the assigned-addresses
property.
Looking at the fdtdec_get_pci_addr() implementation I notice that it
uses the type parameter to match on the type of region. Devices can
have
more than one region of the same type. How is that supposed to work
with
this function. Perhaps it's nothing we care about for the fdtdec API
since we don't access those regions anyway from FDT code?
Ah, yes, some devices may have multiple regions of the same type.
Perhaps we need another parameter bar_index for this api? So far this
API is not used by FDT codes. It is used by the ns16550 driver where
pci ns16550 normally has two bars, one memory and one i/o.
Why not use the BARs directly in the ns16550 driver rather than looking
it up from the device tree? I assume the device will have to be
enumerated anyway to make it work properly, at which point addresses
should've been assigned to the memory and I/O BARs.
It is because we cannot predict which bar to look up if we hardcod
that in the generic ns16550 driver. Normally PCI ns16550 registers can
be memory-mapped or I/O mapped and it could use any of the 6 BARs.
What's more, on x86 for memory-mapped and I/O mapped they use
different instructions to access the registers, and there is one build
time macro (CONFIG_SYS_NS16550_PORT_MAPPED) to control this.
Surely the vendor/device ID (or perhaps subvendor/device ID) directly imply
which BAR is used for this purpose? It's really part of the specification of
the interface to HW, so a particular bit of HW shouldn't be randomly
deciding to use a different BAR register each
Re: [U-Boot] [PATCH v2 22/26] dm: core: Ignore disabled devices when binding
2015-01-20 12:12 GMT+09:00 Simon Glass s...@chromium.org: We don't want to bind devices which should never be used. Signed-off-by: Simon Glass s...@chromium.org Sounds a good idea! Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] odroid: fix g2d sclk rate
G2D core should be provided 200MHz clock rate. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com --- board/samsung/odroid/odroid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c index b7d2381..1554b9d 100644 --- a/board/samsung/odroid/odroid.c +++ b/board/samsung/odroid/odroid.c @@ -248,12 +248,12 @@ static void board_clock_init(void) * MOUTc2c = 800 Mhz * MOUTpwi = 108 MHz * -* sclk_g2d_acp = MOUTg2d / (ratio + 1) = 400 (1) +* sclk_g2d_acp = MOUTg2d / (ratio + 1) = 200 (3) * sclk_c2c = MOUTc2c / (ratio + 1) = 400 (1) * aclk_c2c = sclk_c2c / (ratio + 1) = 200 (1) * sclk_pwi = MOUTpwi / (ratio + 1) = 18 (5) */ - set = G2D_ACP_RATIO(1) | C2C_RATIO(1) | PWI_RATIO(5) | + set = G2D_ACP_RATIO(3) | C2C_RATIO(1) | PWI_RATIO(5) | C2C_ACLK_RATIO(1) | DVSEM_RATIO(1) | DPM_RATIO(1); clrsetbits_le32(clk-div_dmc1, clr, set); -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] arm: mx6: cm-fx6: display compulab logo
Hi Nikita, On 22/01/2015 18:33, Nikita Kiryanov wrote: This is a general question, not strictly related to the patch. You add with the series a way to get splash screen from multiple sources. I have often (I know we are talking about different things..) used splash screen as a way to add a logo, without the necessity to link the image to the code. I think also that the way with logo does not scale well, Why not? Well, it happens if for each maintained board there is a corresponding logo and all logos should be maintain in U-Boot repository - that is quite a mess. Logos has nothing to do with U-Boot development - they are blob data. The fact that they are linked together with U-Boot looks easy, but I do not think it is elegant. Splash images are loaded on demand by u-boot code from a storage - this is IMHO a better solution. and we cannot merge in mainline tons of images - they have nothing to do with u-boot sources. Storing graphics that are part of a program in the program's repository is a common practice, why should U-Boot be different? Maybe due to the number of boards, and if each board wants to have its own logo. If all boards share the same logo I would not see any problem at all. Why is not enough for you to use the splash screen functionality ? IMHO it is much more flexible as using the logo, and there is no need to link it against the code. We are interested in the behavior that VIDEO_LOGO provides: that the logo remains visible on screen and coexists with the frame buffer console, and that no manual installation is required. ok, you like really the logo feature, I see ;-). Added Anatolji to CC - we could let the question in background for the future. Maybe could we have a logo_load_image() near splash_load_from_*() ? Besst regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: video: Make pwm polarity configurable
On Thu, 2015-01-22 at 21:24 +0100, Hans de Goede wrote: It turns out that there are some panels where the pwm input is not active low, so make it configurable. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: Add Hyundai A7HD support
On Thu, 2015-01-22 at 21:24 +0100, Hans de Goede wrote: The Hyundai A7HD is a 7 16:9 A10 powered tablet featuring 1G RAM, 8G nand, 1024x600 IPS screen, a mini hdmi port, mini usb receptacle and a headphones port for details see: http://linux-sunxi.org/Hyundai_A7HD Cc: Mark Janssen man...@maniac.nl Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] Re: [PATCH] sunxi: Add Gemei G9 (Allwinner A10/sun4i) tablet
On Thu, 2015-01-22 at 09:47 +0200, Siarhei Siamashka wrote: On Tue, 20 Jan 2015 15:43:31 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, [...] We have already talked with plaes on IRC yesterday, just now bringing it here. I have finally updated the http://linux-sunxi.org/LCD page to add LVDS panels data and now for Gemei_G9 we have the following settings there: CONFIG_VIDEO_LCD_MODE=x:1024,y:768,depth:24,pclk_khz:10,le:799,ri:260,up:15,lo:16,hs:1,vs:1,sync:3,vmode:0 CONFIG_VIDEO_LCD_PANEL_LVDS=y # warning: unsupported 'lcd_lvds_mode' : 1 CONFIG_VIDEO_LCD_POWER=PH8 CONFIG_VIDEO_LCD_BL_EN=PH7 CONFIG_VIDEO_LCD_BL_PWM=PB2 It's good that lcd_lvds_mode=1 apparently works without problems, while this was not fully expected according to http://lists.denx.de/pipermail/u-boot/2015-January/200168.html Also confirming whether 18-bit or 24-bit is the correct color depth would be a good idea. This tablet has 'lcd_frm = 1' and 'lcd_lvds_bitwidth = 0' in fex. So I tried the 24bit depth setting and it messed up some of the colors (though black remained black and white remained white) in the penguin image in top left corner. Therefore this tablet seems to have 18bit LCD. Päikest, Priit :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: video: Add support for Hitachi tx18d42vm LVDS LCD panels
On Thu, 2015-01-22 at 20:52 +0100, Hans de Goede wrote: Add support for Hitachi tx18d42vm LVDS LCD panels, these panels have a lcd controller which needs to be initialized over SPI, once that is done they work like a regular LVDS panel. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] removing bit reversing for SCFG in immap_ls102xa.h
Hi, Sinan Akman, As the comment of commit c207ff612903389f8b32e377fe32be43e6efd8f7 said, we removes the bit reversing for SCFG registers in u-boot. It is implemented through PBI command in RCW. .pbi write 0x570200, 0x .end Through this way, other SCFG registers could be written in big-endian mode in u-boot or kernel directly. No other bit reversing is needed. For example, we only need to set SCFG_ETSECDMAMCR register as follows. out_be32(scfg-etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); According to your test, I think your RCW is very old and the above PBI command is not added. So I suggest you to add this PBI command in RCW, it will make Ethernet work. Best Regards, Alison Wang -Original Message- From: Sinan Akman [mailto:si...@writeme.com] Sent: Friday, January 23, 2015 3:11 PM To: U-Boot-Denx Cc: Wang Huan-B18965; Sun York-R58495 Subject: removing bit reversing for SCFG in immap_ls102xa.h Hi Alison I was just testing out ls1021atwr board with NOR boot using rcw_1000.bin. I noticed that Ethernet is not working. In ls1021atwr.c we have : out_be32(scfg-etsecdmamcr, SCFG_ETSECDMAMCR_LE_BD_FR); out_be32(scfg-etsecmcr, SCFG_ETSECCMCR_GE2_CLK125); In your earlier commit c207ff612903389f8b32e377fe32be43e6efd8f7 you removed the bit reversing around this but those defines are not in big-endian. By setting bit reversing before those lines as before makes Ethernet working. Could you please take a look at this. Should we reverse your commit since we are accessing SCFG registers directly in the board specific files ? Regards Sinan Akman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10][v6] rsa: Split the rsa-verify to separate the modular exponentiation
Public exponentiation which is required in rsa verify functionality is
tightly integrated with verification code in rsa_verify.c. The patch
splits the file into twp separating the modular exponentiation.
1. rsa-verify.c
- The file parses device tree keys node to fill a keyprop structure.
The keyprop structure can then be converted to implementation specific
format.
(struct rsa_pub_key for sw implementation)
- The parsed device tree node is then passed to a generic rsa_mod_exp
function.
2. rsa-mod-exp.c
Move the software specific functions related to modular exponentiation
from rsa-verify.c to this file.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
No changes
Changes in v5:
Reverted change in rsa_mod_exp_sw function to add pointer to output length
Addressed other comments by Simon
Changes in v4:
Modified rsa_mod_exp_sw function to add pointer to output length
Changes in v3:
Kconfig moved to separate patch. This patch just splits the file now
Changes in v2:
Addressed few of Simon Glass's comments:
- Kconfig option added for RSA
- Comments added for new keyprop struct
include/u-boot/rsa-mod-exp.h | 43 ++
lib/rsa/Makefile | 2 +-
lib/rsa/rsa-mod-exp.c| 303 +++
lib/rsa/rsa-verify.c | 329 ---
tools/Makefile | 3 +-
5 files changed, 404 insertions(+), 276 deletions(-)
create mode 100644 include/u-boot/rsa-mod-exp.h
create mode 100644 lib/rsa/rsa-mod-exp.c
diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h
new file mode 100644
index 000..59cd9ea
--- /dev/null
+++ b/include/u-boot/rsa-mod-exp.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2014, Ruchika Gupta.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+*/
+
+#ifndef _RSA_MOD_EXP_H
+#define _RSA_MOD_EXP_H
+
+#include errno.h
+#include image.h
+
+/**
+ * struct key_prop - holder for a public key properties
+ *
+ * The struct has pointers to modulus (Typically called N),
+ * The inverse, R^2, exponent. These can be typecasted and
+ * used as byte arrays or converted to the required format
+ * as per requirement of RSA implementation.
+ */
+struct key_prop {
+ const void *rr; /* R^2 can be treated as byte array */
+ const void *modulus;/* modulus as byte array */
+ const void *public_exponent; /* public exponent as byte array */
+ uint32_t n0inv; /* -1 / modulus[0] mod 2^32 */
+ int num_bits; /* Key length in bits */
+ uint32_t exp_len; /* Exponent length in number of uint8_t */
+};
+
+/**
+ * rsa_mod_exp_sw() - Perform RSA Modular Exponentiation in sw
+ *
+ * Operation: out[] = sig ^ exponent % modulus
+ *
+ * @sig: RSA PKCS1.5 signature
+ * @sig_len: Length of signature in number of bytes
+ * @node: Node with RSA key elements like modulus, exponent, R^2, n0inv
+ * @out: Result in form of byte array
+ */
+int rsa_mod_exp_sw(const uint8_t *sig, uint32_t sig_len,
+ struct key_prop *node, uint8_t *out);
+
+#endif
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index a5a96cb6..cc25b3c 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -7,4 +7,4 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o rsa-mod-exp.o
diff --git a/lib/rsa/rsa-mod-exp.c b/lib/rsa/rsa-mod-exp.c
new file mode 100644
index 000..4a6de2b
--- /dev/null
+++ b/lib/rsa/rsa-mod-exp.c
@@ -0,0 +1,303 @@
+/*
+ * Copyright (c) 2013, Google Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef USE_HOSTCC
+#include common.h
+#include fdtdec.h
+#include asm/types.h
+#include asm/byteorder.h
+#include asm/errno.h
+#include asm/types.h
+#include asm/unaligned.h
+#else
+#include fdt_host.h
+#include mkimage.h
+#include fdt_support.h
+#endif
+#include u-boot/rsa.h
+#include u-boot/rsa-mod-exp.h
+
+#define UINT64_MULT32(v, multby) (((uint64_t)(v)) * ((uint32_t)(multby)))
+
+#define get_unaligned_be32(a) fdt32_to_cpu(*(uint32_t *)a)
+#define put_unaligned_be32(a, b) (*(uint32_t *)(b) = cpu_to_fdt32(a))
+
+/* Default public exponent for backward compatibility */
+#define RSA_DEFAULT_PUBEXP 65537
+
+/**
+ * subtract_modulus() - subtract modulus from the given value
+ *
+ * @key: Key containing modulus to subtract
+ * @num: Number to subtract modulus from, as little endian word array
+ */
+static void subtract_modulus(const struct rsa_public_key *key, uint32_t num[])
+{
+ int64_t acc = 0;
+ uint i;
+
+ for (i = 0; i key-len; i++) {
+ acc += (uint64_t)num[i] - key-modulus[i];
+ num[i] = (uint32_t)acc;
+ acc = 32;
+ }
+}
+
+/**
+ * greater_equal_modulus() - check if a value is = modulus
+ *
+ * @key: Key containing modulus to check
+ * @num: Number to check against
[U-Boot] [PATCH 3/4 v2] vexpress64: get rid of CONFIG_SYS_EXTRA_OPTIONS
The Versatile Express ARMv8 semihosted FVP platform is still using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure some compile-time flags. Get rid of this and create a Kconfig entry for the FVP model, and a selectable bool for the semihosting library. The FVP subboard is now modeled as a target choice so we can eventually choose between different ARMv8 versatile express boards (FVP, base model, Juno...) this way. All dependent symbols are updated to reflect this. The 64bit Versatile Express board symbols are renamed VEXPRESS64 so we have some chance to see what is actually going on. Tested on the FVP fast model. Acked-by: Steve Rae s...@broadcom.com Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Fix compilation error on the plain Vexpress64 reported by Tom Rini. --- arch/arm/Kconfig | 14 +- board/armltd/vexpress64/Kconfig| 15 ++- configs/vexpress_aemv8a_defconfig | 2 +- configs/vexpress_aemv8a_semi_defconfig | 4 ++-- include/configs/vexpress_aemv8a.h | 16 5 files changed, 38 insertions(+), 13 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5eb1d03cfaaf..d5399f162d57 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -51,6 +51,13 @@ config SYS_CPU default sa1100 if CPU_SA1100 default armv8 if ARM64 +config SEMIHOSTING + bool support boot from semihosting + help + In emulated environments, semihosting is a way for + the hosted environment to call out to the emulator to + retrieve files from the host machine. + choice prompt Target select @@ -720,10 +727,15 @@ config TEGRA select CPU_ARM720T if SPL_BUILD select CPU_V7 if !SPL_BUILD -config TARGET_VEXPRESS_AEMV8A +config TARGET_VEXPRESS64_AEMV8A bool Support vexpress_aemv8a select ARM64 +config TARGET_VEXPRESS64_BASE_FVP + bool Support Versatile Express ARMv8a FVP BASE model + select ARM64 + select SEMIHOSTING + config TARGET_LS2085A_EMU bool Support ls2085a_emu select ARM64 diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 7ebea6317f70..80eaa3d3ab08 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -1,4 +1,17 @@ -if TARGET_VEXPRESS_AEMV8A +if TARGET_VEXPRESS64_AEMV8A + +config SYS_BOARD + default vexpress64 + +config SYS_VENDOR + default armltd + +config SYS_CONFIG_NAME + default vexpress_aemv8a + +endif + +if TARGET_VEXPRESS64_BASE_FVP config SYS_BOARD default vexpress64 diff --git a/configs/vexpress_aemv8a_defconfig b/configs/vexpress_aemv8a_defconfig index b463a333bc6b..9f4b87655613 100644 --- a/configs/vexpress_aemv8a_defconfig +++ b/configs/vexpress_aemv8a_defconfig @@ -1,3 +1,3 @@ CONFIG_ARM=y -CONFIG_TARGET_VEXPRESS_AEMV8A=y +CONFIG_TARGET_VEXPRESS64_AEMV8A=y CONFIG_DEFAULT_DEVICE_TREE=vexpress64 diff --git a/configs/vexpress_aemv8a_semi_defconfig b/configs/vexpress_aemv8a_semi_defconfig index 0035ccdaecd4..26cf7db47f84 100644 --- a/configs/vexpress_aemv8a_semi_defconfig +++ b/configs/vexpress_aemv8a_semi_defconfig @@ -1,4 +1,4 @@ -CONFIG_SYS_EXTRA_OPTIONS=SEMIHOSTING,BASE_FVP +# Semihosted FVP fast model CONFIG_ARM=y -CONFIG_TARGET_VEXPRESS_AEMV8A=y +CONFIG_TARGET_VEXPRESS64_BASE_FVP=y CONFIG_DEFAULT_DEVICE_TREE=vexpress64 diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 027d78b59171..85894bedf8bd 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -11,9 +11,9 @@ /* We use generic board for v8 Versatile Express */ #define CONFIG_SYS_GENERIC_BOARD -#ifdef CONFIG_BASE_FVP +#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #ifndef CONFIG_SEMIHOSTING -#error CONFIG_BASE_FVP requires CONFIG_SEMIHOSTING +#error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING #endif #define CONFIG_BOARD_LATE_INIT #define CONFIG_ARMV8_SWITCH_TO_EL1 @@ -21,8 +21,8 @@ #define CONFIG_REMAKE_ELF -#ifndef CONFIG_BASE_FVP -/* Base FVP not using GICv3 yet */ +#ifndef CONFIG_TARGET_VEXPRESS64_BASE_FVP +/* Base FVP and Juno not using GICv3 yet */ #define CONFIG_GICV3 #endif @@ -40,7 +40,7 @@ #define CONFIG_BOOTP_VCI_STRINGU-boot.armv8.vexpress_aemv8a /* Link Definitions */ -#ifdef CONFIG_BASE_FVP +#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP /* ATF loads u-boot here for BASE_FVP model */ #define CONFIG_SYS_TEXT_BASE 0x8800 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0) @@ -54,7 +54,7 @@ /* SMP Spin Table Definitions */ -#ifdef CONFIG_BASE_FVP +#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP #define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0) #else #define CPU_RELEASE_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0) @@ -119,7 +119,7 @@ #define GICR_BASE (0x2f10) #else
[U-Boot] [PATCH] arm: ls102xa: workaround for cache coherency problem
The RCPM FSM may not be reset after power-on, for example,
in the cases of cold boot and wakeup from deep sleep.
It causes cache coherency problem and may block deep sleep.
Therefore, reset them if they are not be reset.
Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
---
arch/arm/cpu/armv7/ls102xa/cpu.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c b/arch/arm/cpu/armv7/ls102xa/cpu.c
index ce2d92f..a61f6d1 100644
--- a/arch/arm/cpu/armv7/ls102xa/cpu.c
+++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
@@ -14,6 +14,13 @@
#include fsl_epu.h
+#define DCSR_RCPM2_BLOCK_OFFSET0x223000
+#define DCSR_RCPM2_CPMFSMCR0 0x400
+#define DCSR_RCPM2_CPMFSMSR0 0x404
+#define DCSR_RCPM2_CPMFSMCR1 0x414
+#define DCSR_RCPM2_CPMFSMSR1 0x418
+#define CPMFSMSR_FSM_STATE_MASK0x7f
+
DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_DISPLAY_CPUINFO)
@@ -107,6 +114,27 @@ int cpu_eth_init(bd_t *bis)
int arch_cpu_init(void)
{
void *epu_base = (void *)(CONFIG_SYS_DCSRBAR + EPU_BLOCK_OFFSET);
+ void *rcpm2_base =
+ (void *)(CONFIG_SYS_DCSRBAR + DCSR_RCPM2_BLOCK_OFFSET);
+ u32 state;
+
+ /*
+* The RCPM FSM state may not be reset after power-on.
+* So, reset them.
+*/
+ state = in_be32(rcpm2_base + DCSR_RCPM2_CPMFSMSR0)
+ CPMFSMSR_FSM_STATE_MASK;
+ if (state != 0) {
+ out_be32(rcpm2_base + DCSR_RCPM2_CPMFSMCR0, 0x80);
+ out_be32(rcpm2_base + DCSR_RCPM2_CPMFSMCR0, 0x0);
+ }
+
+ state = in_be32(rcpm2_base + DCSR_RCPM2_CPMFSMSR1)
+ CPMFSMSR_FSM_STATE_MASK;
+ if (state != 0) {
+ out_be32(rcpm2_base + DCSR_RCPM2_CPMFSMCR1, 0x80);
+ out_be32(rcpm2_base + DCSR_RCPM2_CPMFSMCR1, 0x0);
+ }
/*
* After wakeup from deep sleep, Clear EPU registers
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compilation of MLO and u-boot.img for SPI NOR flash (Beagle bone Black)
Hi, I want to compile a version of MLO and u-boot for SPI NOR on the beagle bone black board. From buildroot and the uboot-2013.10 version, a MLO.byteswap is compiled, but from the latest version of uboot (u-boot-2015.01), compiled in standalone (outside of buildroot) with the am335x_boneblack_defconfig, no MLO.byteswap is compiled ... Do you know how to configure u-boot-2015.01 in order to provide a MLO.byteswap ? Thanks Manuel Curcio ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Implement SD/MMC versioning properly
The SD/MMC version scheme was buggy when dealing with standard major.minor.change cases. Fix it my using something similar to linux's kernel versioning method. Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com --- common/cmd_mmc.c | 8 ++-- include/mmc.h| 56 +--- 2 files changed, 43 insertions(+), 21 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index 4e28c9d..1335e3d 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -85,8 +85,12 @@ static void print_mmcinfo(struct mmc *mmc) printf(Tran Speed: %d\n, mmc-tran_speed); printf(Rd Block Len: %d\n, mmc-read_bl_len); - printf(%s version %d.%d\n, IS_SD(mmc) ? SD : MMC, - (mmc-version 8) 0xf, mmc-version 0xff); + printf(%s version %d.%d, IS_SD(mmc) ? SD : MMC, + EXTRACT_SDMMC_MAJOR_VERSION(mmc-version), + EXTRACT_SDMMC_MINOR_VERSION(mmc-version)); + if (EXTRACT_SDMMC_CHANGE_VERSION(mmc-version) != 0) + printf(.%d, EXTRACT_SDMMC_CHANGE_VERSION(mmc-version)); + printf(\n); printf(High Capacity: %s\n, mmc-high_capacity ? Yes : No); puts(Capacity: ); diff --git a/include/mmc.h b/include/mmc.h index 09101e2..0fd7517 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -14,24 +14,41 @@ #include linux/compiler.h #include part.h -#define SD_VERSION_SD 0x2 -#define SD_VERSION_3 (SD_VERSION_SD | 0x300) -#define SD_VERSION_2 (SD_VERSION_SD | 0x200) -#define SD_VERSION_1_0 (SD_VERSION_SD | 0x100) -#define SD_VERSION_1_10(SD_VERSION_SD | 0x10a) -#define MMC_VERSION_MMC0x1 -#define MMC_VERSION_UNKNOWN(MMC_VERSION_MMC) -#define MMC_VERSION_1_2(MMC_VERSION_MMC | 0x102) -#define MMC_VERSION_1_4(MMC_VERSION_MMC | 0x104) -#define MMC_VERSION_2_2(MMC_VERSION_MMC | 0x202) -#define MMC_VERSION_3 (MMC_VERSION_MMC | 0x300) -#define MMC_VERSION_4 (MMC_VERSION_MMC | 0x400) -#define MMC_VERSION_4_1(MMC_VERSION_MMC | 0x401) -#define MMC_VERSION_4_2(MMC_VERSION_MMC | 0x402) -#define MMC_VERSION_4_3(MMC_VERSION_MMC | 0x403) -#define MMC_VERSION_4_41 (MMC_VERSION_MMC | 0x429) -#define MMC_VERSION_4_5(MMC_VERSION_MMC | 0x405) -#define MMC_VERSION_5_0(MMC_VERSION_MMC | 0x500) +/* SD/MMC version bits; 8 flags, 8 major, 8 minor, 8 change */ +#define SD_VERSION_SD (1U 31) +#define MMC_VERSION_MMC(1U 30) + +#define MAKE_SDMMC_VERSION(a, b, c)\ + u32)(a)) 16) | ((u32)(b) 8) | (u32)(c)) +#define MAKE_SD_VERSION(a, b, c) \ + (SD_VERSION_SD | MAKE_SDMMC_VERSION(a, b, c)) +#define MAKE_MMC_VERSION(a, b, c) \ + (MMC_VERSION_MMC | MAKE_SDMMC_VERSION(a, b, c)) + +#define EXTRACT_SDMMC_MAJOR_VERSION(x) \ + (((u32)(x) 16) 0xff) +#define EXTRACT_SDMMC_MINOR_VERSION(x) \ + (((u32)(x) 8) 0xff) +#define EXTRACT_SDMMC_CHANGE_VERSION(x)\ + ((u32)(x) 0xff) + +#define SD_VERSION_3 MAKE_SD_VERSION(3, 0, 0) +#define SD_VERSION_2 MAKE_SD_VERSION(2, 0, 0) +#define SD_VERSION_1_0 MAKE_SD_VERSION(1, 0, 0) +#define SD_VERSION_1_10MAKE_SD_VERSION(1, 10, 0) + +#define MMC_VERSION_UNKNOWNMAKE_MMC_VERSION(0, 0, 0) +#define MMC_VERSION_1_2MAKE_MMC_VERSION(1, 2, 0) +#define MMC_VERSION_1_4MAKE_MMC_VERSION(1, 4, 0) +#define MMC_VERSION_2_2MAKE_MMC_VERSION(2, 2, 0) +#define MMC_VERSION_3 MAKE_MMC_VERSION(3, 0, 0) +#define MMC_VERSION_4 MAKE_MMC_VERSION(4, 0, 0) +#define MMC_VERSION_4_1MAKE_MMC_VERSION(4, 1, 0) +#define MMC_VERSION_4_2MAKE_MMC_VERSION(4, 2, 0) +#define MMC_VERSION_4_3MAKE_MMC_VERSION(4, 3, 0) +#define MMC_VERSION_4_41 MAKE_MMC_VERSION(4, 4, 1) +#define MMC_VERSION_4_5MAKE_MMC_VERSION(4, 5, 0) +#define MMC_VERSION_5_0MAKE_MMC_VERSION(5, 0, 0) #define MMC_MODE_HS(1 0) #define MMC_MODE_HS_52MHz (1 1) @@ -43,7 +60,8 @@ #define SD_DATA_4BIT 0x0004 -#define IS_SD(x) (x-version SD_VERSION_SD) +#define IS_SD(x) ((x)-version SD_VERSION_SD) +#define IS_MMC(x) ((x)-version SD_VERSION_MMC) #define MMC_DATA_READ 1 #define MMC_DATA_WRITE 2 -- 1.7.12 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Use a common CONFIG_SYS_PROMPT
From: Ian Campbell i...@hellion.org.uk The CPU info is already logged during boot e.g. CPU:Allwinner A20 (SUN7I) so the prompt is just one more thing to change for each new SoC, just makes it sunxi# instead. Signed-off-by: Ian Campbell i...@hellion.org.uk --- include/configs/sun4i.h| 1 - include/configs/sun5i.h| 1 - include/configs/sun6i.h| 2 -- include/configs/sun7i.h| 1 - include/configs/sun8i.h| 2 -- include/configs/sunxi-common.h | 2 ++ 6 files changed, 2 insertions(+), 7 deletions(-) diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h index 7b85740..87d269b 100644 --- a/include/configs/sun4i.h +++ b/include/configs/sun4i.h @@ -13,7 +13,6 @@ */ #define CONFIG_CLK_FULL_SPEED 100800 -#define CONFIG_SYS_PROMPT sun4i# #define CONFIG_MACH_TYPE 4104 #ifdef CONFIG_USB_EHCI diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h index 09f7533..52e3a6f 100644 --- a/include/configs/sun5i.h +++ b/include/configs/sun5i.h @@ -13,7 +13,6 @@ */ #define CONFIG_CLK_FULL_SPEED 100800 -#define CONFIG_SYS_PROMPT sun5i# #define CONFIG_MACH_TYPE 4138 #ifdef CONFIG_USB_EHCI diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h index 1b73852..f5e11dd 100644 --- a/include/configs/sun6i.h +++ b/include/configs/sun6i.h @@ -16,8 +16,6 @@ */ #define CONFIG_CLK_FULL_SPEED 100800 -#define CONFIG_SYS_PROMPT sun6i# - #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI #define CONFIG_USB_MAX_CONTROLLER_COUNT2 diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index ccec50c..7cd7890 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -14,7 +14,6 @@ */ #define CONFIG_CLK_FULL_SPEED 91200 -#define CONFIG_SYS_PROMPT sun7i# #define CONFIG_MACH_TYPE 4283 #ifdef CONFIG_USB_EHCI diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h index f16e60b..3bdedb3 100644 --- a/include/configs/sun8i.h +++ b/include/configs/sun8i.h @@ -14,8 +14,6 @@ */ #define CONFIG_CLK_FULL_SPEED 100800 -#define CONFIG_SYS_PROMPT sun8i# - #ifdef CONFIG_USB_EHCI #define CONFIG_USB_EHCI_SUNXI #define CONFIG_USB_MAX_CONTROLLER_COUNT1 diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 7a66a4d..4a5cab2 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -40,6 +40,8 @@ */ #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_SYS_PROMPT sunxi# + /* Serial console */ #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] arm: mx6: cm-fx6: display compulab logo
On 01/23/15 11:47, Stefano Babic wrote: Hi Nikita, On 22/01/2015 18:33, Nikita Kiryanov wrote: This is a general question, not strictly related to the patch. You add with the series a way to get splash screen from multiple sources. I have often (I know we are talking about different things..) used splash screen as a way to add a logo, without the necessity to link the image to the code. I think also that the way with logo does not scale well, Why not? Well, it happens if for each maintained board there is a corresponding logo and all logos should be maintain in U-Boot repository - that is quite a mess. Right. I must agree it is a mess. Also, please understand correctly, this is not our intent... Logos has nothing to do with U-Boot development - they are blob data. The fact that they are linked together with U-Boot looks easy, but I do not think it is elegant. Splash images are loaded on demand by u-boot code from a storage - this is IMHO a better solution. Yes, indeed, and also the only one that permits a board to have multiple customizable splash images - which is the case for many SoMs. and we cannot merge in mainline tons of images - they have nothing to do with u-boot sources. Storing graphics that are part of a program in the program's repository is a common practice, why should U-Boot be different? Maybe due to the number of boards, and if each board wants to have its own logo. If all boards share the same logo I would not see any problem at all. And yes, this is our intent. We would like to have a single logo for all our boards (and we have some already - more to come). It is vendor oriented, not board oriented. Why is not enough for you to use the splash screen functionality ? IMHO it is much more flexible as using the logo, and there is no need to link it against the code. We are interested in the behavior that VIDEO_LOGO provides: that the logo remains visible on screen and coexists with the frame buffer console, and that no manual installation is required. ok, you like really the logo feature, I see ;-). Yes, currently, it is used on Utilite computer (which is build around cm-fx6 SoM). So, it looks really good, for the Utilite users to have the HDMI with USB console and the vendor logo. Added Anatolji to CC - we could let the question in background for the future. Maybe could we have a logo_load_image() near splash_load_from_*() ? That would be perfect, I think, and also have it user customizable. Although, I would like to have an option to return to default one... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI
On Thu, Jan 22, 2015 at 07:20:15PM +, Mark Rutland wrote: On Fri, Jan 16, 2015 at 09:12:59AM +, Thierry Reding wrote: On Thu, Jan 15, 2015 at 07:19:37PM +, Mark Rutland wrote: On Wed, Jan 14, 2015 at 07:57:25AM +, Thierry Reding wrote: On Tue, Jan 13, 2015 at 07:44:50PM +, Ian Campbell wrote: Hi Thierry, I needed to boot my Jetson in NS mode (in order to boot Xen) and was investigating the possibility of PSCI support when I discovered that you had already started on it[0]. Hurrah! I cherry-picked the relevant commit onto u-boot-tegra#master and added a few more patches and now it boots correctly for me, both running Xen (some Xen side patches are needed too) and native Linux. The main things which was needed was to rebase for some recent Kconfig changes relating to virt and nonsec mode and to arrange for the RAM used by the secure code to be reserved in the FDT. I also reserved the RAM using the hardware MC_SECURITY_CFG registers for good measure. Great, those were all things that I had wanted to do but never got around to. I also pushed my tree to gitorious: https://gitorious.org/ijc/u-boot jetson-psci-v1 I would Ack your patch, but I don't think you've posted it and it has no S-o-b so that would seem a bit premature/rude of me. For the same reason I've not actually included it in the series posted (but it is in the gitorious branch). Feel free to take ownership of that patch. I currently don't have the time to work on this and it seems you've made good progress on it. It could probably use some cleanup because there's a bit of debug output still in there. Also... FWIW I think you could drop your stub versions of psci_cpu_off and psci_cpu_suspend (assuming you don't want to implement them) since the common code has stubs. ... I'd think you'd need to implement these so that you can get proper suspend/resume support in the kernel. I've had to disable cpuidle (via #undef CONFIG_PM_SLEEP in arch/arm/mach-tegra/cpuidle-tegra114.c) in the kernel to make that code not powergate CPUs. Ideally I think the kernel would check that it's running with PSCI support and disable the cpuidle driver. Maybe that could be done by introducing a new cpuidle driver that checks for PSCI availability and uses it when present. We have a generic CPUidle driver on arm64 which can use PSCI as a backend; we should try to reuse that. The binding should certainly be identical. Is there any reason that driver needs to be ARM64-specific? I would've thought that there could be a generic PSCI driver that works anywhere. Currently the arm and arm64 arch interfaces are a little different, but with some work the bulk of the code could certainly be made common (in drivers/firmware, perhaps). It looks like the tegra124 dts in mainline doesn't use enable-method in the DT, so a better option might be to fail early in cpuidle-tegra114.c if _any_ enable-method is present. Yes, that sounds like a good plan. The absence of an enable-method would signal that a kernel-native method (if any) should be used. And this reminds me that we still need to find a way to synchronize accesses to the powergate registers between secure firmware and the kernel. Tegra has a set of hardware semaphores, but it seems like those can only be used to synchronize between AVP and CPU, whereas for PSCI we'd need something to synchronize between two CPUs. Do you know of any existing mechanism to perform that type of synchronization? Perhaps an option would be to add some sort of global lock in the kernel which the cpuidle driver can grab before issuing the SMC instruction. PSCI assumes that the FW is in full control of the registers it's poking. While a lock isn't necessarily bad, I suspect it's going to be very difficult to have that common across all users without the code becoming unmaintainable fast. I'd also hope that for arm64 we wouldn't need it. When/how/why does the kernel to poke these registers? The PMC is what controls power partitions. Some of these partitions are assigned to CPUs, others are assigned to things like SATA, PCIe, display and so on. The problem is that if we manage the CPU power partitions via the firmware, then they will conflict with calls that we need to make from other drivers that need to gate or ungate the partitions for their hardware. As I understand it there's no provision in PSCI to manage non- CPU devices, so this is a problem. So I think either firmware needs to control everything, in which case we are going to need a new interface (or extend PSCI) or it mustn't control anything, in which case we need custom code in the kernel for SMP. Well, the other alternative would be the lock that we can
Re: [U-Boot] [PATCH] pci: tegra: Fix port information parsing
On Thu, Jan 22, 2015 at 12:04:06AM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 5:40 PM, Thierry Reding tred...@nvidia.com wrote:
On Wed, Jan 21, 2015 at 05:15:42PM +0800, Bin Meng wrote:
Hi Thierry,
On Wed, Jan 21, 2015 at 4:24 PM, Thierry Reding tred...@nvidia.com wrote:
On Wed, Jan 21, 2015 at 10:37:07AM +0800, Bin Meng wrote:
Hi,
On Wed, Jan 21, 2015 at 3:05 AM, Simon Glass s...@chromium.org wrote:
Hi Sjoerd,
On 20 January 2015 at 10:06, Sjoerd Simons
sjoerd.sim...@collabora.co.uk wrote:
commit a62e84d7b1824a202dd incorrectly changed the tegra pci code to
the
new fdtdec pci helpers. To get the device index of the root port, the
reg property should be parsed from the dtb (as was previously the
case).
With this patch i can successfully network boot my jetson tk1
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/pci/pci_tegra.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Can you also please take a look at this patch?
http://patchwork.ozlabs.org/patch/430815/
It tries to support both options.
Although I still don't see how the Tegra's dts is written, I feel this
patch is doing correctly.
It's in the U-Boot tree, look at arch/arm/dts/tegra124.dtsi for an
example.
Got it. I see:
pci@1,0 {
device_type = pci;
assigned-addresses = 0x82000800 0 0x0100 0
0x1000;
reg = 0x000800 0 0 0 0;
status = disabled;
#address-cells = 3;
#size-cells = 2;
ranges;
nvidia,num-lanes = 2;
};
So I would read this 'reg = 0x000800 0 0 0 0' as this is a
downstream port with device number 1 of the root complex.
Correct. Note that these root ports don't appear on the bus using the
regular configuration space accesses, so the definition here is
arbitrary, though in a way to mirror what PCI would typically look like
(host bridge 00:00.0, root ports 00:01.0..00:0N.0).
The Linux kernel driver (and the U-Boot driver for that matter) rely on
this numbering, though, for some aspects of configuration of the root
ports.
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index f9e05ad..67b5fdf 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -459,7 +459,6 @@ static int tegra_pcie_parse_port_info(const void
*fdt, int node,
unsigned int *lanes)
{
struct fdt_pci_addr addr;
- pci_dev_t bdf;
int err;
err = fdtdec_get_int(fdt, node, nvidia,num-lanes, 0);
@@ -470,13 +469,13 @@ static int tegra_pcie_parse_port_info(const
void *fdt, int node,
*lanes = err;
- err = fdtdec_get_pci_bdf(fdt, node, addr, bdf);
+ err = fdtdec_get_pci_addr(fdt, node, 0, reg, addr);
I suggest replace 0 to FDT_PCI_SPACE_CONFIG.
I do like how 0 actually transports the meaning of don't care here.
The reg property encodes only the BDF, whereas the configuration space
region for the root ports is encoded in the assigned-addresses property.
Looking at the fdtdec_get_pci_addr() implementation I notice that it
uses the type parameter to match on the type of region. Devices can have
more than one region of the same type. How is that supposed to work with
this function. Perhaps it's nothing we care about for the fdtdec API
since we don't access those regions anyway from FDT code?
Ah, yes, some devices may have multiple regions of the same type.
Perhaps we need another parameter bar_index for this api? So far this
API is not used by FDT codes. It is used by the ns16550 driver where
pci ns16550 normally has two bars, one memory and one i/o.
Why not use the BARs directly in the ns16550 driver rather than looking
it up from the device tree? I assume the device will have to be
enumerated anyway to make it work properly, at which point addresses
should've been assigned to the memory and I/O BARs.
It is because we cannot predict which bar to look up if we hardcod
that in the generic ns16550 driver. Normally PCI ns16550 registers can
be memory-mapped or I/O mapped and it could use any of the 6 BARs.
What's more, on x86 for memory-mapped and I/O mapped they use
different instructions to access the registers, and there is one build
time macro (CONFIG_SYS_NS16550_PORT_MAPPED) to control this.
That sounds like pretty arbitrary restrictions. For one you can detect
invalid BARs, so selecting the right one should be easy. Also it seems
like adding support for both I/O and memory BARs in the same binary
should be relatively easy to do and not add a whole lot of code to the
[U-Boot] [PATCH][v2] powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
Secure Boot Target is added for NAND for P3041
Changes:
In PowerPC, the core begins execution from address 0xFFFC.
In case of secure boot, this default address maps to Boot ROM.
The Boot ROM code requires that the bootloader(U-boot) must lie
in 0 to 3.5G address space i.e 0x0 - 0xDFFF
In case of NAND Secure Boot, CONFIG_SYS_RAMBOOT is enabled and CPC is
configured as SRAM. U-Boot binary will be located on this SRAM at
location 0xBFF4 with entry point as 0xBFFC.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com
---
Changes in v2:
set_tlb call moved inside the if condition for checking
if tlb_index is valid.
Makefile | 4
arch/powerpc/cpu/mpc85xx/cpu_init.c| 16
board/freescale/common/p_corenet/tlb.c | 18 +-
configs/P3041DS_NAND_SECURE_BOOT_defconfig | 4
include/configs/corenet_ds.h | 6 ++
5 files changed, 47 insertions(+), 1 deletion(-)
create mode 100644 configs/P3041DS_NAND_SECURE_BOOT_defconfig
diff --git a/Makefile b/Makefile
index 36a9a28..ca98b3e 100644
--- a/Makefile
+++ b/Makefile
@@ -714,8 +714,12 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
ifeq ($(CONFIG_SPL_FSL_PBL),y)
ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin
else
+ifneq ($(CONFIG_SECURE_BOOT), y)
+# For Secure Boot The Image needs to be signed and Header must also
+# be included. So The image has to be built explicitly
ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl
endif
+endif
ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 85d32fc..026ed53 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -851,6 +851,22 @@ int cpu_init_r(void)
setup_mp();
#endif
+#ifdef CONFIG_SECURE_BOOT
+ /* Disable the TLB Created for L3 and create the TLB required for
+* PCIE (CONFIG_SYS_PCIE1_MEM_VIRT) which was not created earlier.
+*/
+ int tlb_index;
+ tlb_index = find_tlb_idx((void *)CONFIG_BPTR_VIRT_ADDR, 1);
+ if (tlb_index != -1) {
+ disable_tlb(tlb_index);
+
+ set_tlb(1, CONFIG_SYS_PCIE1_MEM_VIRT,
+ CONFIG_SYS_PCIE1_MEM_PHYS,
+ MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, tlb_index, BOOKE_PAGESZ_1G, 1);
+ }
+#endif
+
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC13
{
if (SVR_MAJ(svr) 3) {
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index 8148e46..1b60cfb 100644
--- a/board/freescale/common/p_corenet/tlb.c
+++ b/board/freescale/common/p_corenet/tlb.c
@@ -42,7 +42,9 @@ struct fsl_e_tlb_entry tlb_table[] = {
/* TLB 1 */
/* *I*** - Covers boot page */
-#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L3_ADDR)
+ /* In Case of Secure RAM Boot L3 address is defined at 0xbff0 */
+#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L3_ADDR) \
+ !defined(CONFIG_SECURE_BOOT)
/*
* *I*G - L3SRAM. When L3 is used as 1M SRAM, the address of the
* SRAM is at 0xfff0, it covered the 0xf000.
@@ -76,11 +78,25 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SR, MAS2_W|MAS2_G,
0, 2, BOOKE_PAGESZ_256M, 1),
+#if defined(CONFIG_SYS_RAMBOOT) defined(CONFIG_SYS_INIT_L3_ADDR) \
+ defined(CONFIG_SECURE_BOOT)
+ /* In case of Secure Boot, L3 is used as 1M SRAM
+* and the address of the SRAM is at 0xbff0.
+* The PCIE TLB entry conflicts with the above entry.
+* So, the entry for PCIE is not created at this point of time.
+* It will be created later on in cpu_init_r()
+* when U-Boot has relocated to DDR
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 3, BOOKE_PAGESZ_1M, 1),
+#else
/* *I*G* - PCI */
SET_TLB_ENTRY(1, CONFIG_SYS_PCIE1_MEM_VIRT, CONFIG_SYS_PCIE1_MEM_PHYS,
MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 3, BOOKE_PAGESZ_1G, 1),
+#endif
/* *I*G* - PCI */
SET_TLB_ENTRY(1, CONFIG_SYS_PCIE1_MEM_VIRT + 0x4000,
CONFIG_SYS_PCIE1_MEM_PHYS + 0x4000,
diff --git a/configs/P3041DS_NAND_SECURE_BOOT_defconfig
b/configs/P3041DS_NAND_SECURE_BOOT_defconfig
new file mode 100644
index 000..e810b1c
--- /dev/null
+++ b/configs/P3041DS_NAND_SECURE_BOOT_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SYS_EXTRA_OPTIONS=RAMBOOT_PBL,NAND,SECURE_BOOT,SYS_TEXT_BASE=0xBFF4
+CONFIG_PPC=y
+CONFIG_MPC85xx=y
+CONFIG_TARGET_P3041DS=y
diff --git a/include/configs/corenet_ds.h
[U-Boot] [PATCH v4 1/2] Errata/ARM57: Add basic constructs to handle and apply A57 specific erratas
This patch adds basic constructs in the ARMv8 u-boot code to handle and apply Cortex-A57 specific erratas. As and example, the framework showcases how erratas 833069, 826974 and 828024 can be handled and applied. Later on this framework can be extended to include other erratas. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- Changes from v3: - Addressed comments from Scott regarding backward branching correct masking from A53's MIDR_EL1. Changes from v2: - Addressed comments regarding incorrect handling of bl and ret sequences. - Reorganized the code to be more readable. Changes from v1: - Addressed Yorks' comments about x29 corruption. arch/arm/cpu/armv8/start.S | 45 ++ arch/arm/include/asm/macro.h | 22 + 2 files changed, 67 insertions(+) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index 4b11aa4..540a5db 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -67,6 +67,9 @@ reset: msr cpacr_el1, x0 /* Enable FP/SIMD */ 0: + /* Apply ARM core specific erratas */ + bl apply_core_errata + /* * Cache/BPB/TLB Invalidate * i-cache is invalidated before enabled in icache_enable() @@ -97,6 +100,48 @@ master_cpu: /*---*/ +WEAK(apply_core_errata) + + mov x29, lr /* Save LR */ + /* For now, we support Cortex-A57 specific errata only */ + + /* Check if we are running on a Cortex-A57 core */ + branch_if_a57_core x0, apply_a57_core_errata +0: + mov lr, x29 /* Restore LR */ + ret + +apply_a57_core_errata: + +#ifdef CONFIG_ARM_ERRATA_828024 + mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */ + /* Disable non-allocate hint of w-b-n-a memory type */ + mov x0, #0x1 49 + /* Disable write streaming no L1-allocate threshold */ + mov x0, #0x3 25 + /* Disable write streaming no-allocate threshold */ + mov x0, #0x3 27 + msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */ +#endif + +#ifdef CONFIG_ARM_ERRATA_826974 + mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */ + /* Disable speculative load execution ahead of a DMB */ + mov x0, #0x1 59 + msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */ +#endif + +#ifdef CONFIG_ARM_ERRATA_833069 + mrs x0, S3_1_c15_c2_0 /* cpuactlr_el1 */ + /* Disable Enable Invalidates of BTB bit */ + and x0, x0, #0xE + msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */ +#endif + b 0b +ENDPROC(apply_core_errata) + +/*---*/ + WEAK(lowlevel_init) mov x29, lr /* Save LR */ diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h index 1c8c425..5f7c7e0 100644 --- a/arch/arm/include/asm/macro.h +++ b/arch/arm/include/asm/macro.h @@ -74,6 +74,28 @@ lr .reqx30 .endm /* + * Branch if current processor is a Cortex-A57 core. + */ +.macro branch_if_a57_core, xreg, a57_label + mrs \xreg, midr_el1 + lsr \xreg, \xreg, #4 + and \xreg, \xreg, #0x0FFF + cmp \xreg, #0xD07 /* Cortex-A57 MPCore processor. */ + b.eq\a57_label +.endm + +/* + * Branch if current processor is a Cortex-A53 core. + */ +.macro branch_if_a53_core, xreg, a53_label + mrs \xreg, midr_el1 + lsr \xreg, \xreg, #4 + and \xreg, \xreg, #0x0FFF + cmp \xreg, #0xD03 /* Cortex-A53 MPCore processor. */ + b.eq\a53_label +.endm + +/* * Branch if current processor is a slave, * choose processor with all zero affinity value as the master. */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/2] configs/ls2085a: Add support for Cortex-A57 erratas
This patch adds support for handling 828024 and 826974 erratas for Cortex-A57 cores present on LS2085A SoC. Signed-off-by: Bhupesh Sharma bhupesh.sha...@freescale.com --- include/configs/ls2085a_common.h |4 1 file changed, 4 insertions(+) diff --git a/include/configs/ls2085a_common.h b/include/configs/ls2085a_common.h index 6fe032c..01c8566 100644 --- a/include/configs/ls2085a_common.h +++ b/include/configs/ls2085a_common.h @@ -14,6 +14,10 @@ #define CONFIG_LS2085A #define CONFIG_GICV3 +/* Errata fixes */ +#define CONFIG_ARM_ERRATA_828024 +#define CONFIG_ARM_ERRATA_826974 + /* Link Definitions */ #define CONFIG_SYS_TEXT_BASE 0x30001000 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10][v6] DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver
Add a new rsa uclass for performing modular exponentiation and implement
the software driver basing on this uclass.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
No Changes
Changes in v5:
Changed UCLASS name to UCLASS_MOD_EXP
Changes in v4:
Removed Kconfig option for DM_RSA
Corrected driver name for sw rsa driver
Updated the rsa_mod_exp operation to have output length
Changes in v3:
New patch with driver model for RSA UCLASS
drivers/crypto/Makefile | 1 +
drivers/crypto/rsa_mod_exp/Kconfig | 5
drivers/crypto/rsa_mod_exp/Makefile | 7 ++
drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 39 +
drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 31 +++
include/dm/uclass-id.h | 1 +
include/u-boot/rsa-mod-exp.h| 34 -
7 files changed, 117 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/rsa_mod_exp/Kconfig
create mode 100644 drivers/crypto/rsa_mod_exp/Makefile
create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_sw.c
create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 7b79237..fb8c10b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,4 +6,5 @@
#
obj-$(CONFIG_EXYNOS_ACE_SHA) += ace_sha.o
+obj-y += rsa_mod_exp/
obj-y += fsl/
diff --git a/drivers/crypto/rsa_mod_exp/Kconfig
b/drivers/crypto/rsa_mod_exp/Kconfig
new file mode 100644
index 000..6dcb39a
--- /dev/null
+++ b/drivers/crypto/rsa_mod_exp/Kconfig
@@ -0,0 +1,5 @@
+config DM_MOD_EXP
+ bool Enable Driver Model for RSA Modular Exponentiation
+ depends on DM
+ help
+ If you want to use driver model for RSA Modular Exponentiation, say Y.
diff --git a/drivers/crypto/rsa_mod_exp/Makefile
b/drivers/crypto/rsa_mod_exp/Makefile
new file mode 100644
index 000..915b751
--- /dev/null
+++ b/drivers/crypto/rsa_mod_exp/Makefile
@@ -0,0 +1,7 @@
+#
+# (C) Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_RSA) += mod_exp_uclass.o mod_exp_sw.o
diff --git a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
new file mode 100644
index 000..dc6c064
--- /dev/null
+++ b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
@@ -0,0 +1,39 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Ruchika Gupta ruchika.gu...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include dm.h
+#include u-boot/rsa-mod-exp.h
+
+int mod_exp_sw(struct udevice *dev, const uint8_t *sig, uint32_t sig_len,
+ struct key_prop *prop, uint8_t *out)
+{
+ int ret = 0;
+
+ ret = rsa_mod_exp_sw(sig, sig_len, prop, out);
+ if (ret) {
+ debug(%s: RSA failed to verify: %d\n, __func__, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct mod_exp_ops mod_exp_ops_sw = {
+ .mod_exp= mod_exp_sw,
+};
+
+U_BOOT_DRIVER(mod_exp_sw) = {
+ .name = mod_exp_sw,
+ .id = UCLASS_MOD_EXP,
+ .ops= mod_exp_ops_sw,
+};
+
+U_BOOT_DEVICE(mod_exp_sw) = {
+ .name = mod_exp_sw,
+};
diff --git a/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
new file mode 100644
index 000..266f094
--- /dev/null
+++ b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
@@ -0,0 +1,31 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc
+ * Author: Ruchika Gupta ruchika.gu...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include u-boot/rsa-mod-exp.h
+#include errno.h
+#include fdtdec.h
+#include malloc.h
+#include asm/io.h
+#include linux/list.h
+
+int rsa_mod_exp(struct udevice *dev, const uint8_t *sig, uint32_t sig_len,
+ struct key_prop *node, uint8_t *out)
+{
+ const struct mod_exp_ops *ops = device_get_ops(dev);
+
+ if (!ops-mod_exp)
+ return -ENOSYS;
+
+ return ops-mod_exp(dev, sig, sig_len, node, out);
+}
+
+UCLASS_DRIVER(mod_exp) = {
+ .id = UCLASS_MOD_EXP,
+ .name = rsa_mod_exp,
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index f17c3c2..91bb90d 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -33,6 +33,7 @@ enum uclass_id {
UCLASS_I2C, /* I2C bus */
UCLASS_I2C_GENERIC, /* Generic I2C device */
UCLASS_I2C_EEPROM, /* I2C EEPROM device */
+ UCLASS_MOD_EXP, /* RSA Mod Exp device */
UCLASS_COUNT,
UCLASS_INVALID = -1,
diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h
index 59cd9ea..fce445a 100644
--- a/include/u-boot/rsa-mod-exp.h
+++ b/include/u-boot/rsa-mod-exp.h
@@ -35,9 +35,41
[U-Boot] [PATCH 05/10][v6] lib/rsa: Modify rsa to use DM driver
Modify rsa_verify to use the rsa driver of DM library .The tools will continue to use the same RSA sw library. CONFIG_RSA is now dependent on CONFIG_DM. All configurations which enable FIT based signatures have been modified to enable CONFIG_DM by default. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Added signature option in am335x_boneblack_vboot_defconfig Made changes in rsa-verify.c as suggested by Simon Changes in v4: Make CONFIG_RSA always depenedent on Driver Model. Add CONFIG_DM in defconfigs of the platforms which enable CONFIG_FIT_SIGNATURE Changes in v3: New patch README | 7 ++- configs/am335x_boneblack_vboot_defconfig | 4 configs/ids8313_defconfig| 1 + configs/sandbox_defconfig| 1 + configs/zynq_microzed_defconfig | 1 + configs/zynq_zc70x_defconfig | 1 + configs/zynq_zc770_xm010_defconfig | 1 + configs/zynq_zc770_xm012_defconfig | 1 + configs/zynq_zc770_xm013_defconfig | 1 + configs/zynq_zed_defconfig | 1 + configs/zynq_zybo_defconfig | 1 + include/configs/am335x_evm.h | 6 ++ include/configs/sandbox.h| 1 - lib/rsa/rsa-verify.c | 14 ++ 14 files changed, 35 insertions(+), 6 deletions(-) diff --git a/README b/README index fefa71c..cac7978 100644 --- a/README +++ b/README @@ -3176,8 +3176,13 @@ CBFS (Coreboot Filesystem) support This enables the RSA algorithm used for FIT image verification in U-Boot. See doc/uImage.FIT/signature.txt for more information. + The Modular Exponentiation algorithm in RSA is implemented using + driver model. So CONFIG_DM needs to be enabled by default for this + library to function. + The signing part is build into mkimage regardless of this - option. + option. The software based modular exponentiation is built into + mkimage irrespective of this option. - bootcount support: CONFIG_BOOTCOUNT_LIMIT diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig index 5837a0a..51bf370 100644 --- a/configs/am335x_boneblack_vboot_defconfig +++ b/configs/am335x_boneblack_vboot_defconfig @@ -4,3 +4,7 @@ CONFIG_SYS_EXTRA_OPTIONS=EMMC_BOOT,ENABLE_VBOOT +S:CONFIG_TARGET_AM335X_EVM=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=am335x-boneblack +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y diff --git a/configs/ids8313_defconfig b/configs/ids8313_defconfig index 8479cd4..0950ec8 100644 --- a/configs/ids8313_defconfig +++ b/configs/ids8313_defconfig @@ -4,3 +4,4 @@ CONFIG_MPC83xx=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_TARGET_IDS8313=y +CONFIG_DM=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 0111f25..660063e 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -3,4 +3,5 @@ CONFIG_OF_HOSTFILE=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y CONFIG_DEFAULT_DEVICE_TREE=sandbox diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig index b9a6fe5..8b985fe 100644 --- a/configs/zynq_microzed_defconfig +++ b/configs/zynq_microzed_defconfig @@ -6,4 +6,5 @@ CONFIG_OF_CONTROL=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y CONFIG_DEFAULT_DEVICE_TREE=zynq-microzed diff --git a/configs/zynq_zc70x_defconfig b/configs/zynq_zc70x_defconfig index dc8aa84..cceb321 100644 --- a/configs/zynq_zc70x_defconfig +++ b/configs/zynq_zc70x_defconfig @@ -7,3 +7,4 @@ CONFIG_DEFAULT_DEVICE_TREE=zynq-zc702 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y diff --git a/configs/zynq_zc770_xm010_defconfig b/configs/zynq_zc770_xm010_defconfig index 2f5fa8c..2935c0d 100644 --- a/configs/zynq_zc770_xm010_defconfig +++ b/configs/zynq_zc770_xm010_defconfig @@ -8,3 +8,4 @@ CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm010 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y diff --git a/configs/zynq_zc770_xm012_defconfig b/configs/zynq_zc770_xm012_defconfig index a92d495..0401739 100644 --- a/configs/zynq_zc770_xm012_defconfig +++ b/configs/zynq_zc770_xm012_defconfig @@ -8,3 +8,4 @@ CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm012 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y diff --git a/configs/zynq_zc770_xm013_defconfig b/configs/zynq_zc770_xm013_defconfig index 3a02f75..a95970a 100644 --- a/configs/zynq_zc770_xm013_defconfig +++ b/configs/zynq_zc770_xm013_defconfig @@ -8,3 +8,4 @@ CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm013 CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_FIT_SIGNATURE=y +CONFIG_DM=y diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig index
[U-Boot] [PATCH 02/10][v6] FIT: Modify option FIT_SIGNATURE in Kconfig
For FIT signature based approach to work, RSA library needs to be selected. The FIT_SIGNATURE option in Kconfig is modified to automatically select RSA. Selecting RSA compiles the RSA library required for image verification. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: Word wrapping in commit Added space after . Changes in v4: Expanded CONFIG_RSA with documentation link Changes in v3: New patch created for adding Kconfig option for FIT signature Kconfig | 3 ++- lib/Kconfig | 7 +++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 4157da3..fed488f 100644 --- a/Kconfig +++ b/Kconfig @@ -116,8 +116,9 @@ config FIT_VERBOSE depends on FIT config FIT_SIGNATURE - bool Enabel signature verification of FIT uImages + bool Enable signature verification of FIT uImages depends on FIT + select RSA help This option enables signature verification of FIT uImages, using a hash signed and verified using RSA. diff --git a/lib/Kconfig b/lib/Kconfig index 8460439..79b91b7 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -27,4 +27,11 @@ config SYS_HZ get_timer() must operate in milliseconds and this option must be set to 1000. +config RSA + bool Use RSA Library + help + RSA support. This enables the RSA algorithm used for FIT image + verification in U-Boot. + See doc/uImage.FIT/signature.txt for more details. + endmenu -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10][v6] configs: Move CONFIG_FIT_SIGNATURE to defconfig
For the platforms which use,CONFIG_FIT_SIGNATURE, the required configs are moved to the platform's defconfig file. Selecting CONFIG_FIT_SIGNATURE using defconfig automatically resolves the dependencies for signature verification. The RSA library gets automatically selected and user does not have to define CONFIG_RSA manually. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: No changes Changes in v4: No changes Changes in v3: New patch configs/ids8313_defconfig | 2 ++ configs/sandbox_defconfig | 3 +++ configs/zynq_microzed_defconfig| 3 +++ configs/zynq_zc70x_defconfig | 3 +++ configs/zynq_zc770_xm010_defconfig | 3 +++ configs/zynq_zc770_xm012_defconfig | 3 +++ configs/zynq_zc770_xm013_defconfig | 3 +++ configs/zynq_zed_defconfig | 3 +++ configs/zynq_zybo_defconfig| 3 +++ include/configs/am335x_evm.h | 4 ++-- include/configs/ids8313.h | 3 --- include/configs/sandbox.h | 3 --- include/configs/zynq-common.h | 6 -- 13 files changed, 28 insertions(+), 14 deletions(-) diff --git a/configs/ids8313_defconfig b/configs/ids8313_defconfig index 1c665aa..8479cd4 100644 --- a/configs/ids8313_defconfig +++ b/configs/ids8313_defconfig @@ -1,4 +1,6 @@ CONFIG_SYS_EXTRA_OPTIONS=SYS_TEXT_BASE=0xFFF0 CONFIG_PPC=y CONFIG_MPC83xx=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y CONFIG_TARGET_IDS8313=y diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 47d8400..0111f25 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -1,3 +1,6 @@ CONFIG_OF_CONTROL=y CONFIG_OF_HOSTFILE=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y CONFIG_DEFAULT_DEVICE_TREE=sandbox diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig index 9588849..b9a6fe5 100644 --- a/configs/zynq_microzed_defconfig +++ b/configs/zynq_microzed_defconfig @@ -3,4 +3,7 @@ CONFIG_SPL=y +S:CONFIG_ZYNQ=y +S:CONFIG_TARGET_ZYNQ_MICROZED=y CONFIG_OF_CONTROL=y +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y CONFIG_DEFAULT_DEVICE_TREE=zynq-microzed diff --git a/configs/zynq_zc70x_defconfig b/configs/zynq_zc70x_defconfig index cf50730..dc8aa84 100644 --- a/configs/zynq_zc70x_defconfig +++ b/configs/zynq_zc70x_defconfig @@ -4,3 +4,6 @@ CONFIG_SPL=y +S:CONFIG_TARGET_ZYNQ_ZC70X=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zc702 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/configs/zynq_zc770_xm010_defconfig b/configs/zynq_zc770_xm010_defconfig index 8bb405d..2f5fa8c 100644 --- a/configs/zynq_zc770_xm010_defconfig +++ b/configs/zynq_zc770_xm010_defconfig @@ -5,3 +5,6 @@ CONFIG_SYS_EXTRA_OPTIONS=ZC770_XM010 +S:CONFIG_TARGET_ZYNQ_ZC770=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm010 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/configs/zynq_zc770_xm012_defconfig b/configs/zynq_zc770_xm012_defconfig index 0ba5da5..a92d495 100644 --- a/configs/zynq_zc770_xm012_defconfig +++ b/configs/zynq_zc770_xm012_defconfig @@ -5,3 +5,6 @@ CONFIG_SYS_EXTRA_OPTIONS=ZC770_XM012 +S:CONFIG_TARGET_ZYNQ_ZC770=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm012 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/configs/zynq_zc770_xm013_defconfig b/configs/zynq_zc770_xm013_defconfig index 13f8112..3a02f75 100644 --- a/configs/zynq_zc770_xm013_defconfig +++ b/configs/zynq_zc770_xm013_defconfig @@ -5,3 +5,6 @@ CONFIG_SYS_EXTRA_OPTIONS=ZC770_XM013 +S:CONFIG_TARGET_ZYNQ_ZC770=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zc770-xm013 +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig index eb057fa..1d816f6 100644 --- a/configs/zynq_zed_defconfig +++ b/configs/zynq_zed_defconfig @@ -4,3 +4,6 @@ CONFIG_SPL=y +S:CONFIG_TARGET_ZYNQ_ZED=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zed +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig index 12311cd..9183629 100644 --- a/configs/zynq_zybo_defconfig +++ b/configs/zynq_zybo_defconfig @@ -4,3 +4,6 @@ CONFIG_SPL=y +S:CONFIG_TARGET_ZYNQ_ZYBO=y CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE=zynq-zybo +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_FIT_SIGNATURE=y diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 0004750..f9bc23b 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -23,8 +23,8 @@ # define CONFIG_TIMESTAMP # define CONFIG_LZO # ifdef CONFIG_ENABLE_VBOOT -# define CONFIG_FIT_SIGNATURE -# define CONFIG_RSA +# define CONFIG_FIT_SIGNATURE +# define CONFIG_RSA # endif #endif diff --git a/include/configs/ids8313.h b/include/configs/ids8313.h index f084834..2384864 100644 ---
[U-Boot] [PATCH 08/10][v6] hash: Add function to find hash_algo struct with progressive hash
The hash_algo structure has some implementations in which progressive hash
API's are not defined. These are basically the hardware based implementations
of SHA. An API is added to find the algo which has progressive hash API's
defined. This can then be integrated with RSA checksum library which uses
Progressive Hash API's.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
No Changes
Changes in v5:
None
Changes in v4:
Few cosmetic changes. Currently I have not replaced CONFIG_SHA1 with
CONFIG_CMD_SHA1SUM.
Waiting for reply from Simon and Denx for the same.
Changes in v3 :
Corrected ifdef for SHA1
Changes in v2 :
Added commit message
common/hash.c | 33 -
include/hash.h | 14 ++
2 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index aceabc5..c4d8c3a 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -20,7 +20,7 @@
#include asm/io.h
#include asm/errno.h
-#ifdef CONFIG_CMD_SHA1SUM
+#ifdef CONFIG_SHA1
static int hash_init_sha1(struct hash_algo *algo, void **ctxp)
{
sha1_context *ctx = malloc(sizeof(sha1_context));
@@ -125,12 +125,7 @@ static struct hash_algo hash_algo[] = {
CHUNKSZ_SHA256,
},
#endif
- /*
-* This is CONFIG_CMD_SHA1SUM instead of CONFIG_SHA1 since otherwise
-* it bloats the code for boards which use SHA1 but not the 'hash'
-* or 'sha1sum' commands.
-*/
-#ifdef CONFIG_CMD_SHA1SUM
+#ifdef CONFIG_SHA1
{
sha1,
SHA1_SUM_LEN,
@@ -140,7 +135,6 @@ static struct hash_algo hash_algo[] = {
hash_update_sha1,
hash_finish_sha1,
},
-#define MULTI_HASH
#endif
#ifdef CONFIG_SHA256
{
@@ -152,7 +146,6 @@ static struct hash_algo hash_algo[] = {
hash_update_sha256,
hash_finish_sha256,
},
-#define MULTI_HASH
#endif
{
crc32,
@@ -165,6 +158,10 @@ static struct hash_algo hash_algo[] = {
},
};
+#if defined(CONFIG_SHA256) || defined(CONFIG_CMD_SHA1SUM)
+#define MULTI_HASH
+#endif
+
#if defined(CONFIG_HASH_VERIFY) || defined(CONFIG_CMD_HASH)
#define MULTI_HASH
#endif
@@ -311,6 +308,24 @@ int hash_lookup_algo(const char *algo_name, struct
hash_algo **algop)
return -EPROTONOSUPPORT;
}
+int hash_progressive_lookup_algo(const char *algo_name,
+struct hash_algo **algop)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(hash_algo); i++) {
+ if (!strcmp(algo_name, hash_algo[i].name)) {
+ if (hash_algo[i].hash_init) {
+ *algop = hash_algo[i];
+ return 0;
+ }
+ }
+ }
+
+ debug(Unknown hash algorithm '%s'\n, algo_name);
+ return -EPROTONOSUPPORT;
+}
+
void hash_show(struct hash_algo *algo, ulong addr, ulong len, uint8_t *output)
{
int i;
diff --git a/include/hash.h b/include/hash.h
index d8ec4f0..c0a7ebc 100644
--- a/include/hash.h
+++ b/include/hash.h
@@ -128,6 +128,20 @@ int hash_block(const char *algo_name, const void *data,
unsigned int len,
int hash_lookup_algo(const char *algo_name, struct hash_algo **algop);
/**
+ * hash_progressive_lookup_algo() - Look up hash_algo for prog. hash support
+ *
+ * The function returns the pointer to the struct or -EPROTONOSUPPORT if the
+ * algorithm is not available with progressive hash support.
+ *
+ * @algo_name: Hash algorithm to look up
+ * @algop: Pointer to the hash_algo struct if found
+ *
+ * @return 0 if ok, -EPROTONOSUPPORT for an unknown algorithm.
+ */
+int hash_progressive_lookup_algo(const char *algo_name,
+struct hash_algo **algop);
+
+/**
* hash_show() - Print out a hash algorithm and value
*
* You will get a message like this (without a newline at the end):
--
1.8.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10][v6] Use hash.c in mkimage
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
Fixed compilation error in this file for tools when FIT_SIGNATURE not enabled
Changes in v5:
New patch based on WIP patch by Simon.
common/hash.c | 81 +-
include/hash.h | 34
tools/Makefile | 1 +
3 files changed, 65 insertions(+), 51 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index c4d8c3a..d154d02 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -10,15 +10,24 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#ifndef USE_HOSTCC
#include common.h
#include command.h
#include malloc.h
#include hw_sha.h
+#include asm/io.h
+#include asm/errno.h
+#else
+#include mkimage.h
+#include time.h
+#include image.h
+#endif /* !USE_HOSTCC*/
+
#include hash.h
+#include u-boot/crc.h
#include u-boot/sha1.h
#include u-boot/sha256.h
-#include asm/io.h
-#include asm/errno.h
+#include u-boot/md5.h
#ifdef CONFIG_SHA1
static int hash_init_sha1(struct hash_algo *algo, void **ctxp)
@@ -173,6 +182,40 @@ static struct hash_algo hash_algo[] = {
#define multi_hash() 0
#endif
+int hash_lookup_algo(const char *algo_name, struct hash_algo **algop)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(hash_algo); i++) {
+ if (!strcmp(algo_name, hash_algo[i].name)) {
+ *algop = hash_algo[i];
+ return 0;
+ }
+ }
+
+ debug(Unknown hash algorithm '%s'\n, algo_name);
+ return -EPROTONOSUPPORT;
+}
+
+int hash_progressive_lookup_algo(const char *algo_name,
+struct hash_algo **algop)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(hash_algo); i++) {
+ if (!strcmp(algo_name, hash_algo[i].name)) {
+ if (hash_algo[i].hash_init) {
+ *algop = hash_algo[i];
+ return 0;
+ }
+ }
+ }
+
+ debug(Unknown hash algorithm '%s'\n, algo_name);
+ return -EPROTONOSUPPORT;
+}
+
+#ifndef USE_HOSTCC
/**
* store_result: Store the resulting sum to an address or variable
*
@@ -293,39 +336,6 @@ static int parse_verify_sum(struct hash_algo *algo, char
*verify_str,
return 0;
}
-int hash_lookup_algo(const char *algo_name, struct hash_algo **algop)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(hash_algo); i++) {
- if (!strcmp(algo_name, hash_algo[i].name)) {
- *algop = hash_algo[i];
- return 0;
- }
- }
-
- debug(Unknown hash algorithm '%s'\n, algo_name);
- return -EPROTONOSUPPORT;
-}
-
-int hash_progressive_lookup_algo(const char *algo_name,
-struct hash_algo **algop)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(hash_algo); i++) {
- if (!strcmp(algo_name, hash_algo[i].name)) {
- if (hash_algo[i].hash_init) {
- *algop = hash_algo[i];
- return 0;
- }
- }
- }
-
- debug(Unknown hash algorithm '%s'\n, algo_name);
- return -EPROTONOSUPPORT;
-}
-
void hash_show(struct hash_algo *algo, ulong addr, ulong len, uint8_t *output)
{
int i;
@@ -439,3 +449,4 @@ int hash_command(const char *algo_name, int flags,
cmd_tbl_t *cmdtp, int flag,
return 0;
}
+#endif
diff --git a/include/hash.h b/include/hash.h
index c0a7ebc..f4eb100 100644
--- a/include/hash.h
+++ b/include/hash.h
@@ -17,7 +17,6 @@ enum {
HASH_FLAG_ENV = 1 1, /* Allow env vars */
};
-#ifndef USE_HOSTCC
#if defined(CONFIG_SHA1SUM_VERIFY) || defined(CONFIG_CRC32_VERIFY)
#define CONFIG_HASH_VERIFY
#endif
@@ -77,6 +76,7 @@ struct hash_algo {
int size);
};
+#ifndef USE_HOSTCC
/**
* hash_command: Process a hash command for a particular algorithm
*
@@ -115,6 +115,23 @@ int hash_block(const char *algo_name, const void *data,
unsigned int len,
uint8_t *output, int *output_size);
/**
+ * hash_show() - Print out a hash algorithm and value
+ *
+ * You will get a message like this (without a newline at the end):
+ *
+ * sha1 for 9eb3337c ... 9eb3338f ==
7942ef1df479fd3130f716eb9613d107dab7e257
+ *
+ * @algo: Algorithm used for hash
+ * @addr: Address of data that was hashed
+ * @len: Length of data that was hashed
+ * @output:Hash value to display
+ */
+void hash_show(struct hash_algo *algo, ulong addr, ulong len,
+ uint8_t *output);
+
+#endif /* !USE_HOSTCC */
+
+/**
* hash_lookup_algo() - Look up the hash_algo struct for an algorithm
*
* The function returns the pointer to the struct or -EPROTONOSUPPORT if the
@@ -141,19 +158,4 @@ int hash_lookup_algo(const char
[U-Boot] [PATCH 10/10][v6] rsa: Use checksum algorithms from struct hash_algo
Currently the hash functions used in RSA are called directly from the sha1
and sha256 libraries. Change the RSA checksum library to use the progressive
hash API's registered with struct hash_algo. This will allow the checksum
library to use the hardware accelerated progressive hash API's once available.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
Removed changes in ls1021aqds.h accidently included in this patch
Changes in v5:
Both tools and uboot use the same code in rsa-checksum.c
Changes in v4:
No changes in this patch. Still under discussion
Changes in v3:
Modified rsa-verify to check for return from checksum function
Changes in v2:
Added generic function hash_calculate. Pass an additional
argument as name of algorithm.
common/image-sig.c| 6 +++---
include/image.h | 5 +++--
include/u-boot/rsa-checksum.h | 17 +++
lib/rsa/rsa-checksum.c| 50 ++-
lib/rsa/rsa-verify.c | 7 +-
5 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c
index 8601eda..2c9f0cd 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -38,7 +38,7 @@ struct checksum_algo checksum_algos[] = {
#if IMAGE_ENABLE_SIGN
EVP_sha1,
#endif
- sha1_calculate,
+ hash_calculate,
padding_sha1_rsa2048,
},
{
@@ -48,7 +48,7 @@ struct checksum_algo checksum_algos[] = {
#if IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa2048,
},
{
@@ -58,7 +58,7 @@ struct checksum_algo checksum_algos[] = {
#if IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa4096,
}
diff --git a/include/image.h b/include/image.h
index ee3afe3..dcbc72f 100644
--- a/include/image.h
+++ b/include/image.h
@@ -927,8 +927,9 @@ struct checksum_algo {
#if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void);
#endif
- void (*calculate)(const struct image_region region[],
- int region_count, uint8_t *checksum);
+ int (*calculate)(const char *name,
+const struct image_region region[],
+int region_count, uint8_t *checksum);
const uint8_t *rsa_padding;
};
diff --git a/include/u-boot/rsa-checksum.h b/include/u-boot/rsa-checksum.h
index c996fb3..3c69d85 100644
--- a/include/u-boot/rsa-checksum.h
+++ b/include/u-boot/rsa-checksum.h
@@ -16,9 +16,18 @@ extern const uint8_t padding_sha256_rsa4096[];
extern const uint8_t padding_sha256_rsa2048[];
extern const uint8_t padding_sha1_rsa2048[];
-void sha256_calculate(const struct image_region region[], int region_count,
- uint8_t *checksum);
-void sha1_calculate(const struct image_region region[], int region_count,
- uint8_t *checksum);
+/**
+ * hash_calculate() - Calculate hash over the data
+ *
+ * @name: Name of algorithm to be used for hash calculation
+ * @region: Array having info of regions over which hash needs to be calculated
+ * @region_count: Number of regions in the region array
+ * @checksum: Buffer contanining the output hash
+ *
+ * @return 0 if OK, 0 if error
+ */
+int hash_calculate(const char *name,
+ const struct image_region region[], int region_count,
+ uint8_t *checksum);
#endif
diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c
index 8d8b59f..68d9d65 100644
--- a/lib/rsa/rsa-checksum.c
+++ b/lib/rsa/rsa-checksum.c
@@ -10,12 +10,13 @@
#include asm/byteorder.h
#include asm/errno.h
#include asm/unaligned.h
+#include hash.h
#else
#include fdt_host.h
-#endif
-#include u-boot/rsa.h
#include u-boot/sha1.h
#include u-boot/sha256.h
+#endif
+#include u-boot/rsa.h
/* PKCS 1.5 paddings as described in the RSA PKCS#1 v2.1 standard. */
@@ -136,28 +137,37 @@ const uint8_t padding_sha256_rsa4096[RSA4096_BYTES -
SHA256_SUM_LEN] = {
0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20
};
-void sha1_calculate(const struct image_region region[], int region_count,
- uint8_t *checksum)
+int hash_calculate(const char *name,
+ const struct image_region region[],
+ int region_count, uint8_t *checksum)
{
- sha1_context ctx;
+ struct hash_algo *algo;
+ int ret = 0;
+ void *ctx;
uint32_t i;
i = 0;
- sha1_starts(ctx);
- for (i = 0; i region_count; i++)
- sha1_update(ctx, region[i].data, region[i].size);
- sha1_finish(ctx, checksum);
-}
+ ret = hash_progressive_lookup_algo(name, algo);
+ if (ret)
+ return ret;
-void sha256_calculate(const struct image_region
[U-Boot] [PATCH 06/10][v6] DM: crypto/fsl - Add Freescale rsa DM driver
Driver added for RSA Modular Exponentiation using Freescale Hardware
Accelerator CAAM. The driver uses UCLASS_MOD_EXP
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v6:
No Changes
Changes in v5:
Reverted mod_exp not to use output length
Changes in v4:
Modified for the changes in op function of rsa class mod_exp
Changes in v3:
Moved to integrate with RSA UCLASS
drivers/crypto/Kconfig| 1 +
drivers/crypto/fsl/Kconfig| 6 +
drivers/crypto/fsl/Makefile | 1 +
drivers/crypto/fsl/fsl_rsa.c | 60 +++
drivers/crypto/fsl/jobdesc.c | 28
drivers/crypto/fsl/jobdesc.h | 5
drivers/crypto/fsl/rsa_caam.h | 28
7 files changed, 129 insertions(+)
create mode 100644 drivers/crypto/fsl/Kconfig
create mode 100644 drivers/crypto/fsl/fsl_rsa.c
create mode 100644 drivers/crypto/fsl/rsa_caam.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e69de29..bd26a2b 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -0,0 +1 @@
+source drivers/crypto/fsl/Kconfig
diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
new file mode 100644
index 000..86b2f2f
--- /dev/null
+++ b/drivers/crypto/fsl/Kconfig
@@ -0,0 +1,6 @@
+config FSL_CAAM
+ bool Freescale Crypto Driver Support
+ help
+ Enables the Freescale's Cryptographic Accelerator and Assurance
+ Module (CAAM), also known as the SEC version 4 (SEC4). The driver uses
+ Job Ring as interface to communicate with CAAM.
diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
index cb13d2e..db3c010 100644
--- a/drivers/crypto/fsl/Makefile
+++ b/drivers/crypto/fsl/Makefile
@@ -8,3 +8,4 @@
obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
+obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
diff --git a/drivers/crypto/fsl/fsl_rsa.c b/drivers/crypto/fsl/fsl_rsa.c
new file mode 100644
index 000..cf1c4c1
--- /dev/null
+++ b/drivers/crypto/fsl/fsl_rsa.c
@@ -0,0 +1,60 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Ruchika Gupta ruchika.gu...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include dm.h
+#include asm/types.h
+#include malloc.h
+#include jobdesc.h
+#include desc.h
+#include jr.h
+#include rsa_caam.h
+#include u-boot/rsa-mod-exp.h
+
+int fsl_mod_exp(struct udevice *dev, const uint8_t *sig, uint32_t sig_len,
+ struct key_prop *prop, uint8_t *out)
+{
+ uint32_t keylen;
+ struct pk_in_params pkin;
+ uint32_t desc[MAX_CAAM_DESCSIZE];
+ int ret;
+
+ /* Length in bytes */
+ keylen = prop-num_bits / 8;
+
+ pkin.a = sig;
+ pkin.a_siz = sig_len;
+ pkin.n = prop-modulus;
+ pkin.n_siz = keylen;
+ pkin.e = prop-public_exponent;
+ pkin.e_siz = prop-exp_len;
+
+ inline_cnstr_jobdesc_pkha_rsaexp(desc, pkin, out, sig_len);
+
+ ret = run_descriptor_jr(desc);
+ if (ret) {
+ debug(%s: RSA failed to verify: %d\n, __func__, ret);
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+static const struct mod_exp_ops fsl_mod_exp_ops = {
+ .mod_exp= fsl_mod_exp,
+};
+
+U_BOOT_DRIVER(fsl_rsa_mod_exp) = {
+ .name = fsl_rsa_mod_exp,
+ .id = UCLASS_MOD_EXP,
+ .ops= fsl_mod_exp_ops,
+};
+
+U_BOOT_DEVICE(fsl_rsa) = {
+ .name = fsl_rsa_mod_exp,
+};
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index 1386bae..cc0dced 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++ b/drivers/crypto/fsl/jobdesc.c
@@ -11,6 +11,7 @@
#include common.h
#include desc_constr.h
#include jobdesc.h
+#include rsa_caam.h
#define KEY_BLOB_SIZE 32
#define MAC_SIZE 16
@@ -123,3 +124,30 @@ void inline_cnstr_jobdesc_rng_instantiation(uint32_t *desc)
append_operation(desc, OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
OP_ALG_RNG4_SK);
}
+
+/* Change key size to bytes form bits in calling function*/
+void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
+ struct pk_in_params *pkin, uint8_t *out,
+ uint32_t out_siz)
+{
+ dma_addr_t dma_addr_e, dma_addr_a, dma_addr_n, dma_addr_out;
+
+ dma_addr_e = virt_to_phys((void *)pkin-e);
+ dma_addr_a = virt_to_phys((void *)pkin-a);
+ dma_addr_n = virt_to_phys((void *)pkin-n);
+ dma_addr_out = virt_to_phys((void *)out);
+
+ init_job_desc(desc, 0);
+ append_key(desc, dma_addr_e, pkin-e_siz, KEY_DEST_PKHA_E | CLASS_1);
+
+ append_fifo_load(desc, dma_addr_a,
+pkin-a_siz, LDST_CLASS_1_CCB | FIFOLD_TYPE_PK_A);
+
+ append_fifo_load(desc, dma_addr_n,
+pkin-n_siz,
[U-Boot] [PATCH 07/10][v6] lib/rsa: Add Kconfig for devices supporting RSA Modular Exponentiation
Kconfig option added for devices which support RSA Verification. 1. RSA_SOFTWARE_EXP Enables driver for supporting RSA Modular Exponentiation in Software 2. RSA_FREESCALE_EXP Enables driver for supporting RSA Modular Exponentiation using Freescale specific driver The above drivers use RSA uclass Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v6: No Changes Changes in v5: No changes Changes in v4: Introduced 2 options when CONFIG_RSA is selected: RSA_SOFTWARE_EXP RSA_FREESCALE_EXP Removed RSA_HW. Changes the name pf RSA_SW to RSA_SOFTWARE_EXP Changes in v3: New patch lib/Kconfig | 7 +-- lib/rsa/Kconfig | 28 2 files changed, 29 insertions(+), 6 deletions(-) create mode 100644 lib/rsa/Kconfig diff --git a/lib/Kconfig b/lib/Kconfig index 79b91b7..a1f30a2 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -27,11 +27,6 @@ config SYS_HZ get_timer() must operate in milliseconds and this option must be set to 1000. -config RSA - bool Use RSA Library - help - RSA support. This enables the RSA algorithm used for FIT image - verification in U-Boot. - See doc/uImage.FIT/signature.txt for more details. +source lib/rsa/Kconfig endmenu diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig new file mode 100644 index 000..4fa79d7 --- /dev/null +++ b/lib/rsa/Kconfig @@ -0,0 +1,28 @@ +config RSA + bool Use RSA Library + select RSA_FREESCALE_EXP if FSL_CAAM + select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP + help + RSA support. This enables the RSA algorithm used for FIT image + verification in U-Boot. + See doc/uImage.FIT/signature.txt for more details. + See doc/uImage.FIT/signature.txt for more details. + +if RSA +config RSA_SOFTWARE_EXP + bool Enable driver for RSA Modular Exponentiation in software + depends on DM RSA + help + Enables driver for modular exponentiation in software. This is a RSA + algorithm used in FIT image verification. It required RSA Key as + input. + See doc/uImage.FIT/signature.txt for more details. + +config RSA_FREESCALE_EXP + bool Enable RSA Modular Exponentiation with FSL crypto accelerator + depends on DM RSA FSL_CAAM + help + Enables driver for RSA modular exponentiation using Freescale cryptographic + accelerator - CAAM. + +endif -- 1.8.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Damien, On 23/01/15 19:03, Damien GOTFROI wrote: Hi, I confirm, my first patch for spl_power_init.c generated DDR errors. And my new (small) patch for spl_power_init.c fixes these errors, it is not my DDR patch. An I can confirm that your smaller patch allows me to boot the G2C1 board. I'll just implement the smaller patch - we can tackle the rest later Thanks for your very helpful experimentation Regards, Graeme Many thanks and best regards, Damien Gotfroi Electronics Engineer GreenWatch S.A. Avenue Lavoisier, 18A B-1300 Wavre Tel. + 32 (0) 10 471 367 dgotf...@greenwatch.be www.greenwatch.be BCE: 0820 144 205 Retrouvez l’actu des thématiques énergétiques sur notre blog Please consider the environment before printing this mail note. « Ce message électronique et ses éventuels fichiers attachés est(sont) destiné(s) à l’usage exclusif de la (les) personne(s) mentionnée(s) comme destinataire. Si vous recevez ce message électronique par erreur, vous n’êtes pas autorisé à utiliser ; dévoiler ; distribuer ; imprimer ou copier tout ou partie de ce message si vous n’en êtes pas le destinataire. GreenWatch décline toute responsabilité pour tout dommage direct ou indirect lié à l’utilisation inappropriée ou frauduleuse de ce message électronique par des personnes non autorisées. En outre, les informations contenues dans ce message électronique sont à caractère exclusivement informatif et GreenWatch ne saurait en garantir l’exactitude ou l’ exhaustivité .Les préjudices occasionnés par l’utilisation d’une information erronée ou incomplète n’entraînent en aucun cas la responsabilité de GreenWatch » -Original Message- From: Graeme Russ [mailto:gr...@tss-engineering.com] Sent: vendredi 23 janvier 2015 05:15 To: Fabio Estevam Cc: U-Boot-Denx; Fabio Estevam; Mårten Wikman; Damien GOTFROI; Stefano Babic; Marek Vašut Subject: Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery Hi Fabio, On 23/01/15 14:49, Fabio Estevam wrote: On Fri, Jan 23, 2015 at 1:27 AM, Graeme Russ gr...@tss-engineering.com wrote: I thought the DDR errors were fixed with Damien's DDR patch. Damien, can you please confirm? His response in the forum was: About the patch posted on January, 6th, you can simply delete it, and empty your recycle bin . It generate DDR errors (I searched a long time in spl_mem_init to find why my DDR was not stable, but it was not a DDR configuration mistake, but a power mistake caused by my patch). Ah - I missed that - my bad. I'll check if his newer patch works. If it does, I'll implement it instead. Best to make these kind of changes one small step at a time :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI
[...] PSCI assumes that the FW is in full control of the registers it's poking. While a lock isn't necessarily bad, I suspect it's going to be very difficult to have that common across all users without the code becoming unmaintainable fast. I'd also hope that for arm64 we wouldn't need it. When/how/why does the kernel to poke these registers? The PMC is what controls power partitions. Some of these partitions are assigned to CPUs, others are assigned to things like SATA, PCIe, display and so on. The problem is that if we manage the CPU power partitions via the firmware, then they will conflict with calls that we need to make from other drivers that need to gate or ungate the partitions for their hardware. As I understand it there's no provision in PSCI to manage non- CPU devices, so this is a problem. Ok. So I think either firmware needs to control everything, in which case we are going to need a new interface (or extend PSCI) or it mustn't control anything, in which case we need custom code in the kernel for SMP. Well, the other alternative would be the lock that we can grab in the powergate API and the PSCI calls. One reason I'm not so keen on a lock is I could imagine you'd need to grab this for CPU_SUSPEND calls (i.e. cpuidle), at which point all CPUs are going to contend for the lock all the time. One thing to bear in mind is that PSCI is only one user of the SMC space. Per SMC calling convention, portions of the SMC ID space are there to be used for other (vendor-specific) purposes. So rather than extending PSCI, a parallel API could be implemented for power control of other devices, and the backend could arbitrate the two without the non-secure OS requiring implementation-specific mutual exclusion. I think this has been brought up internally previously; I'll go and poke around in the area to see if we managed to figure out anything useful. It sounds like what we figured out internally is roughly what I stated above: Allocate some SMC calls in the SIP and/or OEM Service Calls range for vendor-specific device power management, and have the implementation on the secure side (which would do the actual register poking) arbitrate with any other secure-side access to those registers (i.e. CPU power management, which it will already have to arbitrate). Thanks, Mark. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On Fri, Jan 23, 2015 at 02:39:44PM +0100, Michal Simek wrote: On 01/23/2015 12:59 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 10:02:04AM +0100, Michal Simek wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. And we have a _really_ good reason for using FPU instructions, yes? The description for doing that is in the patch but to be honest the biggest problem is that xilinx toolchain has FPU instructions enabled by default. Based on that fpu instructions can be used. For standard xilinx flow FSBL/u-boot - fsbl does that setting. For debug flow TCL + u-boot we are reaching this issue. Maybe the second option can be to disable FPU instructions for u-boot compilation but then the problem is moved to next software which is designed to have FPU instructions enabled. That's why I think it is just better to enable it in u-boot. Siva: Feel free to correct me if my understanding is not correct. And for the record and clarity, we're still not actually using the FPU in U-Boot nor intend to, just enabling normal workflows on these platforms, right? -- 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] Please pull u-boot-sunxi master
Hi Tom,
We've once again build-up a nice collection of patches for sunxi.
Please pull u-boot-sunxi/master into master, highlights:
1) A80 support preparation (non-SPL support is ready, but waiting for the
start.S cleanup)
2) Cleanup sun4i sun7i dram configuration
3) Support for some LCD panels which have a controller which requires some
extra poking
4) Enable OTG support, allowing interaction with u-boot on tablets
5) Support for 8 new boards
The following changes since commit b56f6e2b4e0291efbe1b50f082dec73272ad7ab3:
sunxi: Restore lowlevel_init usage (2015-01-21 10:46:28 -0500)
are available in the git repository at:
http://git.denx.de/u-boot-sunxi.git master
for you to fetch changes up to 4e7c892d15e2aa98086aaacdb979821d011b7db2:
sunxi: Use a common CONFIG_SYS_PROMPT (2015-01-23 15:15:51 +0100)
Aleksei Mamlin (1):
sunxi: Add Marsboard A10 support
Hans de Goede (26):
sunxi: display: Make lcd display clk phase configurable
sunxi: Drop pll6 setting from clock_init_uart
sunxi: Move clock_get_pllX / clock_set_pllX protos to mach specific
headers
sunxi: Rename cpu.h to cpu_sun4i.h
sun9i: Add cpu_sun9i.h with iomem defines
sun9i: Add clock_sun9i.h with ccu register layout for sun9i
sun9i: Add sun9i (A80) clock setup support
sunxi: mmc: Use a realistic timeout when sending a mmc command
sunxi: mmc: Add support for sun9i (A80)
sunxi: axp209: Disable interrupts when intializing the axp209
sunxi: ba10_tv_box_defconfig: Fix USB not working
sunxi: Stop differentiating between 512M and 1G variants of the same board
sunxi: Convert sun4i boards to use auto dram configuration
sunxi: Remove CONFIG_TARGET_FOO for sun4i, sun6i and sun8i boards
sunxi: Add mk802 board / defconfig
sunxi: Add mk802ii board / defconfig
sunxi: Add mk802_a10s board / defconfig
sunxi: video: Use frontend for dma on sun4i to fix memory bandwidth
problems
sunxi: Hookup OTG USB controller support
video: Add support for Hitachi tx18d42vm LVDS LCD panels
sunxi: video: Add support for Hitachi tx18d42vm LVDS LCD panels
sunxi: Add new Chuwi V7 CW0825 board / defconfig
sunxi: Drop qt840a_defconfig
sunxi: Convert sun7i boards to use auto dram configuration
sunxi: video: Make pwm polarity configurable
sunxi: Add Hyundai A7HD support
Ian Campbell (2):
sunxi: Add support for Mele M5.
sunxi: Use a common CONFIG_SYS_PROMPT
Priit Laes (1):
sunxi: Add Gemei G9 (Allwinner A10/sun4i) tablet
Siarhei Siamashka (6):
sunxi: axp221: Add ELDO[1-3] support
include: Add header file with MIPI DSI constants from linux 3.18
video: Add support for SSD2828 (parallel LCD to MIPI bridge)
video: sunxi: Hook up SSD2828 with the sunxi video driver
sun6i: Add LCD display support for MSI Primo81 tablet
video: ssd2828: Allow using 'pclk' as the PLL clock source
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/clock_sun6i.c | 5 +-
arch/arm/cpu/armv7/sunxi/clock_sun9i.c | 68
arch/arm/include/asm/arch-sunxi/clock.h| 6 +-
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 11 +
arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 5 +
arch/arm/include/asm/arch-sunxi/clock_sun9i.h | 139 +++
arch/arm/include/asm/arch-sunxi/cpu.h | 148 +--
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h| 154
arch/arm/include/asm/arch-sunxi/cpu_sun9i.h| 108 +
arch/arm/include/asm/arch-sunxi/display.h | 120 +-
arch/arm/include/asm/arch-sunxi/dram_sun4i.h | 2 +-
arch/arm/include/asm/arch-sunxi/mmc.h | 8 +-
arch/arm/include/asm/arch-sunxi/usbc.h | 2 +
board/sunxi/Kconfig| 132 +++
board/sunxi/MAINTAINERS| 22 +-
board/sunxi/Makefile | 23 +-
board/sunxi/board.c| 26 ++
board/sunxi/dram_a10_olinuxino_l.c | 31 --
board/sunxi/dram_a20_olinuxino_l.c | 31 --
board/sunxi/dram_cubieboard.c | 31 --
board/sunxi/dram_cubieboard2.c | 31 --
board/sunxi/dram_cubietruck.c | 31 --
board/sunxi/dram_linksprite_pcduino3.c | 31 --
board/sunxi/dram_sun4i_360_1024_iow16.c| 31 --
board/sunxi/dram_sun4i_360_1024_iow8.c | 31 --
board/sunxi/dram_sun4i_384_1024_iow8.c | 31 --
board/sunxi/dram_sun4i_408_1024_iow8.c | 31 --
.../{dram_sun4i_360_512.c = dram_sun4i_auto.c}| 16 +-
.../{dram_a20_olinuxino_l2.c = dram_sun5i_auto.c} | 16 +-
board/sunxi/dram_sun7i_384_1024_iow16.c| 31 --
board/sunxi/dram_sun7i_384_512_busw16_iow16.c
[U-Boot] [PATCH] sunxi: Only enable i2c support in the SPL when needed
We do not need i2c support in the SPL when there is no PMIC (some sun4i boards), or when the PMIC is not using i2c such as on sun6i and sun8i. This reduces the SPL size from (e.g.) 21812 to 19260 bytes. Signed-off-by: Hans de Goede hdego...@redhat.com --- include/configs/sunxi-common.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index ad8a6a3..3d69861 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -233,7 +233,10 @@ #define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK /* I2C */ +#if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER #define CONFIG_SPL_I2C_SUPPORT +#endif + #define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_MVTWSI #define CONFIG_SYS_I2C_SPEED 40 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On 01/23/2015 03:12 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 02:39:44PM +0100, Michal Simek wrote: On 01/23/2015 12:59 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 10:02:04AM +0100, Michal Simek wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. And we have a _really_ good reason for using FPU instructions, yes? The description for doing that is in the patch but to be honest the biggest problem is that xilinx toolchain has FPU instructions enabled by default. Based on that fpu instructions can be used. For standard xilinx flow FSBL/u-boot - fsbl does that setting. For debug flow TCL + u-boot we are reaching this issue. Maybe the second option can be to disable FPU instructions for u-boot compilation but then the problem is moved to next software which is designed to have FPU instructions enabled. That's why I think it is just better to enable it in u-boot. Siva: Feel free to correct me if my understanding is not correct. And for the record and clarity, we're still not actually using the FPU in U-Boot nor intend to, just enabling normal workflows on these platforms, right? Yes, correct. M -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/18] dm: i2c: s3c24x0: adjust to dm-i2c api
Hello Simon, On 01/20/2015 04:18 AM, Simon Glass wrote: Hi Przemyslaw, On 9 January 2015 at 01:57, Przemyslaw Marczak p.marc...@samsung.com wrote: Hello Heiko Schocher, On 01/09/2015 07:31 AM, Heiko Schocher wrote: Hello Przemyslaw Marczak, just some nitpick ... [snip] Thank you for the review, I will fix this in the next patchset version. I'd like to apply this to u-boot-dm soon - can you please resend this patch with the nits fixed? I don't have any comments beyond what Heiko says. Also, you probably saw the compatibility layer for I2C which should make it possible for you to run the old PMIC framework with I2C using driver model. It should make it easier to get everything done. It is in u-boot-dm/testing. Regards, Simon I will check this and send the second patch version probably on Monday. Best regards, -- Przemyslaw Marczak Samsung RD Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/26] dm: i2c: Move slave details to child platdata
Hi Masahiro,
On 23 January 2015 at 05:32, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Simon,
On Mon, 19 Jan 2015 20:12:48 -0700
Simon Glass s...@chromium.org wrote:
if (offset_len I2C_MAX_OFFSET_LEN)
return -EINVAL;
@@ -450,13 +448,26 @@ int i2c_post_bind(struct udevice *dev)
return dm_scan_fdt_node(dev, gd-fdt_blob, dev-of_offset, false);
}
+int i2c_child_post_bind(struct udevice *dev)
+{
+ struct dm_i2c_chip *plat = dev_get_parent_platdata(dev);
+
+ if (dev-of_offset == -1)
+ return 0;
+
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset, plat);
+}
+
Add static to i2c_post_bind() and i2c_child_post_bind().
UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name = i2c,
.flags = DM_UC_FLAG_SEQ_ALIAS,
- .per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.post_bind = i2c_post_bind,
.post_probe = i2c_post_probe,
+ .per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
+ .per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
+ .per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),
+ .child_post_bind = i2c_child_post_bind,
};
Now struct dm_i2c_chip is allocated on
both .per_child_auto_alloc_size and .per_child_platdata_auto_alloc_size.
The former is probably unused.
UCLASS_DRIVER(i2c_generic) = {
diff --git a/drivers/i2c/i2c-uniphier-f.c b/drivers/i2c/i2c-uniphier-f.c
index b0d30f7..6707edd 100644
--- a/drivers/i2c/i2c-uniphier-f.c
+++ b/drivers/i2c/i2c-uniphier-f.c
@@ -145,16 +145,6 @@ static int uniphier_fi2c_remove(struct udevice *dev)
return 0;
}
-static int uniphier_fi2c_child_pre_probe(struct udevice *dev)
-{
- struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
-
- if (dev-of_offset == -1)
- return 0;
- return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
-i2c_chip);
-}
-
Currently, i2c_chip_ofdata_to_platdata() is only used in i2c-uclass.c
Perhaps it can become a static function.
Or it might be useful to override something ?
I think it might still be useful to call it from a driver in some
cases. Certainly it is better than having the driver duplicate code.
On the other hand, I hope that the uclass can do this 'default'
processing and the driver can just add to it. We will see.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Only enable i2c support in the SPL when needed
On Fri, 2015-01-23 at 15:50 +0100, Hans de Goede wrote: We do not need i2c support in the SPL when there is no PMIC (some sun4i boards), or when the PMIC is not using i2c such as on sun6i and sun8i. This reduces the SPL size from (e.g.) 21812 to 19260 bytes. Signed-off-by: Hans de Goede hdego...@redhat.com Eventually ought to be expressed via Kconfig, but for now: Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sunxi: Hyundai_A7HD_defconfig fix USB vbus pin config
USB1_VBUS is not used, and USB2_VBUS uses the pin normally used to control USB1_VBUS. Signed-off-by: Hans de Goede hdego...@redhat.com --- configs/Hyundai_A7HD_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/Hyundai_A7HD_defconfig b/configs/Hyundai_A7HD_defconfig index 60eb03e..204640e 100644 --- a/configs/Hyundai_A7HD_defconfig +++ b/configs/Hyundai_A7HD_defconfig @@ -6,7 +6,8 @@ CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER CONFIG_FDTFILE=sun4i-a10-hyundai-a7hd.dtb CONFIG_USB_MUSB_SUNXI=y CONFIG_USB0_VBUS_PIN=PB09 -CONFIG_USB2_VBUS_PIN= +CONFIG_USB1_VBUS_PIN= +CONFIG_USB2_VBUS_PIN=PH6 CONFIG_VIDEO_LCD_MODE=x:1024,y:600,depth:18,pclk_khz:51000,le:45,ri:274,up:22,lo:12,hs:1,vs:1,sync:3,vmode:0 CONFIG_VIDEO_LCD_DCLK_PHASE=1 CONFIG_VIDEO_LCD_POWER=PH2 -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/26] dm: core: Allocate platform data when binding a device
Hi Masahiro, On 23 January 2015 at 02:20, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Simon, On Mon, 19 Jan 2015 20:12:35 -0700 Simon Glass s...@chromium.org wrote: When using allocated platform data, allocate it when we bind the device. This makes it possible to fill in this information before the device is probed. This fits with the platform data model (when not using device tree), since platform data exists at bind-time. Signed-off-by: Simon Glass s...@chromium.org Looks like you have changed your mind to allocate platdata in device_bind() rather than device_probe(). Yes. In fact I think my attempts to avoid this were a little too heroic. Could you explain why you think this should be done? I might have missed something, but your motivation is still unclear to me. I thought one reason is consistency with platform data. But drv-ofdata_to_platdata() is still called from device_probe(), i.e. it is just like zero-filled memory is allocated at the binding stage. Filling it with real device properties is delayed until the device is probed. What is the difference from the before and what does it buy us? Its disadvantage are clear: - We need more malloc memory for devices that may or may not be used. - The boot sequence becomes slower. I want good reasons to compensate these disadvantages. I tried to document the reasoning in the patches, but let me try to expand a bit. Hopefully this can provoke further comments / improvements. The main motivation for me was that buses want to set up the platform data for their children before they are probed. In fact some children may never be probed. For example a SPI bus wants to know the chip select for each of its children. At present we have to hunt around in the device tree to figure out which child is the right one, so we can probe it. Worse, the children's drivers (e.g. cros_ec on a SPI bus) have to be involved in setting themselves up. The device_probe_child() function was my attempt to make this fit better, and it did work, but I was not happy with it. You can see that from my unhappy comments in cros_ec, or SPI flash probe, for example. The new approach makes buses easier to deal with as I hope you can see. The 'bind' step is supposed to set up the entire basic framework of the drivers at start-up. Everything should be visible in the tree (the exception being buses which must be probed at run-time) but nothing should be probed. Now, we are following that approach for buses also. Re the disadvantages: - the per-child platform data for a bus is small, and we need not bind devices which are disabled. So, a board should avoid having a lot of enabled devices which are never used - malloc() is very fast, it is the platform data setup that takes time. I agree this slows things down. But currently it only affects bus children, and only their basic information such as chip select. The use of ofdata_to_platdata() is stil confined to when the device is actually probed. This helps to keep things fast in the common case where we don't need the platform data earlier. I think we can refine this further, but what I have now feels a lot cleaner to me. BTW, you missed to fix the comment in device_probe_child(): /* Allocate private data and platdata if requested */ OK. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 19/26] dm: i2c: Move slave details to child platdata
Hi Simon,
On Mon, 19 Jan 2015 20:12:48 -0700
Simon Glass s...@chromium.org wrote:
if (offset_len I2C_MAX_OFFSET_LEN)
return -EINVAL;
@@ -450,13 +448,26 @@ int i2c_post_bind(struct udevice *dev)
return dm_scan_fdt_node(dev, gd-fdt_blob, dev-of_offset, false);
}
+int i2c_child_post_bind(struct udevice *dev)
+{
+ struct dm_i2c_chip *plat = dev_get_parent_platdata(dev);
+
+ if (dev-of_offset == -1)
+ return 0;
+
+ return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset, plat);
+}
+
Add static to i2c_post_bind() and i2c_child_post_bind().
UCLASS_DRIVER(i2c) = {
.id = UCLASS_I2C,
.name = i2c,
.flags = DM_UC_FLAG_SEQ_ALIAS,
- .per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
.post_bind = i2c_post_bind,
.post_probe = i2c_post_probe,
+ .per_device_auto_alloc_size = sizeof(struct dm_i2c_bus),
+ .per_child_auto_alloc_size = sizeof(struct dm_i2c_chip),
+ .per_child_platdata_auto_alloc_size = sizeof(struct dm_i2c_chip),
+ .child_post_bind = i2c_child_post_bind,
};
Now struct dm_i2c_chip is allocated on
both .per_child_auto_alloc_size and .per_child_platdata_auto_alloc_size.
The former is probably unused.
UCLASS_DRIVER(i2c_generic) = {
diff --git a/drivers/i2c/i2c-uniphier-f.c b/drivers/i2c/i2c-uniphier-f.c
index b0d30f7..6707edd 100644
--- a/drivers/i2c/i2c-uniphier-f.c
+++ b/drivers/i2c/i2c-uniphier-f.c
@@ -145,16 +145,6 @@ static int uniphier_fi2c_remove(struct udevice *dev)
return 0;
}
-static int uniphier_fi2c_child_pre_probe(struct udevice *dev)
-{
- struct dm_i2c_chip *i2c_chip = dev_get_parentdata(dev);
-
- if (dev-of_offset == -1)
- return 0;
- return i2c_chip_ofdata_to_platdata(gd-fdt_blob, dev-of_offset,
-i2c_chip);
-}
-
Currently, i2c_chip_ofdata_to_platdata() is only used in i2c-uclass.c
Perhaps it can become a static function.
Or it might be useful to override something ?
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI
On Fri, Jan 23, 2015 at 10:10:45AM +, Thierry Reding wrote: On Thu, Jan 22, 2015 at 07:20:15PM +, Mark Rutland wrote: On Fri, Jan 16, 2015 at 09:12:59AM +, Thierry Reding wrote: On Thu, Jan 15, 2015 at 07:19:37PM +, Mark Rutland wrote: On Wed, Jan 14, 2015 at 07:57:25AM +, Thierry Reding wrote: On Tue, Jan 13, 2015 at 07:44:50PM +, Ian Campbell wrote: Hi Thierry, I needed to boot my Jetson in NS mode (in order to boot Xen) and was investigating the possibility of PSCI support when I discovered that you had already started on it[0]. Hurrah! I cherry-picked the relevant commit onto u-boot-tegra#master and added a few more patches and now it boots correctly for me, both running Xen (some Xen side patches are needed too) and native Linux. The main things which was needed was to rebase for some recent Kconfig changes relating to virt and nonsec mode and to arrange for the RAM used by the secure code to be reserved in the FDT. I also reserved the RAM using the hardware MC_SECURITY_CFG registers for good measure. Great, those were all things that I had wanted to do but never got around to. I also pushed my tree to gitorious: https://gitorious.org/ijc/u-boot jetson-psci-v1 I would Ack your patch, but I don't think you've posted it and it has no S-o-b so that would seem a bit premature/rude of me. For the same reason I've not actually included it in the series posted (but it is in the gitorious branch). Feel free to take ownership of that patch. I currently don't have the time to work on this and it seems you've made good progress on it. It could probably use some cleanup because there's a bit of debug output still in there. Also... FWIW I think you could drop your stub versions of psci_cpu_off and psci_cpu_suspend (assuming you don't want to implement them) since the common code has stubs. ... I'd think you'd need to implement these so that you can get proper suspend/resume support in the kernel. I've had to disable cpuidle (via #undef CONFIG_PM_SLEEP in arch/arm/mach-tegra/cpuidle-tegra114.c) in the kernel to make that code not powergate CPUs. Ideally I think the kernel would check that it's running with PSCI support and disable the cpuidle driver. Maybe that could be done by introducing a new cpuidle driver that checks for PSCI availability and uses it when present. We have a generic CPUidle driver on arm64 which can use PSCI as a backend; we should try to reuse that. The binding should certainly be identical. Is there any reason that driver needs to be ARM64-specific? I would've thought that there could be a generic PSCI driver that works anywhere. Currently the arm and arm64 arch interfaces are a little different, but with some work the bulk of the code could certainly be made common (in drivers/firmware, perhaps). It looks like the tegra124 dts in mainline doesn't use enable-method in the DT, so a better option might be to fail early in cpuidle-tegra114.c if _any_ enable-method is present. Yes, that sounds like a good plan. The absence of an enable-method would signal that a kernel-native method (if any) should be used. And this reminds me that we still need to find a way to synchronize accesses to the powergate registers between secure firmware and the kernel. Tegra has a set of hardware semaphores, but it seems like those can only be used to synchronize between AVP and CPU, whereas for PSCI we'd need something to synchronize between two CPUs. Do you know of any existing mechanism to perform that type of synchronization? Perhaps an option would be to add some sort of global lock in the kernel which the cpuidle driver can grab before issuing the SMC instruction. PSCI assumes that the FW is in full control of the registers it's poking. While a lock isn't necessarily bad, I suspect it's going to be very difficult to have that common across all users without the code becoming unmaintainable fast. I'd also hope that for arm64 we wouldn't need it. When/how/why does the kernel to poke these registers? The PMC is what controls power partitions. Some of these partitions are assigned to CPUs, others are assigned to things like SATA, PCIe, display and so on. The problem is that if we manage the CPU power partitions via the firmware, then they will conflict with calls that we need to make from other drivers that need to gate or ungate the partitions for their hardware. As I understand it there's no provision in PSCI to manage non- CPU devices, so this is a problem. Ok. So I think either firmware needs to control everything, in
Re: [U-Boot] [PATCH v2 09/26] dm: core: Add a post_bind method for parents
On Mon, 19 Jan 2015 20:12:38 -0700 Simon Glass s...@chromium.org wrote: Allow parent drivers to be called when a new child is bound to them. This allows a bus to set up information it needs for that child. Signed-off-by: Simon Glass s...@chromium.org Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Graeme, On 23/01/2015 09:11, Graeme Russ wrote: Hi Damien, On 23/01/15 19:03, Damien GOTFROI wrote: Hi, I confirm, my first patch for spl_power_init.c generated DDR errors. And my new (small) patch for spl_power_init.c fixes these errors, it is not my DDR patch. An I can confirm that your smaller patch allows me to boot the G2C1 board. I'll just implement the smaller patch - we can tackle the rest later Thanks for your very helpful experimentation Thanks all for digging on this issue ! Graeme, if patch is coming from Damien, it should have also his Signed-off-by (Damien, is it ok for you ?). Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Zynq SoC changes
On Fri, Jan 23, 2015 at 03:33:32PM +0100, Michal Simek wrote: On 01/23/2015 03:12 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 02:39:44PM +0100, Michal Simek wrote: On 01/23/2015 12:59 PM, Tom Rini wrote: On Fri, Jan 23, 2015 at 10:02:04AM +0100, Michal Simek wrote: On 01/23/2015 02:05 AM, Tom Rini wrote: On Wed, Jan 21, 2015 at 10:38:47AM +0100, Michal Simek wrote: Hi Tom, please pull these patches to your tree. I have added there 2 patches for serial. Zynq is only one platform which is using this driver. Thanks, Michal The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368: Prepare v2015.01 (2015-01-12 09:39:08 -0500) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 025216f78e0dacd491908d0d76a3642630cd84dc: serial: Extend structure comments with register offset (2015-01-21 10:36:36 +0100) I can't find a toolchain that doesn't give me something like: arm: + zynq_zc70x +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S: Assembler messages: +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:19: Error: selected processor doe s not support ARM mode `fmrx r1,FPEXC' +(zynq_zc70x) arch/arm/cpu/armv7/zynq/lowlevel_init.S:21: Error: selected processor does not support ARM mode `fmxr FPEXC,r1' +(zynq_zc70x) make[3]: *** [arch/arm/cpu/armv7/zynq/lowlevel_init.o] Error 1 +(zynq_zc70x) make[2]: *** [arch/arm/cpu/armv7/zynq] Error 2 +(zynq_zc70x) make[1]: *** [arch/arm/cpu/armv7] Error 2 +(zynq_zc70x) make: *** [sub-make] Error 2 ok. I see. We have neon instructions enabled by default in xilinx toolchain. I have sent the patch which create and add PLATFORM_RELFLAGS += -mfpu=neon to config.mk. This should solve the problem with compilation. No problem to add this patch as the first in this serial not to break bisectability of the tree. And we have a _really_ good reason for using FPU instructions, yes? The description for doing that is in the patch but to be honest the biggest problem is that xilinx toolchain has FPU instructions enabled by default. Based on that fpu instructions can be used. For standard xilinx flow FSBL/u-boot - fsbl does that setting. For debug flow TCL + u-boot we are reaching this issue. Maybe the second option can be to disable FPU instructions for u-boot compilation but then the problem is moved to next software which is designed to have FPU instructions enabled. That's why I think it is just better to enable it in u-boot. Siva: Feel free to correct me if my understanding is not correct. And for the record and clarity, we're still not actually using the FPU in U-Boot nor intend to, just enabling normal workflows on these platforms, right? Yes, correct. OK, good, waiting for the new PR then, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
