On Fri, Nov 28, 2014 at 06:56:32PM -0500, Bill Pringlemeir wrote:
> On 28 Nov 2014, bpringlem...@nbsps.com wrote:
>
> >
> > I tried to update the new u-boot I get,
> >
> > Bytes transferred = 3413041 (341431 hex)
> > Kernel image @ 0x8600 [ 0x00 - 0x33e150 ]
> > Could not find a valid devi
On 28 Nov 2014, bpringlem...@nbsps.com wrote:
>
> I tried to update the new u-boot I get,
>
> Bytes transferred = 3413041 (341431 hex)
> Kernel image @ 0x8600 [ 0x00 - 0x33e150 ]
> Could not find a valid device tree
[snip]
> Is the imx just using newer patches to be merged to the main tr
I tried to update the new u-boot I get,
Bytes transferred = 3413041 (341431 hex)
Kernel image @ 0x8600 [ 0x00 - 0x33e150 ]
Could not find a valid device tree
The 'bootcmd' is,
tftp ${loadaddr} zImage.dtb; bootz ${loadaddr}
has the syntax changed and I am not up to date? I think
On Fri, Nov 28, 2014 at 11:59:49PM +0100, Gilles Chanteperdrix wrote:
> Hi,
>
> I get the error in the subject when trying and downloading u-boot on
> the ftp:
>
> ftp://ftp.denx.de/pub/u-boot/u-boot-2014.10.tar.bz2
>
> Regards.
If you need to search in the logs, my IP address is:
78.194.115.96
Hi,
I get the error in the subject when trying and downloading u-boot on
the ftp:
ftp://ftp.denx.de/pub/u-boot/u-boot-2014.10.tar.bz2
Regards.
--
Gilles.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://
Hi all,
On 11-11-14 22:57, Tom Rini wrote:
On Mon, Nov 10, 2014 at 03:13:44PM -0700, Simon Glass wrote:
+Albert
Hi Tom,
On 16 September 2014 18:47, Tom Rini wrote:
On Tue, Sep 16, 2014 at 08:27:23PM -0400, Tom Rini wrote:
At the high level, the problem is that we set gd multiple times (an
On 28/11/2014 17:59, Guillaume Gardet wrote:
>
> Le 20/11/2014 08:47, hui@freescale.com a écrit :
>>> -Original Message-
>>> From: Guillaume GARDET [mailto:guillaume.gar...@free.fr]
>>> Sent: Thursday, November 20, 2014 3:39 PM
>>> To: u-boot@lists.denx.de
>>> Cc: Guillaume GARDET; Ste
Le 20/11/2014 08:47, hui@freescale.com a écrit :
-Original Message-
From: Guillaume GARDET [mailto:guillaume.gar...@free.fr]
Sent: Thursday, November 20, 2014 3:39 PM
To: u-boot@lists.denx.de
Cc: Guillaume GARDET; Stefano Babic; Liu Hui-R64343
Subject: [U-Boot] [PATCH] imx: mx53loco:
2014-11-28 22:23 GMT+09:00 Hans de Goede :
> After commit 933cdbb479: "fdt: Try to use
> fdt_address_cells()/fdt_size_cells()"
> I noticed that allwinner boards would no longer boot.
>
> Switching to fdt_address_cells / fdt_size_cells changes the result from
> bytes to 32 bit words, so when we inc
Hi Pantelis,
>
> $ git rebase -i
>
> $
> $ git add
> $ git rebase -continue
>
> You can take a look at something like this:
>
> https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase
>
Thanks for the instructions, I managed to clear up this confusion. I begin to
grasp why git
On Fri, 2014-11-28 at 14:46 +0100, Lukasz Majewski wrote:
> Hello Javier,
>
> > Hello Lukasz,
> >
> > On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> > wrote:
> I'd like to propose a following plan:
>
> 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with link to
> default BL2) t
Hi Diego,
> On Nov 28, 2014, at 16:27 , Diego Santa Cruz
> wrote:
>
> Hi Pantelis,
>
>> I think the source of the confusion is that you've introduced user_enh_start,
>> user_enh_size in one patch and then modify them
>> again in another. That causes diff changes to show up due to the introduct
Hi Pantelis,
> I think the source of the confusion is that you've introduced user_enh_start,
> user_enh_size in one patch and then modify them
> again in another. That causes diff changes to show up due to the introduction
> of the structure. How about declaring the structure
> in the first patch
Hi Diego,
> On Nov 28, 2014, at 12:57 , Diego Santa Cruz
> wrote:
>
> Hi Pantelis,
>
>> Hi Diego,
>>
>> At first glance it's OK, I'm not the turning of user_enh_start, _size to a
>> structure
>> has a lot of benefits. It makes the diff longer.
>>
>
> I did that so that all the user data are
Hello Javier,
> Hello Lukasz,
>
> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> wrote:
> >> I have yet to take him up on that offer though, but it sounds like
> >> a good way forward. The current layout really isn't practical.
> >>
> >
> > It indeed isn't very practical, but this is what yo
On Fri, 2014-11-28 at 13:47 +0100, Lukasz Majewski wrote:
> Hi Sjoerd,
>
> > On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> > > Hi Sjoerd,
> > >
> > > > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > > > Sjoerd Simons wrot
After commit 933cdbb479: "fdt: Try to use fdt_address_cells()/fdt_size_cells()"
I noticed that allwinner boards would no longer boot.
Switching to fdt_address_cells / fdt_size_cells changes the result from
bytes to 32 bit words, so when we increment pointers into the blob, we must
do so by 32 bit
Hi Sjoerd,
> On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> > Hi Sjoerd,
> >
> > > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > > Sjoerd Simons wrote:
> > >
> > > > > signed_bl1_position=1
> > > > > bl2_position=31
> > >
Hi,
On 11/24/2014 05:33 PM, Minkyu Kang wrote:
> Hi,
>
> On 20/11/14 17:17, Jaehoon Chung wrote:
>> The most exynos used the "Ratio + 1" as div value.
>> And value at register is "Ratio".
>> So if want to set exact value, it needs to subtract one.
>>
>> Value at register ("Ratio") = div - 1
>>
>
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski wrote:
>> I have yet to take him up on that offer though, but it sounds like a
>> good way forward. The current layout really isn't practical.
>>
>
> It indeed isn't very practical, but this is what you received from
> HardKernel when
To debug more exactly, add the index for device.
Signed-off-by: Jaehoon Chung
---
drivers/mmc/exynos_dw_mmc.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
index d96dfe1..dfa209b 100644
---
Hi,
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
> Sent: Friday, November 28, 2014 11:05 AM
> To: Diego Santa Cruz
> Cc: pa...@antoniou-consulting.com; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and relat
Hi Pantelis,
> Hi Diego,
>
> At first glance it's OK, I'm not the turning of user_enh_start, _size to a
> structure
> has a lot of benefits. It makes the diff longer.
>
I did that so that all the user data area members can be easily reset to zero
when parsing the mmc hwpartition sub-command arg
Hi Pantelis,
[resending as message was rejected due to base64 content]
>
> Hi Diego,
>
> This is quite a large patchset, so we'll have to take a close look.
Feedback is appreciated. The number of patches is relatively large, but I have
tried to break them in small chunks so that they are easi
On 2014-11-28 11:05, Marc Zyngier wrote:
> On 28/11/14 08:52, Jan Kiszka wrote:
>> On 2014-11-10 14:36, Marc Zyngier wrote:
>>> On 10/11/14 13:25, Jan Kiszka wrote:
On 2014-11-10 14:08, Marc Zyngier wrote:
> On 10/11/14 12:51, Jan Kiszka wrote:
>> Hi Marc,
>>
>> what is the mot
On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> Hi Sjoerd,
>
> > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > Sjoerd Simons wrote:
> >
> > > > signed_bl1_position=1
> > > > bl2_position=31
> > > > uboot_position=63
> > > > tz
> On Nov 28, 2014, at 11:10 , Diego Santa Cruz
> wrote:
>
> The mmc_startup() function uses the ext_csd data even if reading it
> from the mmc device failed. This bug was introduced in commit
> bc897b1d4d86597311430dbe7b3e6c807c8c53e5. We now bail out if
> reading it fails, this should not be a
Hi Diego,
At first glance it’s OK, I’m not the turning of user_enh_start, _size to a
structure
has a lot of benefits. It makes the diff longer.
> On Nov 28, 2014, at 11:10 , Diego Santa Cruz
> wrote:
>
> The eMMC partition write reliability settings are to be set while
> partitioning a device
On 28/11/14 08:52, Jan Kiszka wrote:
> On 2014-11-10 14:36, Marc Zyngier wrote:
>> On 10/11/14 13:25, Jan Kiszka wrote:
>>> On 2014-11-10 14:08, Marc Zyngier wrote:
On 10/11/14 12:51, Jan Kiszka wrote:
> Hi Marc,
>
> what is the motivation to expose a PSCI 0.1 interface in U-boot,
>
> I have the need to hardware partition eMMC devices from U-Boot along
> with setting enhanced and reliable write attributes.
>
> This series of patches adds this support to U-Boot via a new mmc
> API, a few new members of struct mmc and a new mmc sub-command. It
> also features several fixes t
Hi Sjoerd,
> On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > On Thu, 27 Nov 2014 15:33:05 +0100
> > Sjoerd Simons wrote:
>
> > > signed_bl1_position=1
> > > bl2_position=31
> > > uboot_position=63
> > > tzsw_position=719
> > > env_position=1231
> > >
> > > for the various locations
Hi Diego,
This is quite a large patchset, so we’ll have to take a close look.
> On Nov 28, 2014, at 11:10 , Diego Santa Cruz
> wrote:
>
> I have the need to hardware partition eMMC devices from U-Boot along
> with setting enhanced and reliable write attributes.
>
> This series of patches add
The eMMC partition write reliability settings are to be set while
partitioning a device, as per the eMMC spec, so changes to these
attributes needs to be done in the hardware partitioning API.
This commit adds such support.
---
common/cmd_mmc.c | 21 +++--
drivers/mmc/mmc.c |
This change extends the mmc hwpartition sub-command to change the
per-partition write reliability settings. It also changes the
syntax used for the enhanced user data area slightly to better
accomodate the write reliability option.
---
common/cmd_mmc.c | 116 ++
This extends the mmcinfo command's output to show which eMMC partitions
have the enhanced attribute set. Note that the eMMC spec says that
if the enhanced attribute is supported then the boot and RPMB
partitions are of the enhanced type.
The output of mmcinfo becomes:
Device: OMAP SD/MMC
Manufactu
The eMMC spec says that partitioning is only effective after the
PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done,
but that we cannot know). Thus the partition sizes and attributes should
be ignored when that bit is not set, otherwise the various capacities
are not coherent
This extends the mmcinfo hardware partition info output to show
partitions with write reliability enabled with the "WRREL" string.
If the partition does not have write reliability enabled the "WRREL"
string is omitted; this is analogous to the ehhanced attribute.
Example output:
Device: OMAP SD/M
Read the eMMC high capacity write protect group size at mmc device
initialization. This is useful to correctly partition an eMMC device,
as partitions need to be aligned to this size.
---
drivers/mmc/mmc.c |6 ++
include/mmc.h |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
This adds the erase group size and high-capacity WP group size to
mmcinfo's output. The erase group size is necessary to properly align
erase requests on eMMC. The high-capacity WP group size is necessary
to properly align partitions on eMMC.
---
common/cmd_mmc.c | 10 ++
1 files changed
Adds the mmc hwpartition sub-command to perform eMMC hardware
partitioning on an mmc device. The number of arguments can be
large for a complex partitioning, but as the partitioning has
to be done in one go it is difficult to make it simpler.
---
common/cmd_mmc.c | 92 +++
eMMC partitions are defined as of eMMC 4.41, but mmcinfo process
partition info for eMMC >= 4.0, change it to do it for >= 4.41
---
common/cmd_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 414fac6..bc02273 100644
--- a/com
---
drivers/mmc/mmc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c045f9e..b088fd7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1023,6 +1023,7 @@ static int mmc_startup(struct mmc *mmc)
m
This modification reads the size of the eMMC enhanced user data area
upon initialization of an mmc device, it will be used later by
mmcinfo.
---
drivers/mmc/mmc.c | 15 +++
include/mmc.h |4
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mmc.
This adds output to show the eMMC enhanced user data area size and offset
along with the partition sizes in mmcinfo's output.
---
common/cmd_mmc.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index bc02273..aa5ba0e 100644
--
The erase_grp_size in struct mmc is to be a size in 512-byte sectors
but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is
enabled computed it as bytes, leading to erase sizes and alignment
much larger than what is actually required by the mmc device.
---
drivers/mmc/mmc.c |
This adds an API to do hardware partitioning on eMMC devices. The
new mmc_hwpart_config() function does the partitioning in one go.
As the different attributes and partitioning options on eMMC may
be interdependent validation has to be done based on the complete
partitioning configuration. The func
The eMMC spec numbers general purpose partitions starting at 1, but
the mmcinfo output follows the internal numbering which starts at 0.
Make the mmcinfo command output number partitions as in the eMMC
spec to avoid confusion.
---
common/cmd_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 del
The mmc_startup() function uses the ext_csd data even if reading it
from the mmc device failed. This bug was introduced in commit
bc897b1d4d86597311430dbe7b3e6c807c8c53e5. We now bail out if
reading it fails, this should not be a problem as ext_csd was
introduced in MMC 4.0 and this code is conditi
There is currently no command that will provide an overview of the hardware
partitions present on an eMMC device, one has to switch to every partition
via "mmc dev" and run mmcinfo for each to get the partition's capacity.
This commit adds a few lines of output to mmcinfo with the sizes of the
pres
I have the need to hardware partition eMMC devices from U-Boot along
with setting enhanced and reliable write attributes.
This series of patches adds this support to U-Boot via a new mmc
API, a few new members of struct mmc and a new mmc sub-command. It
also features several fixes to the eMMC hard
The eMMC spec mandates that the high-capacity group size definitions
should be enabled when the device is partitioned (by setting
ERASE_GROUP_DEF in EXT_CSD). The current test to determine when this is
required misses a few cases. In particular a device may have been
partitioned without setting the
On 2014-11-10 14:36, Marc Zyngier wrote:
> On 10/11/14 13:25, Jan Kiszka wrote:
>> On 2014-11-10 14:08, Marc Zyngier wrote:
>>> On 10/11/14 12:51, Jan Kiszka wrote:
Hi Marc,
what is the motivation to expose a PSCI 0.1 interface in U-boot, instead
of 0.2? Support for preexisting
On 11/28/2014 11:13 AM, Hyungwon Hwang wrote:
> On Thu, 27 Nov 2014 22:45:18 +0100
> Sjoerd Simons wrote:
>
>> On Thu, 2014-11-27 at 22:21 +0900, Hyungwon Hwang wrote:
>>> This patch adds support for Odroid-XU3.
>>
>> I can't seem to access the EMMC with this patch, is that expected?
>>
>
> Yes.
On Fri, 2014-11-28 at 11:13 +0900, Hyungwon Hwang wrote:
> On Thu, 27 Nov 2014 22:45:18 +0100
> Sjoerd Simons wrote:
>
> > On Thu, 2014-11-27 at 22:21 +0900, Hyungwon Hwang wrote:
> > > This patch adds support for Odroid-XU3.
> >
> > I can't seem to access the EMMC with this patch, is that expec
On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> On Thu, 27 Nov 2014 15:33:05 +0100
> Sjoerd Simons wrote:
> > signed_bl1_position=1
> > bl2_position=31
> > uboot_position=63
> > tzsw_position=719
> > env_position=1231
> >
> > for the various locations.. Which also explains the limit 3
55 matches
Mail list logo
