Re: [U-Boot] [PATCH v4 0/4] configs: rk3288: Tinker Board SPL file must fit into 32 KiB

Hi Heinrich, On Wed, Apr 3, 2019 at 8:20 AM Heinrich Schuchardt wrote: > > On 4/3/19 2:59 AM, Kever Yang wrote: > > Hi Heinrich, > > > > > > On 04/03/2019 01:19 AM, Heinrich Schuchardt wrote: > >> The SPL image for the Tinker Board has to fit into 32 KiB. This includes > >> up to 2 KiB for the fi

Re: [U-Boot] [PATCH 37/41] mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue

Dear Peng Fan, Some other remarks. On Tue, May 29, 2018 at 3:45 AM, Peng Fan wrote: > > >> -Original Message----- >> From: Benoît Thébaudeau [mailto:benoit.thebaudeau@gmail.com] >> Sent: 2018年5月29日 6:32 >> To: Peng Fan >> Cc: sba...@denx.de; Fa

Re: [U-Boot] [PATCH 37/41] mmc: fsl_esdhc: fix sd/mmc ddr mode clock setting issue

Dear Peng Fan, On Mon, May 28, 2018 at 2:25 PM, Peng Fan wrote: > From: Ye Li > > When sd/mmc work at DDR mode, like HS400/HS400ES/DDR52/DDR50 mode, > the actual clock rate is just half of the expected clock. > > This patch set the DDR_EN bit first for DDR mode, hardware divide > the usdhc clock

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

On 25/01/2018 at 22:48, Benoît Thébaudeau wrote: > On Thu, Jan 25, 2018 at 2:06 PM, Michael Trimarchi > wrote: >> SION bit should be used in the situation that we need >> to read back the value of a pin and should not be set by >> default macro. >> >>

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

Hi Michael, On 26/01/2018 at 08:51, Michael Trimarchi wrote: > On Thu, Jan 25, 2018 at 10:48:42PM +0100, Benoît Thébaudeau wrote: >> On Thu, Jan 25, 2018 at 2:06 PM, Michael Trimarchi >> wrote: >>> SION bit should be used in the situation that we need >>> to

Re: [U-Boot] [PATCH V3] imx: mx25: Remove SION bit in all pin-mux that are safe

ed I²C features can be considered board-specific, so SION would still not be required in iomux-mx25.h. In the end, for this patch, apart from the pending test for FEC MDIO: Reviewed-by: Benoît Thébaudeau Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

On 25/01/2018 at 11:17, Michael Nazzareno Trimarchi wrote: > On Thu, Jan 25, 2018 at 11:02 AM, Benoît Thébaudeau > wrote: >> You said that setting SION only for a UART is enough to trigger your USB >> issue. >> Of course, there is no reason to set SION by defau

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi Michael, On 25/01/2018 at 06:47, Michael Nazzareno Trimarchi wrote: > On 25 Jan. 2018 12:07 am, "Fabio Estevam" > wrote: > > Hi Michael, > > On Wed, Jan 24, 2018 at 3:46 PM, Michael Nazzareno Trimarchi > mailto:mich...@amarulasolutions.com>> > wrote: >

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi Fabio, On 24/01/2018 at 18:21, Fabio Estevam wrote: > On Wed, Jan 24, 2018 at 3:12 PM, Michael Nazzareno Trimarchi > wrote: > >> From the datasheet I have: >> >> Software Input On Field. Force the selected mux mode Input path no >> matter of MUX_MODE functionality. >> 1: Force input path of p

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

On 24/01/2018 at 18:12, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 6:05 PM, Benoît Thébaudeau wrote: >> Hi Michael, >> >> On 24/01/2018 at 17:46, Michael Nazzareno Trimarchi wrote: >>> On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: >>&

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi Michael, On 24/01/2018 at 17:46, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 5:38 PM, Fabio Estevam wrote: >> Hi Michael, >> >> [Removed usb list as this is off-topic for them] >> >> On Wed, Jan 24, 2018 at 2:31 PM, Michael Nazzareno Trimarchi >> wrote: >> >>> Can you check w

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi, On 24/01/2018 at 17:17, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 5:03 PM, Benoît Thébaudeau wrote: >> On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote: >>> On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau >>> wrote: >>

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

On 24/01/2018 at 16:43, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 4:39 PM, Benoît Thébaudeau wrote: >> On 24/01/2018 at 16:34, Benoît Thébaudeau wrote: >>> On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: >>>> On Wed, Jan 24, 2018 at

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

On 24/01/2018 at 16:34, Benoît Thébaudeau wrote: > On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: >> On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote: >>> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi >>> wrote: >>>> SION bit shoul

Re: [U-Boot] [PATCH] imx: mx25: Remove SION bit in all pin-mux

