[U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script

This patch series does $SUBJ. The first patch changes the way the existing linker scripts locate the boot page, reset vector, and bss section. This method works for any size of u-boot image (the previous one didn't work images that weren't 512K) and any location flash is mapped to. At this

[U-Boot] [PATCH 4/4] Use ALIGN() in mpc85xx linker script

It wasn't used in one instance where the end of the rotext section is aligned to 256 bytes. Maybe this alignment isn't necessary? I have to wonder about the alignment of the .data.init and .text.init sections too, since they don't appear to even exist. Signed-off-by: Trent Piepho [EMAIL

[U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page

of the linker script is the same for all mpc85xx targets, maybe it should be placed into an include file instead of duplicated? Signed-off-by: Trent Piepho [EMAIL PROTECTED] --- board/freescale/mpc8536ds/u-boot.lds | 11 +-- board/freescale/mpc8540ads/u-boot.lds | 11 +-- board

Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page

On Tue, 14 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: The boot page and reset vector need to be at the absolute address 0xf000 and 0xfffc, respectively, when the CPU boots. ... To handle to both different U-Boot image sizes and flash locations, what we do

Re: [U-Boot] [PATCH 2/4] Merge all mpc85xx platforms to use a single ld script

On Tue, 14 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: B) The U-Boot image is over 4MB in size. The image size for this is from TEXT_BASE to the end of the reset vector. It's not the size of the U-Boot code as there could be a huge gap between the end of the code

Re: [U-Boot] [PATCH 3/4] Improve mpc85xx link script rodata section

On Tue, 14 Oct 2008, Wolfgang Denk wrote: Dear Trent Piepho, In message [EMAIL PROTECTED] you wrote: A recent gcc added a new unaligned rodata section called '.rodata.str1.1' and that needs to be added the the linker script. Rather than just add that one section, instead use '*(.rodata

Re: [U-Boot] [PATCH 2/4] Merge all mpc85xx platforms to use a single ld script

On Tue, 14 Oct 2008, Wolfgang Denk wrote: Dear Trent Piepho, In message [EMAIL PROTECTED] you wrote: B) The U-Boot image is over 4MB in size. The image size for this is from TEXT_BASE to the end of the reset vector. It's not the size of the U-Boot code as there could be a huge gap between

