Re: [U-Boot] [PATCH v2] watchdog: Fix Watchdog Reset while in U-Boot Prompt

[Tom Rini]

On Mon, Sep 19, 2016 at 01:59:44PM +0200, Andreas Reichel wrote:
> Hi Tom,
> 
> is my patch going to be applied or is the problem resolved
> otherwhise?

Sorry, lost in my patchwork queue.  I'll pick this up soon now.

> 
> Kind regards
> Andreas
> 
> On Mo, Sep 05, 2016 at 07:04:53 -0600, Simon Glass wrote:
> > +Tom, in case this should go into the release.
> > 
> > On 1 August 2016 at 05:49, Andreas J. Reichel
> >  wrote:
> > > This patch fixes unwanted watchdog resets while the user enters
> > > a command at the U-Boot prompt.
> > >
> > > As found on the CM-FX6 board from Compulab, when having enabled the
> > > watchdog, a missing WATCHDOG_RESET call in _serial_tstc() in
> > > (/drivers/serial/serial-uclass.c) causes this and alike boards to
> > > reset when the watchdog's timeout has elapsed while waiting at the
> > > U-Boot prompt.
> > >
> > > Despite the user could press several keys within the watchdog
> > > timeout limit, the while loop in cli_readline.c, line 261, does only
> > > call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st
> > > loop iteration. This leads to a watchdog timeout no matter if the
> > > user presses keys or not.
> > >
> > > The problem is solved with a call to WATCHDOG_RESET in _serial_tstc,
> > > defined in drivers/serial/serial-uclass.c.
> > >
> > > Since the macro WATCHDOG_RESET expands to {} if watchdog support
> > > isn't configured, there's no need to surround it by #ifdef in this
> > > case.
> > >
> > >  * Symptom:
> > >U-Boot resets after watchdog times out when in commandline prompt
> > >and watchdog is enabled.
> > >
> > >  * Reasoning:
> > >When U-Boot shows the commandline prompt, the following function
> > >call stack is executed while waiting for a keypress:
> > >
> > >common/main.c:
> > > main_loop  => common/cli.c: cli_loop() =>
> > >common/cli_hush.c:
> > > parse_file_outer   => parse_stream_outer   =>
> > > parse_stream   => b_getch(i)   =>
> > > i->get(i)  => file_get =>
> > > get_user_input => cmdedit_read_input   =>
> > > uboot_cli_readline =>
> > >common/cli_readline.c:
> > > cli_readline   => cli_readline_into_buffer =>
> > > cread_line => getcmd_getch (== getc)   =>
> > >commonn/console.c:
> > > fgetc  => console_tstc
> > >
> > >- in console_tstc line 181:
> > >If dev->tstc(dev) returns 0, the global tstcdev variable doesn't
> > >get set. This is the case if no character is in the serial buffer.
> > >
> > >- in fgetc(int file), line 297:
> > >Program flow keeps looping because tstcdev does not get set.
> > >Therefore WATCHDOG_RESET is not called, as mx_serial_tstc from
> > >drivers/serial/serial_mxc.c does not call it.
> > >
> > >- Initialization calls drv_system_init in stdio.c, which sets
> > >dev.tstc = stdio_serial_tstc. Thus, dev->tstc(dev) calls serial_tstc()
> > >which in turn calls _serial_tstc().
> > >
> > >Hence, _serial_tstc() needs to call WATCHDOG_RESET() to periodically
> > >reset the watchdog while cli_readline waits for user input.
> > >
> > > Signed-off-by: Christian Storm 
> > > Signed-off-by: Jan Kiszka 
> > > Signed-off-by: Andreas J. Reichel 
> > > ---
> > >
> > > Changes in v2:
> > >  - Move WATCHDOG_RESET() call from common/console.c to
> > >drivers/serial/serial-uclass.c.
> > >
> > >  drivers/serial/serial-uclass.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/serial/serial-uclass.c 
> > > b/drivers/serial/serial-uclass.c
> > > index 0ce5c44..72cf808 100644
> > > --- a/drivers/serial/serial-uclass.c
> > > +++ b/drivers/serial/serial-uclass.c
> > > @@ -155,6 +155,7 @@ static int _serial_tstc(struct udevice *dev)
> > >  {
> > > struct dm_serial_ops *ops = serial_get_ops(dev);
> > >
> > > +   WATCHDOG_RESET();
> > > if (ops->pending)
> > > return ops->pending(dev, true);
> > 
> > Great explanation, thank you.
> > 
> > Acked-by: Simon Glass 
> > 
> > >
> > > --
> > > 2.8.2
> > >
> 
> -- 
> Andreas Reichel 
> Dipl.-Phys. (Univ.) 
> Software Consultant
> 
> andreas.reic...@tngtech.com 
> +49-174-3180074
> 
> TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterföhring
> Geschäftsführer: Henrik Klagges, Christoph Stock, Dr. Robert Dahlke
> Sitz: Unterföhring * Amtsgericht München * HRB 135082

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] test/py/tests/test_sleep.py: Add check for CONFIG_CMD_MISC

[Tom Rini]

On Fri, Oct 14, 2016 at 07:13:01PM -0400, Tom Rini wrote:

> We can only run this command if the sleep command is enabled and that
> depends on CONFIG_CMD_MISC
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, RFC] ARM: create .secure_stack section only for PSCI

[Tom Rini]

On Mon, Sep 26, 2016 at 02:21:30PM +0900, Masahiro Yamada wrote:

> Jon Master reports that QEMU refuses to load a U-Boot image built
> with CONFIG_ARMV7_NONSEC, but without CONFIG_ARMV7_PSCI since
> commit 5a3aae68c74e ("ARM: armv7: guard memory reserve for PSCI
> with #ifdef CONFIG_ARMV7_PSCI").
> 
> It looks like only PSCI that needs the Secure stack, so move
> the #ifdef to guard the whole of .secure_stack allocation in order
> not to create the empty section.
> 
> Signed-off-by: Masahiro Yamada 
> Reported-by: Jon Masters 
> Link: http://patchwork.ozlabs.org/patch/664025/

Applied to u-boot/master, thanks!

... and no, I don't know how / why this caused build failures before,
but it did and I replicated it at the time too.  But I just got a
clean build everywhere.  And I've added vexpress-a15 and vexpress-a9 via
QEMU to my test setup now.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc: mpc512x: Add support for get_svr() for mpc512x devices

[Sriram Dash]

>From: Bin Meng [mailto:bmeng...@gmail.com]
>On Fri, Oct 14, 2016 at 1:49 PM, Sriram Dash  wrote:
>> Defines get_svr() for mpc512x devices
>>
>> Signed-off-by: Sriram Dash 
>> ---
>>  arch/powerpc/cpu/mpc512x/start.S | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/powerpc/cpu/mpc512x/start.S
>b/arch/powerpc/cpu/mpc512x/start.S
>> index 471d401..2507842 100644
>> --- a/arch/powerpc/cpu/mpc512x/start.S
>> +++ b/arch/powerpc/cpu/mpc512x/start.S
>> @@ -443,6 +443,11 @@ get_pvr:
>> mfspr   r3, PVR
>> blr
>>
>> +   .globl get_svr
>> +get_svr:
>> +   mfspr   r3,SVR
>
>nits: need a space after ,
>

Ok. Will take care in next version.

>> +   blr
>> +
>
>Other than that,
>Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] qemu-x86 issues

[Tom Rini]

Hey guys,

After making Stephen's scripts work with qemu today, I've started
testing out what platforms I can test out via qemu.  I've found two
problems with qemu-x86.  First, there's a real problem with the network.
I run qemu with "-nographic -cpu qemu32 -netdev
user,id=net0,tftp=/tftpboot -device e1000,netdev=net0" so that I can
tftpboot things in and I'm getting crc32 mismatches.

Second, the sleep command is not at all accurate.  It's returning the 3
second test in less than 1 second.

Any ideas, or places I should try poking to solve these issues?  I'm
going to kludge around this for now by disabling these tests locally.
Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] test/py/tests/test_sleep.py: Add check for CONFIG_CMD_MISC

[Tom Rini]

We can only run this command if the sleep command is enabled and that
depends on CONFIG_CMD_MISC

Signed-off-by: Tom Rini 
---
 test/py/tests/test_sleep.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/py/tests/test_sleep.py b/test/py/tests/test_sleep.py
