On Mon, Aug 13, 2018 at 08:34:05AM +0200, Sascha Hauer wrote:
> On Fri, Aug 10, 2018 at 11:50:33AM -0700, Andrey Smirnov wrote:
> > Declare ar8031_phy_fixup as static since it is not being exported to
> > any other users.
> > ---
> > arch/arm/boards/freescale-mx6sx-sabresdb/board.c | 2 +-
> > 1
On Mon, Aug 13, 2018 at 2:23 PM Robert Schwebel
wrote:
>
> On Mon, Aug 13, 2018 at 08:34:05AM +0200, Sascha Hauer wrote:
> > On Fri, Aug 10, 2018 at 11:50:33AM -0700, Andrey Smirnov wrote:
> > > Declare ar8031_phy_fixup as static since it is not being exported to
> > > any other users.
> > > ---
On Sat, Aug 11, 2018 at 12:35:39PM -0700, Andrey Smirnov wrote:
> On Mon, May 14, 2018 at 11:07 PM Sascha Hauer wrote:
> >
> > On Mon, May 14, 2018 at 05:20:56PM -0700, Andrey Smirnov wrote:
> > > On Mon, May 14, 2018 at 12:14 AM, Sascha Hauer
> > > wrote:
> > > > On Tue, May 08, 2018 at
On Fri, Aug 10, 2018 at 11:53:31AM -0700, Andrey Smirnov wrote:
> Select DRIVER_SPI_IMX_2_3 for i.MX8MQ since that is the variant that's
> being used
>
> Signed-off-by: Andrey Smirnov
> ---
> drivers/spi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks
Sascha
>
On Fri, Aug 10, 2018 at 11:52:55AM -0700, Andrey Smirnov wrote:
> Looks like that particular chunk of the code have not been built in a
> while and bitrotted. Change function parameters appropriately to avoid
> breaking the build.
>
> Signed-off-by: Andrey Smirnov
> ---
Applied, thanks
Sascha
On Fri, Aug 10, 2018 at 11:52:01AM -0700, Andrey Smirnov wrote:
> Together FEC driver and parts of IP stack might end up trying to
> memcpy() small chunks of memory from uncached (that is Device memory)
> addresses that are not properly aligned, leading to data abort.
>
> To prevent such cases,
On Fri, Aug 10, 2018 at 12:04:23PM -0700, Andrey Smirnov wrote:
> Everyone:
>
> This series is a number of fixes and changes I made for boot source
> and reset reason detection on i.MX8MQ. Hopefully all of the changes
> are self-explanatory.
>
> Feedback is welcome!
>
> Thanks,
> Andrey Smirnov
On Fri, Aug 10, 2018 at 11:50:33AM -0700, Andrey Smirnov wrote:
> Declare ar8031_phy_fixup as static since it is not being exported to
> any other users.
> ---
> arch/arm/boards/freescale-mx6sx-sabresdb/board.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks
Sascha
>
>
On Fri, Aug 10, 2018 at 11:54:21AM -0700, Andrey Smirnov wrote:
> Add code to parse "input-enable" and intepret it as SION bit. This is
> needed for I2C configuration on i.MX8MQ EVK board.
>
> Signed-off-by: Andrey Smirnov
> ---
Applied, thanks
Sascha
> drivers/pinctrl/imx-iomux-v3.c | 3 +++
On Fri, Aug 10, 2018 at 12:04:26PM -0700, Andrey Smirnov wrote:
> For both SoCs data found in SBMR registers reflects only the boot
> source that was selected via pins of fuses and not the final boot
> source that ended up being used by MaskROM code. Original i.MX7 boot
> source detection
Hi All,
barebox-2018.08.0 is out. With this release we no longer support
freeing the internal device tree (oftree -f), which has often led to use of
freed memory. Another change worth noting is that the MIPS port now
supports booting ELF Linux images. Other than that we have the usual
flow of
From: Sascha Hauer
No need for the boards to manually add memory, we can do this
automatically by reading back the memory size from the SDRAM
controller.
Signed-off-by: Sascha Hauer
Signed-off-by: Roland Hieber
---
.../arm/boards/chumby_falconwing/falconwing.c | 8 -
Allow to set not only the fractional divider, but also the prescaler for
the EMI clock in mxs_mem_init_clock(), and rename the parameters
accordingly to reflect the change. Port the existing board code to set
up the EMI clock explicitely with the old values. Also fix the
off-by-a-half error in the
Rename bo_int to prev_bo_enirq to make its purpose clearer, and throw in
a few comments for easier understanding.
Signed-off-by: Roland Hieber
---
arch/arm/mach-mxs/power-init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-mxs/power-init.c
... and in that process fix the erroneous usage of VDDA values when
printing the stats for POWER_VDDDCTRL_DISABLE_FET and all of the
*LINREG_OFFSET bitfields.
Signed-off-by: Roland Hieber
---
arch/arm/mach-mxs/power-init.c | 37 ++
1 file changed, 20
Depending on the application, board code might want to configure
different power levels and brownout thresholds. They can do so now with
an additional struct mxs_power_ctrls* parameter to mx2*_power_init.
Note that VDDMEM was not set up explicitely in mx28_power_init, but can
now be configured.
The cfg->bo_irq and cfg->bo_enirq (i.e. VDDx_BO_IRQ and ENIRQ_VDDx_BO)
flags are part of POWER_CTRL, so setting those flag in cfg->reg (i.e.
POWER_VDDxCTRL) makes no sense. Fortunately, those bits are reserved in
ENIRQ_VDDx_BO, so writing them did no harm, but also doesn't work as
intended.
From: Sascha Hauer
Normally MXS SoCs only allow to boot images which have been
encrypted with a zero key. If the ENABLE_UNENCTRYPTED_BOOT fuse
is blown then the SoC also allows to boot unencrypted images.
Add an option to the mxsimage tool to generate such images.
Signed-off-by: Sascha Hauer
Go more into detail about the relationship of the prepare stage and the
bootloader image, and about the generated images. Also don't use
mxs-usb-loader anymore since it has been removed.
Fixes: 3ca576cc4a4236a2556ab17 "scripts: imx/mxs remove mxs-usb-loader"
Signed-off-by: Roland Hieber
---
Having three ints as parameter suggests that we can use up to 2^3
power configurations for the system, but when we look at the code, the
power setup is packaged in if {...} else if {...} else if {...} blocks,
so setting more than one parameter to 1 is useless here.
Refactor the parameters into an
From: Sascha Hauer
We can detect the SDRAM automatically, no need to let the boards
do it manually.
This also fixes device tree based i.MX28 boards like the duckbill.
These boards once had a /memory node in the device tree, but now
that this was changed to /memory@4000 barebox didn't find it
On Fri, Aug 10, 2018 at 12:29:07PM -0700, Andrey Smirnov wrote:
> On Fri, Aug 10, 2018 at 9:36 AM Roland Hieber wrote:
> > diff --git a/arch/arm/mach-mxs/power-init.c b/arch/arm/mach-mxs/power-init.c
> > index 595b51c5ba..a07ff9d676 100644
> > --- a/arch/arm/mach-mxs/power-init.c
> > +++
Some boards don't need the 4.2V power source at all, so allow them to
keep it disabled for efficiency reasons.
For backwards compatibility, don't disable the 4P2 power source on the
existing boards which are supplied from battery input.
The POWER_USE_5V code path however always enables it up as
Exemplary previous behaviour:
vddio: 3100mV (BO -200mV), Linreg enabled, Linreg offset: -1, FET enabled
vdda: 1800mV (BO -175mV), Linreg disabled, Linreg offset: -1, FET enabled
vddd: 1200mV (BO -175mV), Linreg enabled, Linreg offset: -1, FET disabled
vddmem: 1500mV (BO -25mV),
The PINCTRL_*_DDR_MODE_* defines are now needed in global scope, so move
them to the respective include header.
Signed-off-by: Roland Hieber
---
arch/arm/boards/duckbill/lowlevel.c | 3 ++-
arch/arm/boards/freescale-mx28-evk/lowlevel.c | 3 ++-
arch/arm/boards/karo-tx28/lowlevel.c
mxsimage can now build unencrypted images with -u, so make use of it in
the Makefile. To keep the existing rules simple, name the generated
images *.mxsbsu instead of *.mxsbs.
Signed-off-by: Roland Hieber
---
images/Makefile.mxs | 8
1 file changed, 8 insertions(+)
diff --git
On Sun, Aug 12, 2018 at 11:41 PM Sascha Hauer wrote:
>
> On Fri, Aug 10, 2018 at 11:52:01AM -0700, Andrey Smirnov wrote:
> > Together FEC driver and parts of IP stack might end up trying to
> > memcpy() small chunks of memory from uncached (that is Device memory)
> > addresses that are not
Signed-off-by: Peter Mamonov
---
scripts/dtc/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/dtc/.gitignore b/scripts/dtc/.gitignore
index cdabdc95a..80f6b50fd 100644
--- a/scripts/dtc/.gitignore
+++ b/scripts/dtc/.gitignore
@@ -2,3 +2,4 @@ dtc
dtc-lexer.lex.c
On Mon, Aug 13, 2018 at 12:10 AM Sascha Hauer wrote:
>
> On Fri, Aug 10, 2018 at 12:04:26PM -0700, Andrey Smirnov wrote:
> > For both SoCs data found in SBMR registers reflects only the boot
> > source that was selected via pins of fuses and not the final boot
> > source that ended up being used
29 matches
Mail list logo
