Re: [U-Boot] [PATCH] ARM: socfpga: Convert to DM serial

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. Signed-off-by: Marek

Re: [U-Boot] [PATCH] ARM: socfpga: Convert to DM serial

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. Signed-off-by: Marek

Re: [U-Boot] [PATCH v5] u-boot: remove driver lookup loop from env_save()

+ Tom: I don't know via which tree this would go in. I think you took the last env changes directly? v1..v4 are detached threads, I can send you links if you need them. Thanks, Simon On 26.07.2018 16:02, Maxime Ripard wrote: On Thu, Jul 26, 2018 at 07:16:36AM +0200, Simon Goldschmidt

[U-Boot] [PATCH] arm: socfpga: correctly reserve SRAM for boot counter

Bootcounter for is1 and sr1500 boards somewhat relied on struct global data alignment gap at the end of internal SRAM. Let's fix this by explicitly reserving some bytes. Signed-off-by: Simon Goldschmidt --- include/configs/socfpga_common.h | 6 +-

Re: [U-Boot] [PATCH v2 3/4] Convert socfpga: select CONFIG_HW_WATCHDOG support for ARCH_SOCFPGA

On 09.02.2018 23:14, Lukasz Majewski wrote: All Socfpga boards from ./include/configs/socfpga_* define CONFIG_HW_WATCHDOG. To ease CONFIG_HW_WATCHDOG conversion to Kconfig select it in config ARCH_SOCFPGA (arch/arm/Kconfig) section. I do have board configs where the internal watchdog is not

Re: [U-Boot] [PATCH 2/2] env: Add back default action of get_char in env_get_char()

Maxime, York, I've just sent a patch that removes 'get_char' callback from the env drivers. This should restore the old behaviour we had before supporting multiple environment drivers (for all but eeprom, of course). Simon On 08.02.2018 23:10, Maxime Ripard wrote: On Thu, Feb 08, 2018 at

[U-Boot] [PATCH] env: restore old env_get_char() behaviour

With multiple environments, the 'get_char' callback for env drivers does not really make sense any more because it is only supported by two drivers (eeprom and nvram). To restore single character loading for these drivers, override 'env_get_char_spec'. Signed-off-by: Simon Goldschmidt

Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

On 02/07/2018 21:18, York Sun wrote: > On 02/07/2018 12:43 AM, Maxime Ripard wrote: >> Hi, >> >> On Tue, Jan 30, 2018 at 11:02:49PM +, York Sun wrote: >>> On 01/30/2018 12:16 PM, York Sun wrote: On 01/30/2018 11:40 AM, York Sun wrote: > On 01/30/2018 12:19 AM, Simon Goldschmidt wrote:

Re: [U-Boot] [PATCH] cmd: nvedit: env_get_f must check for env_get_char error codes

On 02/02/2018 21:04, York Sun wrote: > On 02/02/2018 10:51 AM, Maxime Ripard wrote: > > > > Simon, This patch looks correct. But it doesn't fix NOR flash. Do you have plan to add .get_char function to other drivers? Without that function, we cannot get env variables

Re: [U-Boot] [PATCH v3 12/15] env: Allow to build multiple environments in Kconfig

On 01.02.2018 20:47, Maxime Ripard wrote: > On Thu, Feb 01, 2018 at 11:06:14AM +0100, Simon Goldschmidt wrote: >> On 23.01.2018 21:17, Maxime Ripard wrote: >> > Now that we have everything in place in the code, let's allow to build >> > multiple environments backend through Kconfig. >> > >> >

Re: [U-Boot] [PATCH] ARM: socfpga: Convert callers of cm_write_with_phase for wait_for_bit_le32