index 5c1a2623fefa..b59a4cfc0fc2 100644
--- a/test/py/tests/test_sleep.py
+++ b/test/py/tests/test_sleep.py
@@ -9,6 +9,8 @@ def test_sleep(u_boot_console):
 """Test the sleep command, and validate that it sleeps for approximately
 the correct amount of time."""
 
+if u_boot_console.config.buildconfig.get('config_cmd_misc', 'n') != 'y':
+pytest.skip('sleep command not supported')
 # 3s isn't too long, but is enough to cross a few second boundaries.
 sleep_time = 3
 tstart = time.time()
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Add defconfig and dts file for Orange Pi One SBC

[Jp Theroux]

Hello hi, my name is jean-philippe theroux.

i'm rather new to linux and tonight i had the crazy idea to try to
recompile the kernel on a orange pi plus Soc.

i am using a somewhat recent distribution and i believe it's not even been
released with the actual config and all the fixes i made (to the img)

i am quite computer educated started in 1983...

just i never compiled a linux kernel being a microsoft idiot for nearly 25
years...

i am rather far in the process, i installed the compiler stuff already and
everything needed for the recompilation, downloaded kernel sources (loboris)
but i'm stuck at some point

im using this tutorial which i tried to follow

https://github.com/umiddelb/armhf/wiki/How-To-compile-a-custom-Linux-kernel-for-your-ARM-device

can i kindly ask for your help?

thanks your for your time

Jean-Philippe theroux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Issue with USB mass storage (thumb drives)

[Michael Kasprowicz]

Hi Uboot team,
Is this problem of EHCI timed out on TD - token=0x80008d80 already resolved
?

If yes can soneone please point me to the solution.
I am seeing this read timeout failure with 2 n 4 GB Usb drives.
Its a no go for our project, please help or advise.

Thanks,
Mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] ARM: sunxi: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines

[Jagan Teki]

On Thu, Oct 13, 2016 at 9:10 PM, Masahiro Yamada
 wrote:
> ARCH_SUNXI selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT
> is not used.
>
> Signed-off-by: Masahiro Yamada 
> ---

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Fix baudrate divider calculation

[Jagan Teki]

On Fri, Oct 14, 2016 at 10:54 AM, Vignesh R  wrote:
> Hi,
>
> On Thursday 13 October 2016 05:41 PM, Jagan Teki wrote:
>> On Wed, Oct 12, 2016 at 9:46 AM, Vignesh R  wrote:
>>> Fix the divider calculation logic to choose a value so that the
>>> resulting baudrate is either equal to or closest possible baudrate less
>>> than the requested value.
>>>
>>> Signed-off-by: Vignesh R 
>>> ---
>>>  drivers/spi/ti_qspi.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
>>> index 52520dff6325..d97e2479d1b3 100644
>>> --- a/drivers/spi/ti_qspi.c
>>> +++ b/drivers/spi/ti_qspi.c
>>> @@ -16,6 +16,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -118,7 +119,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, 
>>> uint hz)
>>> if (!hz)
>>> clk_div = 0;
>>> else
>>> -   clk_div = (priv->fclk / hz) - 1;
>>> +   clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1;
>>
>> Better to have a checks for min and max divider values or mask.
>
> That code already exists in this function.

True but it's unnecessary to print the wrong baud prior to checking.
Do the check, then print/debug and finally write reg.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Dinh Nguyen]

On 10/14/2016 10:09 AM, Marek Vasut wrote:
> On 10/14/2016 03:08 PM, Dinh Nguyen wrote:
>>
>>
>> On 10/14/2016 02:23 AM, Marek Vasut wrote:
>>> On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
 Hi,
>>>
>>> Hi,
>>>
 This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform 
 makes
 use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
>>>
>>> Is there some considerable performanCONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCENce 
>>> benefit over memset() in this case ?
>>>
>>
>> Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.
> 
> Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ?
> 

Yes, the scrubbing is only done if CONFIG_HPS_SDR_CTRLCFG_CTRLCFG_ECCEN
== 1.

Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Dinh Nguyen]

On 10/10/2016 10:52 AM, Dinh Nguyen wrote:
> Hi,
> 
> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes
> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
> 
> This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
> the following patch "a78cd8613204 ARM: Rework and correct barrier definitions"
> in order for this patch set to work correctly. With the above patch applied,
> after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
> device.
> 

I kinda figured out why patch "a78cd8613204 ARM: Rework and correct
barrier definitions" is causing SPL to fail after the SDRAM scrub
operation. It appears that before the above mentioned patch, the dmb()
operation is defined as this:

#define dmb()  __asm__ __volatile__ ("" : : : "memory")

after the patch, the dmb is now:

#define DMBasm volatile ("dmb sy" : : : "memory")

So the "dmb sy" as described in the ARM documentation is a "Full system
DMB operation". For whatever reason, this change is causing the SPL
error after the SDRAM scrub operation.

Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] tpm: tpm_tis_lpc: Add support for AT97SC3204

[George McCollister]

The Atmel AT97SC3204 is also TIS compliant.
Modify the tpm_tis_lpc driver to check for the vid/did used by the
Atmel AT97SC3204 and report an appropriate description.

Signed-off-by: George McCollister 
---
 drivers/tpm/tpm_tis_lpc.c | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/tpm/tpm_tis_lpc.c b/drivers/tpm/tpm_tis_lpc.c
index b4efbb5..316993a 100644
--- a/drivers/tpm/tpm_tis_lpc.c
+++ b/drivers/tpm/tpm_tis_lpc.c
@@ -21,6 +21,21 @@
 
 #define PREFIX "lpc_tpm: "
 
