Hi Simon,
On 12/23/14 21:04, Simon Glass wrote:
> We need to get rid of this SPL-specific setting of the global_data pointer.
> It is already set up in start.S immediately before board_init_f() is called,
> and there may be information there that is needed (e.g. pre-reloc malloc
> info).
>
> Sign
On 12/23/14 21:04, Simon Glass wrote:
> The global_data pointer (gd) has already been set before board_init_f()
> is called. We should not assign it again. We should also not use gdata since
> it is going away.
>
> Signed-off-by: Simon Glass
Acked-by: Igor Grinberg
> ---
>
> board/compulab/c
Right now all dts files under arch/x86/dts are compiled. This is
not necessary so update the Makefile to only compile dts file for
a specific board.
Signed-off-by: Bin Meng
---
arch/x86/dts/Makefile | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/dts/Makefile
This commits cleans up the board dts files.
- Correct the serial port register size to 8
- Remove the misleading status = "disabled" statement in the
serial.dtsi
- Move the inclusion of skeleton.dtsi from serial.dtsi to board
dts files
- Let the board dts file define stdout-path in the chosen
The name of coreboot.dtsi is misleading, as it actually describes
the legacy serial port device node.
Signed-off-by: Bin Meng
---
arch/x86/dts/crownbay.dts | 2 +-
arch/x86/dts/link.dts | 2 +-
arch/x86/dts/{coreboot.dtsi => serial.dtsi} | 0
3 files chan
No board is using alex.dts, so remove it.
Signed-off-by: Bin Meng
---
arch/x86/dts/Makefile | 1 -
arch/x86/dts/alex.dts | 24
2 files changed, 25 deletions(-)
delete mode 100644 arch/x86/dts/alex.dts
diff --git a/arch/x86/dts/Makefile b/arch/x86/dts/Makefile
index 3
The include directory in arch/x86/dts is not used, so remove it.
Signed-off-by: Bin Meng
---
arch/x86/dts/include/dt-bindings | 1 -
1 file changed, 1 deletion(-)
delete mode 12 arch/x86/dts/include/dt-bindings
diff --git a/arch/x86/dts/include/dt-bindings b/arch/x86/dts/include/dt-bindin
Add a board rev entry for the new model A+, and augment the board
rev error handling code to be a bit more verbose.
Signed-off-by: Stephen Warren
---
This series depends on "ARM: rpi: only set usbethaddr on relevant
systems" for context.
arch/arm/include/asm/arch-bcm2835/mbox.h | 1 +
board/ra
Create a fake model table entry with default values, so we can error
check the board rev value once when querying it from the firmware, rather
than error-checking for invalid board rev values every time the model
table is used.
Signed-off-by: Stephen Warren
---
board/raspberrypi/rpi/rpi.c | 16 +
On 22/12/14 19:46, Joonyoung Shim wrote:
> MMC of exynos5420 can select SPLL as source clock, so add to support
> SPLL in exynos5420_get_mmc_clk(). It was tested on Odroid-XU3 board.
>
> Signed-off-by: Joonyoung Shim
> ---
> arch/arm/cpu/armv7/exynos/clock.c | 2 ++
> 1 file changed, 2 insertion
Hi Simon,
On Wed, Dec 24, 2014 at 3:42 AM, Simon Glass wrote:
> Hi Bin,
>
> On 23 December 2014 at 01:01, Bin Meng wrote:
>>
>> Each time U-Boot boots on Intel Crown Bay board, the displayed hard
>> drive information is wrong. It could be either wrong capacity or just
>> a 'Capacity: not availab
The few Versatile Express ARMv8 platforms we have may just as
well be switched to generic board from the beginning.
Tested on the ARM foundation model and the in progress support
for the ARMv8 Juno board.
Signed-off-by: Linus Walleij
---
include/configs/vexpress_aemv8a.h | 5 +++--
1 file chang
The Versatile Express ARMv8 semihosted FVP platform is still
using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure
some compile-time flags. Get rid of this and create a Kconfig
entry for the FVP model, and a selectable bool for the
semihosting library.
The FVP subboard is now modeled as a
The Juno Development Platform is a physical Versatile Express
device with some differences from the emulated semihosting
models. The main difference is that the system is split in
a SoC and an FPGA where the SoC hosts the serial ports at
totally different adresses.
Signed-off-by: Linus Walleij
--
As agreed with Steve Rae I'm taking over maintenance of the
semihosted, emulated FVP/foundation model Versatile Express
64 bit board variant.
Signed-off-by: Linus Walleij
---
board/armltd/vexpress64/MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/armltd/vexp
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Currently the hash functions used in RSA are called directly from the sha1
> and sha256 libraries. Change the RSA checksum library to use the progressive
> hash API's registered with struct hash_algo. This will allow the checksum
>
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> The hash_algo structure has some implementations in which progressive hash
> API's are not defined. These are basically the hardware based implementations
> of SHA. An API is added to find the algo which has progressive hash API's
>
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Modify rsa_verify to use the rsa driver of DM library available.The tools
> and the configurations which don't use Driver Model, will continue to use
> the same RSA sw library. The software implementation of RSA Modular
> Exponentat
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Driver added for RSA Modular Exponentiation using Freescale Hardware
> Accelerator CAAM. The driver used uclass rsa.
>
> Signed-off-by: Ruchika Gupta
> CC: Simon Glass
> ---
> Changes in v3:
> Moved to integrate with RSA UCLASS
Acked-by: Simo
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Kconfig option added for devices which support RSA Verification
> (Modular Exponentiation) operation in hardware
>
> Signed-off-by: Ruchika Gupta
> CC: Simon Glass
> ---
> Changes in v3:
> New patch
>
> lib/rsa/Kconfig | 23 +
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> For the platforms which use,CONFIG_FIT_SIGNATURE, the required configs are
> moved to the platform's defconfig file. Selecting CONFIG_FIT_SIGNATURE using
> defconfig automatically resolves the dependencies for signature verification.
> The RSA l
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Add a new rsa uclass for performing modular exponentiation and implement
> the software driver basing on this uclass.
>
> Signed-off-by: Ruchika Gupta
> CC: Simon Glass
> ---
> Changes in v3:
> New patch with driver model for RSA
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> For FIT signature based approach to work, RSA library needs to be selected.
> The FIT_SIGNATURE option in Kconfig is modified to automatically select RSA.
> Selecting RSA compiles the RSA library required for image verification.
>
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta wrote:
> Public exponentiation which is required in rsa verify functionality is
> tightly integrated with verification code in rsa_verify.c. The patch
> splits the file into twp separating the modular exponentiation.
>
> 1. rsa-verify.c
> -
I am working on a MPC8247-based device that is not booting. I can see
that the CPU is properly powered and gets out of reset, but that the
software watchdog is timing out every ~1.3 sec and sending the device
back into reset again.
The board has a 1Mbit flash EEPROM used for booting, and a larger
Hi Stephen,
On 23 December 2014 at 13:34, Stephen Warren wrote:
> On 12/23/2014 01:05 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 23 December 2014 at 10:34, Stephen Warren
>> wrote:
>>>
>>> From: Stephen Warren
>>>
>>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>>
On 12/23/2014 01:05 PM, Simon Glass wrote:
Hi Stephen,
On 23 December 2014 at 10:34, Stephen Warren wrote:
From: Stephen Warren
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of
Hi Stephen,
On 23 December 2014 at 13:22, Stephen Warren wrote:
> On 12/23/2014 01:01 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 23 December 2014 at 10:34, Stephen Warren
>> wrote:
>>>
>>> From: Stephen Warren
>>>
>>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>>
On 12/23/2014 01:01 PM, Simon Glass wrote:
Hi Stephen,
On 23 December 2014 at 10:34, Stephen Warren wrote:
From: Stephen Warren
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of
On 22 December 2014 at 23:41, Dirk Behme wrote:
> Signed-off-by: Dirk Behme
> ---
> tools/buildman/README | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Thanks for the patch.
Acked-by: Simon Glass
___
U-Boot mailing list
U-Bo
Hi Stephen,
On 23 December 2014 at 10:34, Stephen Warren wrote:
> From: Stephen Warren
>
> Some systems have so much RAM that the end of RAM is beyond 4GB. An
> example would be a Tegra124 system (where RAM starts at 2GB physical)
> that has more than 2GB of RAM.
>
> In this case, we want gd->ra
On 23 December 2014 at 10:34, Stephen Warren wrote:
> From: Stephen Warren
>
> size_mb is used to hold a value that's sometimes KB, sometimes MB,
> and sometimes bytes. Use separate correctly named variables to avoid
> confusion here. Also fix indentation of a conditional statement.
>
> Signed-of
Hi Stephen,
On 23 December 2014 at 10:34, Stephen Warren wrote:
> From: Stephen Warren
>
> Some systems have so much RAM that the end of RAM is beyond 4GB. An
> example would be a Tegra124 system (where RAM starts at 2GB physical)
> that has more than 2GB of RAM.
>
> In this case, we can gd->ram
Hi Masahiro,
On 22 December 2014 at 03:58, Masahiro Yamada wrote:
> This commit adds on-chip I2C driver used on newer SoCs of Panasonic
> UniPhier platform.
>
> Signed-off-by: Masahiro Yamada
For driver model bits:
Reviewed-by: Simon Glass
A few comments below.
> ---
>
> drivers/i2c/Kconfi
Hi Masahiro,
On 22 December 2014 at 03:58, Masahiro Yamada wrote:
> This commit adds on-chip I2C driver used on some old Panasonic
> UniPhier SoCs.
>
> Signed-off-by: Masahiro Yamada
>From a driver model perspective:
Reviewed-by: Simon Glass
A few comments below.
> ---
>
> drivers/i2c/Kcon
Hi Bin,
On 23 December 2014 at 01:01, Bin Meng wrote:
>
> Each time U-Boot boots on Intel Crown Bay board, the displayed hard
> drive information is wrong. It could be either wrong capacity or just
> a 'Capacity: not available' message. After enabling the debug switch,
> we can see the scsi inqui
Some ARM boards use global_data in SPL before it set up by crt0.S. To
achieve this they use a separate global_data variable called gdata which
resides in the data section. The one set up by crt0.S is generally ignored.
This prevents crt0.S from setting up things like the early malloc() pool.
It th
In SPL as in U-Boot proper, global_data should only be set up in one place
which is crt0.S. We should not use on global_data before board_init_f().
The pointer does not exist.
In fact there is no need for this anyway and it just contorts the early init
code for SPL. Drop it.
Signed-off-by: Simon
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass
---
board/compulab/cm_fx6/spl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/board/compulab/cm_
The current sunxi implementation uses gdata, which is going away. It also
sets up DRAM before board_init_f() in SPL.
There is really no reason to do much in s_init() since board_init_f() is
called immediately afterwards. The only change is that we need our own
implementation of board_init_f() whic
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass
---
board/woodburn/woodburn.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/woodburn/wo
This function has grown into something of a monster. Some boards are setting
up a console and DRAM here in SPL. This requires global_data which should be
set up in one place (crt0.S).
There is no need for SPL to use s_init() for anything since board_init_f()
is called immediately afterwards.
Sign
This does nothing now, so drop it. We have SPL anyway to do our low-level
init.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/sunxi/board.c | 5 -
include/configs/sunxi-common.h | 1 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arc
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass
---
arch/arm/cpu/armv7/zynq/spl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/cpu/
The global_data pointer (gd) has already been set before board_init_f()
is called. We should not assign it again. We should also not use gdata since
it is going away.
Signed-off-by: Simon Glass
---
board/freescale/ls1021aqds/ls1021aqds.c | 3 ---
board/freescale/ls1021atwr/ls1021atwr.c | 3 ---
We need to get rid of this SPL-specific setting of the global_data pointer.
It is already set up in start.S immediately before board_init_f() is called,
and there may be information there that is needed (e.g. pre-reloc malloc
info).
Signed-off-by: Simon Glass
---
arch/arm/lib/spl.c | 7 ++-
From: Stephen Warren
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.
In this case, we can gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed
From: Stephen Warren
Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.
In this case, we want gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed
From: Stephen Warren
size_mb is used to hold a value that's sometimes KB, sometimes MB,
and sometimes bytes. Use separate correctly named variables to avoid
confusion here. Also fix indentation of a conditional statement.
Signed-off-by: Stephen Warren
---
arch/arm/cpu/tegra-common/board.c | 17
On 23.11.2014 23:20, Simon Glass wrote:
Hi,
On 21 November 2014 at 16:36, York Sun wrote:
Simon,
Shall we consider host error to be an error reported by buildman? I happen to
try a newer version of toolchain from Linaro. Buildman reports this error
+../scripts/binutils-version.sh: line 20:
Hi Matthew,
On 17.12.2014 01:07, Matthew Fortune wrote:
> Hi Daniel,
>
> I'm looking for a bit of feedback on my query below. Unless there is a
> major problem I'll start to organise an implementation for review.
>
> Thanks,
> Matthew
>
>> -Original Message-
>> From: Matthew Fortune
>>
Hi Simon,
On Tue, Dec 23, 2014 at 8:52 AM, Simon Glass wrote:
> HI Bin,
>
> On 19 December 2014 at 22:36, Bin Meng wrote:
>>
>> Hi Simon,
>>
>> On Sat, Dec 20, 2014 at 1:00 PM, Simon Glass wrote:
>> > Hi Bin,
>> >
>> > On 19 December 2014 at 19:43, Bin Meng wrote:
>> >> Hi Simon,
>> >>
>> >> O
This is not used anymore since the procedure was split into a simple
read function and a later alaysis.
The ivm_read_eeprom name is now used for the previous
ivm_simple_read_eeprom function.
Signed-off-by: Valentin Longchamp
---
board/keymile/common/common.h | 3 +--
board/keymile/common/i
This allows to define the ethaddr env variable according to the the IVM
content by reading the IVM in misc_init_r.
Later, when HUSH is available the content read earlier is analyzed to
populate some non env variables.
Signed-off-by: Valentin Longchamp
---
board/keymile/km82xx/km82xx.c | 10 +++
This allows to define the ethaddr env variable according to the the IVM
content by reading the IVM in misc_init_r.
Later, when HUSH is available the content read earlier is analyzed to
populate some non env variables.
Signed-off-by: Valentin Longchamp
---
board/keymile/km_arm/km_arm.c | 6
This allows to define the ethaddr env variable according to the the IVM
content by reading the IVM in misc_init_r.
Later, when HUSH is available the content read earlier is analyzed to
populate some non env variables.
Signed-off-by: Valentin Longchamp
---
board/keymile/km83xx/km83xx.c | 5
All Keymile boards have an EEPROM that is called IVM that contain
information about the board that is progammed at production time.
One piece of information is the MAC addresses assigned to the board.
u-boot requires the MAC address of the ethernet interfaces it uses to be
defined when the interfa
This allows to define the ethaddr env variable according to the the IVM
content by reading the IVM in misc_init_r.
Later, when HUSH is available the content read earlier is analyzed to
populate some non env variables.
Signed-off-by: Valentin Longchamp
---
board/keymile/kmp204x/kmp204x.c | 5 ++
Hi Prafulla,
Is it okay also for this patch which is a GuruPlug refresh for same config as
the SheevaPlug one.
Regards,
Gérald
Le 19/12/2014 08:20, Gerald Kerma a écrit :
> Refresh for newer kernel.
> Prepare ENV settings for guruplugs to be OpenWRT ready.
>
> +--+
> | UBOOT
Hi Pantelis,
Is these patches reviewed and upstreamed ?
Regards,
Gérald
Le 17/12/2014 11:18, Pantelis Antoniou a écrit :
> Hi Gerald,
>
> Last pull-req for mmc was last Friday, I intend to issue another this Friday
> too.
>
> Regards
>
> — Pantelis
>
>> On Dec 17, 2014, at 11:22 , drEagle
> -Original Message-
> From: drEagle [mailto:drea...@doukki.net]
> Sent: 23 December 2014 17:14
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; l...@openwrt.org
> Subject: Re: [U-Boot] [PATCH v3 0/6] SHEEVAPLUG :
> REFRESH 201412
>
> Hi Prafulla,
>
> Have you review these patchs ?
>
Kconfig option added for devices which support RSA Verification
(Modular Exponentiation) operation in hardware
Signed-off-by: Ruchika Gupta
CC: Simon Glass
---
Changes in v3:
New patch
lib/rsa/Kconfig | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/l
Hi Prafulla,
Have you review these patchs ?
Have you any comments or suggestions ?
Le 17/12/2014 15:27, drEagle a écrit :
> Le 17/12/2014 15:24, Prafulla Wadaskar a écrit :
>>
>>
>>> -Original Message-
>>> From: Gérald Kerma [mailto:drea...@doukki.net]
>>> Sent: 17 December 2014 19:33
>>>
The hash_algo structure has some implementations in which progressive hash
API's are not defined. These are basically the hardware based implementations
of SHA. An API is added to find the algo which has progressive hash API's
defined. This can then be integrated with RSA checksum library which use
Currently the hash functions used in RSA are called directly from the sha1
and sha256 libraries. Change the RSA checksum library to use the progressive
hash API's registered with struct hash_algo. This will allow the checksum
library to use the hardware accelerated progressive hash API's once avail
Modify rsa_verify to use the rsa driver of DM library available.The tools
and the configurations which don't use Driver Model, will continue to use
the same RSA sw library. The software implementation of RSA Modular
Exponentation is now compiled if RSA_MOD_EXP_SW is selected.
Kconfig options are a
Driver added for RSA Modular Exponentiation using Freescale Hardware
Accelerator CAAM. The driver used uclass rsa.
Signed-off-by: Ruchika Gupta
CC: Simon Glass
---
Changes in v3:
Moved to integrate with RSA UCLASS
drivers/crypto/Kconfig| 2 ++
drivers/crypto/fsl/Kconfig| 6 +
Add a new rsa uclass for performing modular exponentiation and implement
the software driver basing on this uclass.
Signed-off-by: Ruchika Gupta
CC: Simon Glass
---
Changes in v3:
New patch with driver model for RSA UCLASS
drivers/crypto/Kconfig | 1 +
drivers/crypto/Makefile
For FIT signature based approach to work, RSA library needs to be selected. The
FIT_SIGNATURE option in Kconfig is modified to automatically select RSA.
Selecting RSA compiles the RSA library required for image verification.
Signed-off-by: Ruchika Gupta
CC: Simon Glass
---
Changes in v3:
New pa
For the platforms which use,CONFIG_FIT_SIGNATURE, the required configs are
moved to the platform's defconfig file. Selecting CONFIG_FIT_SIGNATURE using
defconfig automatically resolves the dependencies for signature verification.
The RSA library gets automatically selected and user does not have to
The rsa-verify functionality is a two step operation involving:
1. Checksum (hash) Calculation over image regions
2. Public Key Modular exponentiation over signature to generate hash
The following patch set modifies the rsa library to use hw
acceleration if available in platform.
The first two
Public exponentiation which is required in rsa verify functionality is
tightly integrated with verification code in rsa_verify.c. The patch
splits the file into twp separating the modular exponentiation.
1. rsa-verify.c
- The file parses device tree keys node to fill a keyprop structure.
The keypr
On 12/18/2014 03:03 PM, Jagan Teki wrote:
> On 3 November 2014 at 19:31, Valentin Longchamp
> wrote:
>> Some board require spi_flash_free to be called after all the accesses,
>> in order, for instance, to restore the pin multiplexing configuration in
>> the case where the SPI pins are multiplexed.
Hi,
On 23-12-14 05:36, Simon Glass wrote:
Hi Hans,
On 22 December 2014 at 09:45, Hans de Goede wrote:
Hi,
On 21-12-14 19:52, Simon Glass wrote:
Hi,
I ran up a banana PI and noticed that HDMI works in U-Boot. Great!
Scrolling seems very slow though - is the L2 cache disabled perhaps?
I
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.
Signed-off-by: Diego Santa Cruz
---
common/cmd_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.
Signed-off-by: Diego Santa Cruz
---
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.
Signed-off-by: Diego Santa Cruz
---
drivers/mmc/mmc.c | 39 +
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
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.
Signed-off-by: Diego Santa
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.
Signed-off-by: Diego Santa Cruz
---
common/cmd_mmc.c | 2 +-
1 file 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
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
Signed-off-by: Diego Santa Cruz
---
common/cmd_mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
index 10315
This adds output to show the eMMC enhanced user data area size and offset
along with the partition sizes in mmcinfo's output.
Signed-off-by: Diego Santa Cruz
---
common/cmd_mmc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
i
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.
Signed-off-by: Diego Santa Cruz
---
drivers/mmc/mmc.c | 6 ++
include/mmc.h | 1 +
2 files changed, 7 in
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 modification reads the size of the eMMC enhanced user data area
upon initialization of an mmc device, it will be used later by
mmcinfo.
Signed-off-by: Diego Santa Cruz
---
drivers/mmc/mmc.c | 15 +++
include/mmc.h | 4
2 files changed, 19 insertions(+)
diff --git a/dr
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.
Signed-off-by: Diego Santa Cruz
---
common/cmd_mmc.c
Signed-off-by: Diego Santa Cruz
---
drivers/mmc/mmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 5e9926c..86c4db9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1026,6 +1026,7 @@ static int mmc_startup(struct mmc *mmc)
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
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
Hi Heiko,
On 23 December 2014 at 12:04, Heiko Schocher wrote:
> Hello Jagan,
>
> Am 22.12.2014 09:58, schrieb Jagan Teki:
>>
>> On 18 December 2014 at 19:21, Jagannadha Sutradharudu Teki
>> wrote:
>>>
>>> This reverts commit 562f8df18da62ae02c4ace1e530451fe82c3312d.
>>>
>>> Never see the issue w
Each time U-Boot boots on Intel Crown Bay board, the displayed hard
drive information is wrong. It could be either wrong capacity or just
a 'Capacity: not available' message. After enabling the debug switch,
we can see the scsi inquiry command did not execute successfully.
However, doing a 'scsi sc
95 matches
Mail list logo