Hi Michael, On 24/01/2018 at 16:26, Michael Nazzareno Trimarchi wrote: > On Wed, Jan 24, 2018 at 4:14 PM, Fabio Estevam wrote: >> On Wed, Jan 24, 2018 at 12:56 PM, Michael Trimarchi >> wrote: >>> SION bit should be used in the situation that we need >>> to read back the value of a pin and should

[U-Boot] [PATCH v2] mmc: fsl_esdhc: Fix i.MX53 eSDHCv3 clock

controller. Signed-off-by: Benoît Thébaudeau Reviewed-by: Fabio Estevam --- Changes for v2: - Surround == with parentheses for clarity (suggested by Stefano). --- drivers/mmc/fsl_esdhc.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/f

Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix i.MX53 eSDHCv3 clock

Hi Stefano, On Mon, Jan 15, 2018 at 11:59 AM, Stefano Babic wrote: > On 15/01/2018 00:46, Benoît Thébaudeau wrote: >> + int pre_div = regs == (struct fsl_esdhc *)MMC_SDHC3_BASE_ADDR ? 2 : 1; > > It is surely a question of taste - but is it not cleared to surround the &g

[U-Boot] [PATCH] mmc: fsl_esdhc: Fix i.MX53 eSDHCv3 clock

controller. Signed-off-by: Benoît Thébaudeau --- drivers/mmc/fsl_esdhc.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 499d622c6d..90425e8a30 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -528,

Re: [U-Boot] [PATCH v3 1/3] mx25: Move MX25 selection to Kconfig

Hi Stefano, Tom, On Tue, Nov 7, 2017 at 10:10 AM, Stefano Babic wrote: > On 07/11/2017 02:22, Tom Rini wrote: >> On Mon, Nov 06, 2017 at 09:44:40PM -0200, Fabio Estevam wrote: >>> Hi Stefano and Tom, >>> >>> On Fri, Nov 3, 2017 at 1:40 PM, Fabio Estevam wrote: From: Fabio Estevam

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On Fri, Nov 3, 2017 at 4:17 PM, Fabio Estevam wrote: > On Sun, Oct 29, 2017 at 7:18 PM, Benoît Thébaudeau > wrote: > >> Of course we can, but CONFIG_SYS_FSL_ERRATUM_ESDHC_A001 seems to be >> the most optimal approach here, so I'll wait for the answer from

Re: [U-Boot] [PATCH v3 1/3] mx25: Move MX25 selection to Kconfig

selection method also aligns with the way other i.MX SoCs are > selected in U-Boot. > > Signed-off-by: Fabio Estevam > Acked-by: Sebastien Bourdelin [...] For the series: Reviewed-by: Benoît Thébaudeau ___ U-Boot mailing list U-Boot@li

Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix PIO timeout

On Tue, Oct 31, 2017 at 4:18 PM, Jagan Teki wrote: > On Mon, Oct 30, 2017 at 2:38 AM, Benoît Thébaudeau > wrote: >> The following error has been observed on i.MX25 with a high-speed SDSC >> card: >> Data Write Failed in PIO Mode. >> >> It was caused by th

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On Tue, Oct 24, 2017 at 10:50 AM, Fabio Estevam wrote: > On Mon, Oct 23, 2017 at 8:45 PM, Benoît Thébaudeau > wrote: > >> The issue is the timeout in esdhc_setup_data() on line 309. If I >> revert e978a31b and fb823981, then everything works fine. However, the >

[U-Boot] [PATCH] mmc: fsl_esdhc: Fix PIO timeout

timeout, all the blocks are properly written. This timeout was implemented by decrementing a variable, so it was depending on the CPU frequency. Fix this issue by setting this timeout to a long enough absolute duration (500 ms). Signed-off-by: Benoît Thébaudeau Cc: Stefano Babic Cc: Fabio Estevam Cc

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On Sat, Oct 21, 2017 at 2:38 PM, Fabio Estevam wrote: > On Sat, Oct 21, 2017 at 10:34 AM, Benoît Thébaudeau > wrote: > >> I already have a mainline version working at HS with changes only in >> fsl_esdhc.c (apart from the port of my board). I still have to narrow

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On Fri, Oct 20, 2017 at 8:40 PM, Fabio Estevam wrote: > On Fri, Oct 20, 2017 at 10:40 AM, Benoît Thébaudeau > wrote: > >> With mainline U-Boot on my board, normal-speed SD cards work fine, but not HS >> ones. Both types of cards work fine at 48 MHz with my custom

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On 19/10/2017 at 13:57, Fabio Estevam wrote: > > I would be interested to see if you can get an SD card high speed to > work with mainline U-Boot on your board. > > On my tests I need to force it 25MHz operation to be able to use the SD card. With mainline U-Boot on my board, normal-s

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

