On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
On Thu, 27 Nov 2014 15:33:05 +0100
Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote:
signed_bl1_position=1
bl2_position=31
uboot_position=63
tzsw_position=719
env_position=1231
for the various locations.. Which also
On Fri, 2014-11-28 at 11:13 +0900, Hyungwon Hwang wrote:
On Thu, 27 Nov 2014 22:45:18 +0100
Sjoerd Simons sjoerd.sim...@collabora.co.uk 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
On 11/28/2014 11:13 AM, Hyungwon Hwang wrote:
On Thu, 27 Nov 2014 22:45:18 +0100
Sjoerd Simons sjoerd.sim...@collabora.co.uk 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
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 users of 0.1? The
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
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
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
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
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
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
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 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
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
---
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
---
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)
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
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
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/MMC
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
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
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
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 |
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 diego.santac...@spinetix.com
wrote:
I have the need to hardware partition eMMC devices from U-Boot along
with setting enhanced and reliable write attributes.
This
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 sjoerd.sim...@collabora.co.uk wrote:
signed_bl1_position=1
bl2_position=31
uboot_position=63
tzsw_position=719
env_position=1231
for the various
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
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, instead
of 0.2? Support
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 diego.santac...@spinetix.com
wrote:
The eMMC partition write reliability settings are to be set
On Nov 28, 2014, at 11:10 , Diego Santa Cruz diego.santac...@spinetix.com
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
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 sjoerd.sim...@collabora.co.uk wrote:
signed_bl1_position=1
bl2_position=31
uboot_position=63
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 motivation to expose a PSCI 0.1
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 easier
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
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 related
To debug more exactly, add the index for device.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
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
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl 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
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
Signed-off-by:
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 sjoerd.sim...@collabora.co.uk wrote:
signed_bl1_position=1
bl2_position=31
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
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
Hello Javier,
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
l.majew...@majess.pl 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
Hi Diego,
On Nov 28, 2014, at 12:57 , Diego Santa Cruz diego.santac...@spinetix.com
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
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 and
Hi Diego,
On Nov 28, 2014, at 16:27 , Diego Santa Cruz diego.santac...@spinetix.com
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
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
l.majew...@majess.pl 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
Hi Pantelis,
$ git rebase -i
pick up the commit you want to edit and change pick to edit
$ make changes
$ git add changed-files
$ 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
2014-11-28 22:23 GMT+09:00 Hans de Goede hdego...@redhat.com:
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
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:
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; Stefano Babic; Liu
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 tr...@ti.com 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
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
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
--
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
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 tree and
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 device tree
55 matches
Mail list logo
