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
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
+ 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
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 +-
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
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
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
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:
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
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.
>> >
>> >
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
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
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
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
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:
>
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
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
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
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
'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
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
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
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:
>&
+ 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:
>
+ 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.
> >>
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
+ 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
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.
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,
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
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
+ 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-
>
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
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?
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
>>>>
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.
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
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
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
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
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
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
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
> 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
> 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
>
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
>> 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
>> 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
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
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
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
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
___
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
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/
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
69 matches
Mail list logo