[U-Boot] [PATCH 0/1] mtd: nand: fsl-ifc: Fix handling of bitflips
Hi, this is a resend of the following patch: https://patchwork.ozlabs.org/patch/774424/ It seems like that patch hasn't been merged, yet. However, I stumbled across the same issue. Linux has an equivalent patch already upstream. Furthermore, I've tested the patch on hardware and it seems to work fine. Thanks, Kurt Darwin Dingel (1): mtd: nand: fsl_ifc: Fix handling of bitflips in erased pages drivers/mtd/nand/fsl_ifc_nand.c | 69 +++-- 1 file changed, 39 insertions(+), 30 deletions(-) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] mtd: nand: fsl_ifc: Fix handling of bitflips in erased pages
From: Darwin Dingel
This is a fix made for the fsl_ifc_nand driver on linux kernel by
Pavel Machek and is applied to uboot. It is currently on applied on
linux-mtd.
https://patchwork.kernel.org/patch/9758117/
IFC always raises ECC errors on erased pages. It is only ignored when
the buffer is checked for all 0xFF by is_blank(). The problem is a
single bitflip will cause is_blank() and then mtd_read to fail. The fix
makes use of nand_check_erased_ecc_chunk() to check for empty pages
instead of is_blank(). This also makes sure that reads are made at ECC
page size granularity to get a proper bitflip count. If the number of
bitflips does not exceed the ECC strength, the page is considered empty
and the bitflips will be corrected when data is sent to the higher
layers (e.g. ubi).
Signed-off-by: Darwin Dingel
Cc: Pavel Machek
Cc: Scott Wood
Acked-by: Pavel Machek
[Kurt: Replaced dev_err by printf due to compiler warnings]
Tested-by: Kurt Kanzenbach
Signed-off-by: Kurt Kanzenbach
---
drivers/mtd/nand/fsl_ifc_nand.c | 69 +++--
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index a47226bd2158..29f30d8ccc42 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -242,31 +242,6 @@ static void set_addr(struct mtd_info *mtd, int column, int
page_addr, int oob)
ctrl->index += mtd->writesize;
}
-static int is_blank(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl,
- unsigned int bufnum)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct fsl_ifc_mtd *priv = nand_get_controller_data(chip);
- u8 __iomem *addr = priv->vbase + bufnum * (mtd->writesize * 2);
- u32 __iomem *main = (u32 *)addr;
- u8 __iomem *oob = addr + mtd->writesize;
- int i;
-
- for (i = 0; i < mtd->writesize / 4; i++) {
- if (__raw_readl(&main[i]) != 0x)
- return 0;
- }
-
- for (i = 0; i < chip->ecc.layout->eccbytes; i++) {
- int pos = chip->ecc.layout->eccpos[i];
-
- if (__raw_readb(&oob[pos]) != 0xff)
- return 0;
- }
-
- return 1;
-}
-
/* returns nonzero if entire page is blank */
static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl,
u32 eccstat, unsigned int bufnum)
@@ -331,16 +306,14 @@ static int fsl_ifc_run_command(struct mtd_info *mtd)
if (errors == 15) {
/*
* Uncorrectable error.
-* OK only if the whole page is blank.
+* We'll check for blank pages later.
*
* We disable ECCER reporting due to erratum
* IFC-A002770 -- so report it now if we
* see an uncorrectable error in ECCSTAT.
*/
- if (!is_blank(mtd, ctrl, bufnum))
- ctrl->status |=
- IFC_NAND_EVTER_STAT_ECCER;
- break;
+ ctrl->status |= IFC_NAND_EVTER_STAT_ECCER;
+ continue;
}
mtd->ecc_stats.corrected += errors;
@@ -727,6 +700,39 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct
nand_chip *chip)
return status | NAND_STATUS_WP;
}
+/*
+ * The controller does not check for bitflips in erased pages,
+ * therefore software must check instead.
+ */
+static int
+check_erased_page(struct nand_chip *chip, u8 *buf, struct mtd_info *mtd)
+{
+ u8 *ecc = chip->oob_poi;
+ const int ecc_size = chip->ecc.bytes;
+ const int pkt_size = chip->ecc.size;
+ int i, res, bitflips;
+
+ /* IFC starts ecc bytes at offset 8 in the spare area. */
+ ecc += 8;
+ bitflips = 0;
+ for (i = 0; i < chip->ecc.steps; i++) {
+ res = nand_check_erased_ecc_chunk(buf, pkt_size, ecc, ecc_size,
+ NULL, 0, chip->ecc.strength);
+
+ if (res < 0) {
+ printf("fsl-ifc: NAND Flash ECC Uncorrectable Error\n");
+ mtd->ecc_stats.failed++;
+ } else if (res > 0) {
+ mtd->ecc_stats.corrected += res;
+ }
+ bitflips = max(res, bitflips);
+ buf += pkt_size;
+ ecc += ecc_size;
+ }
+
+ return bitflips;
+}
+
static int fsl_ifc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *buf, int oob_required, int page)
{
@@ -736,6 +742,9 @@ static int fsl_ifc_read_page(str
Re: [U-Boot] [PATCH] SPL: fit signature: don´t strip off signature node and sub nodes from dtb
Patch isn´t needed anymore... Now I add simply the property "u-boot,dm-spl" to my key node in the signature node with fdtput. Thanks. Best regards Johann Neuhauser ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Convert to DM serial
On 01.08.2018 18:34, Marek Vasut wrote: On 08/01/2018 05:42 PM, Simon Goldschmidt wrote: Marek Vasut mailto:ma...@denx.de>> schrieb am Mi., 1. Aug. 2018, 09:35: On 08/01/2018 09:29 AM, Goldschmidt Simon wrote: > > On 30.07.2018 16:04, Marek Vasut wrote: >> On 07/30/2018 04:03 PM, Simon Goldschmidt wrote: >>> >>> On 12.05.2018 22:28, Marek Vasut wrote: Pull the serial port configuration from DT and use DM serial instead of having the serial configuration in two places, DT and board config. [..] While debugging, a more generic question: which drivers are now remaining non-DM for socfpga? Not much I believe, I can't think of anything right now. And am I correct with the assumption that we could get rid of the qts files (other than sdram maybe) by implementing pinctrl and clk drivers as DM drivers? (Not that I would have found documentation about the pin mux hardware cyclone5...) Yes. The pinmux docs are probably not public, it has to do with the iocsr ring programming and that's super-secret for whatever reason. What Altera did on Arria10 is pure trash, they encode registers in DT and are done with it. If you can design something saner, that'd be so nice. As I'm not familiar with pinmux DTS, that might be hard for me, but I might try to get it done somehow (or by someone... :) Could you give me a hint of a platform to take as a good example? I am working on a clock driver for Arria10 now, I might do Gen5 too afterward, since the clock block is similar. That would be cool. You can count on me testing on cyclone5 as much as I can (as much as I have the hardware, that is). The clock DT bindings on the other hand are complete insanity, words fail me. The clock stuff in U-Boot on SoCFPGA right now is a complete disaster too, the way stuff gets added to mach-socfpga is really irritating. But you would still use the existing bindings? How does this stuff get added to U-Boot, by first being added to Linux and the DTS being copied here? I'm looking for a way to control pins from a fit image that includes kernel, dts and fpga because the pins may change depending on the fpga config... DTOs maybe ? Yeah, I thought of that too. The problem I see is that we would need pinmux and clock support for DTS in Linux but we're kind of stuck to 4.9.y for now due to using an RT configuration. Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: exynos4: fix warning of dts
Hi, 2018년 7월 31일 (화) 21:58, Tom Rini 님이 작성: > On Tue, Jul 31, 2018 at 04:12:42PM +0900, Minkyu Kang wrote: > > > remove this warning: avoid_unnecessary_addr_size > > > > Signed-off-by: Minkyu Kang > > --- > > arch/arm/dts/exynos4210-pinctrl-uboot.dtsi | 4 > > arch/arm/dts/exynos4210-universal_c210.dts | 2 -- > > arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi | 4 > > 3 files changed, 10 deletions(-) > > Here and the rest of the series, have you sent the non -uboot.dtsi > portions upstream so that we'll not get them back when we re-sync with > Linux? Thanks! > It will be fine. > -- > Tom > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] common: include always
Hi Philipp > -Original Message- > From: Philipp Tomsich > Sent: jeudi 26 juillet 2018 16:00 > > With the ram-size variable changed to u64, we'll need appropriate macros for > printing u64 values correctly either in 32bit builds (i.e. ILP32 models) or > in 64bit > builds (i.e. LP64 models). Best to make the PRIx64 macro available > everywhere. > > This include inttypes.h from common.h to make the various macros for > formatted printing available to everyone. > > Signed-off-by: Philipp Tomsich > --- > > include/common.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/common.h b/include/common.h index 940161f..9de9145 > 100644 > --- a/include/common.h > +++ b/include/common.h > @@ -30,6 +30,7 @@ typedef volatile unsigned char vu_char; > #include > #include > #include > +#include > #include > #include I think the include should be moved after the line 40 and __STDC_FORMAT_MACROS definition : -/* Bring in printf format macros if inttypes.h is included */ +/* Bring in printf format macros defined in inttypes.h */ #define __STDC_FORMAT_MACROS +#include Regards Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ram: stm32mp1: use PRIx64 macros for printing ram size
Hi Philipp
> -Original Message-
> From: Philipp Tomsich
> Sent: jeudi 26 juillet 2018 16:00
>
> With the recent changes of the underlying types for the ram size, we need to
> adjust the formatting. Use PRIx64 to print the (now) u64 field.
>
> Signed-off-by: Philipp Tomsich
> ---
>
> arch/arm/mach-stm32mp/dram_init.c | 2 +-
> drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/dram_init.c b/arch/arm/mach-
> stm32mp/dram_init.c
> index 7688b3e..e4c6302 100644
> --- a/arch/arm/mach-stm32mp/dram_init.c
> +++ b/arch/arm/mach-stm32mp/dram_init.c
> @@ -25,7 +25,7 @@ int dram_init(void)
> debug("Cannot get RAM size: %d\n", ret);
> return ret;
> }
> - debug("RAM init base=%lx, size=%x\n", ram.base, ram.size);
> + debug("RAM init base=%lx, size=%" PRIx64 "\n", ram.base, ram.size);
>
> gd->ram_size = ram.size;
>
> diff --git a/drivers/ram/stm32mp1/stm32mp1_ram.c
> b/drivers/ram/stm32mp1/stm32mp1_ram.c
> index bd497a3..faf78b2 100644
> --- a/drivers/ram/stm32mp1/stm32mp1_ram.c
> +++ b/drivers/ram/stm32mp1/stm32mp1_ram.c
> @@ -130,7 +130,7 @@ static __maybe_unused int stm32mp1_ddr_setup(struct
> udevice *dev)
>
> /* check memory access for all memory */
> if (config.info.size != priv->info.size) {
> - printf("DDR invalid size : 0x%x, expected 0x%x\n",
> + printf("DDR invalid size : 0x%" PRIx64 ", expected 0x%x\n",
> priv->info.size, config.info.size);
> return -EINVAL;
> }
> --
> 2.1.4
Tested on STM32MP157c EV1 board with debug activated for RAM driver.
The traces are displayed correctly.
Reviewed-by: Patrick Delaunay
Tested-by: Patrick Delaunay
Regard
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] openrd: Once again shrink binary size
On Wed, 1 Aug 2018, 11:18 PM Tom Rini, wrote: > On Wed, Aug 01, 2018 at 08:40:18PM +1200, Chris Packham wrote: > > > On Fri, Jul 27, 2018 at 11:59 PM Tom Rini wrote: > > > > > > With some recent changes to relevant drivers here the openrd board > > > (openrd_client in this case) does not fit within its size constraint. > > > We can however drop the slightly extended baudrate table and then the > > > duplication of mtdparts/mtdids in the default environment. These > > > defaults are set in the environment by the 'mtdparts' command and > > > otherwise referenced throughout the code. > > > > > > Signed-off-by: Tom Rini > > > > We could probably shrink things further by disabling jffs2 and only > > supporting ubifs. Similarly having support for both fat and ext4 is > > taking up much of the image although it may be less desirable to pick > > only one of these since either of those file systems could be on > > removable media. > > Ah, so, did you also see my email marking the platforms as orphaned? If > so, please feel free to pick them up and trim the config down :) > Thanks! > Yep I did. I'm happy to put some effort into trimming them down but I don't have any genuine openrd hardware to test on (I do have some custom kirkwood based boards). I can do some basic things (like disabling jffs2) but I'd be hesitant to do more involved things like converting to devicetree without actual hardware to test on. Hopefully we can find someone with access to the real thing. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki >> wrote: >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini wrote: >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: >> >> >> >>> Hi Tom, >> >>> >> >>> Please pull this PR. >> >>> >> >>> thanks, >> >>> Jagan. >> >>> >> >>> The following changes since commit >> >>> 5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: >> >>> >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) >> >>> >> >>> are available in the Git repository at: >> >>> >> >>> git://git.denx.de/u-boot-sunxi.git master >> >>> >> >>> for you to fetch changes up to 89a897fc4d78e31332e5899e977d8bf3c82abafa: >> >>> >> >>> board: sun50i: h6: Add OrangePi One Plus initial support (2018-07-31 >> >>> 20:50:01 +0530) >> >>> >> >> >> >> For the moment, on hold. pine_h64 doesn't link (see >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet Andre's >> >> changes to save some space on aarch64 will get it to fit in, and I need >> >> to see if I'm ready to apply them. >> > >> > I though of inform the same, but for h6 atf need to use it from >> > mainline here all a64 boards seems failing. I didn't reproduce this >> > manually. >> > >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is non-functional >> >> The cause is obvious. The ATF blob is missing from the environment. >> If TravisCI is only used to test building, maybe we could just put an >> empty bl31.bin there to make it happy. > > Please note that the above is NOT the problem. That's the non-fatal > warning that your resulting binary won't work as there's no bl31.bin. > The problem is: > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in > region `.sram' > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes > +make[2]: *** [spl/u-boot-spl] Error 1 > +make[1]: *** [spl/u-boot-spl] Error 2 > +make: *** [sub-make] Error 2 ie what, I'm able to built manually pine_h64 with gcc-6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] boot partition access at HS200 speed in eMMC
Hi Everyone, After the following patch from JJ, U-boot shifts to a lower speed mode from HS200 when accessing a boot partition. 01298da31d mmc: Change mode when switching to a boot partition I have looked through the JESD84-B51 spec for eMMC card and don't see it say anywhere that boot0 partition cannot be accessed in HS200 modes. In practice, I have seen timeouts sometimes when I try to write to the boot partition in HS200 mode on a dra7xx-evm in U-boot but not consistently (one would expect if such a thing was forbidden by the spec then it wouldn't work at all). Can anyone point to a documentation that says that boot partition cannot be accessed in HS200 mode? Has anyone else observed failures before this patch? I was able to access the boot0 partition in kernel in HS200 mode (log below). Unless there is code to fallback to a lower speed in kernel also (which doesn't seem to be the case from a simple searching of the code), this should prove that boot partitions can be accessed in HS200 speed mode. Here is the log: https://pastebin.ubuntu.com/p/W3SB4N3rfn/ Thanks, Faiz ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ram: stm32_sdram: Adds stm32f746-disco fix for HardFault at booting
Hi Mark
+Vikas
On 08/01/2018 01:08 PM, Mark Olsson wrote:
> - changes ram start address to 0xC000
In the commit header, indicate that this patch is a fix
Indicates also in the commit message that this patch fixes a regression
by adding the commit which brings this regression :
Commit 1473b12ad0b3 ("lib: fdtdec: Update ram_base to store ram start
adddress") blablabla
>
> Signed-off-by: Mark Olsson
> Cc: Vipin Kumar
For information, don't forget to add maintainers in To: by using
get_maintainer script as following:
./scripts/get_maintainer.pl -f include/configs/stm32f746-disco.h
Vikas Manocha (maintainer:STM32F746 DISCOVERY BOARD)
u-boot@lists.denx.de (open list)
> ---
> include/configs/stm32f746-disco.h | 2 ++
> 1 file changed, 2 insertions(+)
> mode change 100644 => 100755 include/configs/stm32f746-disco.h
>
> diff --git a/include/configs/stm32f746-disco.h
> b/include/configs/stm32f746-disco.h
> old mode 100644
> new mode 100755
> index 567e7f2a00..238d4e939f
> --- a/include/configs/stm32f746-disco.h
> +++ b/include/configs/stm32f746-disco.h
> @@ -21,6 +21,8 @@
>* Configuration of the external SDRAM memory
>*/
> #define CONFIG_NR_DRAM_BANKS1
> +#define CONFIG_SYS_RAM_BASE 0xC000
> +#define CONFIG_SYS_SDRAM_BASECONFIG_SYS_RAM_BASE
>
> #define CONFIG_SYS_MAX_FLASH_SECT 8
> #define CONFIG_SYS_MAX_FLASH_BANKS 1
>
Thanks for your patch.
Patrice
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] SUCCESS: Building U-Boot for MIPS64 on Windows7
I was able to successfully Build U-Boot v2018.07 under Windows 7 SP1
(64bit)
- under MinGW64_NT-6.1 ( a.k.a. MSYS2 or MSYS64 )
- using the native host toolchain (with GCC v7.3.0 for x86_64 code
generation on x86_64 CPU)
- using the target toolchain (with GCC v5.3.0 for MIPS code generation
on x86_64 CPU (Sourcery CodeBench Lite 2016.05-8) )
by modifying the function parse_dep_file() defnied in
u-boot-master/scripts/basic/fixdep.c, as illustrated below:
The change was necessary because the command "gcc cc -Wp,-MD,
dependencyfile.o.d..." generates a dependency file containg Windows
style paths like:
C:\src\bin
...instead of the Linux like path, like:
/c/src/bin
static void parse_dep_file(void *map, size_t len)
{
char *m = map;
char *end = m + len;
char *p;
char s[PATH_MAX];
int is_target;
int saw_any_target = 0;
int is_first_dep = 0;
while (m < end) {
/* Skip any "white space" */
while (m < end && (*m == ' ' || *m == '\t' || *m == '\\' || *m == '\r'
|| *m == '\n'))
m++;
/* Skip any "non-white space" */
p = m;
while (p < end && *p != ' ' && *p != '\t' && *p != '\\' && *p != '\r'
&& *p != '\n')
p++;
/* Convert any Windows paths into Cygwin paths, just like "cygpath -u
" would do. */
if( ( (p-m) >=2) && (*(m+1) == ':') && ((*(m+2) == '/') || (*(m+2) ==
'\\')) && (((*m>='A') && (*m<='Z')) || ((*m>='a') && (*m<='z'))) )
{
*(m+1)= (*m) | 0x20; //Convert the drive letter to lowercase and
move it where the colon was
*m = '/'; //Prepend a forward slash
//*(m+2) = '/'; //Make sure a forward slash follows
the drive letter
// Substitute remaining backslashes in the
Windows path, with forward slashes
while (p < end && *p != ' ' && *p != '\t' && *p != '\r' && *p !=
'\n')
{
if(*p == '\\')
*p = '/';
p++;
}
#ifdef FIXDEP_DBG
fprintf(stderr,"FIXDEP: Windows path at %ld= %s\n",
m-(char*)map, m);
#endif
}
/* Is the token we found a target name? */
is_target = (*(p-1) == ':');
/* Don't write any target names into the dependency file */
if (is_target) {
/* The /next/ file is the first dependency */
is_first_dep = 1;
} else if( (p-m) > 0 )
{ /* Save this token/filename */
memcpy(s, m, p-m);
s[p - m] = 0;
/* Ignore certain dependencies */
if (strrcmp(s, "include/generated/autoconf.h") &&
strrcmp(s, "arch/um/include/uml-config.h") &&
strrcmp(s, "include/linux/kconfig.h") &&
strrcmp(s, ".ver")) {
/*
* Do not list the source file as dependency,
* so that kbuild is not confused if a .c file
* is rewritten into .S or vice versa. Storing
* it in source_* is needed for modpost to
* compute srcversions.
*/
if (is_first_dep) {
/*
* If processing the concatenation of
* multiple dependency files, only
* process the first target name, which
* will be the original source name,
* and ignore any other target names,
* which will be intermediate temporary
* files.
*/
if (!saw_any_target) {
saw_any_target = 1;
printf("source_%s := %s\n\n",
target, s);
printf("deps_%s := \\\n",
target);
}
is_first_dep = 0;
} else
printf(" %s \\\n", s);
do_config_file(s);
}
}
/*
* Start searching for
[U-Boot] mmc: different SD SCR read from U-Boot than from Linux
Hi, I bought recently a new µSD card for an embedded system based on u-boot and Linux. Reading the Linux kernel image (4.5MB) takes u-boot 18s (240.2 KiB/s), instead of 0.6s (7.1 MiB/s) with another µSD card (same HW, same µSD structure and content). Both are specified as Class 4 card. While debugging (sd_change_freq in mmc.c), u-boot reads the following value from the SCR register: scr[0]: b5*00* scr[1]: i.e. it considers SD_VERSION_1_0 as mmc->version, so that it skips switching the speed to a higher one. When analyzing the same µSD card on a Linux system, I get: *cat /sys/block/mmcblk0/device/scr* **02*b5* *mmc scr read /sys/block/mmcblk0/device/* * type: 'SD' version: SD 2.00 bus widths: 4bit, 1bit, * i.e. Linux considers it supports version 2.00 of the Physical Spec, and the speed is OK. It appears as u-boot and Linux read/receive different values for the 1st byte of the SCR register from the µSD. Do you have any idea what could be the cause of it? Thanks in advance. Kind regards, -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] bootelf and 64 bit elf application
Hi, I am trying to use bootelf to load a 64-bit elf binary, but it appears to fail. I tried using the hello_world from U-Boot sources as well. My U-Boot is based 2015.01 and I have patches applied for 64elf support, and compiled as a 64 bit U-Boot. Any idea what is need to support bootelf for 64-bit? # file hello_world.bin hello_world.bin: ELF 64-bit LSB executable, version 1 (SYSV), statically linked, not stripped uboot# tftp 0x8030 tsiddharth/hello_world.bin *ethHw_checkPortSpeed setting speed: 5 Using bcmiproc_eth-0 device TFTP from server 10.204.96.200; our IP address is 10.216.67.182; sending through gateway 10.216.79.254 Filename 'tsiddharth/hello_world.bin'. Load address: 0x8030 Loading: # 889.6 KiB/s done Bytes transferred = 68336 (10af0 hex) uboot# bootelf -p 0x8030 <=== I looked at cmd/elf.c and I see that bootelf calls load_elf64_img_phdr() only with “-p” option. Loading phdr 0 to 0x0c10 (794 bytes) Loading phdr 1 to 0x (0 bytes) ## Starting application at 0x0c10 ... "Synchronous Abort" handler, esr 0x86000210 ELR: c10 LR: fff4197c x0 : 0002 x1 : feb3f058 x2 : 0020 x3 : 0001 x4 : 0020 x5 : 015087ba x6 : ffd0 x7 : 0004 x8 : 0063 x9 : 7af38000 x10: feaf7678 x11: fff8c000 x12: 000f x13: fffa18c1 x14: fff99186 x15: fff99180 x16: fffa18c1 x17: fff99175 x18: feaf7e30 x19: 0c10 x20: x21: feb3f058 x22: 0002 x23: 0002 x24: x25: fff912f9 x26: x27: x28: x29: feaf7b00 Resetting CPU ... resetting ... Patches applied - author Bin Meng mailto:bmeng...@gmail.com>> Thu, 12 Apr 2018 10:32:14 +0530 (22:02 -0700) commit 839c4e9c5bb09ac1ef2c129c7082a15b9cbd3a8a elf: Add a very simple ELF64 loader This adds a very simple ELF64 loader via program headers, similar to load_elf_image_phdr() that we already have. author Bin Meng mailto:bmeng...@gmail.com>> Thu, 12 Apr 2018 10:32:13 +0530 (22:02 -0700) commit 2bce3f595d224fc620b07449d47fa2b08151a890 elf: Add ELF64 related structure defines This adds ELF header, program header and section header structure defines for the 64-bit ELF image. Regards Siddharth ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Thu, Aug 02, 2018 at 02:57:01PM +0530, Jagan Teki wrote: > On Wed, Aug 1, 2018 at 6:25 PM, Tom Rini wrote: > > On Wed, Aug 01, 2018 at 08:43:17PM +0800, Chen-Yu Tsai wrote: > >> On Wed, Aug 1, 2018 at 7:47 PM, Jagan Teki > >> wrote: > >> > On Wed, Aug 1, 2018 at 4:43 PM, Tom Rini wrote: > >> >> On Tue, Jul 31, 2018 at 11:41:50PM +0530, Jagan Teki wrote: > >> >> > >> >>> Hi Tom, > >> >>> > >> >>> Please pull this PR. > >> >>> > >> >>> thanks, > >> >>> Jagan. > >> >>> > >> >>> The following changes since commit > >> >>> 5a0007d481c0fcd2d422dd48b2a129dd8e8a272a: > >> >>> > >> >>> Prepare v2017.09-rc1 (2018-07-30 21:47:29 -0400) > >> >>> > >> >>> are available in the Git repository at: > >> >>> > >> >>> git://git.denx.de/u-boot-sunxi.git master > >> >>> > >> >>> for you to fetch changes up to > >> >>> 89a897fc4d78e31332e5899e977d8bf3c82abafa: > >> >>> > >> >>> board: sun50i: h6: Add OrangePi One Plus initial support (2018-07-31 > >> >>> 20:50:01 +0530) > >> >>> > >> >> > >> >> For the moment, on hold. pine_h64 doesn't link (see > >> >> https://travis-ci.org/trini/u-boot/jobs/410579615) but I bet Andre's > >> >> changes to save some space on aarch64 will get it to fit in, and I need > >> >> to see if I'm ready to apply them. > >> > > >> > I though of inform the same, but for h6 atf need to use it from > >> > mainline here all a64 boards seems failing. I didn't reproduce this > >> > manually. > >> > > >> > +WARNING: BL31 file bl31.bin NOT found, resulting binary is > >> > non-functional > >> > >> The cause is obvious. The ATF blob is missing from the environment. > >> If TravisCI is only used to test building, maybe we could just put an > >> empty bl31.bin there to make it happy. > > > > Please note that the above is NOT the problem. That's the non-fatal > > warning that your resulting binary won't work as there's no bl31.bin. > > The problem is: > > +aarch64-linux-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in > > region `.sram' > > +aarch64-linux-ld.bfd: region `.sram' overflowed by 48 bytes > > +make[2]: *** [spl/u-boot-spl] Error 1 > > +make[1]: *** [spl/u-boot-spl] Error 2 > > +make: *** [sub-make] Error 2 > > ie what, I'm able to built manually pine_h64 with gcc-6.3.1 Travis-CI uses gcc-7.3 from kernel.org. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] gpio: xilinx: Add support for using label property
Add support for reading label property from DT and set up bank name
based on that. If label property is not present full device node name is
used.
Signed-off-by: Michal Simek
---
drivers/gpio/xilinx_gpio.c | 14 --
drivers/gpio/zynq_gpio.c | 14 --
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
index cccfa7561739..da50d1634570 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
@@ -224,8 +224,18 @@ static int xilinx_gpio_probe(struct udevice *dev)
{
struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
- uc_priv->bank_name = dev->name;
+ const void *label_ptr;
+ void *label_c;
+ int size;
+
+ label_ptr = dev_read_prop(dev, "label", &size);
+ if (label_ptr) {
+ label_c = calloc(1, size);
+ memcpy(label_c, label_ptr, size);
+ uc_priv->bank_name = label_c;
+ } else {
+ uc_priv->bank_name = dev->name;
+ }
uc_priv->gpio_count = platdata->bank_max[0] + platdata->bank_max[1];
diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
index 6fbaafb3fa3c..aa8d51e2f709 100644
--- a/drivers/gpio/zynq_gpio.c
+++ b/drivers/gpio/zynq_gpio.c
@@ -336,8 +336,18 @@ static int zynq_gpio_probe(struct udevice *dev)
{
struct zynq_gpio_platdata *platdata = dev_get_platdata(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
- uc_priv->bank_name = dev->name;
+ const void *label_ptr;
+ void *label_c;
+ int size;
+
+ label_ptr = dev_read_prop(dev, "label", &size);
+ if (label_ptr) {
+ label_c = calloc(1, size);
+ memcpy(label_c, label_ptr, size);
+ uc_priv->bank_name = label_c;
+ } else {
+ uc_priv->bank_name = dev->name;
+ }
if (platdata->p_data)
uc_priv->gpio_count = platdata->p_data->ngpio;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
On 1.8.2018 20:23, Stefan Herbrechtsmeier wrote: > Am 30.07.2018 um 10:00 schrieb Michal Simek: >> On 27.7.2018 11:14, Stefan Herbrechtsmeier wrote: >>> Am 27.07.2018 um 08:42 schrieb Michal Simek: On 26.7.2018 22:04, Stefan Herbrechtsmeier wrote: > Am 26.07.2018 um 10:22 schrieb Michal Simek: >> On 25.7.2018 21:17, Stefan Herbrechtsmeier wrote: >>> Am 25.07.2018 um 08:07 schrieb Michal Simek: On 24.7.2018 21:39, Stefan Herbrechtsmeier wrote: > Am 24.07.2018 um 10:37 schrieb Michal Simek: >> On 23.7.2018 20:29, Stefan Herbrechtsmeier wrote: >>> Am 23.07.2018 um 11:08 schrieb Michal Simek: On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote: > Am 12.07.2018 um 16:04 schrieb Michal Simek: >> There should be proper bank name setup to distiguish between >> different >> gpio drivers. Use dev->name for it. >> >> Signed-off-by: Michal Simek >> --- >> >> drivers/gpio/zynq_gpio.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpio/zynq_gpio.c >> b/drivers/gpio/zynq_gpio.c >> index 26f69b1a713f..f793ee5754a8 100644 >> --- a/drivers/gpio/zynq_gpio.c >> +++ b/drivers/gpio/zynq_gpio.c >> @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice >> *dev) >> struct zynq_gpio_privdata *priv = >> dev_get_priv(dev); >> struct gpio_dev_priv *uc_priv = >> dev_get_uclass_priv(dev); >> + uc_priv->bank_name = dev->name; >> + >> if (priv->p_data) >> uc_priv->gpio_count = priv->p_data->ngpio; >> > Does this not lead to ugly names because the gpio number is > append to > the bank_name? Have you check the "gpio status -a" output? Yes I was checking it. Names are composed together but also just numbers works as before. gpio@ff0a0: input: 0 [ ] gpio@ff0a1: input: 0 [ ] gpio@ff0a2: input: 0 [ ] gpio@ff0a3: input: 0 [ ] gpio@ff0a4: input: 0 [ ] gpio@ff0a5: input: 0 [ ] gpio@ff0a6: input: 0 [ ] gpio@ff0a7: input: 0 [ ] gpio@ff0a8: input: 0 [ ] gpio@ff0a9: input: 0 [ ] >>> Do you think that this are meaningful names? It isn't >>> possible to >>> separate the device and pin number as well as it mix hex and >>> decimal >>> numbers. >>> If you know better way how to setup a bank name please let me know but I need to distinguish ps gpio from pl one and for pl we need to know the address. >>> I know the use case. >>> >>> A lot of drivers use the bank_name from the device tree, some >>> drivers >>> append an underscore to the bank name and others add the >>> req_seq of >>> the >>> device to an alphabetic character. >>> > Other drivers use the gpio-bank-name from the device tree. I can't see this property inside Linux kernel. If this has been reviewed by dt guys please let me know. >>> This property is only used by u-boot. I think it isn't needed >>> by the >>> Linux kernel. >> I am happy to use consistent solution but what's that? > Consistent solution between what? all drivers. Name should be composed consistently among all drivers. It means drivers shouldn't add additional "_" in driver code for example. >> Mixing name with hex and int is not nice but adding "_" or >> something >> else is just a pain in driver code. If this is done in core I am >> fine >> with that but adding this code to all drivers don't look like >> generic >> solution at all. > Normally the bank name is an alphabetic character or string. > Maybe we > could add the device name to the gpio_lookup_name function and > add an > additional optional device name parameter to the gpio command. > >> Using additional u-boot property is not good too. >> >> I have mentioned in "gpio: xilinx: Convert driver to DM" >> (sha1:10441ec9224d0d269dc512819a32c0785a6338d3) >> that uc-priv->name is completely unused. Maybe this should be >> dev->name >> and bank_name should be really used for banks. > Isn't the uc-priv->name used for t
Re: [U-Boot] [PATCH 1/1] arm: zynq: Fix device tree for Avnet Picozed boards
Hi Andreas,
On 1.8.2018 00:00, Andreas Galauner wrote:
> This change adds the necessary /chosen/stdout-path to the device tree
> for the Avnet Picozed boards. This node is mandatory for the SPL. Without
> it the board resets in a loop without any output. The change also adds
> the USB, QSPI and Ethernet MAC nodes of the corresponding devices present
> on the board.
>
> Signed-off-by: Andreas Galauner
> ---
> arch/arm/dts/zynq-picozed.dts | 40 +--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/zynq-picozed.dts b/arch/arm/dts/zynq-picozed.dts
> index dea6a422c3..db5bb8a6fe 100644
> --- a/arch/arm/dts/zynq-picozed.dts
> +++ b/arch/arm/dts/zynq-picozed.dts
> @@ -14,13 +14,33 @@
> aliases {
> serial0 = &uart1;
> spi0 = &qspi;
> - mmc0 = &sdhci1;
> + mmc0 = &sdhci0;
> + mmc1 = &sdhci1;
> };
>
> memory@0 {
> device_type = "memory";
> reg = <0 0x4000>;
> };
> +
> + chosen {
> + bootargs = "earlyprintk";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <>;
> +};
> +
> +&qspi {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> };
>
> &uart1 {
> @@ -28,7 +48,17 @@
> status = "okay";
> };
>
> -&qspi {
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> u-boot,dm-pre-reloc;
> status = "okay";
> };
> @@ -37,3 +67,9 @@
> u-boot,dm-pre-reloc;
> status = "okay";
> };
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> +};
>
We have been discussing this topic some months ago here
https://lists.denx.de/pipermail/u-boot/2018-May/327267.html
This is a SoM. You need to do it differently because you need to
describe carrier board and then include SoM dtsi.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ram: stm32_sdram: Adds stm32f746-disco fix for HardFault at booting
Hi again Mark ;-)
I dig into this issue and i think a better fix must be done directly
into the board/st/stm32f746-disco/stm32f746-disco.c.
At the same occasion, some cleaning can be done using last fdtdec_xxx() API.
I will submit a patch for that which fix the issue you saw.
Thanks
Patrice
On 08/02/2018 12:39 PM, Patrice CHOTARD wrote:
> Hi Mark
>
> +Vikas
>
> On 08/01/2018 01:08 PM, Mark Olsson wrote:
>> - changes ram start address to 0xC000
>
> In the commit header, indicate that this patch is a fix
>
> Indicates also in the commit message that this patch fixes a regression
> by adding the commit which brings this regression :
>
> Commit 1473b12ad0b3 ("lib: fdtdec: Update ram_base to store ram start
> adddress") blablabla
>
>
>>
>> Signed-off-by: Mark Olsson
>> Cc: Vipin Kumar
>
> For information, don't forget to add maintainers in To: by using
> get_maintainer script as following:
>
> ./scripts/get_maintainer.pl -f include/configs/stm32f746-disco.h
> Vikas Manocha (maintainer:STM32F746 DISCOVERY BOARD)
> u-boot@lists.denx.de (open list)
>
>> ---
>>include/configs/stm32f746-disco.h | 2 ++
>>1 file changed, 2 insertions(+)
>>mode change 100644 => 100755 include/configs/stm32f746-disco.h
>>
>> diff --git a/include/configs/stm32f746-disco.h
>> b/include/configs/stm32f746-disco.h
>> old mode 100644
>> new mode 100755
>> index 567e7f2a00..238d4e939f
>> --- a/include/configs/stm32f746-disco.h
>> +++ b/include/configs/stm32f746-disco.h
>> @@ -21,6 +21,8 @@
>> * Configuration of the external SDRAM memory
>> */
>>#define CONFIG_NR_DRAM_BANKS 1
>> +#define CONFIG_SYS_RAM_BASE 0xC000
>> +#define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_RAM_BASE
>>
>>#define CONFIG_SYS_MAX_FLASH_SECT 8
>>#define CONFIG_SYS_MAX_FLASH_BANKS1
>>
>
>
> Thanks for your patch.
>
> Patrice
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: don't allocate unusable RAM
Hi, On 1 August 2018 at 10:17, Stephen Warren wrote: > On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote: >> >> On 07/31/2018 09:44 PM, Stephen Warren wrote: >>> >>> From: Stephen Warren >>> >>> Some boards define a maximum usable RAM top that's more restrictive than >>> the ranges defined by U-Boot's memory bank definitions[1]. In this case, >>> the unusable RAM isn't mapped in the page tables, and so the EFI code >>> must >>> not attempt to allocate RAM from outside the usable regions. Fix >>> efi_find_free_memory() to detect when max_addr is unconstrained or out of >>> range, and substitue a valid value. >>> >> >> In this case the board has to call efi_add_memory_map() to mark the >> reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the >> memory region as reserved in the device tree (see efi_carve_out_dt_rsv()). >> >> Please, check if the tegra boards with which you had problems do so. > > > I don't think this makes sense; memory should be managed the same way within > U-Boot no matter which part of U-Boot is consuming that memory. Memory > regions are currently represented by the content of the memory bank > definitions and gd->ram_top. Having different parts of the code define legal > RAM usage in different ways is horribly inconsistent. > > At this point, I think the best thing is to revert aa909462d018 "efi_loader: > efi_allocate_pages is too restrictive" since it causes a regression on > Jetson TX1, and we can work out the correct way to fix all this once the > system is working again. That seems OK to me, since I don't think that patch actually fixed anything...? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/13] misc: Sort Makefile entries
On 31 July 2018 at 04:01, Mario Six wrote: > Makefile entries should be sorted. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > drivers/misc/Makefile | 60 > +++ > 1 file changed, 32 insertions(+), 28 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] test: regmap: Add test for regmap_{set, get}
On 31 July 2018 at 04:01, Mario Six wrote:
> Add test for regmap_{set,get} functions.
>
> Signed-off-by: Mario Six
> ---
>
> v2 -> v3:
> New in v3
>
> ---
> test/dm/regmap.c | 28
> 1 file changed, 28 insertions(+)
>
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] stm32f7: board: Fix memory init
Commit 1473b12ad0b3 ("lib: fdtdec: Update ram_base to store ram start
adddress") brings regression on STM32F7 which can't boot.
Use fdtdec_setup_mem_size_base() to setup memory base and size.
Use fdtdec_setup_memory_banksize() to setup memory bank base and size.
Reported-by: Mark Olsson
Signed-off-by: Patrice Chotard
Cc: Mark Olsson
---
board/st/stm32f746-disco/stm32f746-disco.c | 31 --
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/board/st/stm32f746-disco/stm32f746-disco.c
b/board/st/stm32f746-disco/stm32f746-disco.c
index e21cfc6e4955..a997e1825abf 100644
--- a/board/st/stm32f746-disco/stm32f746-disco.c
+++ b/board/st/stm32f746-disco/stm32f746-disco.c
@@ -21,23 +21,9 @@
DECLARE_GLOBAL_DATA_PTR;
-int get_memory_base_size(fdt_addr_t *mr_base, fdt_addr_t *mr_size)
-{
- int mr_node;
-
- mr_node = fdt_path_offset(gd->fdt_blob, "/memory");
- if (mr_node < 0)
- return mr_node;
- *mr_base = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, mr_node,
- "reg", 0, mr_size, false);
- debug("mr_base = %lx, mr_size= %lx\n", *mr_base, *mr_size);
-
- return 0;
-}
int dram_init(void)
{
- int rv;
- fdt_addr_t mr_base, mr_size;
+ int rv = 0;
#ifndef CONFIG_SUPPORT_SPL
struct udevice *dev;
@@ -48,24 +34,15 @@ int dram_init(void)
}
#endif
- rv = get_memory_base_size(&mr_base, &mr_size);
- if (rv)
- return rv;
- gd->ram_size = mr_size;
- gd->ram_top = mr_base;
+ if (fdtdec_setup_mem_size_base() != 0)
+ rv = -EINVAL;
return rv;
}
int dram_init_banksize(void)
{
- fdt_addr_t mr_base, mr_size;
- get_memory_base_size(&mr_base, &mr_size);
- /*
-* Fill in global info with description of SRAM configuration
-*/
- gd->bd->bi_dram[0].start = mr_base;
- gd->bd->bi_dram[0].size = mr_size;
+ fdtdec_setup_memory_banksize();
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/13] regmap: Add raw read/write functions
Hi Mario,
On 31 July 2018 at 04:01, Mario Six wrote:
> The regmap functions currently assume that all register map accesses
> have a data width of 32 bits, but there are maps that have different
> widths.
>
> To rectify this, implement the regmap_raw_read and regmap_raw_write
> functions from the Linux kernel API that specify the width of a desired
> read or write operation on a regmap.
>
> Implement the regmap_read and regmap_write functions using these raw
> functions in a backwards-compatible manner.
>
> Signed-off-by: Mario Six
> ---
>
> v2 -> v3:
> * Implement the "raw" functions from Linux instead of adding a size
> parameter to the regmap_{read,write} functions
> * Fixed style violation
> * Improved error handling
>
> v1 -> v2:
> New in v2
>
> ---
> drivers/core/regmap.c | 54
> ---
> include/regmap.h | 40 ++
> 2 files changed, 87 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 3488361ee14..83ca19a08a4 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -188,22 +188,62 @@ int regmap_uninit(struct regmap *map)
> return 0;
> }
>
> +int regmap_raw_read(struct regmap *map, uint offset, void *valp, size_t
> val_len)
> +{
> + void *ptr;
> +
> + ptr = map_physmem(map->ranges[0] + offset, val_len, MAP_NOCACHE);
> +
> + switch (val_len) {
> + case REGMAP_SIZE_8:
> + *((u8 *)valp) = in_8((u8 *)ptr);
> + break;
> + case REGMAP_SIZE_16:
> + *((u16 *)valp) = in_le16((u16 *)ptr);
> + break;
> + case REGMAP_SIZE_32:
> + *((u32 *)valp) = in_le32((u32 *)ptr);
> + break;
> + default:
> + debug("%s: regmap size %u unknown\n", __func__, val_len);
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> int regmap_read(struct regmap *map, uint offset, uint *valp)
> {
> - u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
> + return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
> +}
>
> - *valp = le32_to_cpu(readl(ptr));
> +int regmap_raw_write(struct regmap *map, uint offset, const void *val,
> +size_t val_len)
> +{
> + void *ptr;
> +
> + ptr = map_physmem(map->ranges[0] + offset, val_len, MAP_NOCACHE);
> +
> + switch (val_len) {
> + case REGMAP_SIZE_8:
> + out_8((u8 *)ptr, *((u8 *)val));
> + break;
> + case REGMAP_SIZE_16:
> + out_le16((u16 *)ptr, *((u16 *)val));
> + break;
> + case REGMAP_SIZE_32:
> + out_le32((u32 *)ptr, *((u32 *)val));
> + break;
> + default:
> + debug("%s: regmap size %u unknown\n", __func__, val_len);
> + return -EINVAL;
> + }
>
> return 0;
> }
>
> int regmap_write(struct regmap *map, uint offset, uint val)
> {
> - u32 *ptr = map_physmem(map->ranges[0].start + offset, 4, MAP_NOCACHE);
> -
> - writel(cpu_to_le32(val), ptr);
> -
> - return 0;
> + return regmap_raw_write(map, offset, &val, REGMAP_SIZE_32);
> }
>
> int regmap_update_bits(struct regmap *map, uint offset, uint mask, uint val)
> diff --git a/include/regmap.h b/include/regmap.h
> index 32f75e06f59..352851c715b 100644
> --- a/include/regmap.h
> +++ b/include/regmap.h
> @@ -8,6 +8,19 @@
> #define __REGMAP_H
>
> /**
> + * enum regmap_size_t - Access sizes for fpgamap reads and writes
> + *
> + * @REGMAP_SIZE_8: 8-bit read/write access size
> + * @REGMAP_SIZE_16: 16-bit read/write access size
> + * @REGMAP_SIZE_32: 32-bit read/write access size
> + */
> +enum regmap_size_t {
> + REGMAP_SIZE_8 = 1,
> + REGMAP_SIZE_16 = 2,
> + REGMAP_SIZE_32 = 4,
> +};
> +
> +/**
> * struct regmap_range - a register map range
> *
> * @start: Start address
> @@ -57,6 +70,33 @@ int regmap_write(struct regmap *map, uint offset, uint
> val);
> */
> int regmap_read(struct regmap *map, uint offset, uint *valp);
>
> +/**
> + * regmap_raw_write() - Write a value of specified length to a regmap
> + *
Please explain the meaning of 'raw' here. Also please update the
non-raw ones to explain that meaning.
> + * @map: Regmap to write to
> + * @offset:Offset in the regmap to write to
> + * @val: Value to write to the regmap at the specified offset
> + * @val_len: Length of the data to be written to the regmap
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +int regmap_raw_write(struct regmap *map, uint offset, const void *val,
> +size_t val_len);
> +
> +/**
> + * regmap_raw_read() - Read a value of specified length from a regmap
> + *
Same here
> + * @map: Regmap to read from
> + * @offset:Offset in the regmap to read from
> + * @valp: Pointer to the buffer to receive the data read from the r
Re: [U-Boot] [PATCH] efi_loader: don't allocate unusable RAM
On 08/02/2018 02:15 PM, Simon Glass wrote: Hi, On 1 August 2018 at 10:17, Stephen Warren wrote: On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote: On 07/31/2018 09:44 PM, Stephen Warren wrote: From: Stephen Warren Some boards define a maximum usable RAM top that's more restrictive than the ranges defined by U-Boot's memory bank definitions[1]. In this case, the unusable RAM isn't mapped in the page tables, and so the EFI code must not attempt to allocate RAM from outside the usable regions. Fix efi_find_free_memory() to detect when max_addr is unconstrained or out of range, and substitue a valid value. In this case the board has to call efi_add_memory_map() to mark the reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the memory region as reserved in the device tree (see efi_carve_out_dt_rsv()). Please, check if the tegra boards with which you had problems do so. I don't think this makes sense; memory should be managed the same way within U-Boot no matter which part of U-Boot is consuming that memory. Memory regions are currently represented by the content of the memory bank definitions and gd->ram_top. Having different parts of the code define legal RAM usage in different ways is horribly inconsistent. At this point, I think the best thing is to revert aa909462d018 "efi_loader: efi_allocate_pages is too restrictive" since it causes a regression on Jetson TX1, and we can work out the correct way to fix all this once the system is working again. That seems OK to me, since I don't think that patch actually fixed anything...? I think I ran into a problem with the limitation to start_addr_sp in some other case as well, but I can't remember where. So yes, reverting it works for me for now if that gets us forward on the path to make efi_loader work for real on TX1 ;) Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/13] regmap: Introduce init_range
On 31 July 2018 at 04:01, Mario Six wrote:
> Both fdtdec_get_addr_size_fixed and of_address_to_resource can fail with
> an error, which is not currently checked during regmap initialization.
>
> Since the indentation depth is already quite deep, extract a new
> 'init_range' method to do the initialization.
>
> Signed-off-by: Mario Six
> ---
>
> v2 -> v3:
> New in v3
>
> ---
> drivers/core/regmap.c | 68
> ++-
> 1 file changed, 56 insertions(+), 12 deletions(-)
Reviewed-by: Simon Glass
nit below
>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 4ebab233490..51d9cadc510 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -56,6 +56,58 @@ int regmap_init_mem_platdata(struct udevice *dev,
> fdt_val_t *reg, int count,
> return 0;
> }
> #else
> +/**
> + * init_range() - Initialize a single range of a regmap
> + * @node: Device node that will use the map in question
> + * @range:Pointer to a regmap_range structure that will be initialized
> + * @addr_len: The length of the addr parts of the reg property
> + * @size_len: The length of the size parts of the reg property
> + * @index:The index of the range to initialize
> + *
> + * This function will read the necessary 'reg' information from the device
> tree
> + * (the 'addr' part, and the 'length' part), and initialize the range in
> + * quesion.
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +static int init_range(ofnode node, struct regmap_range *range, int addr_len,
> + int size_len, int index)
> +{
> + fdt_size_t sz;
> + struct resource r;
> +
> + if (of_live_active()) {
> + int ret;
> +
> + ret = of_address_to_resource(ofnode_to_np(node),
> +index, &r);
> + if (ret) {
> + debug("%s: Could not read resource of range %d (ret =
> %d)\n",
> + ofnode_get_name(node), index, ret);
> + return ret;
> + }
> +
> + range->start = r.start;
> + range->size = r.end - r.start + 1;
> +
> + return 0;
> + }
I wonder about having an else here? That makes it clear that this
function has two implementations.
> +
> + range->start = fdtdec_get_addr_size_fixed(gd->fdt_blob,
> + ofnode_to_offset(node),
> + "reg", index, addr_len,
> + size_len, &sz, true);
> + if (range->start == FDT_ADDR_T_NONE) {
> + debug("%s: Could not read start of range %d\n",
> + ofnode_get_name(node), index);
> + return -EINVAL;
> + }
> +
> + range->size = sz;
> +
> + return 0;
> +}
> +
> int regmap_init_mem(ofnode node, struct regmap **mapp)
> {
> struct regmap_range *range;
> @@ -64,7 +116,6 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
> int addr_len, size_len, both_len;
> int len;
> int index;
> - struct resource r;
>
> addr_len = ofnode_read_simple_addr_cells(ofnode_get_parent(node));
> if (addr_len < 0) {
> @@ -101,17 +152,10 @@ int regmap_init_mem(ofnode node, struct regmap **mapp)
>
> for (range = map->ranges, index = 0; count > 0;
> count--, range++, index++) {
> - fdt_size_t sz;
> - if (of_live_active()) {
> - of_address_to_resource(ofnode_to_np(node), index, &r);
> - range->start = r.start;
> - range->size = r.end - r.start + 1;
> - } else {
> - range->start =
> fdtdec_get_addr_size_fixed(gd->fdt_blob,
> - ofnode_to_offset(node), "reg", index,
> - addr_len, size_len, &sz, true);
> - range->size = sz;
> - }
> + int ret = init_range(node, range, addr_len, size_len, index);
> +
> + if (ret)
> + return ret;
> }
>
> *mapp = map;
> --
> 2.11.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/13] regmap: Add error output
On 31 July 2018 at 04:01, Mario Six wrote: > Add some debug output in cases where the initialization of a regmap > fails. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > drivers/core/regmap.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Is there a omap_gpmc.c maintainer?
Is there a maintainer for the omap_gpmc driver? Only the u-boot open list is returned when queried. ./scripts/get_maintainer.pl ./drivers/mtd/nand/omap_gpmc.c u-boot@lists.denx.de (open list) I was thinking about (but not promising) adding some device tree support to enable fetching GPMC timings from device tree and configuring and/or re-configuring the GPMC timings based on DT contents. I wanted to shoot my ideas off someone else and/or not duplicate any work, but I am not volunteering to take over this driver. Mostly because the GPMC timings setup for NAND and NOR are fairly generic for NAND/NOR, and it would be nice to optimize them a bit to see if we could get a little faster performance when loading ramdisks or kernels via GPMC. Some peripherals (like ethernet) use the GPMC bus, and we have some hard-coded values, but this kind of information can be fetched from device trees and may also yield a little bit of optimization. adam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Hi Johann,
On 31 July 2018 at 02:22, Johann Neuhauser wrote:
> Dear U-Boot devs,
>
> I've setup verified boot on a imx6 board and want to protect my device
> against the "mix and match" attacks mentioned in
> "doc/uImage.FIT/signature.txt".
> That's why I have only implemented signed configurations and no signed images
> as in doc/uImage.FIT/signed-configs.its.
> My public key in my embedded fdt has the property required = "conf";
>
> Booting a signed config with "bootm ${loadaddr}#conf@1" and an embedded
> public key required for configurations does work as expected and do fail to
> boot if I modify the config, image, hash, signature and so on.
>
> If I boot any fit image(signed and unsigned) for example with "bootm
> ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot
> every image combination without signature verification although a signature
> is enforced for a configuration.
>
> Is this the expected behavior?
>
> I thought if I had set the public key in in the embedded fdt as required for
> configurations, bootm does only boot signed configurations and no subimages
> directly...
I don't think there is any restriction on that at the moment. You are
explicitly asking to boot particular images rather than a config. So I
suppose it would be odd if U-Boot tried to enforce a config. Are you
thinking it should try to find a config that has those images in it?
But why not just specify the config to bootm?
Bear in mind also that users don't have access to the U-Boot command
line when using verified boot, so they wouldn't be able to type this
command.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] gpio: xilinx: Not read output values via regs
Reading registers for finding out output value is not working because
input value is read instead in case of tristate.
Reported-by: Stefan Herbrechtsmeier
Signed-off-by: Michal Simek
---
Changes in v2:
- Rebased on the top of reviewed patches
- Change logic in xilinx_gpio_get_value()
drivers/gpio/xilinx_gpio.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/xilinx_gpio.c b/drivers/gpio/xilinx_gpio.c
index da50d1634570..4b4bf651642c 100644
--- a/drivers/gpio/xilinx_gpio.c
+++ b/drivers/gpio/xilinx_gpio.c
@@ -25,6 +25,11 @@ struct xilinx_gpio_platdata {
int bank_max[XILINX_GPIO_MAX_BANK];
int bank_input[XILINX_GPIO_MAX_BANK];
int bank_output[XILINX_GPIO_MAX_BANK];
+ u32 dout_default[XILINX_GPIO_MAX_BANK];
+};
+
+struct xilinx_gpio_privdata {
+ u32 output_val[XILINX_GPIO_MAX_BANK];
};
static int xilinx_gpio_get_bank_pin(unsigned offset, u32 *bank_num,
@@ -54,6 +59,7 @@ static int xilinx_gpio_set_value(struct udevice *dev,
unsigned offset,
int value)
{
struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
int val, ret;
u32 bank, pin;
@@ -61,10 +67,10 @@ static int xilinx_gpio_set_value(struct udevice *dev,
unsigned offset,
if (ret)
return ret;
- val = readl(&platdata->regs->gpiodata + bank * 2);
+ val = priv->output_val[bank];
- debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x\n",
- __func__, (ulong)platdata->regs, value, offset, bank, pin);
+ debug("%s: regs: %lx, value: %x, gpio: %x, bank %x, pin %x, out %x\n",
+ __func__, (ulong)platdata->regs, value, offset, bank, pin, val);
if (value)
val = val | (1 << pin);
@@ -73,12 +79,15 @@ static int xilinx_gpio_set_value(struct udevice *dev,
unsigned offset,
writel(val, &platdata->regs->gpiodata + bank * 2);
+ priv->output_val[bank] = val;
+
return val;
};
static int xilinx_gpio_get_value(struct udevice *dev, unsigned offset)
{
struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
int val, ret;
u32 bank, pin;
@@ -89,7 +98,14 @@ static int xilinx_gpio_get_value(struct udevice *dev,
unsigned offset)
debug("%s: regs: %lx, gpio: %x, bank %x, pin %x\n", __func__,
(ulong)platdata->regs, offset, bank, pin);
- val = readl(&platdata->regs->gpiodata + bank * 2);
+ if (platdata->bank_output[bank]) {
+ debug("%s: Read saved output value\n", __func__);
+ val = priv->output_val[bank];
+ } else {
+ debug("%s: Read input value from reg\n", __func__);
+ val = readl(&platdata->regs->gpiodata + bank * 2);
+ }
+
val = !!(val & (1 << pin));
return val;
@@ -223,6 +239,7 @@ static const struct dm_gpio_ops xilinx_gpio_ops = {
static int xilinx_gpio_probe(struct udevice *dev)
{
struct xilinx_gpio_platdata *platdata = dev_get_platdata(dev);
+ struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
const void *label_ptr;
void *label_c;
@@ -239,6 +256,11 @@ static int xilinx_gpio_probe(struct udevice *dev)
uc_priv->gpio_count = platdata->bank_max[0] + platdata->bank_max[1];
+ priv->output_val[0] = platdata->dout_default[0];
+
+ if (platdata->bank_max[1])
+ priv->output_val[1] = platdata->dout_default[1];
+
return 0;
}
@@ -255,6 +277,9 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice
*dev)
"xlnx,all-inputs", 0);
platdata->bank_output[0] = dev_read_u32_default(dev,
"xlnx,all-outputs", 0);
+ platdata->dout_default[0] = dev_read_u32_default(dev,
+"xlnx,dout-default",
+0);
is_dual = dev_read_u32_default(dev, "xlnx,is-dual", 0);
if (is_dual) {
@@ -264,6 +289,8 @@ static int xilinx_gpio_ofdata_to_platdata(struct udevice
*dev)
"xlnx,all-inputs-2", 0);
platdata->bank_output[1] = dev_read_u32_default(dev,
"xlnx,all-outputs-2", 0);
+ platdata->dout_default[1] = dev_read_u32_default(dev,
+ "xlnx,dout-default-2", 0);
}
return 0;
@@ -282,4 +309,5 @@ U_BOOT_DRIVER(xilinx_gpio) = {
.ofdata_to_platdata = xilinx_gpio_ofdata_to_platdata,
.probe = xilinx_gpio_probe,
.platdata_auto_alloc_size =
Re: [U-Boot] [PATCH 3/4] gpio: xilinx: Not read output values via regs
On 1.8.2018 20:36, Stefan Herbrechtsmeier wrote:
> Am 30.07.2018 um 21:34 schrieb Stefan Herbrechtsmeier:
>> Am 30.07.2018 um 16:10 schrieb Michal Simek:
>>> On 30.7.2018 15:32, Stefan Herbrechtsmeier wrote:
Am 30.07.2018 um 14:40 schrieb Michal Simek:
> On 27.7.2018 10:41, Stefan Herbrechtsmeier wrote:
>> Am 27.07.2018 um 09:05 schrieb Michal Simek:
>>> On 26.7.2018 21:46, Stefan Herbrechtsmeier wrote:
Am 26.07.2018 um 10:41 schrieb Michal Simek:
> On 25.7.2018 20:21, Stefan Herbrechtsmeier wrote:
>> Am 25.07.2018 um 08:39 schrieb Michal Simek:
>>> On 24.7.2018 21:56, Stefan Herbrechtsmeier wrote:
Am 24.07.2018 um 12:31 schrieb Michal Simek:
> On 23.7.2018 20:42, Stefan Herbrechtsmeier wrote:
>> Am 23.07.2018 um 13:43 schrieb Michal Simek:
>>> Reading registers for finding out output value is not
>>> working
>>> because
>>> input value is read instead in case of tristate.
>>>
>>> Reported-by: Stefan Herbrechtsmeier
>>>
>>> Signed-off-by: Michal Simek
>>> ---
>>>
>>> drivers/gpio/xilinx_gpio.c | 38
>>> +-
>>> 1 file changed, 33 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpio/xilinx_gpio.c
>>> b/drivers/gpio/xilinx_gpio.c
>>> index 4da9ae114d87..9d3e9379d0e5 100644
>>> --- a/drivers/gpio/xilinx_gpio.c
>>> +++ b/drivers/gpio/xilinx_gpio.c
[snip]
>>> + priv->output_val[bank] = val;
>>> +
>>> return val;
>>> };
>>> @@ -441,6 +449,7 @@ static int
>>> xilinx_gpio_get_function(struct
>>> udevice *dev, unsigned offset)
>>> static int xilinx_gpio_get_value(struct udevice
>>> *dev,
>>> unsigned
>>> offset)
>>> {
>>> struct xilinx_gpio_platdata *platdata =
>>> dev_get_platdata(dev);
>>> + struct xilinx_gpio_privdata *priv = dev_get_priv(dev);
>>> int val, ret;
>>> u32 bank, pin;
>>> @@ -451,7 +460,14 @@ static int
>>> xilinx_gpio_get_value(struct
>>> udevice
>>> *dev, unsigned offset)
>>> debug("%s: regs: %lx, gpio: %x, bank %x, pin
>>> %x\n",
>>> __func__,
>>> (ulong)platdata->regs, offset, bank, pin);
>>> - val = readl(&platdata->regs->gpiodata + bank
>>> * 2);
>>> + if (xilinx_gpio_get_function(dev, offset) ==
>>> GPIOF_INPUT) {
>>> + debug("%s: Read input value from reg\n", __func__);
>>> + val = readl(&platdata->regs->gpiodata + bank * 2);
>>> + } else {
>>> + debug("%s: Read saved output value\n", __func__);
>>> + val = priv->output_val[bank];
>>> + }
>> Why you don't always read the data register? This doesn't
>> work for
>> three
>> state outputs.
> In three state register every bit/pin is 0 - output, 1 input.
> It means else part is output and I read saved value in
> priv->output_val.
> If pin is setup as INPUT then I need read data reg to find out
> input
> value.
> Maybe you are commenting something else but please let me
> know if
> there
> is any other bug.
What happen if I have an open drain output. Even if the gpio
output
is 1
the input could read a 0. You driver will always return the
output
value
and not the real input value. According to the picture in
documentation
and my tests a data register write writes the output registers
and a
data register read reads the input registers.
Why should the driver return the desired state (output
register)
and not
the real state (input register)?
>>> First of all thanks for description.
>>>
>>> I have another example where you have output only and you can't
>>> read
>>> input because there is no wire.
>> Does you mean the all outputs configuration? Does this removes
>> the
>> "gpio_io_i" signal from the IP?
> I am not sure what synthesis is doing with that unused IP pins
> but I
> would consider as a bug if this is automatically connecte
Re: [U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Hello Simon,
> > Dear U-Boot devs,
> >
> > I've setup verified boot on a imx6 board and want to protect my device
> against the "mix and match" attacks mentioned in
> "doc/uImage.FIT/signature.txt".
> > That's why I have only implemented signed configurations and no signed
> images as in doc/uImage.FIT/signed-configs.its.
> > My public key in my embedded fdt has the property required = "conf";
> >
> > Booting a signed config with "bootm ${loadaddr}#conf@1" and an
> embedded public key required for configurations does work as expected and
> do fail to boot if I modify the config, image, hash, signature and so on.
> >
> > If I boot any fit image(signed and unsigned) for example with "bootm
> ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot
> every image combination without signature verification although a signature
> is enforced for a configuration.
> >
> > Is this the expected behavior?
> >
> > I thought if I had set the public key in in the embedded fdt as required for
> configurations, bootm does only boot signed configurations and no
> subimages directly...
>
> I don't think there is any restriction on that at the moment. You are
> explicitly
> asking to boot particular images rather than a config. So I suppose it would
> be
> odd if U-Boot tried to enforce a config. Are you thinking it should try to
> find a
> config that has those images in it?
No, I expected that I cannot boot sub images directly if there is a required
public key for a configuration.
After a dive into the bootm source I think this is not easily possible to
enforce this behavior.
> But why not just specify the config to bootm?
At first I wanted to use a simple boot script wrapped in a fit image (unsigned)
and
have only the needed commands enabled in U-Boot.
Now I switched to a signed U-Boot script as boot script and can be sure that
this one gets not tampered.
The only bad thing is here that the source command does only have support for
fit sub images and
I have to sign the config and the image of my system image if I had a required
certificate for images and configs.
Probably this behavior should be mentioned in the doc.
Many thanks for the clarification.
Best regards
Johann Neuhauser
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SUCCESS: Building U-Boot for MIPS64 on Windows7
Hi,
On Thu, Aug 2, 2018 at 6:48 AM, George Robinson
wrote:
> I was able to successfully Build U-Boot v2018.07 under Windows 7 SP1 (64bit)
> - under MinGW64_NT-6.1 ( a.k.a. MSYS2 or MSYS64 )
> - using the native host toolchain (with GCC v7.3.0 for x86_64 code
> generation on x86_64 CPU)
> - using the target toolchain (with GCC v5.3.0 for MIPS code generation on
> x86_64 CPU (Sourcery CodeBench Lite 2016.05-8) )
>
> by modifying the function parse_dep_file() defnied in
> u-boot-master/scripts/basic/fixdep.c, as illustrated below:
>
> The change was necessary because the command "gcc cc -Wp,-MD,
> dependencyfile.o.d..." generates a dependency file containg Windows style
> paths like:
> C:\src\bin
> ...instead of the Linux like path, like:
> /c/src/bin
>
>
> static void parse_dep_file(void *map, size_t len)
> {
> char *m = map;
> char *end = m + len;
> char *p;
> char s[PATH_MAX];
> int is_target;
> int saw_any_target = 0;
> int is_first_dep = 0;
>
> while (m < end) {
> /* Skip any "white space" */
> while (m < end && (*m == ' ' || *m == '\t' || *m == '\\' ||
> *m == '\r' || *m == '\n'))
> m++;
> /* Skip any "non-white space" */
> p = m;
> while (p < end && *p != ' ' && *p != '\t' && *p != '\\' &&
> *p != '\r' && *p != '\n')
> p++;
>
> /* Convert any Windows paths into Cygwin paths, just like
> "cygpath -u " would do. */
> if( ( (p-m) >=2) && (*(m+1) == ':') && ((*(m+2) == '/') ||
> (*(m+2) == '\\')) && (((*m>='A') && (*m<='Z')) || ((*m>='a') && (*m<='z')))
> )
> {
> *(m+1)= (*m) | 0x20; //Convert the drive letter to
> lowercase and move it where the colon was
> *m = '/'; //Prepend a forward slash
> //*(m+2) = '/'; //Make sure a forward slash follows
> the drive letter
>
> // Substitute remaining backslashes in the Windows
> path, with forward slashes
> while (p < end && *p != ' ' && *p != '\t' && *p !=
> '\r' && *p != '\n')
> {
> if(*p == '\\')
> *p = '/';
> p++;
> }
> #ifdef FIXDEP_DBG
> fprintf(stderr,"FIXDEP: Windows path at %ld= %s\n",
> m-(char*)map, m);
> #endif
> }
>
> /* Is the token we found a target name? */
> is_target = (*(p-1) == ':');
> /* Don't write any target names into the dependency file */
> if (is_target) {
> /* The /next/ file is the first dependency */
> is_first_dep = 1;
> } else if( (p-m) > 0 )
> { /* Save this token/filename */
> memcpy(s, m, p-m);
> s[p - m] = 0;
>
>
> /* Ignore certain dependencies */
> if (strrcmp(s, "include/generated/autoconf.h") &&
> strrcmp(s, "arch/um/include/uml-config.h") &&
> strrcmp(s, "include/linux/kconfig.h") &&
> strrcmp(s, ".ver")) {
> /*
> * Do not list the source file as
> dependency,
> * so that kbuild is not confused if a .c
> file
> * is rewritten into .S or vice versa.
> Storing
> * it in source_* is needed for modpost to
> * compute srcversions.
> */
> if (is_first_dep) {
> /*
> * If processing the concatenation
> of
> * multiple dependency files, only
> * process the first target name,
> which
> * will be the original source name,
> * and ignore any other target
> names,
> * which will be intermediate
> temporary
> * files.
> */
> if (!saw_any_target) {
> saw_any_target = 1;
> printf("source_%s :=
> %s\n\n",
> target, s);
> printf("deps_%s := \\\n",
> target);
>
[U-Boot] [PATCH] Convert CONFIG_USB_ULPI_TIMEOUT to Kconfig
This converts the following to Kconfig: CONFIG_USB_ULPI_TIMEOUT Signed-off-by: Adam Ford diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig index 001564d40c..d0eff66e1c 100644 --- a/drivers/usb/ulpi/Kconfig +++ b/drivers/usb/ulpi/Kconfig @@ -30,3 +30,9 @@ config USB_ULPI PHY Transreceiver for USB controllers. This driver uses ULPI viewports that are specific for each SoC. + +config USB_ULPI_TIMEOUT + int "ULPI Timeout (us)" + default 1000 if USB_ULPI + help + Select the UPLI timeout in microseconds diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h index 71642d257b..00cc60190b 100644 --- a/include/usb/ulpi.h +++ b/include/usb/ulpi.h @@ -20,10 +20,6 @@ #define ULPI_ERROR (1 << 8) /* overflow from any register value */ -#ifndef CONFIG_USB_ULPI_TIMEOUT -#define CONFIG_USB_ULPI_TIMEOUT 1000 /* timeout in us */ -#endif - /* * ulpi view port address and * Port_number that can be passed. diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 7ced4099f2..8f6a1e3f7f 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4666,7 +4666,6 @@ CONFIG_USB_SS_BASE CONFIG_USB_TI_CPPI_DMA CONFIG_USB_TTY CONFIG_USB_TUSB_OMAP_DMA -CONFIG_USB_ULPI_TIMEOUT CONFIG_USB_XHCI_EXYNOS CONFIG_USB_XHCI_KEYSTONE CONFIG_USB_XHCI_OMAP -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Convert CONFIG_VIDEO_OMAP3 to Kconfig
This converts the following to Kconfig: CONFIG_VIDEO_OMAP3 Signed-off-by: Adam Ford --- configs/cm_t3517_defconfig | 1 + configs/cm_t35_defconfig | 1 + configs/mcx_defconfig | 1 + configs/mt_ventoux_defconfig | 1 + configs/omap3_beagle_defconfig | 1 + drivers/video/Kconfig | 6 ++ include/configs/cm_t35.h | 1 - include/configs/cm_t3517.h | 1 - include/configs/mcx.h | 1 - include/configs/mt_ventoux.h | 1 - include/configs/omap3_beagle.h | 1 - scripts/config_whitelist.txt | 1 - 12 files changed, 11 insertions(+), 6 deletions(-) diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig index fa7f336739..faf03542e7 100644 --- a/configs/cm_t3517_defconfig +++ b/configs/cm_t3517_defconfig @@ -53,5 +53,6 @@ CONFIG_USB=y CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_AM35X=y CONFIG_USB_STORAGE=y +CONFIG_VIDEO_OMAP3=y CONFIG_LCD=y CONFIG_OF_LIBFDT=y diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig index 30a745210a..52442cc69a 100644 --- a/configs/cm_t35_defconfig +++ b/configs/cm_t35_defconfig @@ -56,5 +56,6 @@ CONFIG_USB_MUSB_UDC=y CONFIG_USB_OMAP3=y CONFIG_TWL4030_USB=y CONFIG_USB_STORAGE=y +CONFIG_VIDEO_OMAP3=y CONFIG_LCD=y CONFIG_OF_LIBFDT=y diff --git a/configs/mcx_defconfig b/configs/mcx_defconfig index e14780927c..6e00c43a9a 100644 --- a/configs/mcx_defconfig +++ b/configs/mcx_defconfig @@ -47,6 +47,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y +CONFIG_VIDEO_OMAP3=y CONFIG_VIDEO=y # CONFIG_VIDEO_SW_CURSOR is not set CONFIG_OF_LIBFDT=y diff --git a/configs/mt_ventoux_defconfig b/configs/mt_ventoux_defconfig index 81ed01e61d..12501f0dee 100644 --- a/configs/mt_ventoux_defconfig +++ b/configs/mt_ventoux_defconfig @@ -43,6 +43,7 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_ULPI_VIEWPORT_OMAP=y CONFIG_USB_ULPI=y CONFIG_USB_STORAGE=y +CONFIG_VIDEO_OMAP3=y CONFIG_VIDEO=y # CONFIG_VIDEO_SW_CURSOR is not set CONFIG_OF_LIBFDT=y diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig index 1e1a391d7f..69ffa51545 100644 --- a/configs/omap3_beagle_defconfig +++ b/configs/omap3_beagle_defconfig @@ -74,6 +74,7 @@ CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_VIDEO_OMAP3=y CONFIG_FAT_WRITE=y CONFIG_BCH=y CONFIG_SPL_OF_LIBFDT=y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 5ee9032dc9..bf93f07d94 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -408,6 +408,12 @@ config VIDEO_MVEBU Support for the LCD controller integrated in the Marvell Armada XP SoC. +config VIDEO_OMAP3 + bool "Enable OMAP3+ DSS Support" + depends on ARCH_OMAP2PLUS + help + This enables the Display subsystem (DSS) on OMAP3+ boards. + config I2C_EDID bool "Enable EDID library" depends on DM_I2C diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index 415924549b..a896a7f455 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -203,7 +203,6 @@ #define CONFIG_SPLASHIMAGE_GUARD /* Display Configuration */ -#define CONFIG_VIDEO_OMAP3 #define LCD_BPPLCD_COLOR16 #define CONFIG_SPLASH_SCREEN diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h index 2c889d4a85..e872641eda 100644 --- a/include/configs/cm_t3517.h +++ b/include/configs/cm_t3517.h @@ -210,7 +210,6 @@ #define GREEN_LED_GPIO 186 /* CM-T3517 Green LED is GPIO186 */ /* Display Configuration */ -#define CONFIG_VIDEO_OMAP3 #define LCD_BPPLCD_COLOR16 #define CONFIG_SPLASH_SCREEN diff --git a/include/configs/mcx.h b/include/configs/mcx.h index 0cad187a3c..4fa6aef2a0 100644 --- a/include/configs/mcx.h +++ b/include/configs/mcx.h @@ -299,6 +299,5 @@ #define CONFIG_SPLASH_SCREEN #define CONFIG_VIDEO_BMP_RLE8 -#define CONFIG_VIDEO_OMAP3 #endif /* __CONFIG_H */ diff --git a/include/configs/mt_ventoux.h b/include/configs/mt_ventoux.h index 3b11cc0e50..e590364441 100644 --- a/include/configs/mt_ventoux.h +++ b/include/configs/mt_ventoux.h @@ -39,7 +39,6 @@ #define CONFIG_SPLASH_SCREEN #define CONFIG_VIDEO_BMP_RLE8 -#define CONFIG_VIDEO_OMAP3 /* DSS Support */ #defineCONFIG_EXTRA_ENV_SETTINGS CONFIG_TAM3517_SETTINGS \ "bootcmd=run net_nfs\0" diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 1599b6f0ba..148c641926 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -61,7 +61,6 @@ #define CONFIG_I2C_MULTI_BUS /* DSS Support */ -#define CONFIG_VIDEO_OMAP3 /* TWL4030 LED Support */ #define CONFIG_TWL4030_LED diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 7ced4099f2..f332615ef1 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4700,7 +4700,6 @@ CONFIG_VIDEO_MB862xx CONFI
Re: [U-Boot] [PATCH] Convert CONFIG_USB_ULPI_TIMEOUT to Kconfig
On 08/02/2018 03:27 PM, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_USB_ULPI_TIMEOUT > > Signed-off-by: Adam Ford > > diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig > index 001564d40c..d0eff66e1c 100644 > --- a/drivers/usb/ulpi/Kconfig > +++ b/drivers/usb/ulpi/Kconfig > @@ -30,3 +30,9 @@ config USB_ULPI > PHY Transreceiver for USB controllers. > > This driver uses ULPI viewports that are specific for each SoC. > + > +config USB_ULPI_TIMEOUT > + int "ULPI Timeout (us)" > + default 1000 if USB_ULPI Shouldn't this depend on USB_ULPI ? > + help > + Select the UPLI timeout in microseconds > diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h > index 71642d257b..00cc60190b 100644 > --- a/include/usb/ulpi.h > +++ b/include/usb/ulpi.h > @@ -20,10 +20,6 @@ > > #define ULPI_ERROR (1 << 8) /* overflow from any register value */ > > -#ifndef CONFIG_USB_ULPI_TIMEOUT > -#define CONFIG_USB_ULPI_TIMEOUT 1000 /* timeout in us */ > -#endif > - > /* > * ulpi view port address and > * Port_number that can be passed. > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > index 7ced4099f2..8f6a1e3f7f 100644 > --- a/scripts/config_whitelist.txt > +++ b/scripts/config_whitelist.txt > @@ -4666,7 +4666,6 @@ CONFIG_USB_SS_BASE > CONFIG_USB_TI_CPPI_DMA > CONFIG_USB_TTY > CONFIG_USB_TUSB_OMAP_DMA > -CONFIG_USB_ULPI_TIMEOUT > CONFIG_USB_XHCI_EXYNOS > CONFIG_USB_XHCI_KEYSTONE > CONFIG_USB_XHCI_OMAP > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Convert to DM serial
On 08/02/2018 10:36 AM, Simon Goldschmidt wrote: > > > On 01.08.2018 18:34, Marek Vasut wrote: >> On 08/01/2018 05:42 PM, Simon Goldschmidt wrote: >>> >>> >>> Marek Vasut mailto:ma...@denx.de>> schrieb am Mi., 1. >>> Aug. 2018, 09:35: >>> >>> On 08/01/2018 09:29 AM, Goldschmidt Simon wrote: >>> > >>> > On 30.07.2018 16:04, Marek Vasut wrote: >>> >> On 07/30/2018 04:03 PM, Simon Goldschmidt wrote: >>> >>> >>> >>> On 12.05.2018 22:28, Marek Vasut wrote: >>> Pull the serial port configuration from DT and use DM serial >>> instead >>> of having the serial configuration in two places, DT and board >>> config. >>> [..] >>> >>> >>> While debugging, a more generic question: which drivers are now >>> remaining non-DM for socfpga? >> >> Not much I believe, I can't think of anything right now. >> >>> And am I correct with the assumption that we could get rid of the qts >>> files (other than sdram maybe) by implementing pinctrl and clk drivers >>> as DM drivers? (Not that I would have found documentation about the pin >>> mux hardware cyclone5...) >> >> Yes. The pinmux docs are probably not public, it has to do with the >> iocsr ring programming and that's super-secret for whatever reason. >> What Altera did on Arria10 is pure trash, they encode registers in DT >> and are done with it. If you can design something saner, that'd be so >> nice. > > As I'm not familiar with pinmux DTS, that might be hard for me, but I > might try to get it done somehow (or by someone... :) > > Could you give me a hint of a platform to take as a good example? Maybe iMX series ? >> I am working on a clock driver for Arria10 now, I might do Gen5 too >> afterward, since the clock block is similar. > > That would be cool. You can count on me testing on cyclone5 as much as I > can (as much as I have the hardware, that is). > >> The clock DT bindings on >> the other hand are complete insanity, words fail me. The clock stuff in >> U-Boot on SoCFPGA right now is a complete disaster too, the way stuff >> gets added to mach-socfpga is really irritating. > > But you would still use the existing bindings? How does this stuff get > added to U-Boot, by first being added to Linux and the DTS being copied > here? Pretty much, except on A10 there are the generated handoff files at play too. Basically Altera really screwed it up there, it contains redundant nodes which are both in the base DT and handoff files, but each contain different set of DT properties and have different names, although they represent the same thing. Sigh ... >>> I'm looking for a way to control pins from a fit image that includes >>> kernel, dts and fpga because the pins may change depending on the fpga >>> config... >> >> DTOs maybe ? > > Yeah, I thought of that too. The problem I see is that we would need > pinmux and clock support for DTS in Linux but we're kind of stuck to > 4.9.y for now due to using an RT configuration. Well, implement those drivers ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] Convert CONFIG_USB_ULPI_TIMEOUT to Kconfig
This converts the following to Kconfig: CONFIG_USB_ULPI_TIMEOUT Signed-off-by: Adam Ford --- V2: Make USB_ULPI_TIMEOUT depend on USB_ULPI diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig index 001564d40c..6a67f70411 100644 --- a/drivers/usb/ulpi/Kconfig +++ b/drivers/usb/ulpi/Kconfig @@ -30,3 +30,10 @@ config USB_ULPI PHY Transreceiver for USB controllers. This driver uses ULPI viewports that are specific for each SoC. + +config USB_ULPI_TIMEOUT + int "ULPI Timeout (us)" + depends on USB_ULPI + default 1000 if USB_ULPI + help + Select the UPLI timeout in microseconds diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h index 71642d257b..00cc60190b 100644 --- a/include/usb/ulpi.h +++ b/include/usb/ulpi.h @@ -20,10 +20,6 @@ #define ULPI_ERROR (1 << 8) /* overflow from any register value */ -#ifndef CONFIG_USB_ULPI_TIMEOUT -#define CONFIG_USB_ULPI_TIMEOUT 1000 /* timeout in us */ -#endif - /* * ulpi view port address and * Port_number that can be passed. diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 7ced4099f2..8f6a1e3f7f 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4666,7 +4666,6 @@ CONFIG_USB_SS_BASE CONFIG_USB_TI_CPPI_DMA CONFIG_USB_TTY CONFIG_USB_TUSB_OMAP_DMA -CONFIG_USB_ULPI_TIMEOUT CONFIG_USB_XHCI_EXYNOS CONFIG_USB_XHCI_KEYSTONE CONFIG_USB_XHCI_OMAP -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Convert CONFIG_USB_ULPI_TIMEOUT to Kconfig
On Thu, Aug 2, 2018 at 8:56 AM Marek Vasut wrote: > > On 08/02/2018 03:27 PM, Adam Ford wrote: > > This converts the following to Kconfig: > >CONFIG_USB_ULPI_TIMEOUT > > > > Signed-off-by: Adam Ford > > > > diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig > > index 001564d40c..d0eff66e1c 100644 > > --- a/drivers/usb/ulpi/Kconfig > > +++ b/drivers/usb/ulpi/Kconfig > > @@ -30,3 +30,9 @@ config USB_ULPI > > PHY Transreceiver for USB controllers. > > > > This driver uses ULPI viewports that are specific for each SoC. > > + > > +config USB_ULPI_TIMEOUT > > + int "ULPI Timeout (us)" > > + default 1000 if USB_ULPI > > Shouldn't this depend on USB_ULPI ? Oops, my bad. V2 coming now. adam > > > + help > > + Select the UPLI timeout in microseconds > > diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h > > index 71642d257b..00cc60190b 100644 > > --- a/include/usb/ulpi.h > > +++ b/include/usb/ulpi.h > > @@ -20,10 +20,6 @@ > > > > #define ULPI_ERROR (1 << 8) /* overflow from any register value */ > > > > -#ifndef CONFIG_USB_ULPI_TIMEOUT > > -#define CONFIG_USB_ULPI_TIMEOUT 1000 /* timeout in us */ > > -#endif > > - > > /* > > * ulpi view port address and > > * Port_number that can be passed. > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt > > index 7ced4099f2..8f6a1e3f7f 100644 > > --- a/scripts/config_whitelist.txt > > +++ b/scripts/config_whitelist.txt > > @@ -4666,7 +4666,6 @@ CONFIG_USB_SS_BASE > > CONFIG_USB_TI_CPPI_DMA > > CONFIG_USB_TTY > > CONFIG_USB_TUSB_OMAP_DMA > > -CONFIG_USB_ULPI_TIMEOUT > > CONFIG_USB_XHCI_EXYNOS > > CONFIG_USB_XHCI_KEYSTONE > > CONFIG_USB_XHCI_OMAP > > > > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] Convert CONFIG_USB_ULPI_TIMEOUT to Kconfig
On 08/02/2018 04:02 PM, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_USB_ULPI_TIMEOUT > > Signed-off-by: Adam Ford > --- > V2: Make USB_ULPI_TIMEOUT depend on USB_ULPI > > diff --git a/drivers/usb/ulpi/Kconfig b/drivers/usb/ulpi/Kconfig > index 001564d40c..6a67f70411 100644 > --- a/drivers/usb/ulpi/Kconfig > +++ b/drivers/usb/ulpi/Kconfig > @@ -30,3 +30,10 @@ config USB_ULPI > PHY Transreceiver for USB controllers. > > This driver uses ULPI viewports that are specific for each SoC. > + > +config USB_ULPI_TIMEOUT > + int "ULPI Timeout (us)" > + depends on USB_ULPI > + default 1000 if USB_ULPI But then the 'if USB_ULPI' is redundant ? btw. give people some time to review a patch, don't immediately send a new version. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/27] SPI-NAND support
___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] xyz-modem: Change getc timeout loop waiting
Hello Tomas, On Wed, 1 Aug 2018 09:16:38 +0300 Tomas Melin wrote: > >> Is the timeout a watchdog timeout or some communication freeze? > > I suppose, it reports false-positive timeout back to ymodem code. > > Because all it does is terminating communication gracefully (with 'C' > > and a bunch of CANs). > If you are using omap_wdt then check the configured value of the timeout > (WDT_HW_TIMEOUT). > Time the y-modem loading, and if the reset happens just after that > configured value, it would indicate that the watchdog is not kicked, for > one reason or another. Yes, I'm using omap_wdt with default 60 seconds timeout, but as I mentioned already, it's not WDT kicking in, but your patch breaking YMODEM protocol reporting false timeout back to YMODEM code. -- Alexander Sverdlin. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fman: Support both new and legacy FMan Compatibles
On 08/01/2018 02:50 AM, Zhao Qiang wrote: > Recently the FMan Port and MAC compatibles were changed. > This patch aligns the FMan Port and MAC compatibles > to the new FMan device tree binding document. > The FMan device tree binding document can be found in the Linux > kernel: > ./Documentation/devicetree/bindings/net/fsl-fman.txt It would be helpful to know which version or commit has this change. It doesn't impact this patch though. Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] bootelf and 64 bit elf application
I would like to know an answer to that problem, too. Is the hello.world.bin an ELF file ? What does objdump say ? Also, the entry address is not the same as the load address, so maybe there is something to do with that... George On 2018-08-01 21:06, Siddharth Tuli wrote: Hi, I am trying to use bootelf to load a 64-bit elf binary, but it appears to fail. I tried using the hello_world from U-Boot sources as well. My U-Boot is based 2015.01 and I have patches applied for 64elf support, and compiled as a 64 bit U-Boot. Any idea what is need to support bootelf for 64-bit? # file hello_world.bin hello_world.bin: ELF 64-bit LSB executable, version 1 (SYSV), statically linked, not stripped uboot# tftp 0x8030 tsiddharth/hello_world.bin *ethHw_checkPortSpeed setting speed: 5 Using bcmiproc_eth-0 device TFTP from server 10.204.96.200; our IP address is 10.216.67.182; sending through gateway 10.216.79.254 Filename 'tsiddharth/hello_world.bin'. Load address: 0x8030 Loading: # 889.6 KiB/s done Bytes transferred = 68336 (10af0 hex) uboot# bootelf -p 0x8030 <=== I looked at cmd/elf.c and I see that bootelf calls load_elf64_img_phdr() only with “-p” option. Loading phdr 0 to 0x0c10 (794 bytes) Loading phdr 1 to 0x (0 bytes) ## Starting application at 0x0c10 ... "Synchronous Abort" handler, esr 0x86000210 ELR: c10 LR: fff4197c x0 : 0002 x1 : feb3f058 x2 : 0020 x3 : 0001 x4 : 0020 x5 : 015087ba x6 : ffd0 x7 : 0004 x8 : 0063 x9 : 7af38000 x10: feaf7678 x11: fff8c000 x12: 000f x13: fffa18c1 x14: fff99186 x15: fff99180 x16: fffa18c1 x17: fff99175 x18: feaf7e30 x19: 0c10 x20: x21: feb3f058 x22: 0002 x23: 0002 x24: x25: fff912f9 x26: x27: x28: x29: feaf7b00 Resetting CPU ... resetting ... Patches applied - author Bin Meng mailto:bmeng...@gmail.com>> Thu, 12 Apr 2018 10:32:14 +0530 (22:02 -0700) commit 839c4e9c5bb09ac1ef2c129c7082a15b9cbd3a8a elf: Add a very simple ELF64 loader This adds a very simple ELF64 loader via program headers, similar to load_elf_image_phdr() that we already have. author Bin Meng mailto:bmeng...@gmail.com>> Thu, 12 Apr 2018 10:32:13 +0530 (22:02 -0700) commit 2bce3f595d224fc620b07449d47fa2b08151a890 elf: Add ELF64 related structure defines This adds ELF header, program header and section header structure defines for the 64-bit ELF image. Regards Siddharth ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Ethernet name length changes
On Thu, Aug 2, 2018 at 6:01 AM, Pankaj Bansal wrote: > The ethernet name should be within the ETH_NAME_LEN, as this > is the buffer space allocated to ethernet name. > > Otherwise, this causes buffer overflow. > > At the same time the 16 char ethernet name size is inadequate to hold the > name of ethernet "DPMAC17@rgmii-id", which is a valid name in upcoming > LX2160AQDS/LX2160ARDB boards. Can you just shorten the name? This is a shared constant with Linux, so while we could change it, I'd prefer not to. > These patches try to solve the above two issues: > 1. first patch honors the limit imposed by ETH_NAME_LEN on ethernet name > 2. second patch increases this limit to accommodate the requirements of >LX2160AQDS/LX2160ARDB > > Cc: Varun Sethi > > Pankaj Bansal (2): > fsl/mc: Limit the ethernet name to ETH_NAME_LEN > net: Increase ethernet name string size to 20 chars > > drivers/net/fsl-mc/mc.c | 6 +++--- > drivers/net/ldpaa_eth/ldpaa_eth.c | 4 ++-- > include/net.h | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > -- > 2.17.1 > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] linux/if_ether.h: Initial import from Linux kernel v4.17
On Tue, Jul 31, 2018 at 4:55 AM, Bin Meng wrote: > This imports include/uapi/linux/if_ether.h from Linux kernel v4.17. > It can be very helpful When porting Linux ethernet driver to U-Boot. > > Note it is not exactly the same as the kernel one, as checkpatch > issues are fixed. > > Signed-off-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] net.h: Include linux/if_ether.h to avoid duplication
On Tue, Jul 31, 2018 at 4:55 AM, Bin Meng wrote: > There are plenty of existing drivers that have macros like ETH_ALEN > defined in their own source files. Now that we imported the kernel's > if_ether.h to U-Boot we can reduce some duplication. > > Signed-off-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] linux/if_ether.h: Add VLAN related macros
On Tue, Jul 31, 2018 at 4:55 AM, Bin Meng wrote: > There are VLAN related macros defined in include/linux/if_vlan.h > in Linux kernel, as well as some kernel useful structures and inline > functions. Instead of a complete import from kernel, let's add these > VLAN macros to U-Boot's include/linux/if_ether.h. > > Signed-off-by: Bin Meng Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fman: Support both new and legacy FMan Compatibles
On Wed, Aug 1, 2018 at 4:48 AM, Zhao Qiang wrote: > Recently the FMan Port and MAC compatibles were changed. > This patch aligns the FMan Port and MAC compatibles > to the new FMan device tree binding document. > The FMan device tree binding document can be found in the Linux > kernel: > ./Documentation/devicetree/bindings/net/fsl-fman.txt Please reference the Linux commit that made the change and the version of the kernel that made the change. > > This patch doesn't affect legacy compatibles support. > > Signed-off-by: Zhao Qiang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/8] ARM: Odroid XU3: Adjust BOOT_TARGET_DEVICES to allow booting from SD card (mmc2)
On 1 August 2018 at 06:48, Lukasz Majewski wrote: > > This change is necessary to allow booting the Odroid XU3 from SD card > after enabling the DM_MMC support. > > After this change the SD card mmc IP block is correctly enumerated as mmc2 > (and not as mmc1 as in the legacy code). > > Signed-off-by: Lukasz Majewski > Tested-by: Anand Moon > > --- > > Changes in v2: > - Add tested-by > - Rebase on the newest main line > > include/configs/exynos5-common.h | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] lib: bitrev: Sync with Linux kernel v4.17
On 31 July 2018 at 22:29, Bin Meng wrote: > Signed-off-by: Bin Meng > --- > > include/linux/bitrev.h | 102 > - > lib/bitrev.c | 28 -- > 2 files changed, 101 insertions(+), 29 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sandbox: Enable bitrev library build
2018-07-31 22:29 GMT-06:00 Bin Meng : > Turn on CONFIG_BITREVERSE for all sandbox builds. > > Signed-off-by: Bin Meng > --- > > configs/sandbox64_defconfig| 1 + > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > configs/sandbox_noblk_defconfig| 1 + > configs/sandbox_spl_defconfig | 1 + > 5 files changed, 5 insertions(+) Can you instead select it or imply it in arch/sandbox/Kconfig? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] board: Add gazerbeam driver
On 31 July 2018 at 03:44, Mario Six wrote: > Add a board driver for the upcoming gdsys Gazerbeam board. > > Signed-off-by: Mario Six > --- > > v3 -> v4: > * Fixed misplaced Kconfig lines > > v2 -> v3: > * Set startup-finished GPIOs during probe > * Added driver binding file for gazerbeam board > * Improved error handling > * Improved error/debug output > * Improved documentation > * Turned magic numbers into named constants > > v1 -> v2: > * Improved error handling > * Renamed DT properties > * Moved the driver over to the board uclass > > --- > .../bindings/board/gdsys,board_gazerbeam.txt | 46 > drivers/board/Kconfig | 10 + > drivers/board/gazerbeam.c | 262 > + > drivers/board/gazerbeam.h | 18 ++ > 4 files changed, 336 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/board/gdsys,board_gazerbeam.txt > create mode 100644 drivers/board/gazerbeam.c > create mode 100644 drivers/board/gazerbeam.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] test: Add tests for misc uclass
On 31 July 2018 at 06:24, Mario Six wrote: > Add a set of tests for the misc uclass. > > Signed-off-by: Mario Six > --- > > v3 -> v4: > New in v4 > > --- > arch/sandbox/dts/test.dts | 4 ++ > drivers/misc/Makefile | 2 +- > drivers/misc/misc_sandbox.c | 133 > > test/dm/Makefile| 1 + > test/dm/misc.c | 83 +++ > 5 files changed, 222 insertions(+), 1 deletion(-) > create mode 100644 drivers/misc/misc_sandbox.c > create mode 100644 test/dm/misc.c > Reviewed-by: Simon Glass Very nice, thanks. Maybe we should have ut_asserttrue/false? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] common: include always
+Tom Hi Masahiro, On 30 July 2018 at 19:41, Masahiro Yamada wrote: > 2018-07-26 22:59 GMT+09:00 Philipp Tomsich > : >> With the ram-size variable changed to u64, we'll need appropriate >> macros for printing u64 values correctly either in 32bit builds >> (i.e. ILP32 models) or in 64bit builds (i.e. LP64 models). Best to >> make the PRIx64 macro available everywhere. >> >> This include inttypes.h from common.h to make the various macros for >> formatted printing available to everyone. >> >> Signed-off-by: Philipp Tomsich >> --- > > > NACK. > > > PRIx64 is evil crap. I would make the code super ugly. > Do not use it. > > > The right thing to do is use the same typedefs > for all architectures. > > typedef unsigned char u8; > typedef unsigned short u16; > typedef unsigned intu32; > typedef unsigned long long u64; > > This works for both ILP32 and LP64. > > > Use '%llx' for printing u64 variables _always_. > > > > This is what Linux exactly does. > > > > In fact, Linux defined fixed-width types differently > for different architectures in old days. > > > After long time effort, Linux unified > the fixed-width types for the kernel space. > > https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/int-ll64.h > > > > See Linux commit: > > commit 0c79a8e29b5fcbcbfd611daf9d500cfad8370fcf > Author: Geert Uytterhoeven > Date: Thu Jan 23 15:53:43 2014 -0800 > > asm/types.h: Remove include/asm-generic/int-l64.h > > > > > > And, I fixed ARM Trusted Firmware in the same way: > > https://github.com/ARM-software/arm-trusted-firmware/commit/0a2d5b43c81ed6132761023bf43755f13122ddf0 > > > > > > U-Boot is still doing wrong, > and core developers in U-Boot do not understand this, unfortunately. While this works in many cases we do seem to have problems with some toolchains. Perhaps things are better now as my problems were a a few years back. Things like size_t with %z caused problems too. I remember m68k producing warnings when I tried this. I am certainly interested in converting over to this other approach. I am also OK with the PRi stuff, since it only affects a relatively small number of cases. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] serial: stm32: Replace setparity by setconfig
Hi Patrice,
On 1 August 2018 at 09:58, Patrice Chotard wrote:
> Replace stm32_serial_setparity by stm32_serial_setconfig
> which allows to set serial bits number, parity and stop
> bits number.
> Only parity setting is implemented.
>
> Signed-off-by: Patrick Delaunay
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v2:
> - Update stm32_serial_setconfig prototype
>
> drivers/serial/serial_stm32.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
Reviewed-by: Simon Glass
Please see below.
Also I worry about bisectability. U-Boot should always build every
commit and I worry that your previous patch will break things, fixed
by this patch.
>
> diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
> index f26234549c3e..53866a23e6fc 100644
> --- a/drivers/serial/serial_stm32.c
> +++ b/drivers/serial/serial_stm32.c
> @@ -47,20 +47,28 @@ static int stm32_serial_setbrg(struct udevice *dev, int
> baudrate)
> return 0;
> }
>
> -static int stm32_serial_setparity(struct udevice *dev, enum serial_par
> parity)
> +static int stm32_serial_setconfig(struct udevice *dev, uint serial_config)
> {
> struct stm32x7_serial_platdata *plat = dev_get_platdata(dev);
> bool stm32f4 = plat->uart_info->stm32f4;
> u8 uart_enable_bit = plat->uart_info->uart_enable_bit;
> u32 cr1 = plat->base + CR1_OFFSET(stm32f4);
> u32 config = 0;
> -
> - if (stm32f4)
> - return -EINVAL; /* not supported in driver*/
> + u8 parity = SERIAL_GET_PARITY(serial_config);
> + u8 bits = SERIAL_GET_BITS(serial_config);
> + u8 stop = SERIAL_GET_STOP(serial_config);
I don't see the benefit of using u8 here. Isn't uint good enough?
> +
> + /*
> +* only parity config is implemented, check if other serial settings
> +* are the default one.
> +* (STM32F4 serial IP didn't support parity setting)
> +*/
> + if (bits != SERIAL_8_BITS || stop != SERIAL_ONE_STOP || stm32f4)
> + return -ENOTSUPP; /* not supported in driver*/
>
> clrbits_le32(cr1, USART_CR1_RE | USART_CR1_TE | BIT(uart_enable_bit));
> /* update usart configuration (uart need to be disable)
> -* PCE: parity check control
> +* PCE: parity check enable
> * PS : '0' : Even / '1' : Odd
> * M[1:0] = '00' : 8 Data bits
> * M[1:0] = '01' : 9 Data bits with parity
> @@ -77,6 +85,7 @@ static int stm32_serial_setparity(struct udevice *dev, enum
> serial_par parity)
> config = USART_CR1_PCE | USART_CR1_M0;
> break;
> }
> +
> clrsetbits_le32(cr1,
> USART_CR1_PCE | USART_CR1_PS | USART_CR1_M1 |
> USART_CR1_M0,
> @@ -210,7 +219,7 @@ static const struct dm_serial_ops stm32_serial_ops = {
> .pending = stm32_serial_pending,
> .getc = stm32_serial_getc,
> .setbrg = stm32_serial_setbrg,
> - .setparity = stm32_serial_setparity
> + .setconfig = stm32_serial_setconfig
> };
>
> U_BOOT_DRIVER(serial_stm32) = {
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: fdt: Make fdt_del_subnodes/fdt_del_partition static
On 31 July 2018 at 06:32, Michal Simek wrote: > These functions are only called in this file that's why make them static > to keep static analysers happy. > > Signed-off-by: Michal Simek > --- > > common/fdt_support.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/13] regmap: Improve error handling
On 31 July 2018 at 04:01, Mario Six wrote: > ofnode_read_simple_addr_cells may fail and return a negative error code. > Check for this when initializing regmaps. > > Also check if both_len is zero, since this is perfectly possible, and > would lead to a division-by-zero further down the line. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > drivers/core/regmap.c | 17 + > 1 file changed, 17 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-dm (take 2)
Hi Tom, Here is another attempt. The build is here: https://travis-ci.org/sglass68/u-boot/builds/410948863 The following changes since commit 61523dde17d1539b8ea361e25909acfdfc465155: Merge tag 'arc-updates-for-2018.09-rc2' of git://git.denx.de/u-boot-arc (2018-08-01 09:26:15 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git for you to fetch changes up to cee02e6ff422fdb8b543a8097b84a9682785f46d: binman: Adjust _GetPropTree() parameters (2018-08-01 16:30:48 -0600) Simon Glass (28): binman: Don't depend on dict order in ELF testOutsideFile() binman: Rename 'position' to 'offset' binman: Add comments to elf_test binman: Tidy up some comments in the tests binman: Enhance the map and fdt-update output binman: Add a new 'image-pos' property dtoc: Add missing comments to fdt_util binman: Add support for passing arguments to entries binman: Support an entry that holds text binman: Allow help to work without libfdt binman: Expand documentation for entries binman: Allow creation of entry documentation binman: Create README.entries binman: Add support for flashrom FMAP binman: Add support for a cros_ec image binman: Add an entry filled with a repeating byte dtoc: Export the _FindNode() function patman: Allow test commands to fall back to real ones patman: Add a few more helpers to the tools library binman: Add support for Chromium GBB patman: Show the current directory in GetInputFilename() dtoc: Add a function to obtain a list of phandles binman: Add an entry for a Chromium vblock binman: Add support for adding TPL binaries binman: Show the image position in the map binman: Rename ReadContents() to ReadBlobContents() binman: Add a test to catch use of the old 'pos' property binman: Adjust _GetPropTree() parameters arch/arm/dts/sunxi-u-boot.dtsi | 2 +- arch/arm/dts/tegra-u-boot.dtsi | 6 +- arch/x86/dts/u-boot.dtsi | 24 +-- common/spl/spl.c | 4 +- common/spl/spl_ram.c | 2 +- include/spl.h| 2 +- tools/binman/README | 135 +++-- tools/binman/README.entries | 585 tools/binman/binman.py | 22 ++- tools/binman/bsection.py | 153 +-- tools/binman/cmdline.py | 6 +- tools/binman/control.py | 35 - tools/binman/elf.py | 10 +- tools/binman/elf_test.py | 33 + tools/binman/entry.py| 267 ++--- tools/binman/etype/_testing.py | 47 +- tools/binman/etype/blob.py | 16 +- tools/binman/etype/blob_named_by_arg.py | 34 + tools/binman/etype/cros_ec_rw.py | 22 +++ tools/binman/etype/fill.py | 32 tools/binman/etype/fmap.py | 61 tools/binman/etype/gbb.py| 96 tools/binman/etype/intel_cmc.py | 10 ++ tools/binman/etype/intel_descriptor.py | 26 +++- tools/binman/etype/intel_fsp.py | 14 ++ tools/binman/etype/intel_me.py | 15 ++ tools/binman/etype/intel_mrc.py | 11 ++ tools/binman/etype/intel_vbt.py | 10 ++ tools/binman/etype/intel_vga.py | 12 ++ tools/binman/etype/section.py| 48 -- tools/binman/etype/text.py | 57 +++ tools/binman/etype/u_boot.py | 16 ++ tools/binman/etype/u_boot_dtb.py | 9 ++ tools/binman/etype/u_boot_dtb_with_ucode.py | 22 ++- tools/binman/etype/u_boot_img.py | 11 ++ tools/binman/etype/u_boot_nodtb.py | 11 ++ tools/binman/etype/u_boot_spl.py | 21 +++ tools/binman/etype/u_boot_spl_bss_pad.py | 16 ++ tools/binman/etype/u_boot_spl_dtb.py | 11 +- tools/binman/etype/u_boot_spl_nodtb.py | 12 ++ tools/binman/etype/u_boot_tpl.py | 43 ++ tools/binman/etype/u_boot_tpl_dtb.py | 25 tools/binman/etype/u_boot_ucode.py | 12 +- tools/binman/etype/u_boot_with_ucode_ptr.py | 44 +++--- tools/binman/etype/vb
Re: [U-Boot] [PATCH 04/20] W1-EEPROM: Add an W1-EEPROM uclass for 1 wire EEPROMs
Hi, On 30 July 2018 at 20:06, Tom Rini wrote: > On Mon, Jul 30, 2018 at 11:54:51AM +0300, Eugen Hristev wrote: >> >> >> On 20.07.2018 17:28, Maxime Ripard wrote: >> >Hi Eugen, >> > >> >Thanks for giving those patches another shot. >> > >> >On Thu, Jul 19, 2018 at 12:57:52PM +0300, Eugen Hristev wrote: >> >>From: Maxime Ripard >> >> >> >>We might want to access data stored onto one wire EEPROMs. >> >>Create a framework to provide a consistent API. >> >> >> >>Signed-off-by: Maxime Ripard >> >>[eugen.hris...@microchip.com: reworked patch] >> >>Signed-off-by: Eugen Hristev >> >>--- >> >> drivers/Kconfig | 2 ++ >> >> drivers/Makefile | 1 + >> >> drivers/w1-eeprom/Kconfig| 17 +++ >> >> drivers/w1-eeprom/Makefile | 2 ++ >> >> drivers/w1-eeprom/w1-eeprom-uclass.c | 56 >> >> >> >> include/dm/uclass-id.h | 1 + >> >> include/w1-eeprom.h | 28 ++ >> >> 7 files changed, 107 insertions(+) >> >> create mode 04 drivers/w1-eeprom >> >> create mode 100644 drivers/w1-eeprom/Kconfig >> >> create mode 100644 drivers/w1-eeprom/Makefile >> >> create mode 100644 drivers/w1-eeprom/w1-eeprom-uclass.c >> >> create mode 100644 include/w1-eeprom.h >> > >> >I believe that we shouldn't have a framework solely for 1-wire >> >EEPROMs, but for EEPROMs, connected to any bus. >> > >> >The 1-Wire EEPROMs all behave pretty much the same, so we'll probably >> >only see a single driver within that framework. And at the same time, >> >we'll want to have a consistent interface to access all the EEPROMs, >> >no matter on which bus they sit on. >> >> Hello, >> >> I worked this series using the original implementation as a starting point: >> having the eeproms on different subsystems (i2c and onewire). >> >> The different types of eeproms have only the name in common as I see it, and >> the way to access them is totally different: two different type of buses, so >> uniting them is just for the namesake ? >> >> One option is to have them separately, as we have spi, i2c memories , etc; >> Or, unite them under a single subsystem for eeproms, and have one driver for >> i2c eeproms and one for w1 eeproms, trying to make the same API to access >> them, and hide the bus specific differences. >> >> Question for maintainers: which is the best direction to go, so I can rework >> the series accordingly ? > > It would be nice if we had a generic eeprom command that wasn't > bus-centric. Unfortunately we have an eeprom command that IS bus > centric and not easily extended to working on all appropriate buses. So > to me, starting out by handing w1 eeproms under w1 seems OK. And we can > put it on the TODO list to make cmd/eeprom.c parse as perhaps > "BUSTYPE:number" so we could do eeprom w1:0 ... or eeprom i2c:0 ... and > so forth. That makes sense to me. We could provide some sort of read/write device supported by SPI, I2C, 1wire, etc. in principle. I don't think anyone has attempted it yet. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/13] test: regmap: Increase size of syscon0 memory
On 31 July 2018 at 04:00, Mario Six wrote: > The upcoming changes to the regmap interface will contain a proper check > for plausibility when reading/writing from/to a register map. To still > have the current tests pass, increase the size of the memory region for > the syscon0 device, since one of the tests reads and writes beyond this > range. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > arch/sandbox/dts/test.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] dm: serial: Replace setparity by setconfig
Hi Patrice,
On 1 August 2018 at 09:58, Patrice Chotard wrote:
> From: Patrick Delaunay
>
> Replace setparity by more generic setconfig ops
> to allow uart parity, bits word length and stop bits
> number change.
>
> Adds SERIAL_GET_PARITY/BITS/STOP macros.
>
> Signed-off-by: Patrick Delaunay
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v2:
> - Update SERIAL_BITS_MASK and SERIAL_STOP_MASK
> - Update serial_setconfig prototype
>
> drivers/serial/serial-uclass.c | 16
> include/serial.h | 42
> +++---
> 2 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index 321d23ee93bf..a7556c9b7bc3 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -287,6 +287,20 @@ void serial_setbrg(void)
> ops->setbrg(gd->cur_serial_dev, gd->baudrate);
> }
>
> +int serial_setconfig(uint config)
> +{
> + struct dm_serial_ops *ops;
> +
> + if (!gd->cur_serial_dev)
> + return 0;
> +
> + ops = serial_get_ops(gd->cur_serial_dev);
> + if (ops->setconfig)
> + return ops->setconfig(gd->cur_serial_dev, config);
> +
> + return 0;
> +}
> +
> void serial_stdio_init(void)
> {
> }
> @@ -398,6 +412,8 @@ static int serial_post_probe(struct udevice *dev)
> ops->pending += gd->reloc_off;
> if (ops->clear)
> ops->clear += gd->reloc_off;
> + if (ops->setconfig)
> + ops->setconfig += gd->reloc_off;
> #if CONFIG_POST & CONFIG_SYS_POST_UART
> if (ops->loop)
> ops->loop += gd->reloc_off
> diff --git a/include/serial.h b/include/serial.h
> index b9ef6d91c9c5..4f104f6a7188 100644
> --- a/include/serial.h
> +++ b/include/serial.h
> @@ -73,6 +73,39 @@ enum serial_par {
> SERIAL_PAR_EVEN
> };
>
> +#define SERIAL_PAR_MASK0x03
> +#define SERIAL_PAR_SHIFT 0
Sorry I should have said this explicitly, but can you please update
the other masks as well?
> +#define SERIAL_GET_PARITY(config) \
> + ((config & SERIAL_PAR_MASK) >> SERIAL_PAR_SHIFT)
> +
> +enum serial_bits {
> + SERIAL_5_BITS,
> + SERIAL_6_BITS,
> + SERIAL_7_BITS,
> + SERIAL_8_BITS
> +};
> +
> +#define SERIAL_BITS_SHIFT 2
> +#define SERIAL_BITS_MASK (0x3 << SERIAL_BITS_SHIFT)
> +#define SERIAL_GET_BITS(config) \
> + ((config & SERIAL_BITS_MASK) >> SERIAL_BITS_SHIFT)
> +
> +enum serial_stop {
> + SERIAL_HALF_STOP, /* 0.5 stop bit */
> + SERIAL_ONE_STOP,/* 1 stop bit */
> + SERIAL_ONE_HALF_STOP, /* 1.5 stop bit */
> + SERIAL_TWO_STOP /* 2 stop bit */
> +};
> +
> +#define SERIAL_STOP_SHIFT 4
> +#define SERIAL_STOP_MASK (0x3 << SERIAL_STOP_SHIFT)
> +#define SERIAL_GET_STOP(config) \
> + ((config & SERIAL_STOP_MASK) >> SERIAL_STOP_SHIFT)
> +
> +#define SERIAL_DEFAULT_CONFIG SERIAL_PAR_NONE << SERIAL_PAR_SHIFT | \
> + SERIAL_8_BITS << SERIAL_BITS_SHIFT | \
> + SERIAL_ONE_STOP << SERIAL_STOP_SHIFT
> +
> /**
> * struct struct dm_serial_ops - Driver model serial operations
> *
> @@ -150,15 +183,18 @@ struct dm_serial_ops {
> int (*loop)(struct udevice *dev, int on);
> #endif
> /**
> -* setparity() - Set up the parity
> +* setconfig() - Set up the uart configuration
> +* (parity, 5/6/7/8 bits word length, stop bits)
> *
> -* Set up a new parity for this device.
> +* Set up a new config for this device.
> *
> * @dev: Device pointer
> * @parity: parity to use
> +* @bits: bits number to use
> +* @stop: stop bits number to use
> * @return 0 if OK, -ve on error
> */
> - int (*setparity)(struct udevice *dev, enum serial_par parity);
> + int (*setconfig)(struct udevice *dev, uint serial_config);
> };
>
> /**
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] sandbox: Add serial test
On 1 August 2018 at 09:58, Patrice Chotard wrote:
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v2:
> - Add sandbox serial test
>
> drivers/serial/sandbox.c | 14 ++
> include/common.h | 1 +
> test/dm/Makefile | 1 +
> test/dm/serial.c | 26 ++
> 4 files changed, 42 insertions(+)
> create mode 100644 test/dm/serial.c
Reviewed-by: Simon Glass
How about also a test that checks it returns -ENOTSUPP when the wrong
options are specified?
>
> diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
> index a60dabe58835..94b4fdfb1714 100644
> --- a/drivers/serial/sandbox.c
> +++ b/drivers/serial/sandbox.c
> @@ -143,6 +143,19 @@ static int sandbox_serial_getc(struct udevice *dev)
> return result;
> }
>
> +static int sandbox_serial_setconfig(struct udevice *dev, uint serial_config)
> +{
> + u8 parity = SERIAL_GET_PARITY(serial_config);
> + u8 bits = SERIAL_GET_BITS(serial_config);
> + u8 stop = SERIAL_GET_STOP(serial_config);
> +
> + if (bits != SERIAL_8_BITS || stop != SERIAL_ONE_STOP ||
> + parity != SERIAL_PAR_NONE)
> + return -ENOTSUPP; /* not supported in driver*/
> +
> + return 0;
> +}
> +
> static const char * const ansi_colour[] = {
> "black", "red", "green", "yellow", "blue", "megenta", "cyan",
> "white",
> @@ -173,6 +186,7 @@ static const struct dm_serial_ops sandbox_serial_ops = {
> .putc = sandbox_serial_putc,
> .pending = sandbox_serial_pending,
> .getc = sandbox_serial_getc,
> + .setconfig = sandbox_serial_setconfig,
> };
>
> static const struct udevice_id sandbox_serial_ids[] = {
> diff --git a/include/common.h b/include/common.h
> index 940161f1758b..5c952af5e319 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -359,6 +359,7 @@ voidserial_putc_raw(const char);
> void serial_puts (const char *);
> intserial_getc (void);
> intserial_tstc (void);
> +intserial_setconfig(uint config);
>
> /* $(CPU)/speed.c */
> intget_clocks (void);
> diff --git a/test/dm/Makefile b/test/dm/Makefile
> index d2ed96c61533..97517c7f825e 100644
> --- a/test/dm/Makefile
> +++ b/test/dm/Makefile
> @@ -44,4 +44,5 @@ obj-$(CONFIG_DM_VIDEO) += video.o
> obj-$(CONFIG_ADC) += adc.o
> obj-$(CONFIG_SPMI) += spmi.o
> obj-$(CONFIG_WDT) += wdt.o
> +obj-$(CONFIG_DM_SERIAL) += serial.o
> endif
> diff --git a/test/dm/serial.c b/test/dm/serial.c
> new file mode 100644
> index ..4d8422eebd34
> --- /dev/null
> +++ b/test/dm/serial.c
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, STMicroelectronics
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int dm_test_serial(struct unit_test_state *uts)
> +{
> + struct udevice *dev_serial;
> +
> + ut_assertok(uclass_get_device_by_name(UCLASS_SERIAL, "serial",
> + &dev_serial));
> +
> + ut_assertok(serial_tstc());
> +
> + ut_assertok(serial_setconfig(SERIAL_DEFAULT_CONFIG));
> +
> + return 0;
> +}
> +
> +DM_TEST(dm_test_serial, DM_TESTF_SCAN_FDT);
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/13] regmap: Add documentation
On 31 July 2018 at 04:01, Mario Six wrote: > Document the regmap_alloc() function. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > drivers/core/regmap.c | 6 ++ > 1 file changed, 6 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/13] regmap: Fix documentation
Hi Mario, On 31 July 2018 at 04:00, Mario Six wrote: > The documentation in regmap.h is not in kernel-doc format. Correct this. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > New in v3 > > --- > include/regmap.h | 48 +++- > 1 file changed, 39 insertions(+), 9 deletions(-) Do we have a checker for this? Reviewed-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] ram: stm32mp1: use PRIx64 macros for printing ram size
On 26 July 2018 at 07:59, Philipp Tomsich wrote: > > With the recent changes of the underlying types for the ram size, we > need to adjust the formatting. Use PRIx64 to print the (now) u64 > field. > > Signed-off-by: Philipp Tomsich > --- > > arch/arm/mach-stm32mp/dram_init.c | 2 +- > drivers/ram/stm32mp1/stm32mp1_ram.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/5] gpio: stm32f7: Add ops get_function
On 1 August 2018 at 10:38, Patrice Chotard wrote: > From: Christophe Kerello > > This patch adds gpio get_function ops support. > This function reports the state of a gpio. > > Signed-off-by: Christophe Kerello > Signed-off-by: Patrice Chotard > --- > > drivers/gpio/stm32f7_gpio.c | 20 > 1 file changed, 20 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/13] misc: Add IHS FPGA driver
On 31 July 2018 at 04:01, Mario Six wrote: > Add a driver for gdsys IHS (Integrated Hardware Systems) FPGAs, which > supports initialization of the FPGA, as well as information gathering. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > * Fixed style violations > * Added full documentation > * Extracted some magic numbers to constants > * Removed unnecessary includes > * Extracted wait_for_fpga_done > * Improved error handling and reporting > * Added device-tree-binding files > * Improved Kconfig entry > > v1 -> v2: > New in v2 > > --- > .../devicetree/bindings/misc/gdsys,iocon_fpga.txt | 19 + > .../devicetree/bindings/misc/gdsys,iocpu_fpga.txt | 19 + > drivers/misc/Kconfig | 9 + > drivers/misc/Makefile | 1 + > drivers/misc/ihs_fpga.c| 867 > + > drivers/misc/ihs_fpga.h| 49 ++ > 6 files changed, 964 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/misc/gdsys,iocon_fpga.txt > create mode 100644 > Documentation/devicetree/bindings/misc/gdsys,iocpu_fpga.txt > create mode 100644 drivers/misc/ihs_fpga.c > create mode 100644 drivers/misc/ihs_fpga.h Reviewed-by: Simon Glass My only nit is that I prefer 'ret' for the return value instead of 'rc' or 'res', for consistency with driver model. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] net: sandbox: Add a priv ptr for tests to use
Hi, On 24 July 2018 at 15:40, Joe Hershberger wrote: Missing commit message - what is this for? > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 9 + > drivers/net/sandbox.c | 20 > 2 files changed, 29 insertions(+) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/13] misc: Add gdsys_soc driver
On 31 July 2018 at 04:01, Mario Six wrote: > This patch adds a driver for the bus associated with a IHS FPGA. > > Signed-off-by: Mario Six > --- > > v2 -> v3: > * Fixed style violations > * Added bindings file > * Added more debug output in case of errors > * Switched all printfs to debug > * Documented the private data structure > * Formatted documentation as proper kernel-doc > * Expanded Kconfig description > > v1 -> v2: > * Switched to correct uclass for IHS FPGA driver (now in MISC uclass) > > --- > .../devicetree/bindings/misc/gdsys,soc.txt | 16 + > drivers/misc/Kconfig | 9 +++ > drivers/misc/Makefile | 1 + > drivers/misc/gdsys_soc.c | 74 > ++ > drivers/misc/gdsys_soc.h | 23 +++ > 5 files changed, 123 insertions(+) > create mode 100644 Documentation/devicetree/bindings/misc/gdsys,soc.txt > create mode 100644 drivers/misc/gdsys_soc.c > create mode 100644 drivers/misc/gdsys_soc.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] net: sandbox: Make the fake eth driver response configurable
On 24 July 2018 at 15:40, Joe Hershberger wrote: > Make the send handler registerable so tests can check for different > things. > > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 17 ++ > drivers/net/sandbox.c | 53 > ++ > 2 files changed, 66 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: align carveout size
On 08/01/2018 06:06 PM, Tom Rini wrote: On Wed, Aug 01, 2018 at 11:52:36PM +, Tom Warren wrote: I can add this to my PR list (but probably won't get one out until tomorrow morning), or: Acked-by: Tom Warren If that'll get it in sooner. Applied, thanks! Thanks. The Jetson TK1 tests all look good again. Tom -Original Message- From: Tom Rini Sent: Wednesday, August 1, 2018 4:47 PM To: Stephen Warren Cc: Tom Warren ; u-boot@lists.denx.de; Simon Glass ; Stephen Warren ; Mark Kettenis ; Alexander Graf Subject: Re: [U-Boot] [PATCH] ARM: tegra: align carveout size On Wed, Aug 01, 2018 at 05:26:10PM -0600, Stephen Warren wrote: On 07/31/2018 12:38 PM, Stephen Warren wrote: From: Stephen Warren Align the size of the carveout region to 2M. This ensures that the size can be accurately represented by an LPAE page table that uses sections. This solves a bug (hang at boot time soon after printing the DRAM size) that only shows up when the following two commits are merged together: d32e86bde8a3 ARM: HYP/non-sec: enable ARMV7_LPAE if HYP mode is supported 6e584e633d10 ARM: tegra: avoid using secure carveout RAM Cc: Mark Kettenis Cc: Alexander Graf Signed-off-by: Stephen Warren --- This should be applied quickly since it fixes a regression that causes all boots to fail, which in turn causes test/py to reset and "reflash" the target board for each test, which causes the test to take eons. Could we apply this please? My Jenkins system will love you because of it:-) I'm looking for one more person to Ack this, thanks! -- Tom --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] net: Don't overwrite waiting packets with asynchronous replies
On 24 July 2018 at 15:40, Joe Hershberger wrote: > Peter originally sent a fix, but it breaks a number of other things. > This addresses the original reported issue in a different way. > > That report was: > >> U-Boot has 1 common buffer to send Ethernet frames, pointed to by >> net_tx_packet. When sending to an IP address without knowing the MAC >> address, U-Boot makes an ARP request (using the arp_tx_packet buffer) >> to find out the MAC address of the IP addressr. When a matching ARP >> reply is received, U-Boot continues sending the frame stored in the >> net_tx_packet buffer. >> >> However, in the mean time, if U-Boot needs to send out any network >> packets (e.g. replying ping packets or ARP requests for its own IP >> address etc.), it will use the net_tx_packet buffer to prepare the >> new packet. Thus this buffer is no longer the original packet meant >> to be transmitted after the ARP reply. The original packet will be >> lost. > > This instead uses the ARP tx buffer to send async replies in the case > where we are actively waiting for an ARP reply. > > Signed-off-by: Joe Hershberger > > Reported-by: Tran Tien Dat > --- > > include/net.h | 8 > net/arp.c | 9 + > net/arp.h | 1 + > net/net.c | 8 > net/ping.c| 7 +-- > test/dm/eth.c | 6 ++ > 6 files changed, 29 insertions(+), 10 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/10] test: eth: Add a test for the target being pinged
On 24 July 2018 at 15:40, Joe Hershberger wrote: > The target will respond to pings while doing other network handling. > Make sure that the response happens and is correct. > > This currently corrupts the ongoing operation of the device if it > happens to be awaiting an ARP reply of its own to whatever serverip it > is attempting to communicate with. In the test, add an expectation that > the user operation (ping, in this case) will fail. A later patch will > address this problem. > > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 9 + > drivers/net/sandbox.c | 51 ++ > test/dm/eth.c | 81 > ++ > 3 files changed, 141 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: don't allocate unusable RAM
On 08/01/2018 11:57 PM, Heinrich Schuchardt wrote: On 08/01/2018 06:17 PM, Stephen Warren wrote: On 08/01/2018 12:07 AM, Heinrich Schuchardt wrote: On 07/31/2018 09:44 PM, Stephen Warren wrote: From: Stephen Warren Some boards define a maximum usable RAM top that's more restrictive than the ranges defined by U-Boot's memory bank definitions[1]. In this case, the unusable RAM isn't mapped in the page tables, and so the EFI code must not attempt to allocate RAM from outside the usable regions. Fix efi_find_free_memory() to detect when max_addr is unconstrained or out of range, and substitue a valid value. In this case the board has to call efi_add_memory_map() to mark the reserved region (cf. board/raspberrypi/rpi/rpi.c) or have to mark the memory region as reserved in the device tree (see efi_carve_out_dt_rsv()). Please, check if the tegra boards with which you had problems do so. I don't think this makes sense; memory should be managed the same way within U-Boot no matter which part of U-Boot is consuming that memory. Memory regions are currently represented by the content of the memory bank definitions and gd->ram_top. Having different parts of the code define legal RAM usage in different ways is horribly inconsistent. Memory banks and gd->top together cannot reflect unusable memory regions in the middle of the RAM area. Sure this is possible. For example, a common set of memory banks for Tegra is: bank 0: start: 0x08000 length: 0x07000 limit: 0x0f000 bank 1: start: 0x1 length: 0x08000 limit: 0x18000 gd->ram_top = 0x0f000 That is set so that U-Boot itself (not just the UEFI code) doesn't use RAM above 4GB due to HW peripherals that can't access such RAM. The RAM above 4GB is left in the DRAM banks so that the kernel can use it for non-DMA purposes. That represents a hole at 0xf000..0x1. To be consistent reflect all information in the device tree and calculate gd->ram_top from the device tree information. Nothing in U-Boot that I'm aware of gets RAM information from DT. It all comes from the banks in gd. That's set up by some early low level code in arch/arm/mach-tegra/board2.c, which at least upstream hard-codes the size of the RAM gap below 4G rather than getting information from either DT or the earlier FW loads. So, I'm not sure what DT has to do with this. At this point, I think the best thing is to revert aa909462d018 "efi_loader: efi_allocate_pages is too restrictive" since it causes a regression on Jetson TX1, and we can work out the correct way to fix all this once the system is working again. The situation before the patch was really buggy. It is sufficient if you get the Jetson device tree right. What bugs specifically? Perhaps there's a better way to fix them. Anyway, there was agreement in other messages in the thread to revert the problematic patch to avoid breaking the code while we work on a more complete solution. That's about all I can do right now since I'm heading off on vacation for a couple of weeks and would rather we have a working U-Boot running in the test farm during that time so that any other bugs that are introduced get caught rather than hidden. I'll send the revert. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] dm: gpio: Add get_function_number ops
Hi Patrice,
On 1 August 2018 at 10:38, Patrice Chotard wrote:
> From: Patrick Delaunay
>
> When a pin is not configured as a GPIO, it could
> have several alternate function.
>
> To be able to identify the alternate function,
> add ops get_function_number() to request the pin
> function index from the driver when pin is not used
> as gpio.
>
> Signed-off-by: Patrick Delaunay
> Signed-off-by: Patrice Chotard
> ---
>
> drivers/gpio/gpio-uclass.c | 6 ++
> include/asm-generic/gpio.h | 11 +++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index da5e9ba6e524..fa249f7b12d4 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -568,6 +568,12 @@ int gpio_get_status(struct udevice *dev, int offset,
> char *buf, int buffsize)
> label ? label : "");
> }
>
> + if (func == GPIOF_FUNC && ops->get_function_number) {
> + ret = ops->get_function_number(dev, offset);
> + if (ret >= 0)
> + snprintf(str + len, buffsize - len, ": %d", ret);
> + }
> +
> return 0;
> }
>
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index d03602696f6d..f8cd6ddccbbf 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -266,6 +266,17 @@ struct dm_gpio_ops {
> int (*get_function)(struct udevice *dev, unsigned offset);
>
> /**
> +* get_function_number() Get the function number
> +*
> +* get index for GPIOF_FUNC, when pin is not used as a GPIO
> +*
> +* @dev: Device to check
> +* @offset: GPIO offset within that device
> +* @return current function index
> +*/
> + int (*get_function_number)(struct udevice *dev, unsigned int offset);
Can you please add comments as to how this is different from
get_function(), Also, I suggest a different name, since it would be
confusing for people to have such similar names for different things,
> +
> + /**
> * xlate() - Translate phandle arguments into a GPIO description
> *
> * This function should set up the fields in desc according to the
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/10] net: sandbox: Move disabled flag into priv struct
On 24 July 2018 at 15:40, Joe Hershberger wrote: > Store the per-device data with the device. > > Signed-off-by: Joe Hershberger > --- > > drivers/net/sandbox.c | 18 ++ > 1 file changed, 14 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] net: sandbox: Refactor sandbox send function
Hi Joe,
On 24 July 2018 at 15:40, Joe Hershberger wrote:
> Make the behavior of the send function reusable.
>
> Signed-off-by: Joe Hershberger
> ---
>
> arch/sandbox/include/asm/eth.h | 20 +
> drivers/net/sandbox.c | 176
> -
> 2 files changed, 124 insertions(+), 72 deletions(-)
>
> diff --git a/arch/sandbox/include/asm/eth.h b/arch/sandbox/include/asm/eth.h
> index bfcd11b593..00062616a4 100644
> --- a/arch/sandbox/include/asm/eth.h
> +++ b/arch/sandbox/include/asm/eth.h
> @@ -13,4 +13,24 @@ void sandbox_eth_disable_response(int index, bool disable);
>
> void sandbox_eth_skip_timeout(void);
>
> +/*
> + * sandbox_eth_arp_req_to_reply()
> + *
> + * Check for an arp request to be sent. If so, inject a reply
comments for args?
> + *
> + * returns 1 if injected, 0 if not
> + */
> +int sandbox_eth_arp_req_to_reply(struct udevice *dev, void *packet,
> +unsigned int len);
> +
> +/*
> + * sandbox_eth_ping_req_to_reply()
> + *
> + * Check for a ping request to be sent. If so, inject a reply
> + *
> + * returns 1 if injected, 0 if not
> + */
> +int sandbox_eth_ping_req_to_reply(struct udevice *dev, void *packet,
> + unsigned int len);
> +
> #endif /* __ETH_H */
> diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c
> index 60fe065ee5..5746af11a6 100644
> --- a/drivers/net/sandbox.c
> +++ b/drivers/net/sandbox.c
> @@ -63,6 +63,108 @@ void sandbox_eth_skip_timeout(void)
> skip_timeout = true;
> }
>
> +/*
> + * sandbox_eth_arp_req_to_reply()
> + *
> + * Check for an arp request to be sent. If so, inject a reply
> + *
> + * returns 1 if injected, 0 if not
> + */
> +int sandbox_eth_arp_req_to_reply(struct udevice *dev, void *packet,
> +unsigned int len)
> +{
> + struct eth_sandbox_priv *priv = dev_get_priv(dev);
> + struct ethernet_hdr *eth = packet;
> + struct arp_hdr *arp;
> + struct ethernet_hdr *eth_recv;
> + struct arp_hdr *arp_recv;
> +
> + if (ntohs(eth->et_protlen) != PROT_ARP)
> + return 0;
It seems odd to put this check here? Why not check it before calling
this function?
> +
> + arp = packet + ETHER_HDR_SIZE;
> +
> + if (ntohs(arp->ar_op) != ARPOP_REQUEST)
> + return 0;
> +
> + /* store this as the assumed IP of the fake host */
> + priv->fake_host_ipaddr = net_read_ip(&arp->ar_tpa);
> +
> + /* Formulate a fake response */
> + eth_recv = (void *)priv->recv_packet_buffer;
> + memcpy(eth_recv->et_dest, eth->et_src, ARP_HLEN);
> + memcpy(eth_recv->et_src, priv->fake_host_hwaddr, ARP_HLEN);
> + eth_recv->et_protlen = htons(PROT_ARP);
> +
> + arp_recv = (void *)eth_recv + ETHER_HDR_SIZE;
> + arp_recv->ar_hrd = htons(ARP_ETHER);
> + arp_recv->ar_pro = htons(PROT_IP);
> + arp_recv->ar_hln = ARP_HLEN;
> + arp_recv->ar_pln = ARP_PLEN;
> + arp_recv->ar_op = htons(ARPOP_REPLY);
> + memcpy(&arp_recv->ar_sha, priv->fake_host_hwaddr, ARP_HLEN);
> + net_write_ip(&arp_recv->ar_spa, priv->fake_host_ipaddr);
> + memcpy(&arp_recv->ar_tha, &arp->ar_sha, ARP_HLEN);
> + net_copy_ip(&arp_recv->ar_tpa, &arp->ar_spa);
> +
> + priv->recv_packet_length = ETHER_HDR_SIZE + ARP_HDR_SIZE;
> +
> + return 1;
> +}
> +
[..]
> + sandbox_eth_arp_req_to_reply(dev, packet, length);
> + sandbox_eth_ping_req_to_reply(dev, packet, length);
Here functions are called unconditionally, but presumably only at most
one function will do anything.
>
> return 0;
> }
> --
> 2.11.0
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/10] test: eth: Add a test for ARP requests
On 24 July 2018 at 15:40, Joe Hershberger wrote: > This tests that ARP requests made to this target's IP address are > responded-to by the target when it is doing other networking operations. > > This currently corrupts the ongoing operation of the device if it > happens to be awaiting an ARP reply of its own to whatever serverip it > is attempting to communicate with. In the test, add an expectation that > the user operation (ping, in this case) will fail. A later patch will > address this problem. > > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 9 + > drivers/net/sandbox.c | 41 + > test/dm/eth.c | 81 > ++ > 3 files changed, 131 insertions(+) Nice! Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10] net: Add an accessor to know if waiting for ARP
On 24 July 2018 at 15:40, Joe Hershberger wrote: > This single-sources the state of the ARP. > > Signed-off-by: Joe Hershberger > --- > > include/net.h | 1 + > net/arp.c | 11 --- > 2 files changed, 9 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] net: sandbox: Share the priv structure with tests
On 24 July 2018 at 15:40, Joe Hershberger wrote: > If tests want to implement tx handlers, they will likely need access to > the details in the priv structure. > > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 19 +++ > drivers/net/sandbox.c | 19 --- > 2 files changed, 19 insertions(+), 19 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis: give every job a name
On 07/30/2018 10:19 AM, Stephen Warren wrote: From: Stephen Warren Travis CI now supports giving jobs an explicit name. Do this for all jobs. This allows more direct control over jobs names than the previous automatic or implicit naming based on the environment variables or script text. Does this look good? Note that I'm on vacation the next 2 weeks, so won't be able to respond to any comments on this patch soon, for a while. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] net: sandbox: Allow fake eth to handle more than 1 packet response
On 24 July 2018 at 15:40, Joe Hershberger wrote: > Use up to the max allocated receive buffers so be able to test more > complex situations. > > Signed-off-by: Joe Hershberger > --- > > arch/sandbox/include/asm/eth.h | 10 +--- > drivers/net/sandbox.c | 57 > ++ > 2 files changed, 52 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis: give every job a name
On Thu, Aug 02, 2018 at 11:08:30AM -0600, Stephen Warren wrote: > On 07/30/2018 10:19 AM, Stephen Warren wrote: > >From: Stephen Warren > > > >Travis CI now supports giving jobs an explicit name. Do this for all jobs. > >This allows more direct control over jobs names than the previous > >automatic or implicit naming based on the environment variables or script > >text. > > Does this look good? Note that I'm on vacation the next 2 weeks, so won't be > able to respond to any comments on this patch soon, for a while. Ah, sorry. Yes, I like this idea, but I've already made it not quite apply cleanly. I'll fix it up and apply soon. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Revert "efi_loader: efi_allocate_pages is too restrictive"
From: Stephen Warren
This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change
caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for
example when running test/py.
Reverting this change isn't optimal, but at least restores TX1 to a working
state. In the future, we should:
a) Fix whatever problem causes the crash with this patch applied. This
needs further discussion, so isn't something we can immediately do.
b) Undo the revert; re-apply the original patch to efi_allocate_pages.
Cc: Heinrich Schuchardt
Cc: Alexander Graf
Signed-off-by: Stephen Warren
---
lib/efi_loader/efi_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 967c3f733e4c..4b6269f35e11 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -305,7 +305,7 @@ efi_status_t efi_allocate_pages(int type, int memory_type,
switch (type) {
case EFI_ALLOCATE_ANY_PAGES:
/* Any page */
- addr = efi_find_free_memory(len, -1ULL);
+ addr = efi_find_free_memory(len, gd->start_addr_sp);
if (!addr) {
r = EFI_NOT_FOUND;
break;
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Talos Security Advisory (TALOS-2018-0633/CVE-2018-3968 )
Hello, Cisco Talos team discovered a security issue impacting Cujo product using an outdated version of U-boot. We’ve assigned a CVE for this issue (CVE-2018-3968) and have attached a copy of the security advisory provided to Cujo. <> ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Hi Johann,
On 2 August 2018 at 07:20, Johann Neuhauser
wrote:
> Hello Simon,
>
>> > Dear U-Boot devs,
>> >
>> > I've setup verified boot on a imx6 board and want to protect my device
>> against the "mix and match" attacks mentioned in
>> "doc/uImage.FIT/signature.txt".
>> > That's why I have only implemented signed configurations and no signed
>> images as in doc/uImage.FIT/signed-configs.its.
>> > My public key in my embedded fdt has the property required = "conf";
>> >
>> > Booting a signed config with "bootm ${loadaddr}#conf@1" and an
>> embedded public key required for configurations does work as expected and
>> do fail to boot if I modify the config, image, hash, signature and so on.
>> >
>> > If I boot any fit image(signed and unsigned) for example with "bootm
>> ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot
>> every image combination without signature verification although a signature
>> is enforced for a configuration.
>> >
>> > Is this the expected behavior?
>> >
>> > I thought if I had set the public key in in the embedded fdt as required
>> > for
>> configurations, bootm does only boot signed configurations and no
>> subimages directly...
>>
>> I don't think there is any restriction on that at the moment. You are
>> explicitly
>> asking to boot particular images rather than a config. So I suppose it would
>> be
>> odd if U-Boot tried to enforce a config. Are you thinking it should try to
>> find a
>> config that has those images in it?
>
> No, I expected that I cannot boot sub images directly if there is a required
> public key for a configuration.
> After a dive into the bootm source I think this is not easily possible to
> enforce this behavior.
It should be easy enough to change fit_image_load() to return an error
if fit_uname_configp doesn't have a config.
>
>> But why not just specify the config to bootm?
>
> At first I wanted to use a simple boot script wrapped in a fit image
> (unsigned) and
> have only the needed commands enabled in U-Boot.
> Now I switched to a signed U-Boot script as boot script and can be sure that
> this one gets not tampered.
> The only bad thing is here that the source command does only have support for
> fit sub images and
> I have to sign the config and the image of my system image if I had a
> required certificate for images and configs.
I don't quite get this, sorry. What is a FIT sub-image? Do you mean a
FIT image? You can actually sign individual images if you want to, but
as the docs mention, this is not fully secure since it is vulnerable
to mix-and-match attacks.
But if do want to group images together, so that only certain ones can
be used together, then a FIT config is the mechanism for that. You
must sign each config simple because otherwise there is nothing
protecting against the attack.
>
> Probably this behavior should be mentioned in the doc.
Please send a patch.
>
> Many thanks for the clarification.
You are welcome. But I suspect I have misunderstood this in some way,
so let me know :-)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "efi_loader: efi_allocate_pages is too restrictive"
On 2 August 2018 at 11:45, Stephen Warren wrote: > From: Stephen Warren > > This reverts commit aa909462d01866354f4cd4534db5f571c2cf1fbb. This change > caused "dhcp filename" to crash the system on p2371-2180 (Jetson TX1), for > example when running test/py. > > Reverting this change isn't optimal, but at least restores TX1 to a working > state. In the future, we should: > > a) Fix whatever problem causes the crash with this patch applied. This > needs further discussion, so isn't something we can immediately do. > > b) Undo the revert; re-apply the original patch to efi_allocate_pages. > > Cc: Heinrich Schuchardt > Cc: Alexander Graf > Signed-off-by: Stephen Warren > --- > lib/efi_loader/efi_memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 1/2] power: domain: Add the VPU Power Domain driver
Hi Neil, On 26 July 2018 at 07:54, Neil Armstrong wrote: > The Amlogic Meson SoCs embeds a specific Power Domain dedicated to the > Video Processing Unit. > This patch implements support for this power domain in preparation of the > future support for the Video display support in U-Boot. > > This driver will depend on changes in the clock driver to handle the setup > of the VPU and VAPB clocks configured from DT using assigned-clocks entries. > > Signed-off-by: Neil Armstrong > --- > drivers/power/domain/Kconfig | 7 ++ > drivers/power/domain/Makefile| 1 + > drivers/power/domain/meson-gx-pwrc-vpu.c | 198 > +++ > 3 files changed, 206 insertions(+) > create mode 100644 drivers/power/domain/meson-gx-pwrc-vpu.c > Reviewed-by: Simon Glass Are the delays documented in a datasheet? I suggest adding a comment about them. People will otherwise forever wonder how the values were chosen. Also it seems odd that you can't power everything up at once. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 2/2] clk: clk_meson: Add mux and div support for reparent and rate setting
On 26 July 2018 at 07:54, Neil Armstrong wrote: > This patch adds support for : > - Rate calculation through muxes and generic dividers > - Basic gate setting propagation > - Reparenting for muxes > - Clock rate setting through generic dividers without reparenting > > Support is only added to the Composite VPU and VAPB clocks in order > to support the Video Processing Unit Power Domain clock setup. > > Signed-off-by: Neil Armstrong > --- > drivers/clk/clk_meson.c | 533 > +++- > 1 file changed, 528 insertions(+), 5 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/21] sandbox: Update test.dts for dynamic PCI device driver matching
Hi Bin, On 29 July 2018 at 07:37, Bin Meng wrote: > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/sandbox/dts/test.dts | 16 ++-- > 1 file changed, 2 insertions(+), 14 deletions(-) But doesn't this mean we lose testing of the device-tree config? We need to keep that. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] board: keymile: add explicit cast to truncate the 64bit ram size field
On 26 July 2018 at 07:59, Philipp Tomsich wrote: > With the change to a 64bit ram size field for 32bit architectures, we need > to add an explicit cast to truncate when converting to a pointer. > This casts to 'void*' through 'uintptr_t'. > > Signed-off-by: Philipp Tomsich > --- > > board/keymile/km_arm/km_arm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] rockchip: rk3368: change type of ram-size field for a min()-calculation
Hi Phiipp, On 26 July 2018 at 07:59, Philipp Tomsich wrote: > With the recent changes of the underlying types for the ram size, we need > to cast the constant used in clamping to u64 instead of size_t. > > Signed-off-by: Philipp Tomsich > --- > > drivers/ram/rockchip/dmc-rk3368.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass > > diff --git a/drivers/ram/rockchip/dmc-rk3368.c > b/drivers/ram/rockchip/dmc-rk3368.c > index 8d1b9fa..35d7605 100644 > --- a/drivers/ram/rockchip/dmc-rk3368.c > +++ b/drivers/ram/rockchip/dmc-rk3368.c > @@ -960,7 +960,7 @@ static int rk3368_dmc_probe(struct udevice *dev) > * is SoC register space (i.e. reserved), and 0xfe00~0xfeff is > * inaccessible for some IP controller. > */ > - priv->info.size = min(priv->info.size, (size_t)0xfe00); > + priv->info.size = min(priv->info.size, (u64)0xfe00); Why case at all? Is it because min() is a macro? > > return 0; > } > -- > 2.1.4 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/21] test: dm: pci: Add tests for mixed static and dynamic devices on the same bus
On 29 July 2018 at 07:37, Bin Meng wrote: > In the Sandbox test configuration, PCI bus#0 only has static devices > while bus#1 only has dynamic devices. Create a bus#2 that has both > types of devices and test such. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/sandbox/dts/test.dts | 18 ++ > test/dm/pci.c | 63 > +++ > 2 files changed, 81 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 20/21] dm: pci: Add APIs to find capability and extended capability
On 29 July 2018 at 07:37, Bin Meng wrote: > This introduces two new APIs dm_pci_find_capability() and > dm_pci_find_ext_capability() to get PCI capability address and > PCI express extended capability address for a given PCI device. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - Mask header_type with 0x7f > > drivers/pci/pci-uclass.c | 68 > > include/pci.h| 46 > 2 files changed, 114 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 12/17] cmd: fpga: Fix loadfs command
On 26 July 2018 at 08:16, Michal Simek wrote: > Convert loadfs command to fpga subcommands. > > Signed-off-by: Michal Simek > --- > > Changes in v1: None > > cmd/fpga.c | 58 -- > 1 file changed, 28 insertions(+), 30 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/21] dm: pci: Fix scanning multi-function device
On 29 July 2018 at 07:36, Bin Meng wrote: > The flag to control whether to scan multi-function device during > enumeration should be cleared at the beginning of each iteration > if the device's function number equals to zero. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/pci/pci-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass Oops! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/21] dm: core: Add ofnode function to read PCI vendor and device id
On 29 July 2018 at 07:36, Bin Meng wrote: > We don't have the live-tree version of fdtdec_get_pci_vendev(). > This adds the API. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/core/ofnode.c | 36 > include/dm/ofnode.h | 13 + > 2 files changed, 49 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/21] pci: sandbox: swap_case: Preserve space indicator bit in BAR registers
On 29 July 2018 at 07:36, Bin Meng wrote: > With the newly added testing of more than one device, we get: > > => ut dm pci_swapcase > Test: dm_test_pci_swapcase: pci.c > test/dm/pci.c:88, dm_test_pci_swapcase(): "tHIS IS A tESt" = ptr: > Expected "tHIS IS A tESt", got "this is a test" > Test: dm_test_pci_swapcase: pci.c (flat tree) > test/dm/pci.c:88, dm_test_pci_swapcase(): "tHIS IS A tESt" = ptr: > Expected "tHIS IS A tESt", got "this is a test" > Failures: 2 > > The failure only happens on the 2nd swap_case device on the PCI bus. > The case passes on the 1st device. > > It turns out the swap_case driver does not emulate bit#0 in BAR > registers as a read-only bit. This corrects the implementation. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/misc/swap_case.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/21] pci: sandbox: emul: Fix the call to pci_bus_find_devfn()
On 29 July 2018 at 07:37, Bin Meng wrote: > With the newly added test cases for PCI configuration access, we get: > > => ut dm pci_busdev > Test: dm_test_pci_busdev: pci.c > test/dm/pci.c:49, dm_test_pci_busdev(): SANDBOX_PCI_VENDOR_ID == vendor: > Expected 4660, got 65535 > Test: dm_test_pci_busdev: pci.c (flat tree) > test/dm/pci.c:49, dm_test_pci_busdev(): SANDBOX_PCI_VENDOR_ID == vendor: > Expected 4660, got 65535 > Failures: 2 > > The bug only shows up when bus number is not equal to zero. This is > caused by the plain find_devfn parameter is passed to function call > pci_bus_find_devfn(), inside which find_devfn is compared to devfn > in the device's pplat structure. However pplat->devfn does not carry > the bus number. Fix this by passing find_devfn with bus number masked. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > drivers/pci/pci-emul-uclass.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Nice to find this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