+enum i2c_chip_type {
+   SLB9635,
+   AT97SC3204,
+};
+
+static const char * const chip_name[] = {
+   [SLB9635] = "Infineon SLB9635 TT 1.2",
+   [AT97SC3204] = "Atmel AT97SC3204",
+};
+
+static const u32 chip_didvid[] = {
+   [SLB9635] = 0xb15d1,
+   [AT97SC3204] = 0x32041114,
+};
+
 struct tpm_locality {
u32 access;
u8 padding0[4];
@@ -146,9 +161,9 @@ static int tis_wait_reg(struct tpm_tis_lpc_priv *priv, u32 
*reg, u8 mask,
 static int tpm_tis_lpc_probe(struct udevice *dev)
 {
struct tpm_tis_lpc_priv *priv = dev_get_priv(dev);
-   u32 vid, did;
fdt_addr_t addr;
u32 didvid;
+   ulong chip_type = dev_get_driver_data(dev);
 
addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
@@ -156,15 +171,16 @@ static int tpm_tis_lpc_probe(struct udevice *dev)
priv->regs = map_sysmem(addr, 0);
didvid = tpm_read_word(priv, >regs[0].did_vid);
 
-   vid = didvid & 0x;
-   did = (didvid >> 16) & 0x;
-   if (vid != 0x15d1 || did != 0xb) {
+   if (didvid == chip_didvid[chip_type]) {
+   debug("Found TPM: %s\n", chip_name[chip_type]);
+   } else {
+   u32 vid, did;
+   vid = didvid & 0x;
+   did = (didvid >> 16) & 0x;
debug("Invalid vendor/device ID %04x/%04x\n", vid, did);
return -ENOSYS;
}
 
-   debug("Found TPM %s by %s\n", "SLB9635 TT 1.2", "Infineon");
-
return 0;
 }
 
@@ -421,11 +437,13 @@ static int tpm_tis_lpc_close(struct udevice *dev)
 
 static int tpm_tis_get_desc(struct udevice *dev, char *buf, int size)
 {
+   ulong chip_type = dev_get_driver_data(dev);
+
if (size < 50)
return -ENOSPC;
 
-   return snprintf(buf, size, "1.2 TPM (vendor %s, chip %s)",
-   "Infineon", "SLB9635 TT 1.2");
+   return snprintf(buf, size, "1.2 TPM (%s)",
+   chip_name[chip_type]);
 }
 
 
@@ -438,7 +456,8 @@ static const struct tpm_ops tpm_tis_lpc_ops = {
 };
 
 static const struct udevice_id tpm_tis_lpc_ids[] = {
-   { .compatible = "infineon,slb9635lpc" },
+   { .compatible = "infineon,slb9635lpc", .data = SLB9635 },
+   { .compatible = "atmel,at97sc3204", .data = AT97SC3204 },
{ }
 };
 
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-fdt (take 2)

[Tom Rini]

On Thu, Oct 13, 2016 at 04:53:40PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Here is a second attempt with this patch pulled in:
> 
> http://patchwork.ozlabs.org/patch/681814/
> 
> 
> The following changes since commit c69f6d04ec66433f2360490a5cd0263c83aab18f:
> 
>   Merge branch 'master' of http://git.denx.de/u-boot-mmc (2016-10-13
> 08:13:56 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git
> 
> for you to fetch changes up to 42b7600d62ae288a8c12431d232b89b26ec61721:
> 
>   libfdt: Drop inlining of fdt_path_offset() (2016-10-13 14:12:40 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[york sun]

On 10/14/2016 01:30 PM, Stephen Warren wrote:
> On 10/14/2016 02:17 PM, York Sun wrote:
>> Previously it was believed L3 cache has to be flushed in order to guarantee
>> data integrity in main memory. However, flushing L3 cache may require EL3,
>> depending on SoC implementation. Flushing with virtual address can also
>> put data into main memory. The trick is to find the correct address range.
>> For U-Boot to function correctly, the stack needs to be flushed, up to the
>> top of ram used by U-Boot.
>>
>> Signed-off-by: York Sun 
>>
>> ---
>> Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
>> Can you check if your board still works with this proposed change?
>
> I'm not convinced this is safe. If we do flush by VA rather than any
> other mechanism, we should at least iterate over the entire page table
> and find all regions marked cacheable, rather than assuming the delta
> between stack pointer and ram_top is the only relevant region. That
> said, I'm not sure even doing that will completely guarantee that the
> cache is fully clean; I think by-set/-way is the only way. I think it's
> better to leave this part as-is.

I agree this is not same as flush_all. I had internal discussion with 
our people. I acknowledge we have other memory potentially needs a 
flush. There are many possibility that a user put something in the 
memory and expect the data persists when OS comes up. My target is to 
eliminate flushing external cache.

Consider how we boot Linux. The kernel image is flushed by VA, then 
d-cache off, MMU off. When kernel comes up, it enables d-cache. As far 
as the data is not accessed for that, we don't have to flush it in 
U-Boot. I understand this is only not the whole picture. Sending out 
this RFC patch meant to start this discussion.

>
> BTW, in the very near future (I've been meaning to do this for the last
> couple of days), I expect to send a patch which adds hooks for
> SoC-/CPU-/system-specific hooks to all 3 of invalidate_dcache_all(),
> flush_dcache_all(), invalidate_icache_all(). That patch will rename
> __asm_flush_l3_cache() for consistency with the other hooks, and remove
> "l3" from the function name because the function isn't only necessary
> for L3 flushing, but can also be required by other aspects of
> multi-cluster systems. As such, the following definitely won't work for
> Tegra:
>
>> -ret = __asm_flush_l3_cache();
>
>

Let's see what the patches will be.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[Stephen Warren]

On 10/14/2016 02:17 PM, York Sun wrote:

Previously it was believed L3 cache has to be flushed in order to guarantee
data integrity in main memory. However, flushing L3 cache may require EL3,
depending on SoC implementation. Flushing with virtual address can also
put data into main memory. The trick is to find the correct address range.
For U-Boot to function correctly, the stack needs to be flushed, up to the
top of ram used by U-Boot.

Signed-off-by: York Sun 

---
Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
Can you check if your board still works with this proposed change?


I'm not convinced this is safe. If we do flush by VA rather than any 
other mechanism, we should at least iterate over the entire page table 
and find all regions marked cacheable, rather than assuming the delta 
between stack pointer and ram_top is the only relevant region. That 
said, I'm not sure even doing that will completely guarantee that the 
cache is fully clean; I think by-set/-way is the only way. I think it's 
better to leave this part as-is.


BTW, in the very near future (I've been meaning to do this for the last 
couple of days), I expect to send a patch which adds hooks for 
SoC-/CPU-/system-specific hooks to all 3 of invalidate_dcache_all(), 
flush_dcache_all(), invalidate_icache_all(). That patch will rename 
__asm_flush_l3_cache() for consistency with the other hooks, and remove 
"l3" from the function name because the function isn't only necessary 
for L3 flushing, but can also be required by other aspects of 
multi-cluster systems. As such, the following definitely won't work for 
Tegra:



-   ret = __asm_flush_l3_cache();


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[Stephen Warren]

On 10/14/2016 02:17 PM, York Sun wrote:

Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push the data to
main memory. However, external L3 cache is not guaranteed to have
the data. To fix this, flush the d-cache by way/set first to make
sure cache is clean before turning it off.



diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cd3f6c1..92d6277 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -478,9 +478,9 @@ void dcache_disable(void)
if (!(sctlr & CR_C))
return;

+   flush_dcache_all();
set_sctlr(sctlr & ~(CR_C|CR_M));

-   flush_dcache_all();
__asm_invalidate_tlb_all();
 }


This one makes sense. I'll try and test it soon.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[york sun]

On 10/14/2016 01:01 PM, York Sun wrote:
> Previously it was believed L3 cache has to be flushed in order to guarantee
> data integrity in main memory. However, flushing L3 cache may require EL3,
> depending on SoC implementation. Flushing with virtual address can also
> put data into main memory. The trick is to find the correct address range.
> For U-Boot to function correctly, the stack needs to be flushed, up to the
> top of ram used by U-Boot.
>
> Signed-off-by: York Sun 
>

Pardon me for this mess up. I thought I put the following addresses in 
Series-cc. But evidentially I did it wrong.

York


>   Thierry Reding ,
>   Radha Mohan Chintakuntla ,
>   Alison Wang ,
>   Albert Aribaud ,
>   Sergey Temerkhanov ,
>   Stephen Warren 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Resend RFC PATCH 0/2] Fix armv8 cache flushing

[York Sun]

I have been puzzled by the need to flush external L3 cache for Freescale
Layerscape series SoCs. Flushing L3 requires EL3. It is the case now, but
this may change in the future. Implementing a SMC call to perform this
task is possible but only if necessary. Recent investigation shows we can
flush by virtual address most of the time. The only exception is when
dcache_disable() is called. I think this can be addressed by flushing
the stack U-Boot is using and skip flushing L3 totally.

Once this is proved to work, we can drop flushing L3 all together.

During this investigation, I found the procedure of turning off d-cache
seems wrong. The data is lost if d-cache is off first. I am not sure
if this only happens to Freescale Layerscape SoCs. Wondering why no
one else reports any issue, expecially those SoCs without L3 cache.


York Sun (2):
  armv8: Fix dcache disable function
  armv8: Fix flush_dcache_all function

 arch/arm/cpu/armv8/cache_v8.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[York Sun]

Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push the data to
main memory. However, external L3 cache is not guaranteed to have
the data. To fix this, flush the d-cache by way/set first to make
sure cache is clean before turning it off.

Signed-off-by: York Sun 
CC: David Feng 
---

 arch/arm/cpu/armv8/cache_v8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cd3f6c1..92d6277 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -478,9 +478,9 @@ void dcache_disable(void)
if (!(sctlr & CR_C))
return;
 
+   flush_dcache_all();
set_sctlr(sctlr & ~(CR_C|CR_M));
 
-   flush_dcache_all();
__asm_invalidate_tlb_all();
 }
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [Resend RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[York Sun]

Previously it was believed L3 cache has to be flushed in order to guarantee
data integrity in main memory. However, flushing L3 cache may require EL3,
depending on SoC implementation. Flushing with virtual address can also
put data into main memory. The trick is to find the correct address range.
For U-Boot to function correctly, the stack needs to be flushed, up to the
top of ram used by U-Boot.

Signed-off-by: York Sun 

---
Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
Can you check if your board still works with this proposed change?

 arch/arm/cpu/armv8/cache_v8.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 92d6277..f5494f8 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -430,14 +430,13 @@ void invalidate_dcache_all(void)
  */
 inline void flush_dcache_all(void)
 {
-   int ret;
+   ulong sp;
 
+   asm("mov %0, sp" : "=r"(sp) : );
+   /* Flush stack to the top of ram */
+   __asm_flush_dcache_range(sp, gd->ram_top);
+   /* Flush cache by way/set */
__asm_flush_dcache_all();
-   ret = __asm_flush_l3_cache();
-   if (ret)
-   debug("flushing dcache returns 0x%x\n", ret);
-   else
-   debug("flushing dcache successfully.\n");
 }
 
 /*
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 1/2] armv8: Fix dcache disable function

[York Sun]

Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push the data to
main memory. However, external L3 cache is not guaranteed to have
the data. To fix this, flush the d-cache by way/set first to make
sure cache is clean before turning it off.

Signed-off-by: York Sun 
CC: David Feng 
---

 arch/arm/cpu/armv8/cache_v8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cd3f6c1..92d6277 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -478,9 +478,9 @@ void dcache_disable(void)
if (!(sctlr & CR_C))
return;
 
+   flush_dcache_all();
set_sctlr(sctlr & ~(CR_C|CR_M));
 
-   flush_dcache_all();
__asm_invalidate_tlb_all();
 }
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 0/2] Fix armv8 cache flushing

[York Sun]

I have been puzzled by the need to flush external L3 cache for Freescale
Layerscape series SoCs. Flushing L3 requires EL3. It is the case now, but
this may change in the future. Implementing a SMC call to perform this
task is possible but only if necessary. Recent investigation shows we can
flush by virtual address most of the time. The only exception is when
dcache_disable() is called. I think this can be addressed by flushing
the stack U-Boot is using and skip flushing L3 totally.

Once this is proved to work, we can drop flushing L3 all together.

During this investigation, I found the procedure of turning off d-cache
seems wrong. The data is lost if d-cache is off first. I am not sure
if this only happens to Freescale Layerscape SoCs. Wondering why no
one else reports any issue, expecially those SoCs without L3 cache.


York Sun (2):
  armv8: Fix dcache disable function
  armv8: Fix flush_dcache_all function

 arch/arm/cpu/armv8/cache_v8.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 2/2] armv8: Fix flush_dcache_all function

[York Sun]

Previously it was believed L3 cache has to be flushed in order to guarantee
data integrity in main memory. However, flushing L3 cache may require EL3,
depending on SoC implementation. Flushing with virtual address can also
put data into main memory. The trick is to find the correct address range.
For U-Boot to function correctly, the stack needs to be flushed, up to the
top of ram used by U-Boot.

Signed-off-by: York Sun 

Thierry Reding ,
Radha Mohan Chintakuntla ,
Alison Wang ,
Albert Aribaud ,
Sergey Temerkhanov ,
Stephen Warren 

---
Stephen Warren, your recently added flushing L3 cache for tegra (8e5d804).
Can you check if your board still works with this proposed change?

 arch/arm/cpu/armv8/cache_v8.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 92d6277..f5494f8 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -430,14 +430,13 @@ void invalidate_dcache_all(void)
  */
 inline void flush_dcache_all(void)
 {
-   int ret;
+   ulong sp;
 
+   asm("mov %0, sp" : "=r"(sp) : );
+   /* Flush stack to the top of ram */
+   __asm_flush_dcache_range(sp, gd->ram_top);
+   /* Flush cache by way/set */
__asm_flush_dcache_all();
-   ret = __asm_flush_l3_cache();
-   if (ret)
-   debug("flushing dcache returns 0x%x\n", ret);
-   else
-   debug("flushing dcache successfully.\n");
 }
 
 /*
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

[york sun]

On 10/13/2016 11:45 PM, Yao Yuan wrote:
> On 10/12/2016 08:00 PM, York Sun wrote:
>> On 10/11/2016 08:00 PM, Yao Yuan wrote:

 Yuan Yao,

 I think the procedure can be applied to many of our boards with QSPI,
 right? It may be better to move this information out of ls2080aqds.

>>>
>>> Hi York,
>>>
>>> Yes, but a little difference for "CCSR  write" for different boards.
>>> But the "CCSR write" should be wrote into uboot code or cw.
>>> So, should I remove the notes for "CCSR  write" and then move this
>>> information for  all the boards which support QSPI boot?
>>>
>>
>> I think you can put the common practice together with specific examples for
>> LS2080A, and other SoCs.
>>
>
> Hi York,
>
> If move this information out of ls2080aqds.
> Do you think where can I put the procedure for all the boards?
> In every board's README or somewhere for the common procedure?
>

Yao,

Take a look at these locations and decide which one fits best.

arch/arm/cpu/armv8/fsl-layerscape/doc/README.*
doc/README.fsl-qspi (you can create this)

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC 3/4] dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS

[Marek Vasut]

On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
> From: Dinh Nguyen 
> 
> Add DMA_SUPPORTS_DEV_TO_MEM type to the DMA uclass.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  drivers/dma/dma-uclass.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
> index ea21fd9..a021395 100644
> --- a/drivers/dma/dma-uclass.c
> +++ b/drivers/dma/dma-uclass.c
> @@ -49,7 +49,8 @@ int dma_memcpy(void *dst, void *src, size_t len)
>   const struct dma_ops *ops;
>   int ret;
>  
> - ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM, );
> + ret = dma_get_device(DMA_SUPPORTS_MEM_TO_MEM |
> +  DMA_SUPPORTS_DEV_TO_MEM, );
>   if (ret < 0)
>   return ret;
>  
> 

The memcpy() is not used for doing dev-to-mem transfers, it's only used
for mem-to-mem transfers, so this patch is wrong. I believe the driver
needs to be corrected if it supports mem2mem transfers but doesn't
advertise them.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC 2/4] dma: Kconfig: Add CONFIG_PL330_DMA entry

[Marek Vasut]

On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
> From: Dinh Nguyen 
> 
> Add PL330_DMA entry.
> 
> Signed-off-by: Dinh Nguyen 

This should be wrapped into 1/4

> ---
>  drivers/dma/Kconfig  | 4 
>  drivers/dma/Makefile | 1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 1b92c77..d95f959 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -19,4 +19,8 @@ config TI_EDMA3
> This driver support data transfer between memory
> regions.
>  
> +config PL330_DMA
> + bool "PL330 DMA driver"
> + help
> +   Enable the ARM PL330 DMA driver.
>  endmenu # menu "DMA Support"
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index 39b78b2..d287512 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o
>  obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
>  obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
>  obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
> +obj-$(CONFIG_PL330_DMA) += pl330.o
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Marek Vasut]

On 10/14/2016 03:08 PM, Dinh Nguyen wrote:
> 
> 
> On 10/14/2016 02:23 AM, Marek Vasut wrote:
>> On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
>>> Hi,
>>
>> Hi,
>>
>>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform 
>>> makes
>>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
>>
>> Is there some considerable performance benefit over memset() in this case ?
>>
> 
> Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.

Understood, thanks. I hope the scrubbing can be disabled in non-ECC case ?

> Dinh
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] ARM: AMx3xx: Allow arch specific code to use early DM

[Tom Rini]

On Fri, Oct 14, 2016 at 10:35:23AM +0530, Lokesh Vutla wrote:

> Early system initialization is being done before initf_dm is being called
> in U-Boot. Then system will fail to boot if any of the DM enabled driver
> is being called in this system initialization code. So, rearrange the
> code a bit so that DM enabled drivers can be called during early system
> initialization. This is inspired by commit e850ed82bce8 ("ARM: OMAP4+: Allow
> arch specific code to use early DM")
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] board: ti: amx3xx: Remove multiple EEPROM reads

[Tom Rini]

On Fri, Oct 14, 2016 at 10:35:25AM +0530, Lokesh Vutla wrote:

> Detect the board very early and avoid reading eeprom multiple times.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] ARM: AMx3xx: Centralize early clock initialization

[Tom Rini]

On Fri, Oct 14, 2016 at 10:35:24AM +0530, Lokesh Vutla wrote:

> This is similar to Commit 93e6253d11030 ("ARM: OMAP4/5: Centralize
> early clock initialization") that was done for OMAP4+, reflecting the same
> for AM33xx and AM43xx SoCs to centralize clock initialization.
> 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NFS and timeouts?

[Tom Rini]

On Fri, Oct 14, 2016 at 11:13:11AM +0200, Guillaume Gardet wrote:
> Hi,
> 
> 
> Le 14/10/2016 à 01:00, Joe Hershberger a écrit :
> >On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass  wrote:
> >>Hi Tom,
> >>
> >>On 13 October 2016 at 13:11, Tom Rini  wrote:
> >>>Hey all,
> >>>
> >>>I've noticed now, but not dug into a problem that goes like this.  On
> >>>every platform that I have tried NFS on now (and I wasn't a user before
> >>>the test came in) I see:
> >>># nfs 8000 /tftpboot/1MiBtest.bin
> >>>link up on port 0, speed 1000, full duplex
> >>>#
> >>>  #
> >>>  #
> >>>  ##T T T T
> >>>done
> >>>Bytes transferred = 1048576 (10 hex)
> >>>
> >>>for the same 1MiB file.  The link line will vary from board to board but
> >>>the end result is that I always see 4 T (for timeout) at the end of the
> >>>transfer.  On boards where I am doing this on gigabit the initial
> >>>transfer is fast enough that the timeout doesn't cause failure.  On the
> >>>boards where I'm at 100Mbit instead however, I fail.
> >>I have seen this also - what type of interface are you using?
> >Does this happen in your testing, Guillaume?
> >
> 
> No, I never saw those timeouts. I will try to reproduce here.
> On which boards does it happen?

AM335x GP EVM, DRA72x EVM ("J6 Eco"), Beagleboard xM, RPi 3 (32 or 64bit
mode).  I suspect it's something either config or network related.
Everything is on the same 24 port gigabit switch.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] power: twl6030: fix code refactoring

[Paul Kocialkowski]

Le jeudi 13 octobre 2016 à 13:47 +0300, Nicolae Rosia a écrit :
> From: Nicolae Rosia 
> 
> Commit a85362fb3e1fc7833723accddbbae431091d06b8 refactored the code
> but the register read ended up in the wrong if branch.
> Currently, the else branch checks a variable which is always 0.

Good catch! Sorry for including that regression in the first place, I should
have checked the patch more thoroughly.

See comment below.

> Signed-off-by: Nicolae Rosia 
> ---
>  drivers/power/twl6030.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/power/twl6030.c b/drivers/power/twl6030.c
> index 05c79be..cd53200 100644
> --- a/drivers/power/twl6030.c
> +++ b/drivers/power/twl6030.c
> @@ -231,9 +231,9 @@ void twl6030_power_mmc_init(int dev_index)
>   /* Enable P1 output for VMMC */
>   twl6030_i2c_write_u8(TWL6030_CHIP_PM, TWL6030_VMMC_CFG_STATE,
>   TWL6030_CFG_STATE_P1 | TWL6030_CFG_STATE_ON);
> -
> - twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT,
> );
>   } else if (dev_index == 1) {
> + twl6030_i2c_read_u8(TWL6030_CHIP_PM, TWL6030_PH_STS_BOOT,
> + );

The indentation before  is inconsistent with what is done in the rest of
the file. I think you should either just move the line as it was or only use one
extra tab indent for the new line. Since this file breaks the 80 chars limit in
a few places, I would tend to prefer the former.

>   /* BOOT2 indicates 1.8V/2.8V VAUX1 for eMMC */
>   if (value & TWL6030_PH_STS_BOOT2) {
>   /* 1.8V voltage output for VAUX1 */

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Dinh Nguyen]

On 10/14/2016 02:23 AM, Marek Vasut wrote:
> On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
>> Hi,
> 
> Hi,
> 
>> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes
>> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.
> 
> Is there some considerable performance benefit over memset() in this case ?
> 

Yes, with the DMA, it takes ~1.5 secs, with memset, it's ~15 secs.

Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] driver: net: cpsw: add support for RGMII id mode support and RMII clock source selection

