Hi mind,
On Sat, 1 Jun 2013 12:01:44 +0530, mind entropy
wrote:
> Hi,
> I am setting up a nfs boot and I am getting a ***ERROR: Cannot umount.
> How can I fix this?
See ./README in the U-Boot source code.
> Thanks,
> Gautam.
Amicalement,
--
Albert.
_
Hello Piotr,
On 05/31/2013 02:26 PM, Piotr Wilczek wrote:
-bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp)
+bmp_image_t *gunzip_bmp(unsigned long addr, unsigned long *lenp,
+ void **alloc_addr)
{
void *dst;
unsigned long len;
@@ -60,7 +65,
> Hello Lubomir,
>
> Am 01.06.2013 18:44, schrieb Lubomir Popov:
>> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
>> (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
>> OMAPs and derivatives as well. The only anticipated exception would
>> be the OMAP2420, which
Hi Stephen,
On 06/02/2013 01:24 AM, Stephen Warren wrote:
On 05/14/2013 12:02 PM, Stephen Warren wrote:
From: Stephen Warren
This can be useful to force bootcmd to execute as soon as U-Boot has
started.
My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
an image to be wr
On Sun, Jun 02, 2013 at 07:20:50AM +0200, Heiko Schocher wrote:
> Hello Lubomir,
>
> Am 01.06.2013 18:44, schrieb Lubomir Popov:
> > New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
> > (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
> > OMAPs and derivatives as
On 05/14/2013 12:02 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> This can be useful to force bootcmd to execute as soon as U-Boot has
> started.
>
> My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with
> an image to be written to device boot flash, with the DT config p
On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
wrote:
> A SPI slave may take time to react to a request. For SPI flash devices
> this time is defined as one bit time, or a whole byte for 'fast read'
> mode.
>
> If the SPI slave is another CPU, then the time it takes to react may
> vary. It is
Hi,
I know this has been reviewed multiples time, but I have few questions on it.
I think this preamble is one of spi mode characteristic, if so does it
specific to a hw?
On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
wrote:
> Support interfaces with a preamble before each received message
Hi,
On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki wrote:
> On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
> wrote:
> > A SPI slave may take time to react to a request. For SPI flash devices
> > this time is defined as one bit time, or a whole byte for 'fast read'
> > mode.
> >
> > If the SPI
On Sun, Jun 2, 2013 at 11:25 PM, Simon Glass wrote:
> Hi,
>
> On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki
> wrote:
>>
>> On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
>> wrote:
>> > A SPI slave may take time to react to a request. For SPI flash devices
>> > this time is defined as one bit
Hi,
On Sun, Jun 2, 2013 at 10:41 AM, Jagan Teki wrote:
> Hi,
>
> I know this has been reviewed multiples time, but I have few questions on
> it.
>
> I think this preamble is one of spi mode characteristic, if so does it
> specific to a hw?
>
> On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
>
Hi Jagan,
On Sun, Jun 2, 2013 at 11:00 AM, Jagan Teki wrote:
> On Sun, Jun 2, 2013 at 11:25 PM, Simon Glass wrote:
> > Hi,
> >
> > On Sun, Jun 2, 2013 at 10:24 AM, Jagan Teki
> > wrote:
> >>
> >> On Wed, May 29, 2013 at 11:40 AM, Rajeshwari Shinde
> >> wrote:
> >> > A SPI slave may take time t
On Thu, May 30, 2013 at 11:22 AM, Rajeshwari Shinde
wrote:
> Since SPI register access is so expensive, it is worth transferring data
> a word at a time if we can. This complicates the driver unfortunately.
>
> Use the byte-swapping feature to avoid having to convert to/from big
> endian in softwa
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
A SPI slave may take time to react to a request. For SPI flash devices
this time is defined as one bit time, or a whole byte for 'fast read'
mode.
If the SPI slave is another CPU, then the time it takes to react may
vary. It is convenient to allow th
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skippin
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skippin
On 29-05-2013 01:40, Rajeshwari Shinde wrote:
A SPI slave may take time to react to a request. For SPI flash devices
this time is defined as one bit time, or a whole byte for 'fast read'
mode.
If the SPI slave is another CPU, then the time it takes to react may
vary. It is convenient to allow th
On 27-05-2013 15:41, Jagannadha Sutradharudu Teki wrote:
This patch adds a print messages while using 'sf read' and
'sf write' commands to make sure that how many bytes read/written
from/into flash device.
Signed-off-by: Jagannadha Sutradharudu Teki
---
common/cmd_sf.c | 26 +
On 27-05-2013 15:44, Jagannadha Sutradharudu Teki wrote:
Missing return after memcpy is done for memory-mapped SPI flashes,
hence added retun 0 after memcpy done.
The return is missing in below patch
"sf: Enable FDT-based configuration and memory mapping"
(sha1: bb8215f437a7c948eec82a6abe754c226
On 27-05-2013 15:41, Jagannadha Sutradharudu Teki wrote:
This patch adds a print messages while using 'sf erase' command
to make sure that how many bytes erased in flash device.
Signed-off-by: Jagannadha Sutradharudu Teki
---
common/cmd_sf.c |8 +++-
drivers/mtd/spi/spi_fl
Hi,
I think this needs to send as v3, as Simon sent v2 for this.
http://patchwork.ozlabs.org/patch/243139/
--
Thanks,
Jagan.
On Thu, May 30, 2013 at 12:01 PM, Rajeshwari Shinde
wrote:
> This patch implements a custom spi_copy funtion to copy u-boot from SF
> to RAM. This is faster then iROM spi
Hi,
Does this tested on hw, please re-base the tree and send the next version patch.
Let me know if it ok to review under current tree.
--
Thanks,
Jagan.
On Thu, Dec 13, 2012 at 7:31 PM, Armando Visconti
wrote:
> On 12/13/2012 12:41 PM, Vipin KUMAR wrote:
>>
>> From: Armando Visconti
>>
>> This
Hi,
Does this tested on hw, please re-base the tree and send the next version patch.
Let me know if it ok to review under current tree.
--
Thanks,
Jagan.
On Mon, Feb 11, 2013 at 9:09 AM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Sebastian Hesselbarth [mailto:sebastian.
On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
wrote:
> This commit is based on the patch from Xie Xiaobo
> with commit head title as "sf: spansion: Add support for S25FL128S".
> pulled the same code changes into current u-boot tree with little update
> on the name field.
>
> http:
Hi,
On Thu, May 30, 2013 at 7:19 PM, Jagannadha Sutradharudu Teki
wrote:
> Use the exact names for W25Q 0x40XX ID's flash parts, as the same
> sizes of flashes comes with different ID's. so-that the distinguishes
> becomes easy with this change.
>
> Signed-off-by: Jagannadha Sutradharudu Teki
>
Hello Lubomir,
Am 02.06.2013 13:42, schrieb Lubomir Popov:
>> Hello Lubomir,
>>
>> Am 01.06.2013 18:44, schrieb Lubomir Popov:
>>> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
>>> (4430/60/70), OMAP5 (5430) and AM335X (3359); should work on older
>>> OMAPs and derivatives as we
Hello Tom,
Am 02.06.2013 15:08, schrieb Tom Rini:
> On Sun, Jun 02, 2013 at 07:20:50AM +0200, Heiko Schocher wrote:
>> Hello Lubomir,
>>
>> Am 01.06.2013 18:44, schrieb Lubomir Popov:
>>> New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4
>>> (4430/60/70), OMAP5 (5430) and AM335X (33
Hi Tom,
On Friday 31 May 2013 07:52 PM, Tom Rini wrote:
> On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote:
>> On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote:
>>
>>> The save_boot_params function does not store the data in a
>>> always writable area. So the code is broken for
Dear Wolfgang Denk,
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Friday, May 31, 2013 4:23 PM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski;
> Anatolij Gustschin
> Subject: Re: [PATCH] lcd: align bmp header when unco
Hello Nikita,
> -Original Message-
> From: Nikita Kiryanov [mailto:nik...@compulab.co.il]
> Sent: Sunday, June 02, 2013 1:06 PM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [U-Boot] [PATCH] lcd: align bmp header when uncopmressing
> image
>
> Hello Piotr,
>
Hi Albert,
On 05/14/2013 05:44 PM, Albert ARIBAUD wrote:
> Hi Michal,
>
> On Mon, 13 May 2013 09:45:12 +0200, Michal Simek
> wrote:
>
>> On 05/10/2013 09:07 PM, Albert ARIBAUD wrote:
>>> Hi Michal,
>>>
>>> On Thu, 9 May 2013 11:35:33 +0200, Michal Simek
>>> wrote:
>>>
Remove ARM eabi exc
On Friday 31 May 2013 11:48 PM, Tom Rini wrote:
> We need to call the save_omap_boot_params function on am33xx/ti81xx and
> other newer TI SoCs, so move the function to boot-common. Only OMAP4+
> has the omap_hw_init_context function so add ifdefs to not call it on
> am33xx/ti81xx. Call save_omap
32 matches
Mail list logo