On 19/10/2017 at 14:52, Fabio Estevam wrote: > On Thu, Oct 19, 2017 at 10:46 AM, Otavio Salvador > wrote: > >> I think the original RFC is better as workaround as it solves the >> issue for other boards. This does not mean we shouldn't fix the root >> cause ... > > Actually I don't know if this

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On Wed, Oct 18, 2017 at 7:35 PM, Fabio Estevam wrote: > On Wed, Oct 18, 2017 at 2:56 PM, Benoît Thébaudeau wrote: > >> I can tell you what to use for imx25pdk if you give me the pads used by the >> eSDHC instance in question here. > > mx25pdk uses the POR de

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On 18/10/2017 at 18:40, Fabio Estevam wrote: > On Wed, Oct 18, 2017 at 2:13 PM, Benoît Thébaudeau wrote: >> You can try to set the drive strength of all the eSDHC pads to high or max >> (for > > Looks like the eSDHC pins do not have drive strength control, onl

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

On 18/10/2017 at 18:13, Benoît Thébaudeau wrote: > Hi Fabio, > > On 18/10/2017 at 17:57, Fabio Estevam wrote: >> Currently when a high speed SD card is connected on MX25 or MX51 boards >> the following error happens: >> >> U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49

Re: [U-Boot] [RFC] mmc: fsl_esdhc: Do not set high speed mode on MX25 and MX51

Hi Fabio, On 18/10/2017 at 17:57, Fabio Estevam wrote: > Currently when a high speed SD card is connected on MX25 or MX51 boards > the following error happens: > > U-Boot 2017.11-rc2 (Oct 18 2017 - 13:49:26 -0200) > > CPU: Freescale i.MX51 rev3.0 at 800 MHz > Reset cause: POR > Board: MX51EVK

Re: [U-Boot] [PATCH v2] usb: fix usb_stor_read/write on DM

On Sat, Jul 15, 2017 at 12:06 AM, Marek Vasut wrote: > On 07/14/2017 11:46 PM, Benoît Thébaudeau wrote: >> On Fri, Jul 14, 2017 at 1:50 PM, Marek Vasut wrote: >>> On 07/14/2017 01:03 PM, Masahiro Yamada wrote: >>>> 2017-07-14 19:07 GMT+09:00 Marek Vasut : >>

Re: [U-Boot] [PATCH v2] usb: fix usb_stor_read/write on DM

platform or something. Looking at ohci-hcd.c, it limits the transfer size to (N_URB_TD - 2) * 4 KiB, with N_URB_TD set to 48, so the maximum number of transfers would depend on the MSC block size. dwc2.c, isp116x-hcd.c, r8a66597-hcd.c, and sl811-hcd.c do not seem to have any limit caused by these d

[U-Boot] [PATCH 4/4] mx25pdk: Set the eSDHC PER clock to 48 MHz

The maximum SD clock frequency in High Speed mode is 50 MHz. This change makes it possible to get 48 MHz from the USB PLL (240 MHz / 5 / 1) instead of the previous 33.25 MHz from the AHB clock (133 MHz / 2 / 2). Signed-off-by: Benoît Thébaudeau --- board/freescale/mx25pdk/mx25pdk.c | 6

[U-Boot] [PATCH 2/4] mx25: Fix imx_get_perclk()

imx_get_perclk() used the AHB clock as the clock source for all PER clocks, but the USB PLL output can also be a PER clock source if the corresponding PER CLK MUX bit is set in CCM.MCR. Signed-off-by: Benoît Thébaudeau --- arch/arm/cpu/arm926ejs/mx25/generic.c | 11 ++- 1 file changed

[U-Boot] [PATCH 1/4] mmc: fsl_esdhc: Allow all supported prescaler values

possible to get 48 MHz from the USB PLL (240 MHz / 5 / 1) instead of only 40 MHz from the USB PLL (240 MHz / 3 / 2) or 33.25 MHz from the AHB clock (133 MHz / 2 / 2). Signed-off-by: Benoît Thébaudeau --- drivers/mmc/fsl_esdhc.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions

[U-Boot] [PATCH 3/4] mx25: Add function to set PER clocks

Introduce the imx_set_perclk() function to make it possible to set the PER clocks. Signed-off-by: Benoît Thébaudeau --- arch/arm/cpu/arm926ejs/mx25/generic.c | 19 +++ arch/arm/include/asm/arch-mx25/clock.h | 1 + 2 files changed, 20 insertions(+) diff --git a/arch/arm/cpu

Re: [U-Boot] ARM - cache and alignment

Hi, On Tue, Jan 17, 2017 at 10:54 AM, Marek Vasut wrote: > On 01/17/2017 10:51 AM, Jean-Jacques Hiblot wrote: >> >> >> On 17/01/2017 10:38, Marek Vasut wrote: >>> On 01/17/2017 10:35 AM, Jean-Jacques Hiblot wrote: On 17/01/2017 10:15, Marek Vasut wrote: > On 01/17/2017 10:08 AM, Jea

Re: [U-Boot] DMA bounce buffer in FAT code

Dear Jean-Jacques, On Tue, Jan 10, 2017 at 12:35 PM, Jean-Jacques Hiblot wrote: > commits 8133f43d and cc63b25e introduced buffer bouncing at the level of the > FAT fs driver. I came across those because of printf() saying that the > buffer is not aligned when I save my env in file on a FAT parti

Re: [U-Boot] [PATCH 2/2] fs/fat: merge readwrite get_fatent_value() with readonly get_fatent()

ue(fsdata *mydata, __u32 entry) > -{ [...] > - debug("FAT%d: ret: %08x, entry: %08x, offset: %04x\n", > - mydata->fatsize, ret, entry, offset); It might be worth adding this entry info to the same line in get_fatent(

Re: [U-Boot] [PATCH 1/2] fs/fat: Avoid corruption of sectors following the FAT

here's a character encoding issue for the "ü" in your last name in "From:". It is correct in your "Signed-off-by:". Apart from that: Reviewed-by: Benoît Thébaudeau Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1] fat: fatwrite: fix the command for FAT12

Dear Stefan Brüns, On Sun, Dec 11, 2016 at 12:29 AM, Stefan Bruens wrote: > On Freitag, 9. Dezember 2016 13:55:37 CET Philipp Skadorov wrote: >> The u-boot command fatwrite empties FAT clusters from the beginning >> till the end of the file. >> Specifically for FAT12 it fails to detect the end of

Re: [U-Boot] [PATCH v1] fat: fatwrite: fix the command for FAT12

gt; The command then works correctly for all types of FAT. > > Signed-off-by: Philipp Skadorov > Cc:Donggeun Kim [...] Reviewed-by: Benoît Thébaudeau Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd/nand.c: Remove unnecessarily repeated step

Dear Ahmed Samir Khalil, On Mon, Oct 10, 2016 at 6:44 AM, Ahmed Samir Khalil wrote: > Getting the current NAND device is already done once as part > of nand command. Therefore, repeating this step as part of > the sub-commands is unnecessary. > > Signed-off-by: Ahmed Samir Khalil > --- > cmd/

Re: [U-Boot] [PATCH 1/4] fs/fat: Remove two statements without effect

Hi Stefan, On Sun, Sep 11, 2016 at 10:51 PM, Stefan Brüns wrote: > fatlength is a local variable which is no more used after the assignment. > s_name is not used in the function, save the strncpy. > > Signed-off-by: Stefan Brüns [...] For the series: Reviewed-by: Benoît Théba

Re: [U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3

Hi, On Fri, Sep 9, 2016 at 6:34 PM, Brüns, Stefan wrote: > On Sonntag, 14. August 2016 00:57:38 CEST Benoît Thébaudeau wrote: >> On Tue, Aug 2, 2016 at 9:35 PM, Benoît Thébaudeau >> >> wrote: >> > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren > wrote: >&g

Re: [U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3

Hi, On Tue, Aug 2, 2016 at 9:35 PM, Benoît Thébaudeau wrote: > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren wrote: >> On 07/28/2016 12:11 AM, Tien Fong Chee wrote: >>> >>> Single 64KB get_contents_vfatname_block global variable would be used for >>&g

Re: [U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3

Hi, On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren wrote: > On 07/28/2016 12:11 AM, Tien Fong Chee wrote: >> >> Single 64KB get_contents_vfatname_block global variable would be used for >> all FAT implementation instead of allocating additional two global >> variables >> which are get_denfromdir_

Re: [U-Boot] fatwrite issue in sub-directories

Hi Nicolas, On Wed, Jul 20, 2016 at 6:21 PM, Nicolas le bayon wrote: > Hi all, > > With a quite old u-boot release (October 2015 more or less), I has some > different issues around fatwrite operations. I realigned a few things > around FAT with latest release, and now I observe only one issue. Ma

Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

Dear Tien Fong, On Thu, Jul 14, 2016 at 12:48 PM, Tien Fong Chee wrote: > Dear Benoît, > > On Wed, 2016-07-13 at 12:56 +0200, Benoît Thébaudeau wrote: >> Dear Tien Fong Chee, >> >> On Jul 13, 2016 at 11:01 AM, Tien Fong Chee wrote: >> > Single 64KB get_con

Re: [U-Boot] [PATCH 2/2] fs/fat/fat: Optimizes memory size with single global variable instead of 3

ock. This implementation > can help in saving up 128KB memory space. > > Signed-off-by: Tien Fong Chee > Cc: Dinh Nguyen > Cc: Dinh Nguyen > Cc: ChinLiang > Cc: Vagrant Cascadian > Cc: Simon Glass > Cc: Stephen Warren > Cc: Benoît Thébaudeau > --- > fs/

Re: [U-Boot] [PATCH v3 2/2] nand: extend nand torture

quot; > + "torture offset [size]" >Torture block to determine if it is still reliable. >Enabled by the CONFIG_CMD_NAND_TORTURE configuration option. >This command returns 0 if the block is still reliable, else 1. > @@ -324,6 +324,10 @@ Miscellaneous and testin

Re: [U-Boot] [PATCH v2 2/2] nand: extend nand torture

Hi Max, On Thu, Jun 9, 2016 at 3:19 PM, Max Krummenacher wrote: > Hi Benoît, > > 2016-06-09 1:41 GMT+02:00 Benoît Thébaudeau : >> On Tue, Jun 7, 2016 at 1:46 PM, Max Krummenacher >> wrote: >>> diff --git a/cmd/nand.c b/cmd/nand.c >>> index 583a18f..8ade5e

Re: [U-Boot] [PATCH v2 2/2] nand: extend nand torture

Hi Max, On Tue, Jun 7, 2016 at 1:46 PM, Max Krummenacher wrote: > nand torture currently works on exactly one nand block which is specified > by giving the byteoffset to the beginning of the block. > > Extend this by allowing for a second parameter specifying the byte size > to be tested. > > e.g

Re: [U-Boot] [PATCH 2/2] nand: extend nand torture

Hi Max, On Tue, Jun 7, 2016 at 12:57 PM, Max Krummenacher wrote: > Hi Benoît, > > Thank you for your review. You're welcome. > I wanted to wait for Scott's patchseries to make it into master to > allow for potential needed > changes. No problem. > 2016-05-31 22

Re: [U-Boot] [PATCH 2/2] nand: extend nand torture

Dear Max Krummenacher, On Mon, May 30, 2016 at 4:28 PM, Max Krummenacher wrote: > nand torture currently works on exactly one nand block which is specified > by giving the byteoffset to the beginning of the block. > > Extend this by allowing for a second parameter specifying the byte offset > to

Re: [U-Boot] [PATCH 03/13] imx-common: use simpler runtime cpu dection macros

Hi Peng, On Fri, May 20, 2016 at 10:41 AM, Peng Fan wrote: > On Fri, May 20, 2016 at 01:02:10AM +0200, Benoît Thébaudeau wrote: >>On Wed, May 18, 2016 at 9:53 AM, Peng Fan wrote: >>> Use simpler runtime cpu dection macros. >>> >>> Signed-off-by: Peng Fan &

Re: [U-Boot] [PATCH 03/13] imx-common: use simpler runtime cpu dection macros

Dear Peng Fan, On Wed, May 18, 2016 at 9:53 AM, Peng Fan wrote: > Use simpler runtime cpu dection macros. > > Signed-off-by: Peng Fan > Cc: Stefano Babic > Cc: Ulises Cardenas > Cc: Bhuvanchandra DV > Cc: "Benoît Thébaudeau" > --- >

Re: [U-Boot] Linker script u-boot.lds makes u-boot ELF not load with debugger

Hi Héctor, On Wed, May 18, 2016 at 1:28 PM, Palacios, Hector wrote: > I'm loading U-Boot to an i.MX6Q platform using ARM DSTREAM debugger and after > running the DDR initialization script it fails to load the u-boot ELF binary > complaining with: > > loadfile "/home/hpalacio/git/u-boot-denx/u-b

Re: [U-Boot] Inconsistencies in commands regarding load_addr

Dear Wolfgang, On 09/10/2015 15:18, Wolfgang Denk wrote: > Regarding the "load address" topic, be careful, as there has always > been a lot of confusion (due to unfortunate historic choice of names). > There is the "load address" as part of the image formates (uImage, FIT > image), which means the

Re: [U-Boot] Inconsistencies in commands regarding load_addr

Dear Wolfgang, On 08/10/2015 23:29, Wolfgang Denk wrote: > Dear Stephen, > > In message <56167db6.3000...@wwwdotorg.org> you wrote: >> What's the expected correct behavior here? >>> >>> After successful loading the data to memory, load_addr should be set >>> correctly, for all commands. In

Re: [U-Boot] [PATCH 1/5] fs/fat/fat_write: Fix buffer alignments

Hi Tom, On Mon, Sep 28, 2015 at 5:22 PM, Tom Rini wrote: > On Mon, Sep 28, 2015 at 03:45:28PM +0200, Benoît Thébaudeau wrote: > >> set_cluster() was using a temporary buffer without enforcing its >> alignment for DMA and cache. Moreover, it did not check the alignment of &g

Re: [U-Boot] Inconsistencies in commands regarding load_addr

On Tue, Oct 6, 2015 at 8:09 PM, Stephen Warren wrote: > On 10/06/2015 09:00 AM, Benoît Thébaudeau wrote: >> >> Hi all, >> >> I've just noticed that before the commit >> 045fa1e1142552799ad3203e9e0bc22a11e866ea, ext2load and ext4load were >> setti

[U-Boot] Inconsistencies in commands regarding load_addr

Hi all, I've just noticed that before the commit 045fa1e1142552799ad3203e9e0bc22a11e866ea, ext2load and ext4load were setting the load_addr global variable, but not fatload. Since then, none of these commands set load_addr (initially derived from the loadaddr environment variable). ubifsload also

[U-Boot] [PATCH 3/5] fs/fat/fat_write: Fix curclust/newclust mix-up

curclust was used instead of newclust in the debug() calls and in one CHECK_CLUST() call, which could skip a failure case. Signed-off-by: Benoît Thébaudeau --- fs/fat/fat_write.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c

[U-Boot] [PATCH 1/5] fs/fat/fat_write: Fix buffer alignments

(): - print them with debug() in case of error, - consider that there is an error is disk_write() returns a smaller block count than the requested one, not only if its return value is negative. After this change, set_cluster() and get_cluster() are almost symmetrical. Signed-off-by: Benoît

[U-Boot] [PATCH 4/5] fs/fat/fat_write: Factor out duplicate code

Signed-off-by: Benoît Thébaudeau --- fs/fat/fat_write.c | 72 +- 1 file changed, 22 insertions(+), 50 deletions(-) diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c index 2399844..2d032ee 100644 --- a/fs/fat/fat_write.c +++ b/fs/fat

[U-Boot] [PATCH 2/5] fs/fat/fat_write: Merge calls to set_cluster()

set_contents() had uselessly split calls to set_cluster(). Merge these calls, which removes some cases of set_cluster() being called with a size of zero. Signed-off-by: Benoît Thébaudeau --- fs/fat/fat_write.c | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/fs

[U-Boot] [PATCH 5/5] fs/fat/fat_write: Fix management of empty files

must be set to 0 in the directory entry in that case), and by supporting overwriting such files. Signed-off-by: Benoît Thébaudeau --- fs/fat/fat_write.c | 85 -- 1 file changed, 64 insertions(+), 21 deletions(-) diff --git a/fs/fat/fat_write.c b

Re: [U-Boot] [PATCH V2] imx-common: consider mux_ctrl_ofs when setting mux_mode

gt; @@ -53,7 +51,8 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad) > } > #endif > > - __raw_writel(mux_mode, base + mux_ctrl_ofs); > + if (is_soc_type(MXC_SOC_MX7) || mux_ctrl_ofs) > + __raw_writel(mux_mode, base + mux_ctrl_ofs); > > if (sel_inpu

Re: [U-Boot] [PATCH] imx-common: consider mux_ctrl_ofs when setting mux_mode

Hi Peng, On Mon, Sep 21, 2015 at 11:08 AM, Peng Fan wrote: > Some i.MXes use __NA_ or 0 to avoid setting mux_mode, but the following patch > only take i.MX6/7 into consideration. > > "c3c8a5748897b24f18618047804317167a531dd3 imx-common: fix iomux settings" > > Use is_soc_type(MXC_CPU_MX7) to avoi

Re: [U-Boot] [PATCH 1/3] imx-common: fix iomux settings

Hi Peng, On Mon, Sep 21, 2015 at 3:05 AM, Peng Fan wrote: > On Sun, Sep 20, 2015 at 05:02:58PM +0200, Benoît Thébaudeau wrote: >>On Sun, Sep 20, 2015 at 3:02 PM, Peng Fan wrote: >>> On Sun, Sep 20, 2015 at 01:33:20PM +0200, Benoît Thébaudeau wrote: >>>>>> Als

Re: [U-Boot] [PATCH 1/3] imx-common: fix iomux settings

Hi Peng, On Sun, Sep 20, 2015 at 3:02 PM, Peng Fan wrote: > On Sun, Sep 20, 2015 at 01:33:20PM +0200, Benoît Thébaudeau wrote: >>Hi Stefano, Peng, Fabio, all, >> >>Sorry for seeing this only now, but... >> >>On Sun, Sep 20, 2015 at 9:43 AM, Stefano Babic wrote

Re: [U-Boot] [PATCH 1/3] imx-common: fix iomux settings

Hi Stefano, Peng, Fabio, all, Sorry for seeing this only now, but... On Sun, Sep 20, 2015 at 9:43 AM, Stefano Babic wrote: > > > On 14/09/2015 07:34, Peng Fan wrote: >> When setting iomux for a pin mux, there is no need to check mux_ctrl_ofs. This assumption is wrong. This check was there for a

Re: [U-Boot] BDI3000 U-Boot debugging questions (MX51/MX53)

Hi Dave, On Thu, Feb 26, 2015 at 9:05 PM, DaveKucharczyk wrote: > I would like to debug from the earliest possible point pre-relocation (for > educational reasons). Couple questions > > In the Makefile, where do I place the following flags... > -Os #-fomit-frame-pointer -g -fno-schedule-insn

Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board

Hi Dave, On Thu, Feb 26, 2015 at 3:19 PM, DaveKucharczyk wrote: > Benoît Thébaudeau-2 wrote >> Also, check the CONFIG_SYS_TEXT_BASE of your board. From your log, I'm >> wondering if it's not set too high, resulting in an overlap of the >> pre- and post-reloca

Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board

Hi Albert, On Thu, Feb 26, 2015 at 11:38 AM, Albert ARIBAUD wrote: > Hello Benoît, > > On Thu, 26 Feb 2015 00:56:00 +0100, Benoît Thébaudeau > wrote: >> Dear Dave Kucharczyk, >> >> On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk >> wrote: >> > Fa

Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board

.Hi Fabio, On Wed, Feb 25, 2015 at 11:05 PM, Fabio Estevam wrote: > I have just tested top of tree U-boot and my mx53loco board boots fine. That's because CONFIG_HAS_VBAR is set for ARMv7. There may be an issue, though: according to Freescale, the TrustZone security extensions are present on i.M

Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board

Dear Dave Kucharczyk, On Wed, Feb 25, 2015 at 11:08 PM, DaveKucharczyk wrote: > Fabio Estevam-2 wrote >> Also, you said that your 512MB board version works fine, but the 256MB >> fails. >> >> I suppose you are using two different binaries for each board, right? >> You can't have a single binary f

Re: [U-Boot] U-Boot stuck after relocation attempt on MX51 board

Dear Dave Kucharczyk, On Wed, Feb 25, 2015 at 3:19 AM, DaveKucharczyk wrote: > I'm porting U-Boot for an MX51 based board. > > This is the boot sequence with debug on... > > U-Boot 2014.07-svn10 (Feb 24 2015 - 15:49:39) > > initcall: 9ff85820 > U-Boot code: 9FF8 -> 9FFA6824 BSS: -> 9FFD944C

Re: [U-Boot] Unused video drivers

Dear Nikita Kiryanov, Fabio, all, On Fri, Feb 13, 2015 at 1:49 PM, Nikita Kiryanov wrote: > I noticed we have a lot of unused video drivers, specifically: > > CONFIG_EXYNOS_PWM_BL > CONFIG_L5F31188 > CONFIG_SED156X > CONFIG_VIDEO_COREBOOT > CONFIG_VIDEO_IMX25LCDC Fabio, do you think that this on

Re: [U-Boot] Nokia RX-51 (N900) board broken

Dear Pali Rohár, On Sat, Jan 3, 2015 at 11:47 AM, Pali Rohár wrote: > Hello, > > Nokia N900 board does not work anymore from master branch in > qemu. I bisected first commit which broke it. It is: > > 41623c91b09a0c865fab41acdaff30f060f29ad6 > arm: move exception handling out of start.S files > >

Re: [U-Boot] [PATCH 1/2] mxc_ocotp: Do not disable the OCOTP clock after every access

Hi Fabio, On Tue, Nov 25, 2014 at 8:56 PM, Fabio Estevam wrote: > On Tue, Nov 25, 2014 at 5:48 PM, Benoît Thébaudeau > wrote: > >> That, or: >> - Make imx_get_mac_from_fuse() call enable_ocotp_clk(1) before >> reading the fuses, then call enable_ocotp_clk(0). > &g

Re: [U-Boot] [PATCH 1/2] mxc_ocotp: Do not disable the OCOTP clock after every access

Hi Fabio, On Tue, Nov 25, 2014 at 4:11 PM, Fabio Estevam wrote: > Leave the OCOTP turned on, so that we subsequent access do not fail. > > After enabling the thermal driver on a mx6sxsabresd board: > > U-Boot 2015.01-rc1-18267-g99d4189-dirty (Nov 24 2014 - 12:59:01) > > CPU: Freescale i.MX6SX r

Re: [U-Boot] [PATCH v2] cmd_fuse: return CMD_RET_FAILURE on error

ommon/cmd_fuse.c > index abab9789b0df..d4bc0f6c94a1 100644 > --- a/common/cmd_fuse.c > +++ b/common/cmd_fuse.c > @@ -128,7 +128,7 @@ static int do_fuse(cmd_tbl_t *cmdtp, int flag, int argc, > char *const argv[]) > > err: > puts("ERROR\n"); > - re

Re: [U-Boot] [PATCH] cmd_fuse: return CMD_RET_FAILURE on error

Dear Hector Palacios, On Wed, Nov 19, 2014 at 4:52 PM, Hector Palacios wrote: > Fuse drivers, like the mxs_ocotp.c, may return negative error codes but > the commands are not allowed to return negative error codes to the shell, Correct, except -1 for CMD_RET_USAGE. > otherwise the following err

Re: [U-Boot] SPL broken on i.mx31 platforms

Hi Magnus, On Thu, Sep 4, 2014 at 9:12 PM, Magnus Lilja wrote: > On 3 September 2014 03:13, Tom Rini wrote: >> On Wed, Sep 03, 2014 at 02:53:17AM +0200, Benoît Thébaudeau wrote: >>> > IMHO, the 'b reset' and the 'nop nop nop' are two different issue

Re: [U-Boot] [PATCH 1/2] arm: Make reset position-independent

On Wed, Sep 3, 2014 at 11:32 PM, Benoît Thébaudeau wrote: > Some boards, like mx31pdk and tx25, require the beginning of the SPL > code to be position-independent. For these two boards, this is because > they use the i.MX external NAND boot, which starts by executing the > first NAN

Re: [U-Boot] [PATCH 1/2] arm: Make reset position-independent

On Wed, Sep 3, 2014 at 11:32 PM, Benoît Thébaudeau wrote: > Some boards, like mx31pdk and tx25, require the beginning of the SPL > code to be position-independent. For these two boards, this is because > they use the i.MX external NAND boot, which starts by executing the > first NAN

[U-Boot] [PATCH 1/2] arm: Make reset position-independent

he boot of mx31pdk and tx25. Signed-off-by: Benoît Thébaudeau Reported-by: Helmut Raiger Cc: Albert Aribaud Cc: Magnus Lilja Cc: John Rigby --- arch/arm/lib/vectors.S |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S ind

[U-Boot] [PATCH 2/2] arm: Fix _start for CONFIG_SYS_DV_NOR_BOOT_CFG

definition of the _start symbol after the CONFIG_SYS_DV_NOR_BOOT_CFG word. This new commit fixes this issue by restoring the original behavior, i.e. by defining the _start symbol before the CONFIG_SYS_DV_NOR_BOOT_CFG word. Signed-off-by: Benoît Thébaudeau Cc: Albert Aribaud Cc: Manfred Rudigie

Re: [U-Boot] SPL broken on i.mx31 platforms

Hi Helmut, all, On Tue, Aug 19, 2014 at 10:55 PM, Benoît Thébaudeau wrote: > On Fri, Aug 15, 2014 at 7:45 PM, Magnus Lilja wrote: >> On 13 August 2014 14:01, Helmut Raiger wrote: >>> On 08/05/2014 02:32 PM, Magnus Lilja wrote: >>>> I would expect Helmut to create

Re: [U-Boot] [PATCH] mx6: Fix cacheline size

Hi Fabio, On Thu, Aug 21, 2014 at 9:11 PM, Fabio Estevam wrote: > On Thu, Aug 21, 2014 at 2:14 PM, Marek Vasut wrote: >> On Thursday, August 21, 2014 at 07:10:02 PM, Fabio Estevam wrote: >>> mx6 is an armv7 which has 64-byte cacheline size. >>> >>> Without this fix we are not able to get the FEC

Re: [U-Boot] [PATCH] arm: fix missing exception handling

On Thu, Aug 21, 2014 at 8:36 AM, Christian Riesch wrote: > Benoît, > > On Wed, Aug 20, 2014 at 12:47 PM, Benoît Thébaudeau > wrote: >> On Wed, Aug 20, 2014 at 9:21 AM, Christian Riesch >> wrote: >>> On Tue, Aug 19, 2014 at 8:35 PM, Benoît Thébaudeau >>&

[U-Boot] [PATCH v2] arm: Add missing .vectors section to linker scripts

Commit 41623c9 'arm: move exception handling out of start.S files' missed some linker scripts. Hence, some boards no longer had exception handling linked since this commit. Restore the original behavior by adding the .vectors section to these linker scripts. Signed-off-by: Benoît Théb

Re: [U-Boot] [PATCH] arm: fix missing exception handling

Christian, On Wed, Aug 20, 2014 at 9:21 AM, Christian Riesch wrote: > Benoît, > > On Tue, Aug 19, 2014 at 8:35 PM, Benoît Thébaudeau > wrote: >> Commit 41623c9 'arm: move exception handling out of start.S files' missed >> some >> linker scripts. He

Re: [U-Boot] SPL broken on i.mx31 platforms

Hi Magnus, all, On Fri, Aug 15, 2014 at 7:45 PM, Magnus Lilja wrote: > Hi > > On 13 August 2014 14:01, Helmut Raiger wrote: >> On 08/05/2014 02:32 PM, Magnus Lilja wrote: >>> >>> Hi Fabio, >>> >>> On 5 August 2014 14:28, Fabio Estevam wrote: Hi Magnus, >>> I would expect Helmut t

[U-Boot] [PATCH] arm: fix missing exception handling

Commit 41623c9 'arm: move exception handling out of start.S files' missed some linker scripts. Hence, some boards no longer had exception handling linked since this commit. Restore the original behavior by adding the .vectors section to these linker scripts. Signed-off-by: Benoît Théb

Re: [U-Boot] [PATCH 0/8] zmx25: Add hardware support

Hi Thomas, On Mon, Aug 4, 2014 at 7:59 AM, Thomas Diener wrote: > Hi folks, > do you have any comments or statements for this patches? You already have received replies to 1, 3, 4 and 8 / 8 in May: http://lists.denx.de/pipermail/u-boot/2014-May/179759.html http://lists.denx.de/pipermail/u-boot/2

  1   2   3   4   5   6   7   8   9   10   >