[Roger Quadros]

Joe,

On 02/09/16 17:53, Tom Rini wrote:
> On Wed, Aug 24, 2016 at 03:35:49PM +0300, Roger Quadros wrote:
> 
>> From: Mugunthan V N 
>>
>> cpsw driver supports only selection of phy mode in control module
>> but control module has more setting like RGMII ID mode selection,
>> RMII clock source selection. So ported to cpsw-phy-sel driver
>> from kernel to u-boot.
>>
>> [Lokesh Vutla]
>> - Update for am43xx variants.
>> - Use DT data to configure external chip clock for RMII mode.
>>
>> Signed-off-by: Mugunthan V N 
>> Signed-off-by: Lokesh Vutla 
>> Signed-off-by: Roger Quadros 
> 
> Reviewed-by: Tom Rini 
> 
Seems like you have missed this patch and picked the remaining two in this 
series.

cheers,
-roger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] efi_loader: Rename EFI_RUNTIME_{TEXT, DATA} to __efi_runtime{, _data}

[Alexander Graf]

Compiler attributes are more commonly __foo style tags rather than big
upper case eye sores like EFI_RUNTIME_TEXT.

Simon Glass felt quite strongly about this, so this patch converts our
existing defines over to more eye friendly ones.

Signed-off-by: Alexander Graf 
---
 arch/arm/cpu/armv8/fwcall.c   | 12 ++--
 include/efi_loader.h  | 12 ++--
 lib/efi_loader/efi_boottime.c |  6 +++---
 lib/efi_loader/efi_runtime.c  | 20 ++--
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
index 64539f9..7dfd270 100644
--- a/arch/arm/cpu/armv8/fwcall.c
+++ b/arch/arm/cpu/armv8/fwcall.c
@@ -18,7 +18,7 @@
  * x0~x7: input arguments
  * x0~x3: output arguments
  */
