Emmanuel Vadot schrieb am Mo., 6. Aug. 2018, 15:48:
> On Mon, 6 Aug 2018 15:42:01 +0200
> Simon Goldschmidt wrote:
>
> > Marek Vasut schrieb am Mo., 6. Aug. 2018, 15:19:
> >
> > > On 08/05/2018 09:34 PM, Simon Goldschmidt wrote:
> > > > Device tr
Stefan Roese schrieb am Mo., 6. Aug. 2018, 16:34:
> Some SPI NOR chips only support 4-byte mode addressing. Here the default
> 3-byte mode does not work and leads to incorrect accesses. Setting this
> option enables the use of such SPI NOR chips, that only support this
> 4-byte mode.
>
I think i
Stefan Roese schrieb am Mo., 6. Aug. 2018, 17:23:
> Hi Simon,
>
> On 06.08.2018 17:15, Simon Goldschmidt wrote:
> >
> >
> > Stefan Roese mailto:s...@denx.de>> schrieb am Mo., 6. Aug.
> > 2018, 16:34:
> >
> > Some SPI NOR chips only support 4
Stefan Roese schrieb am Mo., 6. Aug. 2018, 17:29:
>
>
> On 06.08.2018 17:27, Simon Goldschmidt wrote:
> >
> >
> > Stefan Roese mailto:s...@denx.de>> schrieb am Mo., 6. Aug.
> > 2018, 17:23:
> >
> > Hi Simon,
>
Stefan Roese schrieb am Mo., 6. Aug. 2018, 17:36:
> On 06.08.2018 17:33, Simon Goldschmidt wrote:
> >
> >
> > Stefan Roese mailto:s...@denx.de>> schrieb am Mo., 6. Aug.
> > 2018, 17:29:
> >
> >
> >
> > On 06.08.2018 17:27, Simon G
On Mon, Aug 6, 2018 at 4:41 PM Simon Goldschmidt
wrote:
>
>
>
> Emmanuel Vadot schrieb am Mo., 6. Aug. 2018, 15:48:
>>
>> On Mon, 6 Aug 2018 15:42:01 +0200
>> Simon Goldschmidt wrote:
>>
>> > Marek Vasut schrieb am Mo., 6. Aug. 2018, 15:19:
>>
of board_init_f()
moved to an extra patch
- don't change printf() to debug() in reset_manager_gen5.c
socfpga_bridges_reset() (instead make debug uart handle this)
- make ns16550 debug uart handle putc being called before init
- removed the assignment of gd->malloc_limit from board_ini
or one of its relatives) has not been called.
All this is fixed by calling spl_early_init before calling
preloader_console_init.
This fixes commit 73172753f4f3 ("ARM: socfpga: Convert to DM serial")
Signed-off-by: Simon Goldschmidt
---
v2:
- Don't remove gd->malloc_base
From: Simon Goldschmidt
In spl_gen5's board_init_f(), gd->malloc_base is manually assigned
at the end of the function to point to sdram. This code is outdated
as by now, the heap is switched to sdram by the common function
spl_relocate_stack_gd() if the appropriate defines are set.
A
If CONFIG_DEBUG_UART is enabled, correctly initialize
the debug uart before console is initialized to debug
early boot problems in SPL.
Signed-off-by: Simon Goldschmidt
---
v2:
- don't change printf() to debug() in reset_manager_gen5.c
socfpga_bridges_reset()
arch/arm/mach-socfpga/spl
Device trees need to have the serial console device available
before relocation and require a stdout-path in chosen at least
for SPL to have a console.
Signed-off-by: Simon Goldschmidt
---
v2: no changes
arch/arm/dts/socfpga.dtsi | 1 +
arch/arm/dts
malloc_simple() can return 0 if out of memory. Don't call memset
from calloc() in this case but rely on the caller checking
the return value.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Marek Vasut
---
v2: no changes
common/malloc_simple.c | 3 ++-
1 file changed, 2 insertions(
rt is initialized.
This is done by reading the baudrate divisor and aborting if is zero.
Tested on socfpga_cyclone5_socrates.
Signed-off-by: Simon Goldschmidt
---
v2:
- this patch is new in v2 of the series. It replaces the printf/debug
change in reset_manager_gen5.c from v1
drivers/serial/ns16
On Mon, Aug 6, 2018 at 3:45 PM Simon Goldschmidt
wrote:
>
>
>
> Marek Vasut schrieb am Mo., 6. Aug. 2018, 15:19:
>>
>> On 08/06/2018 03:05 PM, Simon Goldschmidt wrote:
>> > This fixes the board's dts to supply SPL with QSPI info.
>> >
>> >
On 10.08.2018 00:41, Marek Vasut wrote:
On 08/10/2018 12:35 AM, Andy Shevchenko wrote:
On Fri, Aug 10, 2018 at 12:45 AM, Marek Vasut wrote:
On 08/09/2018 11:13 PM, Adam Ford wrote:
On Thu, Aug 9, 2018 at 2:08 PM Simon Goldschmidt
wrote:
If _debug_uart_putc() is called before
On 10.08.2018 11:51, Marek Vasut wrote:
On 08/10/2018 07:22 AM, Simon Goldschmidt wrote:
On 10.08.2018 00:41, Marek Vasut wrote:
On 08/10/2018 12:35 AM, Andy Shevchenko wrote:
On Fri, Aug 10, 2018 at 12:45 AM, Marek Vasut wrote:
On 08/09/2018 11:13 PM, Adam Ford wrote:
On Thu, Aug 9, 2018
On 09.08.2018 23:42, Marek Vasut wrote:
On 08/09/2018 09:04 PM, Simon Goldschmidt wrote:
There were NULL pointers dereferenced because DM was used
too early without correct initialization:
- malloc_simple returned NULL when called from preloader_console_init()
because gd->malloc_limit wa
On 10.08.2018 14:41, Marek Vasut wrote:
On 08/10/2018 02:39 PM, Simon Goldschmidt wrote:
On 09.08.2018 23:42, Marek Vasut wrote:
On 08/09/2018 09:04 PM, Simon Goldschmidt wrote:
There were NULL pointers dereferenced because DM was used
too early without correct initialization:
- malloc_simple
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
[..]
BTW, the DIP switches even allow the SoCrates to boot from fpga, which
is what I'm currently working on. In this case, it seems like we need
a separate config at least, but the dts can still b
On 10.08.2018 15:15, Marek Vasut wrote:
On 08/10/2018 02:56 PM, Simon Goldschmidt wrote:
On 09.08.2018 23:57, Marek Vasut wrote:
On 08/09/2018 09:17 PM, Simon Goldschmidt wrote:
[..]
BTW, the DIP switches even allow the SoCrates to boot from fpga, which
is what I'm currently working o
Adam Ford schrieb am Sa., 11. Aug. 2018, 14:42:
> On Fri, Aug 10, 2018 at 2:58 PM Adam Ford wrote:
> >
> > On Fri, Aug 10, 2018 at 7:42 AM Jagan Teki
> wrote:
> > >
> > > On Fri, Aug 10, 2018 at 3:50 PM, Adam Ford wrote:
> > > > On Fri, Aug 10, 2018 at 12:14 AM Jagan Teki <
> ja...@amarulasolu
On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut wrote:
>
> On 08/10/2018 10:11 PM, Simon Goldschmidt wrote:
> > On 10.08.2018 15:15, Marek Vasut wrote:
> >> On 08/10/2018 02:56 PM, Simon Goldschmidt wrote:
> >>> On 09.08.2018 23:57, Marek Vasut wrote:
> >>&g
On Sun, Aug 12, 2018 at 12:05 AM Marek Vasut wrote:
>
> On 08/11/2018 09:26 PM, Simon Goldschmidt wrote:
> > On Fri, Aug 10, 2018 at 10:32 PM Marek Vasut wrote:
> >>
> >> On 08/10/2018 10:11 PM, Simon Goldschmidt wrote:
> >>> On 10.08.2018 15:15, Marek
gd->malloc_limit from board_init()
Simon Goldschmidt (8):
arm: socfpga: fix SPL on gen5 after moving to DM serial
arm: socfpga: fix device trees to work with DM serial
arm: socfpga: spl_gen5: clean up malloc_base assignment
arm: socfpga: cyclone5: handle debug uart
arm: socfpga: fix U-Boo
or one of its relatives) has not been called.
All this is fixed by calling spl_early_init before calling
preloader_console_init.
This fixes commit 73172753f4f3 ("ARM: socfpga: Convert to DM serial")
Signed-off-by: Simon Goldschmidt
---
Changes in v3: None
Changes in v2:
- Don't r
From: Simon Goldschmidt
In spl_gen5's board_init_f(), gd->malloc_base is manually assigned
at the end of the function to point to sdram. This code is outdated
as by now, the heap is switched to sdram by the common function
spl_relocate_stack_gd() if the appropriate defines are set.
A
If CONFIG_DEBUG_UART is enabled, correctly initialize
the debug uart before console is initialized to debug
early boot problems in SPL.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: None
Changes in v2:
- don't change printf() to debug() in reset_manager_gen5.c
socfpga_bridges_
malloc_simple() can return 0 if out of memory. Don't call memset
from calloc() in this case but rely on the caller checking
the return value.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Marek Vasut
---
Changes in v3: None
Changes in v2: None
common/malloc_simple.c | 3 ++-
1 file ch
Some of the code for low level system initialization in SPL's
board_init_f() and U-Boot's arch_early_init_r() is the same,
so let's combine it into a single function called from both.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: this patch is new in v3
Changes in v2: None
idges).
This adds a new config option (CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA)
for socfpga gen5 boards.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: this patch is new in v3
Changes in v2: None
arch/arm/mach-socfpga/Kconfig | 12
arch/arm/mach-socfpga/misc_gen5.c
gd->env_addr points to pre-relocation address even after
relocation. This leads to an abort in env_callback_init
when loading the environment.
Fix this by enabling CONFIG_SYS_EXTRA_ENV_RELOC.
Signed-off-by: Simon Goldschmidt
---
Changes in v3: this patch is new in v3
Changes in v2: N
Device trees need to have the serial console device available
before relocation and require a stdout-path in chosen at least
for SPL to have a console.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved uart0's "u-boot,dm-pre-reloc;" from socfpga.dtsi to board
spe
spl_common_init() debug-prints "spl_early_init()\n" but it is
called both from spl_early_init() and spl_init().
Fix this by moving the debug() statement to the calling functions
which now print their name.
Signed-off-by: Simon Goldschmidt
---
common/spl/spl.c | 6 --
1 file
%s/parition/partition
Signed-off-by: Simon Goldschmidt
---
common/spl/Kconfig| 2 +-
drivers/i2c/muxes/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0ad1e049a9..b44b7412fd 100644
--- a/common/spl/Kconfig
Signed-off-by: Simon Goldschmidt
---
u-boot-config/domain-map | 1 +
1 file changed, 1 insertion(+)
diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map
index f2abba9..74c1538 100644
--- a/u-boot-config/domain-map
+++ b/u-boot-config/domain-map
@@ -262,6 +262,7 @@ parallels.com
Since I cannot use my work address to send patches from at home,
add an alias for my gmail address.
Signed-off-by: Simon Goldschmidt
---
u-boot-config/aliases | 1 +
1 file changed, 1 insertion(+)
diff --git a/u-boot-config/aliases b/u-boot-config/aliases
index ee1e014..da59298 100644
--- a/u
On Mon, Aug 13, 2018 at 3:17 PM Tom Rini wrote:
>
> On Mon, Aug 13, 2018 at 09:33:45AM +0200, Simon Goldschmidt wrote:
>
> > Device trees need to have the serial console device available
> > before relocation and require a stdout-path in chosen at least
> >
On Mon, Aug 13, 2018 at 12:46 PM Dr. Philipp Tomsich
wrote:
>
>
> > On 13 Aug 2018, at 11:34, Simon Goldschmidt
> > wrote:
> >
> > %s/parition/partition
>
> Make this a whole sentence to make it easier to read.
Sure I can. I was only following exa
Marek Vasut schrieb am Mo., 13. Aug. 2018, 15:29:
> On 08/13/2018 09:33 AM, Simon Goldschmidt wrote:
> > To boot from fpga OnChip RAM, some changes are required in SPL
> > to ensure the code is linked to the correct address (in contrast
> > to QSPI and MMC boot, FPGA boot
Marek Vasut schrieb am Mo., 13. Aug. 2018, 15:29:
> On 08/13/2018 09:33 AM, Simon Goldschmidt wrote:
> > gd->env_addr points to pre-relocation address even after
> > relocation. This leads to an abort in env_callback_init
> > when loading the environment.
>
Marek Vasut schrieb am Mo., 13. Aug. 2018, 15:29:
> On 08/13/2018 09:33 AM, Simon Goldschmidt wrote:
> > Socfpga gen5 SPL has been broken since moving to DM serial with
> > v2018.07. Also, U-Boot console output has been broken since then.
> > This series fixes this and mak
Tom Rini schrieb am Mo., 13. Aug. 2018, 15:33:
> On Mon, Aug 13, 2018 at 03:29:30PM +0200, Marek Vasut wrote:
> > On 08/13/2018 03:28 PM, Tom Rini wrote:
> > > On Mon, Aug 13, 2018 at 03:25:19PM +0200, Simon Goldschmidt wrote:
> > >> On Mon, Aug 13, 2
Tom Rini schrieb am Mo., 13. Aug. 2018, 15:41:
> On Mon, Aug 13, 2018 at 03:36:35PM +0200, Simon Goldschmidt wrote:
> > Tom Rini schrieb am Mo., 13. Aug. 2018, 15:33:
> >
> > > On Mon, Aug 13, 2018 at 03:29:30PM +0200, Marek Vasut wrote:
> > > > On
>> > >> >> -{
> > >> >> > >> >> - struct davinci_spi_slave *ds = to_davinci_spi(slave);
> > >> >> > >> >> -
> > >> >> > >> >> -#ifdef CONFIG_SPI_HALF_DUPLEX
> > >&g
Device trees need to have the serial console device available
before relocation and require a stdout-path in chosen at least
for SPL to have a console.
Signed-off-by: Simon Goldschmidt
---
Changes in v4: None
Changes in v3:
- moved uart0's "u-boot,dm-pre-reloc;" from socfpg
()
moved to an extra patch
- don't change printf() to debug() in reset_manager_gen5.c
socfpga_bridges_reset() (instead make debug uart handle this)
- make ns16550 debug uart handle putc being called before init
- removed the assignment of gd->malloc_limit from board_init()
Simon Goldsch
Some of the code for low level system initialization in SPL's
board_init_f() and U-Boot's arch_early_init_r() is the same,
so let's combine it into a single function called from both.
Signed-off-by: Simon Goldschmidt
---
Changes in v4:
- rename socfpga_init_b
gd->env_addr points to pre-relocation address even after
relocation. This leads to an abort in env_callback_init
when loading the environment.
Fix this by enabling CONFIG_SYS_EXTRA_ENV_RELOC.
Signed-off-by: Simon Goldschmidt
---
Changes in v4: enable this fix for all socfpga, not for gen5 o
malloc_simple() can return 0 if out of memory. Don't call memset
from calloc() in this case but rely on the caller checking
the return value.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Marek Vasut
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/malloc_simple.
idges).
This adds a new config option (CONFIG_SPL_SOCFPGA_BOOT_FROM_FPGA)
for socfpga gen5 boards.
Signed-off-by: Simon Goldschmidt
---
Changes in v4: Adapted to changed previous patch
Changes in v3: this patch is new in v3
Changes in v2: None
arch/arm/mach-socfpga/Kconfig
Marek Vasut schrieb am Mo., 13. Aug. 2018, 22:36:
> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
> > gd->env_addr points to pre-relocation address even after
> > relocation. This leads to an abort in env_callback_init
> > when loading the environment.
>
Marek Vasut schrieb am Mo., 13. Aug. 2018, 22:36:
> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
> > To boot from fpga OnChip RAM, some changes are required in SPL
> > to ensure the code is linked to the correct address (in contrast
> > to QSPI and MMC boot, FPGA boot
On Tue, Aug 14, 2018 at 11:27 AM Marek Vasut wrote:
>
> The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
> is available and can be corrupted by loading ie. uImage or fitImage
> headers there. Sometimes it could be beneficial to load the headers
> elsewhere, ie. if CONFIG_SYS_TE
On Tue, Aug 14, 2018 at 12:10 PM Marek Vasut wrote:
>
> On 08/14/2018 11:51 AM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 11:27 AM Marek Vasut wrote:
> >>
> >> The SPL loaders assume that the CONFIG_SYS_TEXT_BASE memory location
> >> is avail
On Tue, Aug 14, 2018 at 2:05 PM Marek Vasut wrote:
>
> On 08/14/2018 12:22 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 12:10 PM Marek Vasut wrote:
> >>
> >> On 08/14/2018 11:51 AM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018 at 11:2
On Tue, Aug 14, 2018 at 8:17 PM Marek Vasut wrote:
>
> On 08/14/2018 02:56 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 2:05 PM Marek Vasut wrote:
> >>
> >> On 08/14/2018 12:22 PM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018 at 12:10
On Tue, Aug 14, 2018 at 10:37 AM Marek Vasut wrote:
>
> On 08/14/2018 08:09 AM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 13.
> > Aug. 2018, 22:36:
> >
> > On 08/13/2018 09:34 PM, Simon Goldsch
On Tue, Aug 14, 2018 at 8:12 AM Simon Goldschmidt
wrote:
>
>
>
> Marek Vasut schrieb am Mo., 13. Aug. 2018, 22:36:
>>
>> On 08/13/2018 09:34 PM, Simon Goldschmidt wrote:
>> > To boot from fpga OnChip RAM, some changes are required in SPL
>> > to ensure
Marek Vasut schrieb am Mi., 15. Aug. 2018, 10:57:
> On 08/14/2018 08:25 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 8:17 PM Marek Vasut wrote:
> >>
> >> On 08/14/2018 02:56 PM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018 at 2:05 PM Mar
On Wed, Aug 15, 2018 at 10:57 AM Marek Vasut wrote:
>
> On 08/14/2018 10:26 PM, Simon Goldschmidt wrote:
> > On Tue, Aug 14, 2018 at 8:12 AM Simon Goldschmidt
> > wrote:
> >>
> >>
> >>
> >> Marek Vasut schrieb am Mo., 13. Aug. 2018, 22:36:
On Thu, Aug 16, 2018 at 1:33 AM Marek Vasut wrote:
>
> On 08/15/2018 09:23 PM, Simon Goldschmidt wrote:
> > On Wed, Aug 15, 2018 at 10:57 AM Marek Vasut wrote:
> >>
> >> On 08/14/2018 10:26 PM, Simon Goldschmidt wrote:
> >>> On Tue, Aug 14, 2018
gd->env_addr points to pre-relocation address even after
relocation. This leads to an abort in env_callback_init
when loading the environment.
Fix this by enabling CONFIG_SYS_EXTRA_ENV_RELOC.
Signed-off-by: Simon Goldschmidt
---
Changes in v5:
Improve comments
Changes in v4:
enable this
Replaced misspelled words "parition"/"paritioning" (missing 't') in two
Kconfig files by correct words "partition"/"partitioning"
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- Improve commit message
common/spl/Kconfig| 2 +-
dr
malloc_simple() can return 0 if out of memory. Don't call memset
from calloc() in this case but rely on the caller checking
the return value.
Signed-off-by: Simon Goldschmidt
Reviewed-by: Marek Vasut
---
Changes in v1:
- extracted this patch from series "Get socfpga gen5 SPL wor
On Thu, Aug 16, 2018 at 1:18 PM Marek Vasut wrote:
>
> On 08/16/2018 09:38 AM, Simon Goldschmidt wrote:
> > gd->env_addr points to pre-relocation address even after
> > relocation. This leads to an abort in env_callback_init
> > when loading the environment.
&
Marek Vasut schrieb am Do., 16. Aug. 2018, 15:06:
> On 08/16/2018 03:00 PM, Simon Goldschmidt wrote:
> > On Thu, Aug 16, 2018 at 1:18 PM Marek Vasut wrote:
> >>
> >> On 08/16/2018 09:38 AM, Simon Goldschmidt wrote:
> >>> gd->env_addr points to pre-relo
On Thu, Aug 16, 2018 at 3:15 PM Marek Vasut wrote:
>
> On 08/16/2018 03:12 PM, Simon Goldschmidt wrote:
> >
> >
> > Marek Vasut mailto:ma...@denx.de>> schrieb am Do., 16.
> > Aug. 2018, 15:06:
> >
> > On 08/16/2018 03:00 PM, Simon Goldschmidt
On Thu, Aug 16, 2018 at 4:04 PM Marek Vasut wrote:
>
> On 08/16/2018 03:50 PM, Simon Goldschmidt wrote:
> > On Thu, Aug 16, 2018 at 3:15 PM Marek Vasut wrote:
> >>
> >> On 08/16/2018 03:12 PM, Simon Goldschmidt wrote:
> >>>
> >>>
>
nary in my configuration (socfpga_socrates_defconfig,
MACRONIX, SPANSION and STMICRO enabled).
Signed-off-by: Simon Goldschmidt
---
drivers/mtd/spi/sf_internal.h | 10 ++
drivers/mtd/spi/spi_flash.c | 7 +-
drivers/mtd/spi/spi_flash_ids.c | 270 +---
3 fil
On Fri, Aug 17, 2018 at 1:57 AM Marek Vasut wrote:
>
> On 08/16/2018 09:44 PM, Simon Goldschmidt wrote:
> > On Thu, Aug 16, 2018 at 4:04 PM Marek Vasut wrote:
> >>
> >> On 08/16/2018 03:50 PM, Simon Goldschmidt wrote:
> >>> On Thu, Aug 16, 2018 at 3:15
On Fri, Aug 17, 2018 at 12:20 PM Marek Vasut wrote:
>
> On 08/17/2018 08:56 AM, Simon Goldschmidt wrote:
> > On Fri, Aug 17, 2018 at 1:57 AM Marek Vasut wrote:
> >>
> >> On 08/16/2018 09:44 PM, Simon Goldschmidt wrote:
> >>> On Thu, Aug 16, 2018 at 4:04
On Sat, Aug 18, 2018 at 1:14 AM Tom Rini wrote:
>
> On Mon, Jul 30, 2018 at 12:53:19PM +0200, Simon Goldschmidt wrote:
>
> > To prepare supporting compression for all image types, change
> > compression to "none" for ramdisks in all examples.
> >
On Thu, Sep 6, 2018 at 5:04 AM Dalon Westergreen wrote:
>
> Stratix10 requires a hex image of the spl for boot. The hex
> image is added to the FPGA configuration image and loaded to
> the processor memory by the configuration engine.
Although not running a Stratix10, I also need a hex image for
On 30.05.2018 07:10, Jagan Teki wrote:
On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
wrote:
Hi Jagan,
On 21.05.2018 17:09, Jagan Teki wrote:
Hi Simon,
On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt
wrote:
On 14.05.2018 09:47, Simon Goldschmidt wrote:
On 14.05.2018 09
On 30.05.2018 11:56, Marek Vasut wrote:
On 05/30/2018 07:10 AM, Jagan Teki wrote:
On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
wrote:
Hi Jagan,
On 21.05.2018 17:09, Jagan Teki wrote:
Hi Simon,
On Fri, May 18, 2018 at 12:48 PM, Simon Goldschmidt
wrote:
On 14.05.2018 09:47
On 30.05.2018 13:25, Jagan Teki wrote:
On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt
wrote:
On 30.05.2018 07:10, Jagan Teki wrote:
On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
wrote:
Hi Jagan,
On 21.05.2018 17:09, Jagan Teki wrote:
Hi Simon,
On Fri, May 18, 2018 at
On 30.05.2018 13:27, Marek Vasut wrote:
On 05/30/2018 01:25 PM, Jagan Teki wrote:
On Wed, May 30, 2018 at 1:42 PM, Simon Goldschmidt
wrote:
On 30.05.2018 07:10, Jagan Teki wrote:
On Tue, May 22, 2018 at 9:59 AM, Simon Goldschmidt
wrote:
Hi Jagan,
On 21.05.2018 17:09, Jagan Teki
has been loaded from, which is questionable. But storing to all
locations or the default location might not be correct, either.
Maybe the 'env save' command might need a parameter the tells it where
to save?
Regards,
Simon (Goldschmidt)
The env_save() function should not lo
might not be correct, either.
Maybe the 'env save' command might need a parameter the tells it where
to save?
Regards,
Simon (Goldschmidt)
The env_save() function should not loop through the environment
location list but it should use the previously discovered
environment driver onc
On 11.07.2018 11:48, Maxime Ripard wrote:
Hi,
On Wed, Jul 11, 2018 at 10:33:28AM +0200, Nicholas wrote:
Hi Simon,
thanks for your comments and clarifications. I realize that I was not
super clear when describing the problem.
On mer, 2018-07-11 at 07:09 +0200, Simon Goldschmidt wrote:
Hi
On 11.07.2018 15:50, Maxime Ripard wrote:
On Wed, Jul 11, 2018 at 12:44:23PM +0200, Nicholas wrote:
Maybe a solution could be to have an env_save() function which
acts in a similar way as proposed in my patch and an
env_save_prio() function, which acts like the env_load()
i.e. looking for the
On 12.07.2018 12:52, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environment location and priority.
This behaviour causes env_save() to fall into an infinite loop when
the low-level d
On 12.07.2018 14:32, Nicholas wrote:
On gio, 2018-07-12 at 13:02 +0200, Simon Goldschmidt wrote:
On 12.07.2018 12:52, Nicholas Faustini wrote:
When called with ENVOP_SAVE, env_get_location() only returns the
gd->env_load_location variable without actually checking for
the environm
}
+ if (prio >= ARRAY_SIZE(env_locations))
+ return ENVL_UNKNOWN;
+
+ gd->env_load_location = env_locations[prio];
+ gd->env_load_prio = prio;
- return ENVL_UNKNOWN;
+ return gd->env_load_location;
Ehrm, I just saw gd->env_load_location is n
vel drv->save() call fails.
The env_save() function should not loop through the environment
location list but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini
Reviewed-by: Simon Goldschmidt
Oh n
On 12.07.2018 09:20, Maxime Ripard wrote:
On Thu, Jul 12, 2018 at 09:02:26AM +0200, Simon Goldschmidt wrote:
On 11.07.2018 15:50, Maxime Ripard wrote:
On Wed, Jul 11, 2018 at 12:44:23PM +0200, Nicholas wrote:
Maybe a solution could be to have an env_save() function which
acts in a similar
On 24.07.2018 15:07, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type. >
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
On 25.07.2018 08:40, Michal Simek wrote:
On 25.7.2018 08:26, Simon Goldschmidt wrote:
On 24.07.2018 15:07, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type. >
Signed-off-by: Michal Simek
---
common/spl/spl_fit.c | 5 +
1 f
On 25.07.2018 09:04, Michal Simek wrote:
On 25.7.2018 08:52, Simon Goldschmidt wrote:
On 25.07.2018 08:40, Michal Simek wrote:
On 25.7.2018 08:26, Simon Goldschmidt wrote:
On 24.07.2018 15:07, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel
image
st but it should save the environment into the location
stored in gd->env_load_location by the last env_load() call.
Signed-off-by: Nicholas Faustini
Reviewed-by: Simon Goldschmidt
---
Changes in v5:
- Correction to 'Reviewed-by' tag
Changes in v4:
- Remove env_load_location from g
On 26.07.2018 08:52, Michal Simek wrote:
On 25.7.2018 23:18, York Sun wrote:
On 07/24/2018 10:58 PM, Michal Simek wrote:
On 24.7.2018 18:26, York Sun wrote:
On 07/24/2018 06:07 AM, Michal Simek wrote:
There is no reason to limit gzip usage only for OS_BOOT and kernel image
type.
Signed-off
Compressed images should have their compression property
set to "none" if U-Boot should leave them compressed.
This is especially the case for compressed ramdisks that
should be uncompressed by the kernel only.
Signed-off-by: Simon Goldschmidt
---
doc/uImage.FIT/source_file_form
To prepare supporting compression for all image types, change
compression to "none" for ramdisks in all examples.
Signed-off-by: Simon Goldschmidt
---
arch/arm/cpu/armv8/fsl-layerscape/doc/README.falcon | 2 +-
doc/README.bcm7xxx | 2 +-
doc/
On 30.07.2018 13:19, Wolfgang Denk wrote:
Dear Simon,
In message <20180730105319.79424-1-sgoldschm...@de.pepperl-fuchs.com> you wrote:
Compressed images should have their compression property
set to "none" if U-Boot should leave them compressed.
This is especially the case for compressed ram
make that behavior configurable as I can see
people having put the correct compression in and not wanting it to be
uncompressed as we have examples of both none and gzip for ramdisks
today. It's also possible (and if someone wants to dig back /
experiment and
Dear Wolfgang,
On 30.07.2018 13:46, Wolfgang Denk wrote:
Dear Simon,
In message <6009778b-1c55-d67b-26a5-7d9039c85...@de.pepperl-fuchs.com> you
wrote:
It might seem obvious to you, but given the examples had both "none" and
"gzip" for ramdisk, it seems it has not been obvious for everybody.
Dear Wolfgang,
On 30.07.2018 13:45, Wolfgang Denk wrote:
Dear Simon,
In message <20180730105319.79424-2-sgoldschm...@de.pepperl-fuchs.com> you wrote:
To prepare supporting compression for all image types, change
compression to "none" for ramdisks in all examples.
What makes you think this is
On 30.07.2018 14:32, Wolfgang Denk wrote:
Dear Simon,
In message you
wrote:
These may be different examples, documenting different use cases
which do exactly what they say?
That might well be, but given that compression in FIT images only works
for kernel sub-images up to now, I strongl
On 30.07.2018 14:36, Wolfgang Denk wrote:
Dear Simon,
In message <6bce9049-a812-d8e4-cd2a-4b86dccae...@de.pepperl-fuchs.com> you
wrote:
However, uncompression currently is only implemented for kernels, not
for other sub-images. This patch aims at updating the docs and the
current .its examp
On 30.07.2018 14:44, Wolfgang Denk wrote:
Dear Simon,
In message <642b8dae-f941-5255-42c7-3761e12d0...@de.pepperl-fuchs.com> you
wrote:
As I'm not that long with U-Boot, can you point me to a rough date of a
release that I could check to see if it worked at that time?
I can only speculate
401 - 500 of 1666 matches
Mail list logo
