From: Sinan Akman
Signed-off-by: Sinan Akman
---
Changes for v2:
- Split patches for device tree and DM_MMC
board/freescale/mpc837xerdb/mpc837xerdb.c | 9 -
configs/MPC837XERDB_defconfig | 5 -
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git
From: Sinan Akman
Signed-off-by: Sinan Akman
---
Changes for v2:
- Split patches for device tree and DM_MMC
arch/powerpc/dts/Makefile| 1 +
arch/powerpc/dts/mpc8379erdb.dts | 74
2 files changed, 75 insertions(+)
create mode 100644
Currently the driver gets ns16550 base address in the driver
probe() routine, which may potentially break any ns16550 wrapper
driver that does additional initialization before calling
ns16550_serial_probe().
Things are complicated that we need consider ns16550 devices on
both simple-bus and PCI
Hi Jehoon
On 2020-04-03 7:59 p.m., Jaehoon Chung wrote:
HI,
On 4/4/20 6:36 AM, si...@writeme.com wrote:
From: Sinan Akman
I'm not sure but its subject is strange.
It's not only the converting to DM_MMC. you're adding mpc8397.dtb device-tree.
I think you don't add device-tree for only
HI,
On 4/4/20 6:36 AM, si...@writeme.com wrote:
> From: Sinan Akman
>
I'm not sure but its subject is strange.
It's not only the converting to DM_MMC. you're adding mpc8397.dtb device-tree.
I think you don't add device-tree for only mmc.
It's better to separate patches. "Add devicetree...",
On 4/3/20 10:03 AM, Patrick DELAUNAY wrote:
> Hi Marek,
Hi,
>> From: Marek Vasut
>> Sent: lundi 30 mars 2020 16:04
>>
>> On 3/30/20 3:49 PM, Patrick DELAUNAY wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>> [...]
>>
> - /* Enable D-cache. I-cache is already enabled in start.S */
> + /* I-cache is
On 4/3/20 10:28 AM, Patrick Delaunay wrote:
> Detect and solve the overflow on phys_addr_t type for start + size in
> mmu_set_region_dcache_behaviour() function.
>
> This issue occurs for example with ARM32, start = 0xC000 and
> size = 0x4000: start + size = 0x1 and end = 0x0.
>
From: Sinan Akman
Signed-off-by: Sinan Akman
Cc: mario@gdsys.cc
---
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/mpc8379erdb.dts | 239 ++
board/freescale/mpc837xerdb/mpc837xerdb.c | 9 +-
configs/MPC837XERDB_defconfig
On 4/3/20 11:25 AM, Patrick Delaunay wrote:
> Activate cache on DDR to improves the accesses to DDR used by SPL:
> - CONFIG_SPL_BSS_START_ADDR
> - CONFIG_SYS_SPL_MALLOC_START
>
> Cache is configured only when DDR is fully initialized,
> to avoid speculative access and issue in get_ram_size().
>
On 4/3/20 11:25 AM, Patrick Delaunay wrote:
[...]
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 36a9205819..c22c1a9bbc 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -75,6 +75,12 @@
> #define PKG_SHIFT27
> #define
On 4/3/20 10:28 AM, Patrick Delaunay wrote:
> Add the new flags DCACHE_DEFAULT_OPTION to define the default
> option to use according the compilation flags
> CONFIG_SYS_ARM_CACHE_WRITETHROUGH or CONFIG_SYS_ARM_CACHE_WRITEALLOC.
Can't you unify these macros into a single Kconfig "select" statement
On 4/3/20 10:28 AM, Patrick Delaunay wrote:
> Add protection in dram_bank_mmu_setup() to avoid access to bd->bi_dram
> before relocation.
>
> This patch allow to use the generic weak function dram_bank_mmu_setup
> to activate the MMU and the data cache in SPL or in U-Boot before
> relocation,
Hi Moritz,
which version of EspressoBin do you have? How much RAM, is it DDR3 or
DDR4? How many RAM chips are there?
Marek
Tom,
Please pull u-boot-tegra/master into U-Boot/master. Thanks.
All Tegra builds are OK on my system, and Stephen's test frame reports that
all tests pass.
This adds support for Jetson Nano, plus miscellaneous other fixes found
during Nano bringup.
It also adds Igor's update_uboot wrapper
Patch Linux's device tree according to which Mox modules are connected.
Linux's device tree has all possible Mox module nodes preprogrammed, but
in disabled state.
If MOX B, MOX F or MOX G module is present, this code enables the PCI
node.
For the network modules (MOX C, MOX D and MOX E) are
Commit e8e9715df2d4 requires the USB3 regulator node to have the
enable-active-high property for the regulator to work properly. The
GPIO_ACTIVE_HIGH constant is not enough anymore.
Signed-off-by: Marek Behún
Fixes: e8e9715df2d4 ("regulator: fixed: Modify enable-active-high...")
Reviewed-by:
With recent changes to the mmc subsystem (chip detect code etc) update
the sdhci node of the Turris Mox device tree.
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
---
arch/arm/dts/armada-3720-turris-mox.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git
The SPI clock signal changes value when the SPI configuration register
is configured. This can sometimes lead to the device misinterpreting
the enablement of the SPI controller as actual clock tick.
This can be solved by first setting the SPI CS1 pin from GPIO to SPI mode,
and only after that
On Sat, Mar 28, 2020 at 12:28 AM wrote:
>
> From: Bacem Daassi
>
> The s25fl256s0 supports dual and quad read like s25fl256s1.
> Enable it by adding SPI_NOR_DUAL_READ and SPI_NOR_QUAD_READ
> flags to the flash_info entry.
> Tested on real silicon and confirmed to be working.
>
> Signed-off-by:
On Sat, Mar 14, 2020 at 6:24 PM Kuldeep Singh wrote:
>
> Commit 658df8bd9464 ("mtd: spi-nor-core: Add octal mode support")
> enables octal mode(1-1-8) support in spi-nor framework.
>
> mt35xu512aba and mt35xu02g supports SINGLE and OCTAL I/O. Hence, enable
> SPI_NOR_OCTAL_READ flag for these
On Fri, Mar 20, 2020 at 3:05 PM wrote:
>
> From: Tudor Ambarus
>
> Commit: 0ebb261a0b2d ("spi: spi-mem: Add SPI_MEM_NO_DATA to the
> spi_mem_data_dir enum")
> in linux.
>
> When defining spi_mem_op templates we don't necessarily know the size
> that will be passed when the template is actually
On Mon, Feb 24, 2020 at 12:40 PM Pratyush Yadav wrote:
>
> "assigned-clock-parents" and "assigned-clock-rates" DT properties take
> effect only after ofdata_to_platdata() when clk_set_defaults() is called
> in device_probe(). Therefore clk get rate() would return a wrong value
> in
On Fri, Mar 13, 2020 at 5:37 AM Rasmus Villemoes
wrote:
>
> hweight32 is a somewhat expensive way to check for power-of-2. Use the
> is_power_of_2 helper, which does the standard and cheap idiom
> foo&(foo-1)==0.
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-96 (-96)
> Function
On Wed, Mar 4, 2020 at 12:58 AM Robert Marko wrote:
>
> Toshiba recently launched new revisions of their serial SLC NAND series.
> TC58CVG2S0HRAIJ is a refresh of previous series with minor improvements.
> Basic parameters are same so lets add support for this new revision.
>
> Datasheet:
>
On Wed, Mar 4, 2020 at 12:57 AM Robert Marko wrote:
>
> Linux has good support for Toshiba SPI-NAND, so lets import it.
>
> Signed-off-by: Robert Marko
> Tested-by: Luka Kovacic
> Cc: Luka Perkov
> ---
> Changes from v1:
> Refresh to apply due to free() to rfree() rename
Reviewed-by: Jagan
On Wed, Feb 26, 2020 at 4:09 PM Michal Simek wrote:
>
> There is no reason to continue when DT status property indicates that NAND
> flash is disabled. But that means that NOR flash should be present that's
> why try it find it out.
>
> Signed-off-by: Michal Simek
> ---
Reviewed-by: Jagan Teki
On Wed, Feb 26, 2020 at 4:08 PM Michal Simek wrote:
>
> xnand structure is private data structure and it is handled by core and
> probe shouldn't touch it.
>
> Signed-off-by: Michal Simek
Reviewed-by: Jagan Teki
On Mon, Feb 24, 2020 at 4:52 PM Kuldeep Singh wrote:
>
> Board gets reset when performing burst read/write operations. On the
> other hand, no such behaviour is observed on small size operations.
>
> In Linux, readl_poll_timeout API already add delay of 1us which is
> skipped in U-boot. Since,
On Thu, Feb 20, 2020 at 10:58 PM Kuldeep Singh wrote:
>
> To support the SPI MEM API, instead of modifying the existing U-Boot
> driver, this patch adds a port of the existing Linux driver.
> This also has the advantage that porting changes and fixes from Linux will
> be easier.
> Porting of
On Sat, Nov 23, 2019 at 4:39 AM Vladimir Olovyannikov
wrote:
>
> Add commands for dual and quad SPI transfers on Micon SPI.
>
> Signed-off-by: Corneliu Doban
> Signed-off-by: Vladimir Olovyannikov
> ---
> include/spi.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
Hi Moritz,
On 03.04.20 16:25, Moritz Berghof wrote:
Hi Stefan, Hi Marek
I got your U-Boot mainline booting on the ESPRESSObin. First Step is done.
Your are right Stefan, the SATA makes kind of Issues. With disabling it
is booting!
Okay, thanks for testing and reporting. But we should
Hi Chee Hong,
On Fri, 3 Apr 2020 at 01:56, Ang, Chee Hong wrote:
>
> > On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong
> > wrote:
> > >
> > > > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong
> > > >
> > > > wrote:
> > > > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > > > >
Hi Tom,
Please pull this PR for the release.
Summary:
- fix for MMIO window size (Tudor Ambarus)
thanks,
Jagan.
The following changes since commit e0718b3ab754860bd47677e6b4fc5b70da42c4ab:
Merge tag 'dm-pull-1apr20' of git://git.denx.de/u-boot-dm (2020-04-01
14:29:21 -0400)
are available
On Tue, Mar 31, 2020 at 07:14:18PM +0100, Leif Lindholm wrote:
> On Mon, Mar 30, 2020 at 17:13:05 -0600, Simon Glass wrote:
> > +static void list_fact(struct acpi_fadt *fadt)
>
> Hmm, should this function be called list_facp or list_fadt?
> (The wonder that is the table called FADT with the
On Mon, Mar 30, 2020 at 05:13:05PM -0600, Simon Glass wrote:
> It is useful to dump ACPI tables in U-Boot to see what has been generated.
> Add a command to handle this.
>
> To allow the command to find the tables, add a position into the global
> data.
>
> Support subcommands to list and dump
On Mon, Mar 30, 2020 at 05:13:03PM -0600, Simon Glass wrote:
> We always write three basic tables to ACPI at the start. Move this into
> its own function, along with acpi_fill_header(), so we can write a test
> for this code.
...
> /* Re-calculate checksum */
> rsdt->header.checksum
On Fri, Apr 03, 2020 at 04:24:06PM +0300, Andy Shevchenko wrote:
> On Mon, Mar 30, 2020 at 05:12:59PM -0600, Simon Glass wrote:
> > The current code uses an address but a pointer would result in fewer
> > casts. Also it repeats the alignment code in a lot of places so this would
> > be better done
On Mon, Mar 30, 2020 at 05:12:59PM -0600, Simon Glass wrote:
> The current code uses an address but a pointer would result in fewer
> casts. Also it repeats the alignment code in a lot of places so this would
> be better done in a helper function.
>
> Update write_acpi_tables() to make use of the
On Mon, Mar 30, 2020 at 05:12:58PM -0600, Simon Glass wrote:
> A device may want to write out ACPI tables to describe itself to Linux.
> Add a method to permit this.
> +acpi_method acpi_get_method(struct udevice *dev, enum method_t method)
> +{
> + struct acpi_ops *aops;
> +
> + aops =
On Mon, Mar 30, 2020 at 05:12:56PM -0600, Simon Glass wrote:
> The DMA Remapping Reporting (DMAR) table contains information about DMA
> remapping.
>
> Add a version simple version of this table with only the minimum fields
> filled out. i.e. no entries.
> +/* TODO(s...@chromium.org): Figure out
On Fri, Apr 03, 2020 at 05:46:19AM -0700, Bin Meng wrote:
> Currently the driver gets ns16550 base address in the driver
> probe() routine, which may potentially break any ns16550 wrapper
> driver that does additional initialization before calling
> ns16550_serial_probe().
>
> Things are
On Mon, Mar 30, 2020 at 05:12:55PM -0600, Simon Glass wrote:
> Each ACPI table has its own version number. Add the version numbers in a
> single function so we can keep them consistent and easily see what
> versions are supported.
>
> Start a new acpi_table file in a generic directory to house
Hi Bin,
-"Bin Meng" schrieb: -
>Betreff: [PATCH v2] serial: ns16550: Fix ordering of getting base
>address
>
>Currently the driver gets ns16550 base address in the driver
>probe() routine, which may potentially break any ns16550 wrapper
>driver that does additional initialization before
On Mon, Mar 30, 2020 at 05:12:53PM -0600, Simon Glass wrote:
> This file is potentially useful to other architectures saddled with ACPI
> so move most of its contents to a common location.
It's not just potentially, it's definitely useful.
But this makes me think, why we don't incorporate ACPICA
On Mon, Mar 30, 2020 at 05:12:52PM -0600, Simon Glass wrote:
> This header relates to ACPI and we are about to add some more ACPI
> headers. Move this one into a new directory so they are together.
>
FWIW,
Reviewed-by: Andy Shevchenko
One nit below.
> Signed-off-by: Simon Glass
> ---
>
>
On Mon, Mar 30, 2020 at 05:12:51PM -0600, Simon Glass wrote:
> Add a sandbox test for the basic ACPI functionality we have so far.
> +U_BOOT_DRIVER(testacpi_drv) = {
> + .name = "testacpi_drv",
> + .of_match = testacpi_ids,
> + .id = UCLASS_TEST_ACPI,
> +
Currently the driver gets ns16550 base address in the driver
probe() routine, which may potentially break any ns16550 wrapper
driver that does additional initialization before calling
ns16550_serial_probe().
Things are complicated that we need consider ns16550 devices on
both simple-bus and PCI
On Mon, Mar 30, 2020 at 05:12:50PM -0600, Simon Glass wrote:
> Devices need to report various identifiers in the ACPI tables. Rather than
> hard-coding these in drivers it is typically better to put them in the
> device tree.
>
> Add a binding file to describe this.
> +elan_touchscreen:
Hi Wolfgang,
On Fri, Apr 3, 2020 at 7:47 PM Wolfgang Wallner
wrote:
>
> Hi Bin,
>
> Thanks for taking care of this!
>
> -"Bin Meng" schrieb: -
>
> >An: "Simon Glass" , "Tom Rini"
> >, "Andy Shevchenko"
> >, "Wolfgang Wallner"
> >, "Chee Hong Ang"
> >, "U-Boot Mailing List"
> >
> >Von:
On Fri, Apr 03, 2020 at 03:52:54AM +, Tan, Ley Foon wrote:
>
>
> > -Original Message-
> > From: Marek Vasut
> > Sent: Friday, April 3, 2020 6:47 AM
> > To: Tom Rini
> > Cc: Simon Glass ; Ang, Chee Hong
> > ; U-Boot Mailing List ;
> > Simon Goldschmidt ; See, Chin Liang
> > ; Tan,
On 4/3/20 5:33 AM, Chunfeng Yun wrote:
[...]
> +static int xhci_mtk_ofdata_get(struct mtk_xhci *mtk)
> +{
> + struct udevice *dev = mtk->dev;
> + int ret = 0;
> +
> + mtk->hcd = devfdt_remap_addr_name(dev, "mac");
> + if (!mtk->hcd) {
> + dev_err(dev, "Failed to get
Hi Bin,
Thanks for taking care of this!
-"Bin Meng" schrieb: -
>An: "Simon Glass" , "Tom Rini"
>, "Andy Shevchenko"
>, "Wolfgang Wallner"
>, "Chee Hong Ang"
>, "U-Boot Mailing List"
>
>Von: "Bin Meng"
>Datum: 03.04.2020 11:58
>Betreff: [PATCH] serial: ns16550: Fix ordering of getting
On Mon, Mar 30, 2020 at 05:12:48PM -0600, Simon Glass wrote:
> ACPI (Advanced Configuration and Power Interface) is a standard for
> specifying information about a platform. It is a little like device
> tree but the bindings are part of the specification and it supports an
> interpreted bytecode
On Tue, Mar 31, 2020 at 10:07:37AM +0200, Wolfgang Wallner wrote:
> >+struct __packed acpi_global_nvs {
> >+/* Miscellaneous */
> >+u8 pcnt; /* 0x00 - Processor Count */
> >+u8 ppcm; /* 0x01 - Max PPC State */
> >+u8 lids; /* 0x02 - LID State */
> >+u8
On Mon, Mar 30, 2020 at 05:12:46PM -0600, Simon Glass wrote:
> At present if reading a BAR returns 0x (e.g. the device is not
> present) then the value is masked and a different value is returned.
> This makes it harder to detect the problem when debugging.
The above ('the device is not
On Fri, Apr 03, 2020 at 06:16:51PM +0800, Bin Meng wrote:
> On Fri, Apr 3, 2020 at 6:05 PM Andy Shevchenko
> wrote:
> > On Fri, Apr 03, 2020 at 02:58:08AM -0700, Bin Meng wrote:
...
> > > Fixes: 720f9e1fdb0c9 ("serial: ns16550: Move PCI access from
> > > ofdata_to_platdata() to probe()")
> >
>
Content-Type: text/plain; charset="us-ascii"
fdtdec_set_carveout() is limited to only one phandle. Fix this
limitation by adding support for multiple phandles and also add
an unit test for the function.
Changes in v2:
- added a unit test for the function (Simon)
- added a cover letter
fdtdec_set_carveout() is limited to only one phandle. Fix this
limitation by adding support for multiple phandles.
Signed-off-by: Laurentiu Tudor
---
lib/fdtdec.c | 36 ++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/lib/fdtdec.c
Add a new test for fdtdec_set_carveout().
Signed-off-by: Laurentiu Tudor
---
test/dm/Makefile | 1 +
test/dm/fdtdec.c | 60
2 files changed, 61 insertions(+)
create mode 100644 test/dm/fdtdec.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
Hi Andy,
On Fri, Apr 3, 2020 at 6:05 PM Andy Shevchenko
wrote:
>
> On Fri, Apr 03, 2020 at 02:58:08AM -0700, Bin Meng wrote:
> > Currently the driver gets ns16550 base address in the driver
> > probe() routine, which may potentially break any ns16550 wrapper
> > driver that does additional
On Fri, Apr 3, 2020 at 1:08 PM Bin Meng wrote:
> On Fri, Apr 3, 2020 at 5:02 PM Wolfgang Wallner
> wrote:
> We can't revert as that will put PCI based ns16550 in a broken state again.
>
> I've sent a patch to fix it. Please have a try.
Just did, thank you!
--
With Best Regards,
Andy
Hi Wolfgang,
On Fri, Apr 3, 2020 at 5:02 PM Wolfgang Wallner
wrote:
>
> Hi Andy,
>
> -"Andy Shevchenko" schrieb: -
>
> The commit 720f9e1fdb0c ("Move PCI access from ofdata_to_platdata() to
> probe()") while doing formally a right thing, actually brings a regression
> to the drivers
On Fri, Apr 03, 2020 at 02:58:08AM -0700, Bin Meng wrote:
> Currently the driver gets ns16550 base address in the driver
> probe() routine, which may potentially break any ns16550 wrapper
> driver that does additional initialization before calling
> ns16550_serial_probe().
>
> Things are
Currently the driver gets ns16550 base address in the driver
probe() routine, which may potentially break any ns16550 wrapper
driver that does additional initialization before calling
ns16550_serial_probe().
Things are complicated that we need consider ns16550 devices on
both simple-bus and PCI
The content dm_ofnode_pre_reloc() is identical with ofnode_pre_reloc()
defined in drivers/core/ofnode.c and used only three times:
- drivers/core/lists.c:lists_bind_fdt()
- drivers/clk/at91/pmc.c::at91_clk_sub_device_bind
- drivers/clk/altera/clk-arria10.c::socfpga_a10_clk_bind
So this function
V2 after first feedbacks of the previous patch
"arm: stm32mp1: activate data cache in SPL and before relocation"
http://patchwork.ozlabs.org/patch/1263815/
This new serie depends on the ARM cache serie:
http://patchwork.ozlabs.org/project/uboot/list/?series=168378
I move tlb in .data section
Activate cache on DDR to improves the accesses to DDR used by SPL:
- CONFIG_SPL_BSS_START_ADDR
- CONFIG_SYS_SPL_MALLOC_START
Cache is configured only when DDR is fully initialized,
to avoid speculative access and issue in get_ram_size().
Data cache is deactivated at the end of SPL, to flush the
Activate the data cache in SPL and in U-Boot before relocation.
In arch_cpu_init(), the function early_enable_caches() sets the early
TLB, early_tlb[] located .init section, and set cacheable:
- for SPL, all the SYSRAM
- for U-Boot, all the DDR
After relocation, the function enable_caches()
Hi Andy,
-"Andy Shevchenko" schrieb: -
The commit 720f9e1fdb0c ("Move PCI access from ofdata_to_platdata() to
probe()") while doing formally a right thing, actually brings a regression
to the drivers that would like to pre-initialize hardware before calling
ns16550_serial_probe(). In
On Fri, Apr 3, 2020 at 11:40 AM Andy Shevchenko
wrote:
>
> The commit 720f9e1fdb0c ("Move PCI access from ofdata_to_platdata() to
> probe()") while doing formally a right thing, actually brings a regression
> to the drivers that would like to pre-initialize hardware before calling
>
On Fri, Apr 3, 2020 at 11:35 AM Bin Meng wrote:
> On Fri, Apr 3, 2020 at 4:26 PM Wolfgang Wallner
> wrote:
> > > -"Andy Shevchenko" schrieb: -
> > > On Thu, Apr 2, 2020 at 7:55 AM Bin Meng wrote:
...
> > > I think I understand what happened, and Wolfgang's patch *is* a culprit.
> > >
The commit 720f9e1fdb0c ("Move PCI access from ofdata_to_platdata() to
probe()") while doing formally a right thing, actually brings a regression
to the drivers that would like to pre-initialize hardware before calling
ns16550_serial_probe(). In particular, the code, which gets moved out,
is
Hi Wolfgang,
On Fri, Apr 3, 2020 at 4:26 PM Wolfgang Wallner
wrote:
>
>
> Hi Andy, Bin,
>
> > -"Andy Shevchenko" schrieb: -
> > On Thu, Apr 2, 2020 at 7:55 AM Bin Meng wrote:
> > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote:
> > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> > I'm working on enabling the VIA805 XCHI controller found on the new
> > Raspberry
> > Pi 4. The controller sits behind a PCIe bus, which I've already
> > implemented[1]
> > and will submit once the XCHI issues are resolved, as it's worthless
> > otherwise.
> >
> > The XHCI initialization
Add the new flags DCACHE_DEFAULT_OPTION to define the default
option to use according the compilation flags
CONFIG_SYS_ARM_CACHE_WRITETHROUGH or CONFIG_SYS_ARM_CACHE_WRITEALLOC.
This new compilation flag allows to simplify dram_bank_mmu_setup()
and can be used as third parameter (option=dcache
Detect and solve the overflow on phys_addr_t type for start + size in
mmu_set_region_dcache_behaviour() function.
This issue occurs for example with ARM32, start = 0xC000 and
size = 0x4000: start + size = 0x1 and end = 0x0.
Overflow is detected when end < start.
In normal case
Add protection in dram_bank_mmu_setup() to avoid access to bd->bi_dram
before relocation.
This patch allow to use the generic weak function dram_bank_mmu_setup
to activate the MMU and the data cache in SPL or in U-Boot before
relocation, when bd->bi_dram is not yet initialized.
In this cases,
Hi Andy, Bin,
> -"Andy Shevchenko" schrieb: -
> On Thu, Apr 2, 2020 at 7:55 AM Bin Meng wrote:
> > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote:
> > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> > > wrote:
> > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote:
On Fri, Apr 3, 2020 at 10:56 AM Ang, Chee Hong wrote:
> > On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong
> > wrote:
> > >
> > > > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong
> > > >
> > > > wrote:
> > > > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > > > > On Thu, Apr
Hi Marek,
> From: Marek Vasut
> Sent: lundi 30 mars 2020 16:04
>
> On 3/30/20 3:49 PM, Patrick DELAUNAY wrote:
> > Hi Marek,
>
> Hi,
>
> [...]
>
> >>> - /* Enable D-cache. I-cache is already enabled in start.S */
> >>> + /* I-cache is already enabled in start.S */
> >
> > Not needed for arm
> On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong
> wrote:
> >
> > > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong
> > >
> > > wrote:
> > > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass
> wrote:
> > > > > > > On Wed, 1 Apr
On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong wrote:
>
> > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong
> > wrote:
> > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote:
> > > > > > On Wed, 1 Apr 2020 at 11:39, Andy
+Cc: Chee Hong
On Thu, Apr 2, 2020 at 10:09 PM Andy Shevchenko
wrote:
>
> On Thu, Apr 2, 2020 at 7:55 AM Bin Meng wrote:
> > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote:
> > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
> > > wrote:
> > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600,
From: Yuantian Tang
Add this udimm memory support on ls1046ardb board.
Signed-off-by: Yuantian Tang
---
board/freescale/ls1046ardb/ddr.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/freescale/ls1046ardb/ddr.h b/board/freescale/ls1046ardb/ddr.h
index 3b4d44d465..d401daa776 100644
On 02/04/20 06:59PM, Vignesh Raghavendra wrote:
> In 1 bit mode OSPI can work at upto 50MHz, this provides before write
^
Provides _what_ before write performance? Did you mean "provides better
write performance"? Same in the
Spansion "s25fs512s" flash is incorrectly decoded as "s25fl512s" on
various platforms as former is not present. Add the entry.
Linux already has both the flashes present. A snippet below:
{ "s25fl512s", INFO6(0x010220, 0x4d0080, 256 * 1024, 256...},
{ "s25fs512s", INFO6(0x010220, 0x4d0081, 256
86 matches
Mail list logo