Re: [U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script

On Tue, 14 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: U-Boot should *never* assume static flash bank sizes. The whole design is based on the idea to automatically determine the actual size of flash and RAM that is fit on a specific board, and to

Re: [U-Boot] [PATCH 2/4] Merge all mpc85xx platforms to use a single ld script

On Tue, 14 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: This is where bss goes when u-boot is linked. It gets relocated to a different address in ram. Where is defined which address it is, then? It is determined at run time. Look in cpu/mpc85xx/start.S at

Re: [U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page

On Tue, 14 Oct 2008, Wolfgang Denk wrote: Dear Trent, in message [EMAIL PROTECTED] you wrote: This data doesn't exist in the board config file. The linker scripts already in effect contain this data. I have a calculation that uses the flash bank size. What's there now is the result of a

Re: [U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script

On Wed, 15 Oct 2008, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: All the mpc85xx platforms hard code the size of the flash via the local bus No, they don't. Name one that doesn't. controller settings. For example, if you look in include/configs/MPC8572DS.h you will find

Re: [U-Boot] [PATCH] Align end of bss by 4 bytes.

On Thu, 16 Oct 2008, Selvamuthukumar wrote: Most of the bss initialization loop increments 4 bytes at a time. And the loop end is checked for an 'equal' condition. Make the bss end address aligned by 4, so that the loop will end as expected. It's not really the end of bss that matters, but

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Fri, May 3, 2013 at 5:08 PM, Marek Vasut ma...@denx.de wrote: On 4/25/2013 6:13 PM, Marek Vasut wrote: I didn't really track the thread and I'm plenty busy, besides I had quite a clash with Trent in another thread, sorry about me being plenty unpleasant. Anyway, can you please sum

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Mon, Mar 18, 2013 at 5:50 PM, Paul B. Henson hen...@acm.org wrote: I'm prototyping a project that's going to need to boot linux from NAND on a mx28evk board. I was able to successfully use the u-boot mxsboot utility to generate a nand image and burn it, then boot from it. I noticed one

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Apr 5, 2013 9:28 PM, Paul B. Henson hen...@acm.org wrote: On 4/4/2013 3:09 AM, Trent Piepho wrote: It's something to do with the way u-boot writes to nand. If I write with nandwrite it doesn't happen, nandtest doesn't find any bad Hmm, I'm pretty sure I tested burning the u-boot

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

I don't think the image u-boot mxsboot generates includes any OOB data. For me, it made an image which is *exactly* 24 blocks of 128 kiB each. If the FCB blocks had OOB data then there would need to be some multiple of 64 OBB bytes in the image (16 kiB I would think). I think maybe this is

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Thu, Apr 11, 2013 at 11:33 AM, Paul B. Henson hen...@acm.org wrote: On 4/11/2013 5:03 AM, Trent Piepho wrote: What one should actually do to flash these blocks is write 2048 bytes in raw mode. I guess that would only work if whatever reading the blocks also read them in raw mode

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Sat, Apr 13, 2013 at 7:42 AM, Marek Vasut ma...@denx.de wrote: Dear Paul B. Henson, Let me just preface this reply with the disclaimer that I'm fairly new to embedded development, and it sounds like you know a lot more about what you're talking about than I do ;). [...] I'm not reading

Re: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad blocks

On Fri, Apr 19, 2013 at 6:03 PM, Paul B. Henson hen...@acm.org wrote: On 4/11/2013 4:25 PM, Trent Piepho wrote: Maybe it would make more sense for mxsboot to write two files? One with the FCBs and one with everything else? Hmm, possibly; I guess that would be conceptually simpler

Re: [U-Boot] [PATCH] Fix all linker script to handle all rodata sections

On Sun, 16 Aug 2009, Wolfgang Denk wrote: ... I change this to: *(.text) . = ALIGN(16); *(.eh_frame) *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) Unfortunately it turns out that this breaks some older tool chains. For example, using ELDK 3.1 (binutils 2.14-5) we get:

Re: [U-Boot] [PATCH] Fix Freescale link scripts for newer GCCs

On Wed, 21 Jan 2009, Kim Phillips wrote: On Wed, 7 Jan 2009 18:29:54 -0500 This addresses the problem described here: http://lists.denx.de/pipermail/u-boot/2008-December/045029.html This changes the link scripts of several of the mpcXXX CPUs to include everything from '.rodata'. Without

Re: [U-Boot] [PATCH] Fix Freescale link scripts for newer GCCs

On Sat, 31 Jan 2009, Wolfgang Denk wrote: In message pine.lnx.4.64.0901310259430.8...@t2.domain.actdsltmp you wrote: so, what's the status of this patch? I've seen this fail on 83xx. Most of these types of patches that fix the newer gcc's behaviour have been dropped, one of which even

Re: [U-Boot] [PATCH] Fix Freescale link scripts for newer GCCs

On Wed, 18 Feb 2009, Wolfgang Denk wrote: He. Of course I can only ask to provide patch that, to the best of Trent's experience, is supposed to fix the problems. I am aware thatthere is a chance that it will not work on some boards, but then it's up to the board maintainers to

Re: [U-Boot] [PATCH v4] Update U-Boot's build timestamp on every compile

On Fri, 31 Oct 2008, Peter Tyser wrote: +$(TIMESTAMP_FILE): + @( printf '#define U_BOOT_DATE %s\n' '$(shell date +%b %d %C%y)' \ + ) $@ + @( printf '#define U_BOOT_TIME %s\n' '$(shell date +%T)' \ + ) $@ You could do this: @date

[U-Boot] [PATCH] Section name should be .data not data

Signed-off-by: Trent Piepho [EMAIL PROTECTED] --- drivers/i2c/fsl_i2c.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c index 281a88b..3b5c06b 100644 --- a/drivers/i2c/fsl_i2c.c +++ b/drivers/i2c/fsl_i2c.c @@ -38,11

Re: [U-Boot] NAND only (no NOR)

On Wed, 3 Dec 2008, Sean MacLennan wrote: Yes, I would recommend to do it this way if possible. A small NOR for U-Boot and environment and everything else in NAND. This makes things much easier. But I understand that this is sometimes a problem with space (2 FLASH chips) and costs. Mainly

[U-Boot] [PATCH 3/5] mpc86xx: Double local bus clock divider

The local bus clock divider should be doubled for both 8610 and 8641. Signed-off-by: Trent Piepho [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] --- cpu/mpc86xx/cpu.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/cpu

[U-Boot] [PATCH 2/5] mpc8568: Double local bus clock divider

-by: Trent Piepho [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] --- cpu/mpc85xx/cpu.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c index 59a9ac8..89800b8 100644 --- a/cpu/mpc85xx

[U-Boot] [PATCH 5/5] mpc8[56]xx: Put localbus clock in device tree

of the 86xx systems and is also looked for by the Linux code. On MPC8641, I've also used fsl,mpc8641-localbus as it is also commonly used in dts files, some of which don't use fsl,elbc or any other acceptable name to match on. Signed-off-by: Trent Piepho [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL

[U-Boot] [PATCH 4/5] mpc8[56]xx: Put localbus clock in sysinfo and gd

will print out the local bus frequency from sysinfo, like the other frequencies, instead of calculating it on the spot. Signed-off-by: Trent Piepho [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] --- cpu/mpc85xx/cpu.c | 31

[U-Boot] [PATCH 1/5] mpc8xxx: LCRR[CLKDIV] is sometimes five bits

LCRR_CLKDIV. Signed-off-by: Trent Piepho [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] --- board/freescale/mpc8540ads/mpc8540ads.c |2 +- board/freescale/mpc8541cds/mpc8541cds.c |2 +- board/freescale/mpc8548cds/mpc8548cds.c |2 +- board

Re: [U-Boot] [PATCH v4] mmc: socfpga_dw_mmc: Enable calibration for drvsel and smplsel

On Fri, 2015-11-27 at 15:22 +0800, Chin Liang See wrote: > Enable SDMMC calibration to determine the best setting for > drvsel and smplsel. Calibration will be triggered if the > drvsel and smplsel node are not available in DTS. We have a Cyclone V based board and on the latest revision the SD

Re: [U-Boot] [PATCH v4] mmc: socfpga_dw_mmc: Enable calibration for drvsel and smplsel

On Wed, 2016-01-27 at 21:13 +0800, Chin Liang See wrote: > On Wed, 2016-01-27 at 00:01 +0000, Trent Piepho wrote: > > On Fri, 2015-11-27 at 15:22 +0800, Chin Liang See wrote: > > > Enable SDMMC calibration to determine the best setting for > > > drvsel and smplsel. Ca

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

On Tue, 2018-05-08 at 05:29 +, Peng Fan wrote: > > -Original Message- > > From: Trent Piepho [mailto:tpie...@impinj.com] > > Sent: 2018年5月8日 6:07 > > To: christian.gmei...@gmail.com; Peng Fan <peng@nxp.com>; Anson > > Huang <ans

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote: > Add i.MX7 PSCI system reset support, linux > kernel now can use "reboot" command to reset > system. > +__secure void imx_system_reset(void) > +{ > + writew(1 << 2, WDOG1_BASE_ADDR); > +} This does not work properly on our board. Due

Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

On Wed, 2018-05-09 at 01:13 +, Peng Fan wrote: > > +0800, Anson Huang wrote: > > > > > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot" > > > > > command to reset system. > > > > > > > > > > > > > +__secure void imx_system_reset(void) { > > > > > + writew(1 << 2,

Re: [U-Boot] [PATCH 04/12] Net: phy: ti: Fix fifo_depth register write

On Thu, 2018-06-14 at 10:53 +, u-boot-requ...@lists.denx.de wrote: > Message: 52 > Date: Thu, 14 Jun 2018 11:48:48 +0200 > From: Janine Hagemann > To: albert.u.b...@aribaud.net, s...@chromium.org, > philipp.toms...@theobroma-systems.com, w.ego...@phytec.de, >

[U-Boot] [PATCH] rtc: Add read8 and write8 support to isl1208 driver

This can be used for device register access from board code. This allows access to capabilities in the RTC chip not abstracted in U-Boot's RTC class. E.g., device NVRAM or a tamper detection circuit. Cc: Klaus Goger Cc: Philipp Tomsich Cc: Simon Glass Signed-off-by: Trent Piepho

[U-Boot] [PATCH] imx: mx7: psci: Add support for version command

k anything, as the incorrect version and correct version are both >= 1.0, but as soon as a check for > 1.0 goes in it will fail. CC: Anson Huang Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Signed-off-by: Trent Piepho --- arch/arm/mach-imx/mx7/psci.S | 10 ++ 1 file changed, 10 ins

Re: [U-Boot] [PATCH] power: pmic: Let PFUZE3000 see all 256 registers

Ping. Been a while. 2018.05 is out. On Thu, 2018-04-26 at 03:22 -0300, Fabio Estevam wrote: > On Wed, Apr 25, 2018 at 2:06 PM, Trent Piepho > wrote: > > The PFUZE3000 uses registers addresses up to 0xff. > > > > The DM pfuze100 driver supports both pfuze1

Re: [U-Boot] [PATCH] imx: mx7: psci: Add support for version command

On Fri, 2018-06-22 at 11:09 +0200, Stefan Agner wrote: > On 31.05.2018 20:13, Trent Piepho wrote: > > This command should be supported for PSCI 1.0. Current code results in > > this message from the kernel: "PSCIv65535.65535 detected in firmware." > > >

Re: [U-Boot] [PATCH] Makefile: drop mention of *.cfgtmp

On Mon, 2018-06-18 at 06:57 +0300, Baruch Siach wrote: > Since commit f916757300 (imx: Create distinct pre-processed mkimage > config files), *.cfgtmp files are no longer generated. There is no need > to remove them on the 'clean' target anymore. > > Remove also the .gitignore glob. I didn't

Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

On Mon, 2018-07-16 at 23:56 +, Henry Beberman wrote: > > > > > > > > I need to revise the commit message for this patch. The script is not > > > fixed > > > > to the first partition of the selected MMC, it scans the disk for partitions > > marked bootable, then checks each one of those

Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

On Tue, 2018-07-17 at 01:41 +, Henry Beberman wrote: > > -Original Message- > > From: Trent Piepho > > Sent: Monday, July 16, 2018 11:22 AM > > To: Henry Beberman ; u- > > b...@lists.denx.de > > Cc: fabio.este...@nxp.com; adrian.alo...@nxp.com &g

Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote: > From: Henry Beberman > > This patch enables i.MX platforms to easily add a boot script to their > U-Boot Proper environment to automatically load and execute an EFI > firmware from the first FAT partition of an MMC device. Is there a

Re: [U-Boot] [PATCH 04/11] spl: imx: Add optional lds to keep SPL entirely in on-chip RAM

On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote: > From: Henry Beberman > > This patch is part of the i.MX Windows 10 IoT Core boot flow. > > It adds a modified linker script for SPL to keep all segments in > on-chip ram. This is to harden the device against potential leaks of > device

Re: [U-Boot] [PATCH 06/11] mx7dsabresd: Add Windows boot support for iMX7 Sabre

On Sat, 2018-07-14 at 00:11 +, Henry Beberman wrote: > From: Henry Beberman > > This patch adds a new bootable configuration for Windows 10 IoT Core on > the i.MX7 Dual Sabre board. > > It enables SPL on the i.MX7 Sabre in order to support the FIT load of > OP-TEE and U-Boot proper. > >

Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI from mmc

On Mon, 2018-07-16 at 22:28 +, Henry Beberman wrote: > Hi Trent, > > > -Original Message- > > From: Trent Piepho > > Sent: Monday, July 16, 2018 10:17 AM > > To: Henry Beberman ; u- > > b...@lists.denx.de > > Cc: tr...@konsulko.com; fabi

Re: [U-Boot] Fwd: Parallel build is broken

On Wed, 2018-09-05 at 06:57 -0500, Adam Ford wrote: > On Wed, Sep 5, 2018 at 3:46 AM Alex Kiernan wrote: > > > > On Tue, Sep 4, 2018 at 3:54 PM Andy Shevchenko > > wrote: > > > > > > On Tue, Sep 4, 2018 at 5:50 PM Andy Shevchenko > > > wrote: > > > > > > > > On Tue, Sep 4, 2018 at 5:00 PM

Re: [U-Boot] SoCFPGA PL330 DMA driver and ECC scrubbing

On Wed, 2018-07-11 at 08:56 -0500, Jason Rush wrote: > On 7/11/2018 8:48 AM, Marek Vasut wrote: > > On 07/11/2018 03:49 PM, Jason Rush wrote: > > > > > > My mistake. I did disable the dcache after scrubbing too. The > > > code is almost identical to the Arria10 code where after > > > scrubbing

[U-Boot] [PATCH] imx: Create distinct pre-processed mkimage config files

the build bug referenced in b5b0e4e3 ("imximage: Remove failure when no IVT offset is found"). Cc: Breno Lima <breno.l...@nxp.com> Cc: Thomas Petazzoni <thomas.petazz...@bootlin.com> Cc: Fabio Estevam <fabio.este...@nxp.com> Signed-off-by: Trent Piepho <tpie...@imp

Re: [U-Boot] [U-Boot, v3] imximage: Remove failure when no IVT offset is found

On Fri, 2018-03-09 at 08:25 -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Sometimes imximage throws the following error: > > CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp > CFGSboard/freescale/vf610twr/imximage.cfg.cfgtmp > MKIMAGE u-boot-dtb.imx

[U-Boot] [PATCH] power: pmic: Let PFUZE3000 see all 256 registers

3000_" prefixed enumerations and the pfuze100 enumeration value PFUZE100_NUM_OF_REGS. Cc: Peng Fan <peng@freescale.com> Cc: Jaehoon Chung <jh80.ch...@samsung.com> Cc: Stefano Babic <sba...@denx.de> Cc: Fabio Estevam <fabio.este...@nxp.com> Signed-off-by: Trent Piepho

Re: [U-Boot] [U-Boot,V4,1/2] mmc: add HS400 support

I didn't see HS400 working on my IMX7d, even thought it appears it should be supported. The problem appears to be when this bit of code in fsl_esdhc.c, which dates to a patch "mmc: fsl_esdhc: support SDR104 and HS200": static struct esdhc_soc_data usdhc_imx7d_data = { .flags =

[U-Boot] [PATCH] power: pfuze100: Fix off by one error in voltage table handling

The code that sets a regulator by looking up the voltage in a table had an off by one error. vsel_mask is a bitmask, not the number of table entries, so a vsel_mask value of 0x7 indicates there are 8, not 7, entries in the table. Cc: Peng Fan Cc: Jaehoon Chung Signed-off-by: Trent Piepho

Re: [U-Boot] [U-Boot,V4,1/2] mmc: add HS400 support

On Thu, 2019-03-28 at 03:42 +0100, Marek Vasut wrote: > On 3/27/19 9:43 PM, Trent Piepho wrote: > > I didn't see HS400 working on my IMX7d, even thought it appears it > > should be supported. > > > > Alternatively, there is a property that can be added to the devi

[U-Boot] [PATCH] bootm: Simplying cache flush code

of the flushed region by subtracting the former from the latter. Cc: Tom Rini Cc: Simon Glass Cc: Bryan O'Donoghue Signed-off-by: Trent Piepho --- common/bootm.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/common/bootm.c b/common/bootm.c index 8bf84ebcb7..8af8efd169

[U-Boot] [PATCH] mmc: Move FSL_ESDHC under if MMC

looks like a rebase mistake in the original commit that added it, as it would behaved as expected if just moved up a bit in the file. Cc: Peng Fan Cc: Mario Six Cc: Jaehoon Chung Signed-off-by: Trent Piepho --- drivers/mmc/Kconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletion

[U-Boot] [PATCH] mmc: Move tegra loopback disable option to be under tegra

as if it's some kind of generic MMC configuration option. Cc: Marcel Ziswiler Cc: Simon Glass Cc: Jaehoon Chung Cc: Tom Warren Signed-off-by: Trent Piepho --- drivers/mmc/Kconfig | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/mmc/Kconfig b/d

[U-Boot] [PATCH 1/2] i2c: mxc_i2c: Document how non-DM functions work

boards. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent Piepho --- drivers/i2c/mxc_i2c.c | 34 ++ 1 file changed, 34 insertions(+) diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c index

[U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

t more invasive and obviously no one has every wanted them since they've never worked. It didn't seem like the extra complexity was justified to support something no one uses. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by:

[U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode

controllers and setting the speed when really it's doing nothing. Cc: Sriram Dash Cc: Priyanka Jain Cc: Heiko Schocher Signed-off-by: Trent Piepho --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index

[U-Boot] [PATCH] net: eth-uclass: No warning for using ROM MAC

Using a ROM burned in MAC address is the normal way devices that have this ability will store their MAC. It's normal operation and a warning message isn't appropriate. Make it a debug message, as it is in non-DM_ETH code paths that do this. Signed-off-by: Trent Piepho --- net/eth-uclass.c | 3

[U-Boot] [PATCH] net: phy: ti: Fix clock output DT property

if value overflows. For instance, if one were to add 0x as a code to mean the clock output should be turned off. Cc: Joe Hershberger Cc: Janine Hagemann Cc: Grygorii Strashko Signed-off-by: Trent Piepho --- drivers/net/phy/ti.c | 16 +--- 1 file changed, 5 insertions(+), 11

[U-Boot] [PATCH] core: ofnode: Have ofnode_read_u32_default return a u32

obvious one is meant to use ofnode_read_s32_default() with signed values. Cc: Simon Glass Signed-off-by: Trent Piepho --- drivers/core/ofnode.c | 2 +- include/dm/ofnode.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c

[U-Boot] [PATCH 1/2] cmd: mii: Refactor some of the MII reg dump code

the field. Change reg > max+1 into reg >= max, which doesn't fail if max+1 could overflow, besides just making more sense. Signed-off-by: Trent Piepho --- cmd/mii.c | 154 -- 1 file changed, 69 insertions(+), 85 deletions(-)

[U-Boot] [PATCH 2/2] cmd: mii: Add the standard 1000BASE-T registers

These are standard across gigabit phys. These mostly extend the auto-negotiation information with gigabit fields. Signed-off-by: Trent Piepho --- cmd/mii.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/cmd/mii.c b/cmd/mii.c index

[U-Boot] [PATCH] net: phy: ti: Use default values for tx/rx delay and fifo size

: Janine Hagemann Cc: Grygorii Strashko Signed-off-by: Trent Piepho --- drivers/net/phy/ti.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c index 6db6edd0d0..33f5687e0e 100644 --- a/drivers/net/phy/ti.c +++ b/drivers/net/phy/ti.c

Re: [U-Boot] [PATCH v2 1/2] wandboard: Don't use I2C speed Kconfig settings with DM_I2C

On Thu, 2019-05-09 at 08:20 +0200, Anatolij Gustschin wrote: > On Wed, 8 May 2019 23:30:01 + > Trent Piepho tpie...@impinj.com wrote: > ... > > diff --git a/board/wandboard/wandboard.c > > b/board/wandboard/wandboard.c > > index 69fbc8b690..9d7a94ff9d 10064

[U-Boot] [PATCH v2 1/2] wandboard: Don't use I2C speed Kconfig settings with DM_I2C

that they do not control the bus speed. Otherwise it is quite easy to mistakenly believe they are used to set the bus speed. Cc: Heiko Schocher Cc: Anatolij Gustschin Signed-off-by: Trent Piepho --- board/wandboard/wandboard.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions

[U-Boot] [PATCH v2 2/2] i2c: mxc: Hide kconfig based control in DM_I2C mode

: Priyanka Jain Cc: Heiko Schocher Signed-off-by: Trent Piepho --- Changes from v1: Added patch in series to fix wandboard build issue Enable settings if SPL is enabled, as SPL will not use DM_I2C drivers/i2c/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote: > Hello Trent, > > Am 16.04.2019 um 00:02 schrieb Trent Piepho: > > This is an old driver that supports both device mapped and non-mapped > > mode, and covers a wide range of hardware. It's hard to change without

[U-Boot] [PATCH 2/2 v2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

t more invasive and obviously no one has every wanted them since they've never worked. It didn't seem like the extra complexity was justified to support something no one uses. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent

[U-Boot] [PATCH 1/2 v2] i2c: mxc_i2c: Document how non-DM functions work

boards. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent Piepho --- Changes from v1: None, re-sending as base64 to avoid Microsoft email mangling. drivers/i2c/mxc_i2c.c | 34 ++ 1 file changed

Re: [U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode

On Tue, 2019-04-30 at 09:20 +0200, Heiko Schocher wrote: > > Am 12.04.2019 um 21:19 schrieb Trent Piepho: > > > These options only apply when not using DM_I2C. When using device > > > trees, the dt will enable and control the speeds of the I2C > > > controller(s

Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode

On Thu, 2019-05-02 at 07:23 +0200, Heiko Schocher wrote: > Am 30.04.2019 um 18:04 schrieb Trent Piepho: > > On Tue, 2019-04-30 at 06:34 +0200, Heiko Schocher wrote: > > > Am 16.04.2019 um 00:02 schrieb Trent Piepho: > > > > This is an old driver that supports bot

Re: [U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode

On Thu, 2019-05-02 at 08:11 +0200, Anatolij Gustschin wrote: > Hi Heiko, > > On Thu, 2 May 2019 07:39:06 +0200 > Heiko Schocher h...@denx.de wrote: > ... > > > > @Anatolij: Is this code needed anymore, as board is moved to DM ? > > ... > > dm_i2c_probe should initialize the i2c bus completly,