On 01/26/2018 17:28, Tom Rini wrote: > Now that we have and use wait_for_bit_le32() available, the callers of > cm_write_with_phase() should not be casting values to u32 and instead we > expect a const void *, so provide that directly. > > Fixes: 48263504c8d5 ("wait_bit: use wait_for_bit_le32 and

[U-Boot] [RESEND PATCH] ddr: altera: silence PHY calibration unless in debug mode

This driver has been using printf() including filename since it was added. Convert to using debug() instead. Signed-off-by: Simon Goldschmidt --- drivers/ddr/altera/sequencer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [U-Boot] [PATCH] ddr: altera: silence PHY calibration unless in debug mode

On 01/11/2018 12:28, Marek Vasut wrote: > On 01/11/2018 08:19 AM, Goldschmidt Simon wrote: >> This driver has been using printf() including filename since it was >> added. Convert to using debug() instead. >> >> Signed-off-by: Simon Goldschmidt <sgoldschm...@de.p

[U-Boot] [PATCH] ddr: altera: silence PHY calibration unless in debug mode

This driver has been using printf() including filename since it was added. Convert to using debug() instead. Signed-off-by: Simon Goldschmidt --- drivers/ddr/altera/sequencer.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

Re: [U-Boot] [PATCH v2 0/3] cadence-quadspi: Fix issues with non 32bit aligned accesses

On Tue 09/01/18 14:19, Vignesh R wrote: > This series reverts use of bounce_buf.c for non-DMA related alignment > restriction > and replaces it with local bounce buffer to handle problems with non 32 bit > aligned > writes on TI platforms. > Based on top of Jason's series: >

Re: [U-Boot] [PATCH] spl: unbreak CONFIG_SPL_MULTI_DTB_FIT after fixing CONFIG_OF_EMBED

On Wed, 10/01/18 09:48, Lokesh Vutla wrote: > On Wednesday 10 January 2018 12:32 PM, Goldschmidt Simon wrote: > > Commit 9bd76b80 "spl: make CONFIG_OF_EMBED pass dts through fdtgrep" > > moved the fdtgrep code from scripts/Makefile.spl to dts/Makefile so > > that

[U-Boot] [PATCH] spl: unbreak CONFIG_SPL_MULTI_DTB_FIT after fixing CONFIG_OF_EMBED

Commit 9bd76b80 "spl: make CONFIG_OF_EMBED pass dts through fdtgrep" moved the fdtgrep code from scripts/Makefile.spl to dts/Makefile so that the dtb is stripped in embedded mode, too. This broke CONFIG_SPL_MULTI_DTB_FIT where fdtgrep is still called from scripts/Makefile.spl to strip all dtbs in

Re: [U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

On Tue, 09/01/18 15:43, Lokesh Vutla wrote: > On Sunday 26 November 2017 05:08 PM, Simon Glass wrote: > > On 21 November 2017 at 05:29, Goldschmidt Simon > > <sgoldschm...@de.pepperl-fuchs.com> wrote: > >> Building spl with CONFIG_OF_EMBED enabled results in an error

Re: [U-Boot] [PATCH 3/3] spi: cadence_qspi_apb: Make flash writes 32 bit aligned

On Mon, 08/01/2018 12:18, Vignesh R wrote: > Make flash writes 32 bit aligned by using bounce buffers to deal with non 32 > bit > aligned buffers. Allocate a 512 byte bounce buffer (max known page size > currently) for this case. Looking at drivers/mtd/spi/sf_dataflash.c, I see at least one chip

Re: [U-Boot] [PATCH 0/3] cadence-quadspi: Fix issues with non 32bit aligned accesses

's series: > https://patchwork.ozlabs.org/cover/856431/ > > Tested on K2G EVM. > > Goldschmidt Simon (1): > Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction > when possible" > > Vignesh R (2): > Revert "spi: cadence_qspi_apb: Use

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On Mon, 08/012018 06:27, Vignesh R wrote: > On Monday 08 January 2018 09:10 AM, Jason Rush wrote: > [...] > >>> 1. The indaddrtrig register was being programmed with an incorrect > >>> value for socfpga as the result of assuming it should be programmed > >>> with the same address as the ahbbase

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On Fri, 05/01/2018, Marek Vasut wrote: > On 01/05/2018 08:31 PM, Goldschmidt Simon wrote: >> On Fri, 05/01/2018 Marek Vasut wrote: >>> On 01/05/2018 04:49 PM, Goldschmidt Simon wrote: >> >> >> >>>>>> OK, so I need these patches to get qspi wor

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On Fri, 05/01/2018 Marek Vasut wrote: > On 01/05/2018 04:49 PM, Goldschmidt Simon wrote: >>>> OK, so I need these patches to get qspi work on socfpga: >>>> >>>> - Series "spi: cadence_spi: Adopt Linux DT bindings" (v4) from Jason Rush: >&

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

+ Marek (as Jagan wants an ack) On 05/01/2018 Jagan Teki wrote: > On Fri, Jan 5, 2018 at 5:32 PM, Goldschmidt Simon wrote: >> + Vignesh >> + Jason >> >> On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote: >>> On Wed, 03/01/2018 14:51, Jagan Teki wrote: >

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

+ Vignesh + Jason On Wed, 03/01/2018 16:57, Goldschmidt Simon wrote: > On Wed, 03/01/2018 14:51, Jagan Teki wrote: > >> There were already patches posted on this list by me and others, but > >> unfortunately they haven't made it into the repository, yet. > >>

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On Wed, 03/01/2018 14:51, Jagan Teki wrote: >> There were already patches posted on this list by me and others, but >> unfortunately they haven't made it into the repository, yet. >> >> Jagan, could you comment on the status of these fixes? I can search >> for the patchwork items related if you

Re: [U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

+ Jagan On Wed, 03/01/2018, Mr. goldenstreet wrote: > hey, i have looked at this thread: > http://u-boot.10912.n7.nabble.com/QSPI-quot-sf-probe-quot-quot-sf-read-quot-on- > Altera-SoC-FPGA-td304882.html > > i'm having the same problem with Arria 5, when i try to use the "sf probe" > command on

Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework

On Tuesday 12 December 2017 11:51, Vignesh R wrote: > [...] > Many of the newer SPI NOR flashes such as MT35x do not support U-Boot's > legacy way of accessing >128Mb region. > Are you planning to submit dm-spi-nor anytime soon? If not, then IMO, at > least patch 2/5 is worth considering for now.

Re: [U-Boot] Linux hang

Pepperl+Fuchs GmbH, Mannheim Geschaeftsfuehrer/Managing Directors: Dr.-Ing. Gunther Kegel (Vors./CEO), Werner Guthier, Mehmet Hatiboglu Vorsitzender des Aufsichtsrats/Chairman of the supervisory board: Claus Michael Registergericht/Register Court: AG Mannheim HRB 4713 On 2017-12-07 12:01,

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

On 2017-10-07 09:23 AM, Prabhakar Kushwaha wrote: > Dear Jagan, Simon, > > > -Original Message- > > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jagan > > Teki > > Sent: Thursday, December 07, 2017 11:19 AM > > To: Goldschmidt Simo

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

On 5.12.2017 08:22, Michal Simek wrote: > > Which release will this be in? Does it fit into 2018.01 or has that > > window already closed? > > I believe so. Sorry to bother you again, I'm just not sure I understood your answer. Was that "I beleive so" meant as "yes, 2018.01 unless someone

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

+ Lukasz (as a reviewer of my patch[1]) On Mon, Dec 4, 2017 at 8:20, Jagan Teki wrote: > This is the patch[1] for 4-byte addressing, but I would wonder how can proceed > operations with 4-byte if we disable during probe. > > [1] http://git.denx.de/?p=u-boot- >

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

Hi, On 4.12.2017 15:27, Michal Simek wrote: > [..] > ok. Then applied to my xilinx tree. Great to hear that, thanks! Which release will this be in? Does it fit into 2018.01 or has that window already closed? Thanks, Simon ___ U-Boot mailing list

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

Hi Jagan, On Fri, Nov 10, 2017 08:04, Jagan Teki wrote: >>> I've similar change on my patchwork, since no-one tested Will CC you by re- > basing it please have test? >> >> Yes, of course I'd like to test this. Where do I find your patch? > > Will rebase and send to ML soon. Any progress here?

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

On 28.11.2017 14:46, Michal Simek wrote: > On 28.11.2017 10:08, Goldschmidt Simon wrote: >> Simon Goldschmidt wrote: >>> Hi Simon, >>> >>> Simon Glass wrote: >>>> I see that, although it is adding to the fpga header so presumably >>>>

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

Simon Goldschmidt wrote: > Hi Simon, > > Simon Glass wrote: > > I see that, although it is adding to the fpga header so presumably > > making it harder for someone to move this over. > > Yes, I'm not happy with changing the header and even xilinx C file to add > functionality for altera.

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

Hi Simon, Simon Glass wrote: > I see that, although it is adding to the fpga header so presumably > making it harder for someone to move this over. Yes, I'm not happy with changing the header and even xilinx C file to add functionality for altera. However, this is due to the fact that a core

Re: [U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

Hi Lukasz > > Building spl with CONFIG_OF_EMBED enabled results in an error message > ^^^ - is the CONFIG_OF_EMBED a standard > feature for SPL? Well, it's not really a standard feature I want to use in my final product. But if I want to debug SPL

[U-Boot] [PATCH] spl: make CONFIG_OF_EMBED pass dts through fdtgrep

Building spl with CONFIG_OF_EMBED enabled results in an error message on my board: "SPL image too big". This is because the fdtgrep build step is only executed for CONFIG_OF_SEPARATE. Fix this by moving the fdtgrep build step ('cmd_fdtgreo') from scripts/Makefile.spl to dts/Makefile so that the

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

Hi, > Simon Glass wrote: > On 10 November 2017 at 07:17, Goldschmidt Simon <sgoldschmidt@de.pepperl- > fuchs.com> wrote: > > This drops the limit that fpga is only loaded from FIT images for Xilinx. > > This is done by moving the 'partial' check from 'common/image.c' to

Re: [U-Boot] Working with patchwork

Hi Lukasz, thanks for taking the time :-) > > as I'm quite new to U-Boot and its patch workflow: what do I have to > > do to send a reviewed-by or tested-by tag for a patch? I sent it as a > > reply to this list but I can't see them in patchwork. > > > > Did I miss something here? Or could it be

[U-Boot] Working with patchwork

Hi, as I'm quite new to U-Boot and its patch workflow: what do I have to do to send a reviewed-by or tested-by tag for a patch? I sent it as a reply to this list but I can't see them in patchwork. Did I miss something here? Or could it be a problem in the email format used? Thanks, Simon

[U-Boot] [PATCH v2] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f. This commit changed cadence_qspi_apb to use bouncebuf.c, which invalidates the data cache after reading. This is meant for dma transfers only and breaks the cadence_qspi driver which copies via cpu only: data that is copied by the cpu

Re: [U-Boot] [PATCH v4 3/5] config: cadence_spi: Remove defines read from DT

> Jason Rush wrote: > Cleanup unused #define values that are read from the DT. > --- > Changes for v4: >- Rebased Reviewed-by: Simon Goldschmidt Tested on a socfpga-cyclonev board: Tested-by: Simon Goldschmidt Best

Re: [U-Boot] [PATCH v4 2/5] dts: cadence_spi: Sync DT bindings with Linux

> Jason Rush wrote: > Adopt the Linux DT bindings and clean-up duplicate > and unused values. > --- > Changes for v4: >- Rebased Reviewed-by: Simon Goldschmidt > > arch/arm/dts/keystone-k2g-evm.dts | 8 >

Re: [U-Boot] [PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux

> Jason Rush wrote: > Adopt the Linux DT bindings. This also fixes an issue > with the indaddrtrig register on the Cadence QSPI > device being programmed with the wrong value for the > socfpga arch. > --- > Changes for v4: >- Rebased > Reviewed-by: Simon Goldschmidt

[U-Boot] [PATCH] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f. This commit changed cadence_qspi_apb to use bouncebuf.c, which invalidates the data cache after reading. This is meant for dma transfers only and breaks the cadence_qspi driver which copies via cpu only: data that is copied by the cpu

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

Hi Vignesh, Vignesh R wrote: > [..] > Its not actually unaligned access, cadence QSPI IP on TI platforms do > not support non-byte accesses except for the last word. As per the TRM: > "The external master is only permitted to issue 32-bit data interface > writes until the last word of an indirect

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

Simon Goldschmidt wrote: >Marek Vasut wrote: >> So what alignment problems do you observe ? If you copy using the CPU >> only, why do you need the bounce buffer at all ? I don't quite get it. > > Sorry for not explaining it good enough: > I don't observe any alignment problems. mach-socfpga can

Re: [U-Boot] cadence_qspi_apb: cache issues on mach-socfpga

Marek Vasut wrote: >>> I don't believe the patchset I submitted for DT bindings were merged in. >> >> I can confirm that. I'd strongly vote for them to get in as cadence_qspi >> is otherwise not usable on mach socfpga. >> >> How can I ensure a tested-by from me gets related to that patch set? >> I

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

Marek Vasut wrote: > So what alignment problems do you observe ? If you copy using the CPU > only, why do you need the bounce buffer at all ? I don't quite get it. Sorry for not explaining it good enough: I don't observe any alignment problems. mach-socfpga can do unaligned accesses as well. This

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

Marek Vasut wrote: > Why don't you just fix the cache operations in the driver ? This driver is copying CPU only. There are no cache operations involved! Vignesh added the bounce buffer obviously to fix alignment issues on his platform. > This bounce-buffer for only CPU operations is just

Re: [U-Boot] cadence_qspi_apb: cache issues on mach-socfpga

Rush, Jason A wrote;: > I don't believe the patchset I submitted for DT bindings were merged in. I can confirm that. I'd strongly vote for them to get in as cadence_qspi is otherwise not usable on mach socfpga. How can I ensure a tested-by from me gets related to that patch set? I can't reply to

[U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

Bounce buffer may be used for CPU-only transfers (this is currently the case for cadence_qspi). However, in this case, invalidating the data cache might throw away copied data that is still in the cache only. To make CPU-only transfers work with bouncebuf (but still take advantage of having

[U-Boot] [PATCH 2/2] spi: cadence_spi_apb: fix using bouncebuf with writeback dcache

The last two commits on this file have added bounce buffer handling to indirect read and write transfers. However, these are cpu-only transfers and bouncebuf seems to be written for dma transfers only (it invalidates the dcache in bouncebuf_stop, which throws away data copied by the cpu that are

[U-Boot] [PATCH 0/2] spi: cadence_spi_apb: fix using bouncebuf with writeback dcache

Currently, cadence_spi_apb is broken at least on mach-socfpga: Commits 57897c13de03ac0136d64641a3eab526c6810387 and b63b46313ed29e9b0c36b3d6b9407f6eade40c8f added bounce buffer handling to cadence_qspi_apb. This is the first usage of bounce buffers for non-DMA transfer. As it turns out, bounce

[U-Boot] spi: cadence_qspi_apb: cache issues on mach-socfpga

Hi, I ran into the same issue with the cadence qspi driver and dcache as Jason reported (in febuary, I think - I started to monitor U-Boot in july only). May I ask what's the status here? I do need fixes for this to keep mach-socfpga running with qspi. I currently set dcache off globally and it

Re: [U-Boot] [PATCH v2] spi: kirkwood: avoid divide by zero crash

On Mon, Nov 13, 2017 at 06:26 AM, Baruch Siach wrote: >On Sun, Nov 12, 2017 at 08:42:28PM +0100, Heinrich Schuchardt wrote: >> On 11/12/2017 04:30 PM, Baruch Siach wrote: >> > Calling .set_speed with zero speed is definitely a bug. Instead of >> > crashing, set hz to 1 so that we get the lowest

[U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

This drops the limit that fpga is only loaded from FIT images for Xilinx. This is done by moving the 'partial' check from 'common/image.c' to 'drivers/fpga/xilinx.c' (the only driver supporting partial images yet) and supplies a weak default implementation in 'drivers/fpga/fpga.c'. Signed-off-by:

[U-Boot] [PATCH] rockchip: doc: update U-Boot location info

The U-Boot location has been moved to block 16384. This is 8MB, not 4MB. Signed-off-by: Simon Goldschmidt --- doc/README.rockchip | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index

Re: [U-Boot] [U-Boot, 2/3] rockchip: doc: update U-Boot location info

>> I just found this commit has calculated the size wrong. 16384 blocks should >> be 8MB, not 4MB. > > Yes, 8MB is what expected here and even Kever[1] commented the same, what is > 4MB here? can you elaborate. I know. It's only wrong in 'doc/README.rockchip' at line 105 where it says: "image

Re: [U-Boot] [U-Boot, 2/3] rockchip: doc: update U-Boot location info

>> Update rockchip U-Boot location to 0x4000/16384. >> >> Signed-off-by: Kever Yang >> Acked-by: Philipp Tomsich >> Reviewed-by: Philipp Tomsich >> --- >> >> doc/README.rockchip | 6

Re: [U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

On Mon, Oct 30, 2017 at 7:26 AM, Jagan Teki wrote: > I've similar change on my patchwork, since no-one tested Will CC you by > re-basing it please have test? Yes, of course I'd like to test this. Where do I find your patch? Simon

[U-Boot] [PATCH] sf: ensure flash device is in 3-byte address mode

On some boards where the spi flash is not reset during warm reboot, the chip has to be manually set into 3-byte address mode. Signed-off-by: Simon Goldschmidt --- drivers/mtd/spi/sf_internal.h | 2 ++ drivers/mtd/spi/spi_flash.c | 53

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

Hi Clémént, > Did you also test the saveenv and sf unlock ? I did test saveenv and it works. I did not test sf protection. > Did you get some strange behaviors after a "warm reboot" from linux ? Indeed, warm reboot fails. When rebooting via "reboot" command from linux, the last thing I see is

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

Hi Clement, > Did you also test the saveenv and sf unlock ? Not yet. > Did you get some strange behaviors after a "warm reboot" from linux ? Unfortunately, I'm not that far, yet. My Linux image only uses the sd-card for now. Regards, Simon ___

[U-Boot] Debugging SPL

Hi, When trying to debug SPL on the socfpga platform with CONFIG_OF_EMBED, I get an error message "SPL image too big" when linking SPL. It seems this is because the U-Boot DTB (~16 Kbyte) is not stripped for SPL when building this way. Is this a known issue? Is there a workaround other than

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 09/27/2017 06:54 AM, Hannes Schmelzer wrote: > On 09/22/2017 02:20 PM, Clément Péron wrote: >> Sorry these are my local commits you can find them here : >> >> https://patchwork.ozlabs.org/patch/765992/ >> https://patchwork.ozlabs.org/patch/765996/ >> https://patchwork.ozlabs.org/patch/765997/

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

On 09/22/2017 02:20 PM, Clément Péron wrote: > Sorry these are my local commits you can find them here : > > https://patchwork.ozlabs.org/patch/765992/ > https://patchwork.ozlabs.org/patch/765996/ > https://patchwork.ozlabs.org/patch/765997/ > https://patchwork.ozlabs.org/patch/765998/ Tested on