-static void EFI_RUNTIME_TEXT hvc_call(struct pt_regs *args)
+static void __efi_runtime hvc_call(struct pt_regs *args)
 {
asm volatile(
"ldr x0, %0\n"
@@ -52,7 +52,7 @@ static void EFI_RUNTIME_TEXT hvc_call(struct pt_regs *args)
  * x0~x3: output arguments
  */
 
-void EFI_RUNTIME_TEXT smc_call(struct pt_regs *args)
+void __efi_runtime smc_call(struct pt_regs *args)
 {
asm volatile(
"ldr x0, %0\n"
@@ -82,9 +82,9 @@ void EFI_RUNTIME_TEXT smc_call(struct pt_regs *args)
  * use PSCI on U-Boot running below a hypervisor, please detect
  * this and set the flag accordingly.
  */
-static const EFI_RUNTIME_DATA bool use_smc_for_psci = true;
+static const __efi_runtime_data bool use_smc_for_psci = true;
 
-void __noreturn EFI_RUNTIME_TEXT psci_system_reset(void)
+void __noreturn __efi_runtime psci_system_reset(void)
 {
struct pt_regs regs;
 
@@ -99,7 +99,7 @@ void __noreturn EFI_RUNTIME_TEXT psci_system_reset(void)
;
 }
 
-void __noreturn EFI_RUNTIME_TEXT psci_system_off(void)
+void __noreturn __efi_runtime psci_system_off(void)
 {
struct pt_regs regs;
 
@@ -121,7 +121,7 @@ void reset_misc(void)
 }
 
 #ifdef CONFIG_EFI_LOADER
-void EFI_RUNTIME_TEXT EFIAPI efi_reset_system(
+void __efi_runtime EFIAPI efi_reset_system(
enum efi_reset_type reset_type,
efi_status_t reset_status,
unsigned long data_size, void *reset_data)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 871499f..35b3fe2 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -156,8 +156,8 @@ static inline void ascii2unicode(u16 *unicode, const char 
*ascii)
  * Use these to indicate that your code / data should go into the EFI runtime
  * section and thus still be available when the OS is running
  */
-#define EFI_RUNTIME_DATA __attribute__ ((section ("efi_runtime_data")))
-#define EFI_RUNTIME_TEXT __attribute__ ((section ("efi_runtime_text")))
+#define __efi_runtime_data __attribute__ ((section ("efi_runtime_data")))
+#define __efi_runtime __attribute__ ((section ("efi_runtime_text")))
 
 /* Call this with mmio_ptr as the _pointer_ to a pointer to an MMIO region
  * to make it available at runtime */
@@ -165,13 +165,13 @@ void efi_add_runtime_mmio(void *mmio_ptr, u64 len);
 
 /* Boards may provide the functions below to implement RTS functionality */
 
-void EFI_RUNTIME_TEXT EFIAPI efi_reset_system(
+void __efi_runtime EFIAPI efi_reset_system(
enum efi_reset_type reset_type,
efi_status_t reset_status,
unsigned long data_size, void *reset_data);
 void efi_reset_system_init(void);
 
-efi_status_t EFI_RUNTIME_TEXT EFIAPI efi_get_time(
+efi_status_t __efi_runtime EFIAPI efi_get_time(
struct efi_time *time,
struct efi_time_cap *capabilities);
 void efi_get_time_init(void);
@@ -179,8 +179,8 @@ void efi_get_time_init(void);
 #else /* defined(EFI_LOADER) && !defined(CONFIG_SPL_BUILD) */
 
 /* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
-#define EFI_RUNTIME_DATA
-#define EFI_RUNTIME_TEXT
+#define __efi_runtime_data
+#define __efi_runtime
 static inline void efi_add_runtime_mmio(void **mmio_ptr, u64 len) { }
 
 /* No loader configured, stub out EFI_ENTRY */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 476ef1b..1fdddf4 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -37,7 +37,7 @@ static bool efi_is_direct_boot = true;
  * In most cases we want to pass an FDT to the payload, so reserve one slot of
  * config table space for it. The pointer gets populated by do_bootefi_exec().
  */
-static struct efi_configuration_table EFI_RUNTIME_DATA efi_conf_table[2];
+static struct efi_configuration_table __efi_runtime_data efi_conf_table[2];
 
 #ifdef CONFIG_ARM
 /*
@@ -790,10 +790,10 @@ static const struct efi_boot_services efi_boot_services = 
{
 };
 
 
-static uint16_t EFI_RUNTIME_DATA firmware_vendor[] =
+static uint16_t __efi_runtime_data firmware_vendor[] =
{ 'D','a','s',' ','U','-','b','o','o','t',0 };

[U-Boot] [PicoZed] Error uenvboot script

[Oscar Gomez Fuente]

Hi everyone,

I'm trying to boot u-boot from uEnv.txt. And I've got a problem. I'm
using zynq_picozed_defconfig

The problem is I've got this error after the uEnv.txt is read:
---
...
eth0: ethernet@e000b000
Hit any key to stop autoboot:  0
Device: sdhci@e010
Manufacturer ID: 3
OEM: 5344
Name: SL16G
Tran Speed: 5000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
reading uEnv.txt
754 bytes read in 15 ms (48.8 KiB/s)
Loaded environment from uEnv.txt
Importing environment from SD ...
test - minimal test like /bin/sh

Usage:
test [args..]
---

It seems to be that fail to run the script:

uenvboot=if run loadbootenv; then echo Loaded environment from ${bootenv};
run importbootenv; fi; if test -n $uenvcmd; then echo Running uenvcmd ...;
run uenvcmd; fi

When the test -n $uenvcmd is executed, but I don't understand why, because
when I execute the script, run uenvcmd runs fine.

Any suggestion? It seems to be when the console is ready the test function
works fine, but before it fails.


Best regards.

Oscar Gomez Fuente.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spi: ti_qspi: Fix baudrate divider calculation

[R, Vignesh]

On 10/14/2016 12:27 PM, Jagan Teki wrote:
> On Fri, Oct 14, 2016 at 10:54 AM, Vignesh R  wrote:
...
  DECLARE_GLOBAL_DATA_PTR;

 @@ -118,7 +119,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv 
 *priv, uint hz)
 if (!hz)
 clk_div = 0;
 else
 -   clk_div = (priv->fclk / hz) - 1;
 +   clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1;
>>>
>>> Better to have a checks for min and max divider values or mask.
>>
>> That code already exists in this function.
> 
> True but it's unnecessary to print the wrong baud prior to checking.
> Do the check, then print/debug and finally write reg.
> 

Posted a v2 in reply to the patch. Thanks for the review!

Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] spi: ti_qspi: Fix baudrate divider calculation

[Vignesh R]

Fix the divider calculation logic to choose a value so that the
resulting baudrate is either equal to or closest possible baudrate less
than the requested value. While at that, cleanup ti_spi_set_speed().

Signed-off-by: Vignesh R 
---

v2: cleanup ti_spi_set_speed() a bit.

 drivers/spi/ti_qspi.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index 52520dff6325..b5de70bf40e3 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -118,21 +119,19 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, 
uint hz)
if (!hz)
clk_div = 0;
else
-   clk_div = (priv->fclk / hz) - 1;
-
-   debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
+   clk_div = DIV_ROUND_UP(priv->fclk, hz) - 1;
 
/* disable SCLK */
writel(readl(>base->clk_ctrl) & ~QSPI_CLK_EN,
   >base->clk_ctrl);
 
-   /* assign clk_div values */
-   if (clk_div < 0)
-   clk_div = 0;
-   else if (clk_div > QSPI_CLK_DIV_MAX)
+   /* truncate clk_div value to QSPI_CLK_DIV_MAX */
+   if (clk_div > QSPI_CLK_DIV_MAX)
clk_div = QSPI_CLK_DIV_MAX;
 
-   /* enable SCLK */
+   debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
+
+   /* enable SCLK and program the clk divider */
writel(QSPI_CLK_EN | clk_div, >base->clk_ctrl);
 }
 
-- 
2.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] ext4: Only write journal entries for modified blocks in unlink_filename

[Lukasz Majewski]

Hi Stefan,

> Instead of creating a journal entry for each directory block, even
> if the block is unmodified, only log the modified block.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  fs/ext4/ext4_common.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index 11be0b7..ec02eec 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -874,8 +874,6 @@ static int unlink_filename(char *filename,
> unsigned int blknr) if (status == 0)
>   goto fail;
>  
> - if (ext4fs_log_journal(block_buffer, blknr))
> - goto fail;
>   offset = 0;
>   do {
>   previous_dir = dir;
> @@ -889,14 +887,6 @@ static int unlink_filename(char *filename,
> unsigned int blknr) if (dir->inode && (strlen(filename) ==
> dir->namelen) && (strncmp(direntname, filename, dir->namelen) == 0)) {
>   inodeno = le32_to_cpu(dir->inode);
> - if (previous_dir) {
> - uint16_t new_len;
> - new_len =
> le16_to_cpu(previous_dir->direntlen);
> - new_len +=
> le16_to_cpu(dir->direntlen);
> - previous_dir->direntlen =
> cpu_to_le16(new_len);
> - } else {
> - dir->inode = 0;
> - }
>   break;
>   }
>  
> @@ -905,7 +895,20 @@ static int unlink_filename(char *filename,
> unsigned int blknr) } while (offset < fs->blksz);
>  
>   if (inodeno > 0) {
> + printf("file found, deleting\n");
> + if (ext4fs_log_journal(block_buffer, blknr))
> + goto fail;
>  
> + if (previous_dir) {
> + /* merge dir entry with predecessor */
> + uint16_t new_len;
> + new_len =
> le16_to_cpu(previous_dir->direntlen);
> + new_len += le16_to_cpu(dir->direntlen);
> + previous_dir->direntlen =
> cpu_to_le16(new_len);
> + } else {
> + /* invalidate dir entry */
> + dir->inode = 0;
> + }
>   if (ext4fs_put_metadata(block_buffer, blknr))
>   goto fail;
>   ret = inodeno;

Reviewed-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] ext4: Fix handling of direntlen in unlink_filename

[Lukasz Majewski]

Hi Stefan,

> The direntlen checks were quite bogus, i.e. the loop termination used
> "len + offset == blocksize" (exact match only), and checked for a
> direntlen less than 0. The latter can never happen as the len is
> unsigned, this has been reported by Coverity, CID 153384.
> 
> Use the same code as in search_dir for directory traversal. This code
> has the correct checks for direntlen >= sizeof(struct dirent), and
> offset < blocksize.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  fs/ext4/ext4_common.c | 45
> + 1 file changed, 17
> insertions(+), 28 deletions(-)
> 
> diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
> index 699a640..11be0b7 100644
> --- a/fs/ext4/ext4_common.c
> +++ b/fs/ext4/ext4_common.c
> @@ -854,16 +854,15 @@ fail:
>  
>  static int unlink_filename(char *filename, unsigned int blknr)
>  {
> - int templength = 0;
> - int status, inodeno;
> - int found = 0;
> + int status;
> + int inodeno = 0;
>   int offset;
>   char *block_buffer = NULL;
>   struct ext2_dirent *dir = NULL;
> - struct ext2_dirent *previous_dir = NULL;
> - char *ptr = NULL;
> + struct ext2_dirent *previous_dir;
>   struct ext_filesystem *fs = get_fs();
>   int ret = -1;
> + char *direntname;
>  
>   block_buffer = zalloc(fs->blksz);
>   if (!block_buffer)
> @@ -877,20 +876,18 @@ static int unlink_filename(char *filename,
> unsigned int blknr) 
>   if (ext4fs_log_journal(block_buffer, blknr))
>   goto fail;
> - dir = (struct ext2_dirent *)block_buffer;
> - ptr = (char *)dir;
>   offset = 0;
> - while (le16_to_cpu(dir->direntlen) >= 0) {
> - /*
> -  * blocksize-offset because last
> -  * directory length i.e., *dir->direntlen
> -  * is free availble space in the block that
> -  * means it is a last entry of directory entry
> -  */
> + do {
> + previous_dir = dir;
> + dir = (struct ext2_dirent *)(block_buffer + offset);
> + direntname = (char *)(dir) + sizeof(struct
> ext2_dirent); +
> + int direntlen = le16_to_cpu(dir->direntlen);
> + if (direntlen < sizeof(struct ext2_dirent))
> + break;
> +
>   if (dir->inode && (strlen(filename) == dir->namelen)
> &&
> - (strncmp(ptr + sizeof(struct ext2_dirent),
> -  filename, dir->namelen) == 0)) {
> - printf("file found, deleting\n");
> + (strncmp(direntname, filename, dir->namelen) ==
> 0)) { inodeno = le32_to_cpu(dir->inode);
>   if (previous_dir) {
>   uint16_t new_len;
> @@ -900,23 +897,15 @@ static int unlink_filename(char *filename,
> unsigned int blknr) } else {
>   dir->inode = 0;
>   }
> - found = 1;
>   break;
>   }
>  
> - if (fs->blksz - offset ==
> le16_to_cpu(dir->direntlen))
> - break;
> + offset += direntlen;
>  
> - /* traversing the each directory entry */
> - templength = le16_to_cpu(dir->direntlen);
> - offset = offset + templength;
> - previous_dir = dir;
> - dir = (struct ext2_dirent *)((char *)dir +
> templength);
> - ptr = (char *)dir;
> - }
> + } while (offset < fs->blksz);
>  
> + if (inodeno > 0) {
>  
> - if (found == 1) {
>   if (ext4fs_put_metadata(block_buffer, blknr))
>   goto fail;
>   ret = inodeno;

Reviewed-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] 0/4] Add Pl330 DMA support

[Marek Vasut]

On 10/10/2016 05:52 PM, Dinh Nguyen wrote:
> Hi,

Hi,

> This patchset adds the PL330 DMA driver to U-Boot. The SoCFPGA platform makes
> use of the PL330 to transfer zereos to the SDRAM which enables the ECC bit.

Is there some considerable performance benefit over memset() in this case ?

> This is only an RFC because after rebasing to v2016.11-rc1, I had to revert
> the following patch "a78cd8613204 ARM: Rework and correct barrier definitions"
> in order for this patch set to work correctly. With the above patch applied,
> after the SDRAM scrubbing is complete, the SPL is failing to find the MMC
> device.
> 
> I'm continue to debug this, but would like to solicit comments with this
> patchset.
> 
> Thanks,
> Dinh
> 
> 
> Dinh Nguyen (4):
>   drivers: dma: Add the ARM PL330 DMA driver
>   dma: Kconfig: Add CONFIG_PL330_DMA entry
>   dm: add DMA_SUPPORTS_DEV_TO_MEM type to DMA_UCLASS
>   arm: socfpga: scrub the SDRAM to properly enable ECC support
> 
>  arch/arm/include/asm/pl330.h   | 105 +++
>  arch/arm/mach-socfpga/include/mach/reset_manager.h |  21 +
>  arch/arm/mach-socfpga/include/mach/sdram.h |   2 +
>  arch/arm/mach-socfpga/spl.c|   8 +
>  arch/arm/mach-socfpga/wrap_sdram_config.c  |  28 +
>  configs/socfpga_cyclone5_defconfig |   2 +
>  drivers/dma/Kconfig|   4 +
>  drivers/dma/Makefile   |   1 +
>  drivers/dma/dma-uclass.c   |   3 +-
>  drivers/dma/pl330.c| 942 
> +
>  10 files changed, 1115 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/include/asm/pl330.h
>  create mode 100644 drivers/dma/pl330.c
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] NFS and timeouts?

[Guillaume Gardet]

Hi,


Le 14/10/2016 à 01:00, Joe Hershberger a écrit :

On Fri, Oct 14, 2016 at 12:52 AM, Simon Glass  wrote:

Hi Tom,

On 13 October 2016 at 13:11, Tom Rini  wrote:

Hey all,

I've noticed now, but not dug into a problem that goes like this.  On
every platform that I have tried NFS on now (and I wasn't a user before
the test came in) I see:
# nfs 8000 /tftpboot/1MiBtest.bin
link up on port 0, speed 1000, full duplex
#
  #
  #
  ##T T T T
done
Bytes transferred = 1048576 (10 hex)

for the same 1MiB file.  The link line will vary from board to board but
the end result is that I always see 4 T (for timeout) at the end of the
transfer.  On boards where I am doing this on gigabit the initial
transfer is fast enough that the timeout doesn't cause failure.  On the
boards where I'm at 100Mbit instead however, I fail.

I have seen this also - what type of interface are you using?

Does this happen in your testing, Guillaume?



No, I never saw those timeouts. I will try to reproduce here.
On which boards does it happen?

Guillaume


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] ARM: zynq(mp): remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines

[Moritz Fischer]

On Fri, Oct 14, 2016 at 9:29 AM, Michal Simek  wrote:
> On 13.10.2016 17:40, Masahiro Yamada wrote:
>> ARCH_ZYNQ(MP) selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT
>> is not used.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  include/configs/xilinx_zynqmp.h | 1 -
>>  include/configs/zynq-common.h   | 1 -
>>  2 files changed, 2 deletions(-)
>>
>> diff --git a/include/configs/xilinx_zynqmp.h 
>> b/include/configs/xilinx_zynqmp.h
>> index adc42cf..c8e1ffa 100644
>> --- a/include/configs/xilinx_zynqmp.h
>> +++ b/include/configs/xilinx_zynqmp.h
>> @@ -110,7 +110,6 @@
>>  #define CONFIG_SYS_LOAD_ADDR 0x800
>>
>>  #if defined(CONFIG_ZYNQMP_USB)
>> -#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
>>  #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS  2
>>  #define CONFIG_USB_XHCI_ZYNQMP
>>
>> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
>> index 0118fd2..7cca83f 100644
>> --- a/include/configs/zynq-common.h
>> +++ b/include/configs/zynq-common.h
>> @@ -86,7 +86,6 @@
>>
>>  #ifdef CONFIG_USB_EHCI_ZYNQ
>>  # define CONFIG_EHCI_IS_TDI
>> -# define CONFIG_USB_MAX_CONTROLLER_COUNT 2
>>
>>  # define CONFIG_SYS_DFU_DATA_BUF_SIZE0x60
>>  # define DFU_DEFAULT_POLL_TIMEOUT300
>>
>
> Acked-by: Michal Simek 
Acked-by: Moritz Fischer 

Cheers,

Moritz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 6/9] cmd, help: break the help command

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 cmd/help.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/help.c b/cmd/help.c
index 701ae7e..d58bbdd 100644
--- a/cmd/help.c
+++ b/cmd/help.c
@@ -30,7 +30,7 @@ U_BOOT_CMD(
 
 /* This does not use the U_BOOT_CMD macro as ? can't be used in symbol names */
 ll_entry_declare(cmd_tbl_t, question_mark, cmd) = {
-   "?",CONFIG_SYS_MAXARGS, 1,  do_help,
+   "??",   CONFIG_SYS_MAXARGS, 1,  do_help,
"alias for 'help'",
 #ifdef  CONFIG_SYS_LONGHELP
""
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 5/9] README: simple change 5

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index cf98e7c..2305a77 100644
--- a/README
+++ b/README
@@ -9,6 +9,7 @@ Test
 Test 2
 Test 3
 Test 4
+Test 5
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 4/9] README: simple change 4

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 812febb..cf98e7c 100644
--- a/README
+++ b/README
@@ -8,6 +8,7 @@
 Test
 Test 2
 Test 3
+Test 4
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 7/9] README: simple change 6

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 2305a77..1f56fdc 100644
--- a/README
+++ b/README
@@ -10,6 +10,7 @@ Test 2
 Test 3
 Test 4
 Test 5
+Test 6
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 9/9] README: simple change 8

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index adfdf1a..921d79d 100644
--- a/README
+++ b/README
@@ -12,6 +12,7 @@ Test 4
 Test 5
 Test 6
 Test 7
+Test 8
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 3/9] README: simple change 3

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 5cb82f7..812febb 100644
--- a/README
+++ b/README
@@ -7,6 +7,7 @@
 
 Test
 Test 2
+Test 3
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 2/9] README: simple change 2

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 50e53a1..5cb82f7 100644
--- a/README
+++ b/README
@@ -6,6 +6,7 @@
 #
 
 Test
+Test 2
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 8/9] README: simple change 7

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
---

 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 1f56fdc..adfdf1a 100644
--- a/README
+++ b/README
@@ -11,6 +11,7 @@ Test 3
 Test 4
 Test 5
 Test 6
+Test 7
 
 Summary:
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 1/9] README: simple change 1

[Heiko Schocher]

do not apply this patch to mainline, simple test for
a tbot demo, please ignore.

Signed-off-by: Heiko Schocher 
do not apply this patch to mainline, simple test for
a tbot demo.

---

 README | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README b/README
index 68d6a49..50e53a1 100644
--- a/README
+++ b/README
@@ -5,6 +5,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+Test
+
 Summary:
 
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [IGNORE PATCH 0/9] tbot demo patches, please ignore

[Heiko Schocher]

do not apply this patches to mainline!

I move the patches to my ToDo list, until a tbot
patchwork user is created.

This is for a simple test to create a tbot demo video, which
will demonstrate:

- Step 1:
  - clone mainline u-boot, compile, install it on
a board, and start a simple uboot help cmd testcase
on it.

- Step 2:
  - get all patchwork patches from a ToDo list
  - check them with scripts/checkpatch.pl
  - apply the patches to u-boot source with "git am"
  - compile, install and call a simple u-boot testcase
for the help command, which gets intentionally
broken with this testpatches

- Step 3:
  start an automated git bisect testcase
  - as the patches break u-boot, start an automated
"git bisect" testcase to find out, which commit
breaks ...

If video is finished, I give feedback here ...


Heiko Schocher (9):
  README: simple change 1
  README: simple change 2
  README: simple change 3
  README: simple change 4
  README: simple change 5
  cmd, help: break the help command
  README: simple change 6
  README: simple change 7
  README: simple change 8

 README | 9 +
 cmd/help.c | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] ARM: zynq(mp): remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines

[Michal Simek]

On 13.10.2016 17:40, Masahiro Yamada wrote:
> ARCH_ZYNQ(MP) selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT
> is not used.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  include/configs/xilinx_zynqmp.h | 1 -
>  include/configs/zynq-common.h   | 1 -
>  2 files changed, 2 deletions(-)
> 
> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
> index adc42cf..c8e1ffa 100644
> --- a/include/configs/xilinx_zynqmp.h
> +++ b/include/configs/xilinx_zynqmp.h
> @@ -110,7 +110,6 @@
>  #define CONFIG_SYS_LOAD_ADDR 0x800
>  
>  #if defined(CONFIG_ZYNQMP_USB)
> -#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
>  #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS  2
>  #define CONFIG_USB_XHCI_ZYNQMP
>  
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index 0118fd2..7cca83f 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -86,7 +86,6 @@
>  
>  #ifdef CONFIG_USB_EHCI_ZYNQ
>  # define CONFIG_EHCI_IS_TDI
> -# define CONFIG_USB_MAX_CONTROLLER_COUNT 2
>  
>  # define CONFIG_SYS_DFU_DATA_BUF_SIZE0x60
>  # define DFU_DEFAULT_POLL_TIMEOUT300
> 

Acked-by: Michal Simek 

Thanks,
Michal

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v6, 07/10] smbios: Generate type 4 on non-x86 systems

[Alexander Graf]

On 10/14/2016 07:21 AM, Bin Meng wrote:

On Fri, Oct 14, 2016 at 1:13 PM, Alexander Graf  wrote:



Am 14.10.2016 um 03:50 schrieb Bin Meng :

On Thu, Oct 13, 2016 at 10:35 PM, Alexander Graf  wrote:

The type 4 table generation code is very x86 centric today. Refactor things
out into the device model cpu class to allow the tables to get generated for
other architectures as well.

Signed-off-by: Alexander Graf 
Reviewed-by: Simon Glass 
Reviewed-by: Bin Meng 

Thanks, applied to

Applied to where?

Sorry, my efi-next tree.


At which repo? I don't see it at git.denx.de. I thought it was going
to be applied by Tom directly.


We're moving to a model where I apply efi patches, the custodian tree 
just isn't set up yet, so I pushed it to:


  https://github.com/agraf/u-boot/tree/efi-next

instead, but wanted to notify people that there is indeed progress on 
their patches.



Alex

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

[Yao Yuan]

On 10/12/2016 08:00 PM, York Sun wrote:
> On 10/11/2016 08:00 PM, Yao Yuan wrote:
> >>
> >> Yuan Yao,
> >>
> >> I think the procedure can be applied to many of our boards with QSPI,
> >> right? It may be better to move this information out of ls2080aqds.
> >>
> >
> > Hi York,
> >
> > Yes, but a little difference for "CCSR  write" for different boards.
> > But the "CCSR write" should be wrote into uboot code or cw.
> > So, should I remove the notes for "CCSR  write" and then move this
> > information for  all the boards which support QSPI boot?
> >
> 
> I think you can put the common practice together with specific examples for
> LS2080A, and other SoCs.
> 

Hi York,

If move this information out of ls2080aqds.
Do you think where can I put the procedure for all the boards?
In every board's README or somewhere for the common procedure?

Thanks.

Yao.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] powerpc: mpc512x: Add support for get_svr() for mpc512x devices

[Sriram Dash]

Defines get_svr() for mpc512x devices

Signed-off-by: Sriram Dash 
Reviewed-by: Bin Meng 
---
Changes in v2:
  - cosmetic changes

 arch/powerpc/cpu/mpc512x/start.S | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/cpu/mpc512x/start.S b/arch/powerpc/cpu/mpc512x/start.S
index 471d401..dd3066e 100644
--- a/arch/powerpc/cpu/mpc512x/start.S
+++ b/arch/powerpc/cpu/mpc512x/start.S
@@ -443,6 +443,11 @@ get_pvr:
mfspr   r3, PVR
blr
 
+   .globl get_svr
+get_svr:
+   mfspr   r3, SVR
+   blr
+
 /*---*/
 
 /*
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc: mpc512x: Add support for get_svr() for mpc512x devices

[Bin Meng]

On Fri, Oct 14, 2016 at 1:49 PM, Sriram Dash  wrote:
> Defines get_svr() for mpc512x devices
>
> Signed-off-by: Sriram Dash 
> ---
>  arch/powerpc/cpu/mpc512x/start.S | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/cpu/mpc512x/start.S 
> b/arch/powerpc/cpu/mpc512x/start.S
> index 471d401..2507842 100644
> --- a/arch/powerpc/cpu/mpc512x/start.S
> +++ b/arch/powerpc/cpu/mpc512x/start.S
> @@ -443,6 +443,11 @@ get_pvr:
> mfspr   r3, PVR
> blr
>
> +   .globl get_svr
> +get_svr:
> +   mfspr   r3,SVR

nits: need a space after ,

> +   blr
> +

Other than that,
Reviewed-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc: mpc512x: Add support for get_svr() for mpc512x devices

[Sriram Dash]

Defines get_svr() for mpc512x devices

Signed-off-by: Sriram Dash 
---
 arch/powerpc/cpu/mpc512x/start.S | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/powerpc/cpu/mpc512x/start.S b/arch/powerpc/cpu/mpc512x/start.S
index 471d401..2507842 100644
--- a/arch/powerpc/cpu/mpc512x/start.S
+++ b/arch/powerpc/cpu/mpc512x/start.S
@@ -443,6 +443,11 @@ get_pvr:
mfspr   r3, PVR
blr
 
+   .globl get_svr
+get_svr:
+   mfspr   r3,SVR
+   blr
+
 /*---*/
 
 /*
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot