Re: [U-Boot] [PATCH] Revert "warp: Use imx_ddr_size() for calculating the DDR size"

[Fabio Estevam]

Hi Otavio,

On Fri, Aug 12, 2016 at 3:27 PM, Otavio Salvador
 wrote:

> Why is this happening? I am fine in reverting this but we need to fix
> the detection. Is it due memory callibration problems?

The problem here is that warp uses the DDR initialization from mx6sl-evk.

>From configs/mx6slevk_defconfig:
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx6slevk/imximage.cfg,MX6SL"

The usage of imx_ddr_size() revealed that the DDR size is not being
programmed correctly for the warp board.

The proper way to fix this is to create a board/warp/imximage.cfg file
with the DDR configuration done specifically for this board.

Then imx_ddr_size() should work without issues for warp.

Until this is done, better go with the revert patch for now:

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

Re: [U-Boot] Nvidia Trega Tk1 - /cpus/cpu@0 missing clock-frequency property

[Stephen Warren]

On 08/12/2016 03:15 AM, vinoth eswaran wrote:

Hi,

 Currently I am working on an Nvidia Jetson Tk1 board.

With u-boot v2016.05 I am seeing the following messages on the start up

...

I am not sure about what's the issue here. Google search shows
something might be missing in the device tree. Can you let me know
whats the issue here.


The DTB file that's passed to the kernel should be the DTB file built 
along with the kernel binary. If you're already doing that, and there 
are still problems, I suggest discussing this on the Tegra kernel 
mailing list; those messages are all kernel messages and nothing to do 
with U-Boot.


(BTW, the -517 messages aren't actually errors; they're expected 
behaviour when a device attempts to initialize and the dependencies it 
needs are not yet available. The initialization will be retried later 
and should succeed then).

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

Re: [U-Boot] [PATCH 1/2 V4] misc: add "call" uclass op

[Tom Warren]

Please CC me on your pull request to TomR/u-boot/master. Thanks.

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, August 12, 2016 10:04 AM
> To: Stephen Warren 
> Cc: U-Boot Mailing List ; Tom Warren
> ; Stephen Warren ; Tom Rini
> 
> Subject: Re: [PATCH 1/2 V4] misc: add "call" uclass op
> 
> On 8 August 2016 at 13:47, Simon Glass  wrote:
> > +Tom
> >
> > Hi Stephen,
> >
> > On 8 August 2016 at 10:41, Stephen Warren 
> wrote:
> >> On 08/08/2016 10:38 AM, Simon Glass wrote:
> >>>
> >>> Hi Stephen,
> >>>
> >>> On 8 August 2016 at 09:41, Stephen Warren 
> wrote:
> 
> 
>  From: Stephen Warren 
> 
>  The call op requests that the callee pass a message to the
>  underlying HW or device, wait for a response, and then pass back
>  the response error code and message to the callee. It is useful for
>  drivers that represent some kind of messaging or IPC channel to a
>  remote device.
> 
>  Signed-off-by: Stephen Warren 
>  Acked-by: Simon Glass 
>  ---
>  v4: Adjust misc_call() to return the response msg size on success.
>  v3: New patch.
>  ---
>   drivers/misc/misc-uclass.c | 11 +++
>   include/misc.h | 35 +++
>   2 files changed, 46 insertions(+)
> >>>
> >>>
> >>> Are you planning for the Tegra186 stuff to go into the upcoming release?
> >>
> >>
> >> I'd like it to if at all possible; it's all pretty much
> >> Tegra-specific drivers so shouldn't cause any fallout for other
> >> platforms. The only exception is the fdt_translate_address() changes,
> >> which are a dependency, which will be built into other platforms, but
> >> there's a simple Boolean parameter that controls the new behaviour, so it
> should be pretty safe.
> >
> > OK, sounds reasonable to me. I'll pick these up later in the week and
> > send a pull request. Can you bring any other dependencies in via
> > Tegra?
> >
> > Regards,
> > Simon
> 
> Applied to u-boot-dm, thanks!

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] efi_loader: Implement reset on RPi

[Alexander Graf]

On 12.08.16 19:21, Simon Glass wrote:
> Hi Alex,
> 
> On 11 August 2016 at 05:49, Alexander Graf  wrote:
>>
>>
>> On 08.08.16 23:44, Simon Glass wrote:
>>> Hi,
>>>
>>> On 7 August 2016 at 10:59, Andreas Färber  wrote:
 Am 14.07.2016 um 08:18 schrieb Alexander Graf:
>> Am 14.07.2016 um 06:48 schrieb Andreas Färber :
>>
>> Hi Alex,
>>
>>> Am 05.06.2016 um 23:17 schrieb Alexander Graf:
>>> If Linux finds an EFI implementation it always uses the EFI reset 
>>> handler to
>>> reboot or power down the system.
>>
>> Hm, I thought my powerdown issues on the Jetson TK1 were for lack of
>> CONFIG_AS3277_RESET - sounds like it could be due to EFI instead?
>
> It depends. IIRC the TK1 is 32bit, where you're probably using grub2 
> which is not efi Linux aware, but instead boots over the zImage protocol. 
> In that case Linux doesn't know about efi runtime services.

 We've confirmed in the meantime that the Jetson TK1 issues were
 unrelated to EFI and could be worked around by enabling some as3722
 kernel option.

>>> Unfortunately we haven't implemented that one yet. In fact, while we 
>>> prepared
>>> for RTS handling, we never actually implemented a single user.
>>>
>>> This is going to change today. This simple patch set enables RTS reset 
>>> support
>>> for the RPi systems, allowing you to reboot and shut down the rpi if 
>>> booted
>>> via EFI.
>>>
>>> It also lays the groundwork to show how to implement that functionality 
>>> at all,
>>> so I expect more boards to follow.
>>>
>>> Alexander Graf (2):
>>>  efi_loader: Allow boards to implement get_time and reset_system
>>>  ARM: bcm283x: Implement EFI RTS reset_system
>>>
>>> arch/arm/mach-bcm283x/include/mach/wdog.h |   2 +-
>>> arch/arm/mach-bcm283x/reset.c |  59 +++--
>>> cmd/bootefi.c |   4 ++
>>> include/efi_loader.h  |  18 ++
>>> lib/efi_loader/efi_runtime.c  | 101 
>>> ++
>>> 5 files changed, 166 insertions(+), 18 deletions(-)
>>
>> This all looks very non-generic and would mean that every board will
>> need to be patched individually, which is unrealistic to be tested by
>> just the two of us.
>>
>> Can't you patch the reset_cpu() declaration (common.h/sysreset.h)
>> instead of all its implementations? We might still need to patch
>> individual implementations but I don't see why any reset_cpu()
>> implementation should be in a different section than others.
>
> Hmm. There are 2 minor problems:
>
>   1) Efi also supports power off on top of reset
>   2) We would have to convert all boards at once, rather than one by one, 
> as we couldn't distinguish between efi aware and unaware ones

 I don't see why we would need to convert everything at once either way.

>
> And one major issue:
>
> All device memory pointers used by the reset functions need to be marked 
> as such in the efi memory map and live relocated when entering runtime 
> mode. So we need to manually touch every function either way.
>>>
>>> I'm worried about this. It means that any code used from this run-time
>>> needs to be so marked. This could be large tracts of U-Boot. In
>>
>> We only need to mark the few bits that are actually executed and used
>> within RTS. That's usually just 2 or 3 functions.
>>
> 
> At present you only have reset, and you've only implemented it for one
> board. Are there other calls that we need to implement? This
> EFI_RUNTIME is transitive - anything it calls must be in the runtime.
> Does the linker prevent us from screwing up?

It doesn't (I couldn't find a way), but the runtime relocation code does:


https://github.com/trini/u-boot/blob/master/lib/efi_loader/efi_runtime.c#L205

> 
>> Also, moving forward, we'll see more and more systems implement PSCI
>> which means we can implement a generic PSCI RTS for reset/shutdown.
> 
> What system can I get that uses that today?

Anything that runs ATF:

  https://github.com/ARM-software/arm-trusted-firmware

in EL3:

  - Pine64
  - ZynqMP
  - S905X
  - Hikey
  - probably many many more

I think the only AArch64 systems that I'm aware of that do *not* run ATF
in EL3 are

  - Anything FSL LS
  - RPi3
  - uniphier

and in all 3 cases it's a bad design decision IMHO, but it's one that
their respective creators did.

> 
>>
>>> particular, as I have mentioned a few times, I think the UEFI tables
>>> should be 'live' and not just created before booting, which means that
>>> much of driver/core needs to be in the UEFI section.
>>
>> I don't fully understand what you're aiming for here. The tables are
>> always static in a uEFI world. I don't see how they could get more
>> "live" 

Re: [U-Boot] [PATCH v2] serial: bcm283x_mu: Detect disabled serial device

[Alexander Graf]

On 12.08.16 19:21, Simon Glass wrote:
> Hi Alex,
> 
> On 11 August 2016 at 23:27, Alexander Graf  wrote:
>>
>>
>>> Am 12.08.2016 um 00:38 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
 On 11 August 2016 at 05:33, Alexander Graf  wrote:


> On 09.08.16 06:28, Stephen Warren wrote:
>> On 08/04/2016 05:15 PM, Alexander Graf wrote:
>>
>>> On 04 Aug 2016, at 20:11, Stephen Warren  wrote:
>>>
>>> On 08/04/2016 01:11 AM, Alexander Graf wrote:
 On the raspberry pi, you can disable the serial port to gain dynamic
 frequency
 scaling which can get handy at times.

 However, in such a configuration the serial controller gets its rx
 queue filled
 up with zero bytes which then happily get transmitted on to whoever
 calls
 getc() today.

 This patch adds detection logic for that case by checking whether
 the RX pin is
 mapped to GPIO15 and disables the mini uart if it is not mapped
 properly.

 That way we can leave the driver enabled in the tree and can
 determine during
 runtime whether serial is usable or not, having a single binary that
 allows for
 uart and non-uart operation.
>>>
 diff --git a/drivers/serial/serial_bcm283x_mu.c
 b/drivers/serial/serial_bcm283x_mu.c
>>>
 @@ -72,9 +87,18 @@ static int bcm283x_mu_serial_probe(struct udevice
 *dev)
 {
struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
struct bcm283x_mu_priv *priv = dev_get_priv(dev);
 +struct bcm283x_gpio_regs *gpio = (struct bcm283x_gpio_regs
 *)plat->gpio;

priv->regs = (struct bcm283x_mu_regs *)plat->base;

 +/*
 + * The RPi3 disables the mini uart by default. The easiest way
 to find
 + * out whether it is available is to check if the pin is muxed.
 + */
 +if (((readl(>gpfsel1) >> BCM283X_GPIO_GPFSEL1_F15_SHIFT) &
 +BCM283X_GPIO_ALTFUNC_MASK) != BCM283X_GPIO_ALTFUNC_5)
 +priv->disabled = true;
 +
return 0;
>>>
>>> Comment on the current implementation: Can't probe() return an error
>>> if the device should be disabled? That would avoid the need to check
>>> priv->disabled in all the other functions.
>>
>> I guess I should’ve put that in a comment somewhere. Unfortunately we
>> can’t. If I just return an error on probe, U-Boot will panic because
>> we tell it in a CONFIG define that we require a serial port (grep for
>> CONFIG_REQUIRE_SERIAL_CONSOLE).
>>
>> We could maybe try to unset that define instead?
>
> Yes, assuming that U-Boot runs just fine with HDMI console only, I think
> it's fine to unset CONFIG_REQUIRE_SERIAL_CONSOLE.
>
>>> Overall comment: I'd rather not put this logic into the UART driver
>>> itself; it is system-specific rather than device-specific. I'd also
>>> rather not have the UART driver touching GPIO registers; that's not
>>> very modular, and could cause problems if the Pi is converted to use
>>> DT to instantiate devices.
>>>
>>> Instead, can we put the logic into board/raspberrypi/rpi/rpi.c? I.e.
>>> have some early function come along and enable/disable the
>>> bcm2837_serials device object as appropriate? That way it isolates
>>> the code to the Pi specifically, and not any other bcm283x board.
>>> We'd want to wrap that code in #ifdef CONFIG_PL01X_SERIAL.
>>
>> We can do that if we can fail at probe time. If we absolutely must
>> have a serial driver to work in the first place, that doesn’t work. I
>> can try to poke at it, but it’ll be a few days I think :).

 So I couldn't find a sane way to fail probing based on something defined
 in the board file, reusing the existing gpio device.
>>>
>>> Would it be possible to move this code into the serial driver?
>>
>> You mean like in v2 which Stephen nacked? :)
> 
> Yes :-(
> 
> Well you can put what you like in the board code, and if this is only
> on the rpi, then it makes sense.
> 
> Really though, this is a pinctrl thing, so if there were a pinctrl
> driver you could just use it. The GPIO driver should not deal with pin
> muxing.

It's the same IP block on the RPi :).

> 
>>
>>>

 However, there's an easy alternative. We can make the console code just
 ignore our serial device if we set its pointer to NULL. That way we
 still have the device, but can contain all logic to disable usage of the
 mini uart to the board file.
>>>
>>> I'm not very keen on that - feels like a hack.  What is stopping
>>> Stephen's idea from working? I could perhaps help with dm plumbing is
>>> that is the issue...
>>
>> The problem 

Re: [U-Boot] [PATCH 2/5] mmc: initialize mmc_cmd with 0

[Simon Glass]

Hi Peng,

On 11 August 2016 at 05:00, Peng Fan  wrote:
> Using {0} to initialize mmc_cmd, before filling the structure.
>
> Signed-off-by: Peng Fan 
> Cc: Jaehoon Chung 
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Stefan Wahren 
> Cc: Clemens Gruber 
> Cc: Kever Yang 
> Cc: Eric Nelson 
> Cc: Stephen Warren 
> ---
>  drivers/mmc/mmc.c   | 28 ++--
>  drivers/mmc/mmc_write.c |  4 ++--
>  2 files changed, 16 insertions(+), 16 deletions(-)

Why is this needed? Does it affect code size?

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

[U-Boot] [RFC PATCH 3/4] ext4: fix endianess problems in ext4 write support

[Michael Walle]

All fields were accessed directly instead of using the proper byte swap
functions. Thus, ext4 write support was only usable on little-endian
architectures. Fix this.

Signed-off-by: Michael Walle 
---

Ok this patch is huge, please comment. I know, checkpatch fails because
there are longer lines than 80 characters. I don't want do be rude, but the
coding style is awful :/ Eg.
  
http://git.denx.de/?p=u-boot.git;a=blob;f=fs/ext4/ext4_common.c;h=eb49fce04c5a290e839575945da722bc97d2f670;hb=HEAD#l440
  
http://git.denx.de/?p=u-boot.git;a=blob;f=fs/ext4/ext4_write.c;h=e027916763f9b52937c7fe13f1698b67b94eb901;hb=HEAD#l137

Many ugly places seems to come from the 80 characters limit. Most of the
code looks like its right-aligned. I know there is a valid point for having
this limit, eg refactor code into small functions. And frankly, the ext4
write code badly needs such a refactoring. But I won't and can't do it. I
can resend a new version which meet the 80 character restriction, but it
won't make the code easier to read. And believe me, it is already hard to
do it.

Ok, back to business. Sparse really helped to find the places where the
byteswaps were missing once you annotated it correctly with the
__le16/__le32 types. If someone want to do check again, just run
 make C=1
See Documentation/sparse.txt in the linux kernel for more information. I've
done a short test, to verify I can (over)write a 700kB file. No cornertests
etc.

 fs/ext4/ext4_common.c  | 260 ++---
 fs/ext4/ext4_common.h  |   4 +-
 fs/ext4/ext4_journal.c |  15 +--
 fs/ext4/ext4_journal.h |   4 +-
 fs/ext4/ext4_write.c   | 195 +++--
 include/ext_common.h   |   2 +-
 6 files changed, 251 insertions(+), 229 deletions(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index e8ed30a..4eb4e18 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -33,19 +33,22 @@
 
 struct ext2_data *ext4fs_root;
 struct ext2fs_node *ext4fs_file;
-uint32_t *ext4fs_indir1_block;
+__le32 *ext4fs_indir1_block;
 int ext4fs_indir1_size;
 int ext4fs_indir1_blkno = -1;
-uint32_t *ext4fs_indir2_block;
+__le32 *ext4fs_indir2_block;
 int ext4fs_indir2_size;
 int ext4fs_indir2_blkno = -1;
 
-uint32_t *ext4fs_indir3_block;
+__le32 *ext4fs_indir3_block;
 int ext4fs_indir3_size;
 int ext4fs_indir3_blkno = -1;
 struct ext2_inode *g_parent_inode;
 static int symlinknest;
 
+#define DEC_LE16(x) (x = cpu_to_le16(le16_to_cpu(x) - 1))
+#define DEC_LE32(x) (x = cpu_to_le32(le32_to_cpu(x) - 1))
+
 #if defined(CONFIG_EXT4_WRITE)
 uint32_t ext4fs_div_roundup(uint32_t size, uint32_t n)
 {
@@ -112,7 +115,7 @@ static int _get_new_inode_no(unsigned char *buffer)
while (*ptr == 255) {
ptr++;
count += 8;
-   if (count > ext4fs_root->sblock.inodes_per_group)
+   if (count > le32_to_cpu(ext4fs_root->sblock.inodes_per_group))
return -1;
}
 
@@ -249,7 +252,7 @@ int ext4fs_set_inode_bmap(int inode_no, unsigned char 
*buffer, int index)
unsigned char *ptr = buffer;
unsigned char operand;
 
-   inode_no -= (index * ext4fs_root->sblock.inodes_per_group);
+   inode_no -= (index * le32_to_cpu(ext4fs_root->sblock.inodes_per_group));
i = inode_no / 8;
remainder = inode_no % 8;
if (remainder == 0) {
@@ -274,7 +277,7 @@ void ext4fs_reset_inode_bmap(int inode_no, unsigned char 
*buffer, int index)
unsigned char *ptr = buffer;
unsigned char operand;
 
-   inode_no -= (index * ext4fs_root->sblock.inodes_per_group);
+   inode_no -= (index * le32_to_cpu(ext4fs_root->sblock.inodes_per_group));
i = inode_no / 8;
remainder = inode_no % 8;
if (remainder == 0) {
@@ -289,19 +292,20 @@ void ext4fs_reset_inode_bmap(int inode_no, unsigned char 
*buffer, int index)
*ptr = *ptr & ~(operand);
 }
 
-int ext4fs_checksum_update(unsigned int i)
+uint16_t ext4fs_checksum_update(uint32_t i)
 {
struct ext2_block_group *desc;
struct ext_filesystem *fs = get_fs();
-   __u16 crc = 0;
+   uint16_t crc = 0;
+   __le32 le32_i = cpu_to_le32(i);
 
desc = (struct ext2_block_group *)>bgd[i];
-   if (fs->sb->feature_ro_compat & EXT4_FEATURE_RO_COMPAT_GDT_CSUM) {
+   if (le32_to_cpu(fs->sb->feature_ro_compat) & 
EXT4_FEATURE_RO_COMPAT_GDT_CSUM) {
int offset = offsetof(struct ext2_block_group, bg_checksum);
 
crc = ext2fs_crc16(~0, fs->sb->unique_id,
   sizeof(fs->sb->unique_id));
-   crc = ext2fs_crc16(crc, , sizeof(i));
+   crc = ext2fs_crc16(crc, _i, sizeof(le32_i));
crc = ext2fs_crc16(crc, desc, offset);
offset += sizeof(desc->bg_checksum);/* skip checksum */
assert(offset == sizeof(*desc));
@@ -322,7 +326,7 @@ static int 

[U-Boot] [PATCH v3 2/3] cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

[Tom Rini]

From: Masahiro Yamada 

This command is used to boot ARM64 Linux.

I made DISTRO_DEFAULTS select this option for ARM64 to respect
include/config_distro_defaults.h.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
Changes in v3:
- None

Changes in v2:
- Move to default y so this isn't in the defconfig files
- Reword help text slightly
---
 Kconfig   | 1 +
 cmd/Kconfig   | 7 +++
 include/config_distro_defaults.h  | 3 ---
 include/configs/uniphier.h| 1 -
 include/configs/vexpress_aemv8a.h | 1 -
 include/configs/xilinx_zynqmp.h   | 1 -
 6 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index 1119b1971666..0bc06d859f75 100644
--- a/Kconfig
+++ b/Kconfig
@@ -58,6 +58,7 @@ config DISTRO_DEFAULTS
default y if ARCH_SUNXI
default n
select CMD_BOOTZ
+   select CMD_BOOTI if ARM64
select CMD_DHCP
select CMD_EXT2
select CMD_EXT4
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d69b817c827b..e21924639fa5 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -165,6 +165,13 @@ config CMD_BOOTZ
help
  Boot the Linux zImage
 
+config CMD_BOOTI
+   bool "booti"
+   depends on ARM64
+   default y
+   help
+ Boot an AArch64 Linux Kernel image from memory.
+
 config CMD_BOOTEFI
bool "bootefi"
depends on EFI_LOADER
diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h
index 924468045262..b5efab5c3f9c 100644
--- a/include/config_distro_defaults.h
+++ b/include/config_distro_defaults.h
@@ -20,9 +20,6 @@
 #define CONFIG_BOOTP_PXE
 #define CONFIG_BOOTP_SUBNETMASK
 
-#ifdef CONFIG_ARM64
-#define CONFIG_CMD_BOOTI
-#endif
 #define CONFIG_CMD_PXE
 
 #define CONFIG_CMDLINE_EDITING
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 950c5353d253..0f5b20ff48c4 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -189,7 +189,6 @@
"__nfsboot=run tftpboot\0"
 #else
 #ifdef CONFIG_ARM64
-#define CONFIG_CMD_BOOTI
 #define CONFIG_BOOTFILE"Image"
 #define LINUXBOOT_CMD  "booti"
 #define KERNEL_ADDR_R  "kernel_addr_r=0x8008\0"
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index 46cf83be02e0..9aca3936fb13 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -133,7 +133,6 @@
 /* Command line configuration */
 #define CONFIG_MENU
 /*#define CONFIG_MENU_SHOW*/
-#define CONFIG_CMD_BOOTI
 #define CONFIG_CMD_UNZIP
 #define CONFIG_CMD_PXE
 #define CONFIG_CMD_ENV
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 297cc4d5f3dd..ca60e5d3d9cd 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -205,7 +205,6 @@
 
 #define CONFIG_SYS_BOOTM_LEN   (60 * 1024 * 1024)
 
-#define CONFIG_CMD_BOOTI
 #define CONFIG_CMD_UNZIP
 
 #define CONFIG_BOARD_EARLY_INIT_R
-- 
1.9.1

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

Re: [U-Boot] [PATCH 5/7] smbios: Expose in efi_loader as table

[Alexander Graf]

On 12.08.16 19:20, Simon Glass wrote:
> Hi Alex,
> 
> On 8 August 2016 at 08:06, Alexander Graf  wrote:
>> We can pass SMBIOS easily as EFI configuration table to an EFI payload. This
>> patch adds enablement for that case.
>>
>> While at it, we also enable SMBIOS generation for ARM systems, since they 
>> support
>> EFI_LOADER.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>>  cmd/bootefi.c|  3 +++
>>  include/efi_api.h|  4 
>>  include/efi_loader.h |  2 ++
>>  include/smbios.h |  1 +
>>  lib/Kconfig  |  4 ++--
>>  lib/smbios.c | 36 
>>  6 files changed, 48 insertions(+), 2 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 53a6ee3..e241b7d 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void 
>> *fdt)
>> if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
>> loaded_image_info.device_handle = nethandle;
>>  #endif
>> +#ifdef CONFIG_GENERATE_SMBIOS_TABLE
>> +   efi_smbios_register();
>> +#endif
>>
>> /* Initialize EFI runtime services */
>> efi_reset_system_init();
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index f572b88..bdb600e 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -201,6 +201,10 @@ struct efi_runtime_services {
>> EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
>>  0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
>>
>> +#define SMBIOS_TABLE_GUID \
>> +   EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
>> +0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>> +
>>  struct efi_configuration_table
>>  {
>> efi_guid_t guid;
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index ac8b77a..b0e8a7f 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -85,6 +85,8 @@ int efi_disk_register(void);
>>  int efi_gop_register(void);
>>  /* Called by bootefi to make the network interface available */
>>  int efi_net_register(void **handle);
>> +/* Called by bootefi to make SMBIOS tables available */
>> +void efi_smbios_register(void);
>>
>>  /* Called by networking code to memorize the dhcp ack package */
>>  void efi_net_set_dhcp_ack(void *pkt, int len);
>> diff --git a/include/smbios.h b/include/smbios.h
>> index 5962d4c..fb6396a 100644
>> --- a/include/smbios.h
>> +++ b/include/smbios.h
>> @@ -55,6 +55,7 @@ struct __packed smbios_entry {
>>  #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
>>
>>  #define BIOS_CHARACTERISTICS_EXT1_ACPI (1 << 0)
>> +#define BIOS_CHARACTERISTICS_EXT1_UEFI (1 << 3)
>>  #define BIOS_CHARACTERISTICS_EXT2_TARGET   (1 << 2)
>>
>>  struct __packed smbios_type0 {
>> diff --git a/lib/Kconfig b/lib/Kconfig
>> index 5a14530..d7f75fe 100644
>> --- a/lib/Kconfig
>> +++ b/lib/Kconfig
>> @@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
>>   version of the device tree.
>>
>>  menu "System tables"
>> -   depends on !EFI && !SYS_COREBOOT
>> +   depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
>>
>>  config GENERATE_SMBIOS_TABLE
>> bool "Generate an SMBIOS (System Management BIOS) table"
>> default y
>> -   depends on X86
>> +   depends on X86 || EFI_LOADER
>> help
>>   The System Management BIOS (SMBIOS) specification addresses how
>>   motherboard and system vendors present management information about
>> diff --git a/lib/smbios.c b/lib/smbios.c
>> index 8dfd486..b9aa741 100644
>> --- a/lib/smbios.c
>> +++ b/lib/smbios.c
>> @@ -7,10 +7,13 @@
>>   */
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> +#ifdef CONFIG_X86
>>  #include 
>> +#endif
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int 
>> handle)
>> t->vendor = smbios_add_string(t->eos, "U-Boot");
>> t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
>> t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
>> +#ifdef CONFIG_ROM_SIZE
>> t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
>> +#endif
>> t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
>>   BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
>>   BIOS_CHARACTERISTICS_UPGRADEABLE;
>>  #ifdef CONFIG_GENERATE_ACPI_TABLE
>> t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
>>  #endif
>> +#ifdef CONFIG_EFI_LOADER
>> +   t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
>> +#endif
>> t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
>> +
>> t->bios_major_release = 0xff;
>> t->bios_minor_release = 0xff;
>> t->ec_major_release = 0xff;
>> @@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int 
>> handle)
>> return len;
>>  }
>>
>> 

Re: [U-Boot] [PATCH v3 00/27] spi/sf: Updates on flash detection

[Jagan Teki]

On 12 August 2016 at 04:37, york sun  wrote:
> I saw some errors when compiling for arm. Compiling for power is still
> going.

Can you please try again?

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

[U-Boot] [PATCH] Revert "warp: Use imx_ddr_size() for calculating the DDR size"

[Breno Lima]

Commit a13d3757f7df25d0 "warp: Use imx_ddr_size() for calculating the DDR size"
causes breakage on warp board.

U-boot gets stuck in the DRAM line. It's necessary to revert this patch until
a better solution is found, otherwise it's not possible to use the board.

This reverts commit a13d3757f7df25d0f017e85551b899d598ad1bdb.

Signed-off-by: Breno Lima 
---
 board/warp/warp.c  | 2 +-
 include/configs/warp.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/warp/warp.c b/board/warp/warp.c
index 0bc0a6a..49dfdb6 100644
--- a/board/warp/warp.c
+++ b/board/warp/warp.c
@@ -46,7 +46,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int dram_init(void)
 {
-   gd->ram_size = imx_ddr_size();
+   gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
 
return 0;
 }
diff --git a/include/configs/warp.h b/include/configs/warp.h
index 12c7c38..4a8e270 100644
--- a/include/configs/warp.h
+++ b/include/configs/warp.h
@@ -43,6 +43,7 @@
 /* Physical Memory Map */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM MMDC0_ARB_BASE_ADDR
+#define PHYS_SDRAM_SIZESZ_512M
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
 #define CONFIG_SYS_INIT_RAM_ADDR   IRAM_BASE_ADDR
-- 
2.7.4

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

Re: [U-Boot] [PATCH] kconfig: use bool instead of boolean for type definition attributes

[Simon Glass]

On 11 August 2016 at 19:20, Masahiro Yamada
 wrote:
> Linux stopped the use of keyword 'boolean' in Kconfig.
>
> Refer to commit 6341e62b212a2541efb0160c470e90bd226d5496 ("kconfig:
> use bool instead of boolean for type definition attributes")
> in Linux Kernel.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/cpu/armv7/Kconfig |  8 
>  arch/arm/cpu/armv8/Kconfig |  2 +-
>  board/sunxi/Kconfig| 16 
>  drivers/power/Kconfig  | 14 +++---
>  drivers/spmi/Kconfig   |  4 ++--
>  5 files changed, 22 insertions(+), 22 deletions(-)

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

[U-Boot] [PATCH V2 4/5] mmc: esdhc: change timeout value

[Peng Fan]

Change timeout according to the timeout value in mmc_cmd->timeout.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
---
 drivers/mmc/fsl_esdhc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 9796d39..eca2f31 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -350,6 +350,7 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct 
mmc_data *data)
int err = 0;
uintxfertyp;
uintirqstat;
+   int timeout = cmd->timeout;
struct fsl_esdhc_priv *priv = mmc->priv;
struct fsl_esdhc *regs = priv->esdhc_regs;
 
@@ -431,7 +432,8 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct 
mmc_data *data)
 
/* Workaround for ESDHC errata ENGcm03648 */
if (!data && (cmd->resp_type & MMC_RSP_BUSY)) {
-   int timeout = 6000;
+   if (timeout < 6000)
+   timeout = 6000;
 
/* Poll on DATA0 line for cmd with busy signal for 600 ms */
while (timeout > 0 && !(esdhc_read32(>prsstat) &
-- 
2.6.2

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

[U-Boot] [PATCH] mmc: uniphier-sd: add static qualifiers to probe and remove callbacks

[Masahiro Yamada]

They are both only referenced in this file.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/uniphier-sd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 2a48378..f06e737 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -646,7 +646,7 @@ static const struct mmc_ops uniphier_sd_ops = {
.getcd = uniphier_sd_getcd,
 };
 
-int uniphier_sd_probe(struct udevice *dev)
+static int uniphier_sd_probe(struct udevice *dev)
 {
struct uniphier_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
@@ -731,7 +731,7 @@ int uniphier_sd_probe(struct udevice *dev)
return 0;
 }
 
-int uniphier_sd_remove(struct udevice *dev)
+static int uniphier_sd_remove(struct udevice *dev)
 {
struct uniphier_sd_priv *priv = dev_get_priv(dev);
 
-- 
1.9.1

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

[U-Boot] [PATCH V2 2/5] mmc: initialize mmc_cmd with 0

[Peng Fan]

Using {0} to initialize mmc_cmd, before filling the structure.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Stefan Wahren 
Cc: Clemens Gruber 
Cc: Kever Yang 
Cc: Eric Nelson 
Cc: Stephen Warren 
---
 drivers/mmc/mmc.c   | 28 ++--
 drivers/mmc/mmc_write.c |  4 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index a855acf..7a3a4f8 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -140,7 +140,7 @@ int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
struct mmc_data *data)
 
 int mmc_send_status(struct mmc *mmc, int timeout)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int err, retries = 5;
 
cmd.cmdidx = MMC_CMD_SEND_STATUS;
@@ -184,7 +184,7 @@ int mmc_send_status(struct mmc *mmc, int timeout)
 
 int mmc_set_blocklen(struct mmc *mmc, int len)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
 
if (mmc->ddr_mode)
return 0;
@@ -199,7 +199,7 @@ int mmc_set_blocklen(struct mmc *mmc, int len)
 static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
   lbaint_t blkcnt)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
struct mmc_data data;
 
if (blkcnt > 1)
@@ -292,7 +292,7 @@ ulong mmc_bread(struct blk_desc *block_dev, lbaint_t start, 
lbaint_t blkcnt,
 
 static int mmc_go_idle(struct mmc *mmc)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int err;
 
udelay(1000);
@@ -315,7 +315,7 @@ static int sd_send_op_cond(struct mmc *mmc)
 {
int timeout = 1000;
int err;
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
 
while (1) {
cmd.cmdidx = MMC_CMD_APP_CMD;
@@ -381,7 +381,7 @@ static int sd_send_op_cond(struct mmc *mmc)
 
 static int mmc_send_op_cond_iter(struct mmc *mmc, int use_arg)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int err;
 
cmd.cmdidx = MMC_CMD_SEND_OP_COND;
@@ -423,7 +423,7 @@ static int mmc_send_op_cond(struct mmc *mmc)
 
 static int mmc_complete_op_cond(struct mmc *mmc)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int timeout = 1000;
uint start;
int err;
@@ -467,7 +467,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
 
 static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
struct mmc_data data;
int err;
 
@@ -488,7 +488,7 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd)
 
 int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int timeout = 1000;
int ret;
 
@@ -821,7 +821,7 @@ int mmc_getcd(struct mmc *mmc)
 
 static int sd_switch(struct mmc *mmc, int mode, int group, u8 value, u8 *resp)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
struct mmc_data data;
 
/* Switch the frequency */
@@ -843,7 +843,7 @@ static int sd_switch(struct mmc *mmc, int mode, int group, 
u8 value, u8 *resp)
 static int sd_change_freq(struct mmc *mmc)
 {
int err;
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
ALLOC_CACHE_ALIGN_BUFFER(uint, scr, 2);
ALLOC_CACHE_ALIGN_BUFFER(uint, switch_status, 16);
struct mmc_data data;
@@ -953,7 +953,7 @@ retry_scr:
 static int sd_read_ssr(struct mmc *mmc)
 {
int err, i;
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
ALLOC_CACHE_ALIGN_BUFFER(uint, ssr, 16);
struct mmc_data data;
int timeout = 3;
@@ -1070,7 +1070,7 @@ static int mmc_startup(struct mmc *mmc)
int err, i;
uint mult, freq;
u64 cmult, csize, capacity;
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
ALLOC_CACHE_ALIGN_BUFFER(u8, test_csd, MMC_MAX_BLOCK_LEN);
int timeout = 1000;
@@ -1553,7 +1553,7 @@ static int mmc_startup(struct mmc *mmc)
 
 static int mmc_send_if_cond(struct mmc *mmc)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
int err;
 
cmd.cmdidx = SD_CMD_SEND_IF_COND;
diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 0f8b5c7..4149f4a 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -17,7 +17,7 @@
 
 static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
 {
-   struct mmc_cmd cmd;
+   struct mmc_cmd cmd = {0};
ulong end;
int err, start_cmd, end_cmd;
 
@@ -119,7 +119,7 @@ unsigned long mmc_berase(struct blk_desc *block_dev, 
lbaint_t start,
 static ulong 

[U-Boot] [PATCH] cmd: efi_loader: Return CMD_RET_USAGE in case of not enough arguments

[Bin Meng]

When typing 'bootefi' from U-Boot shell, nothing outputs. Like other
commands, return CMD_RET_USAGE so that it can print help message.

Signed-off-by: Bin Meng 
---

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

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ecf9968..ccd2126 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -228,7 +228,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
int r = 0;
 
if (argc < 2)
-   return 1;
+   return CMD_RET_USAGE;
 #ifdef CONFIG_CMD_BOOTEFI_HELLO
if (!strcmp(argv[1], "hello")) {
addr = CONFIG_SYS_LOAD_ADDR;
-- 
2.9.2

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

Re: [U-Boot] [PATCH v3 00/27] spi/sf: Updates on flash detection

[Bin Meng]

On Thu, Aug 11, 2016 at 4:06 PM, Jagan Teki  wrote:
> Updated spi_flash_info table in sync with Linux, and removed
> legacy and unsupported code.
>
> Changes for v3:
> - New patches
> - Fix checkpatch.pl
> - Fix BIT positions in spi.h
> - Fix ti_qspi.c mode
> - Fix commit Nit: s/becuase/because
>

For the whole series, tested on Intel Crown Bay
Tested-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] rockchip: use dummy byte only enable OF_PLATDATA

[Ziyuan Xu]

Add a condition to determine the rk3288_sdram_channel size.

This patch fixes read sdram_channel property failed from DT on rk3288
boards, which not enable OF_PLATDATA.

Signed-off-by: Ziyuan Xu 
---

 arch/arm/include/asm/arch-rockchip/sdram.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/arch-rockchip/sdram.h 
b/arch/arm/include/asm/arch-rockchip/sdram.h
index e08e28f..82c3d07 100644
--- a/arch/arm/include/asm/arch-rockchip/sdram.h
+++ b/arch/arm/include/asm/arch-rockchip/sdram.h
@@ -24,12 +24,16 @@ struct rk3288_sdram_channel {
u8 row_3_4;
u8 cs0_row;
u8 cs1_row;
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
/*
 * For of-platdata, which would otherwise convert this into two
 * byte-swapped integers. With a size of 9 bytes, this struct will
 * appear in of-platdata as a byte array.
+*
+* If OF_PLATDATA enabled, need to add a dummy byte in dts.(i.e 0xff)
 */
u8 dummy;
+#endif
 };
 
 struct rk3288_sdram_pctl_timing {
-- 
2.9.2


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

Re: [U-Boot] [PATCH 0/4] k2g: switch mmc/sd to driver model

[Jaehoon Chung]

Hi,

On 08/10/2016 10:54 PM, Sekhar Nori wrote:
> This patch set switches mmc/sd support on k2g
> to use driver model.
> 
> Tested both SD card and emmc on k2g-evm by
> writing data, reading it back and comparing crc.
> 
> also tested with buildman for am33xx and omap

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Sekhar Nori (4):
>   drivers: mmc: omap_hsmmc: fix build breakage
>   ARM: dts: K2G: Add support for MMC controller
>   ARM: dts: k2g-evm: enable mmc/sd suppport
>   defconfig: k2g_evm_defconfig: Enable mmc driver model
> 
>  arch/arm/dts/k2g-evm.dts  |  8 
>  arch/arm/dts/k2g.dtsi | 23 +++
>  configs/k2g_evm_defconfig |  1 +
>  drivers/mmc/omap_hsmmc.c  |  2 ++
>  4 files changed, 34 insertions(+)
> 

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

Re: [U-Boot] [PATCH v2 1/2] cmd: Split 'bootz' and 'booti' out from 'bootm'

[Masahiro Yamada]

Hi Tom,


2016-08-02 0:28 GMT+09:00 Tom Rini :
> The bootz and booti commands rely on common functionality that is found
> in common/bootm.c and common/bootm_os.c.  They do not however rely on
> the rest of cmd/bootm.c to be implemented so split them into their own
> files.  Have various Makefiles include the required infrastructure for
> CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM.
>
> Signed-off-by: Tom Rini 


If I apply this patch,
I got a build error for the combination of
"CONFIG_CMD_BOOTZ=y" and "# CONFIG_CMD_BOOTM is not set".


$ make CROSS_COMPILE=arm-linux-gnueabi-
scripts/kconfig/conf  --silentoldconfig Kconfig
  CHK include/config.h
  UPD include/config.h
  GEN include/autoconf.mk
  GEN include/autoconf.mk.dep
  GEN spl/include/autoconf.mk
  CHK include/config/uboot.release
  UPD include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  UPD include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  CC  lib/asm-offsets.s
  CHK include/generated/generic-asm-offsets.h
  UPD include/generated/generic-asm-offsets.h
  CC  arch/arm/lib/asm-offsets.s
  CHK include/generated/asm-offsets.h
  UPD include/generated/asm-offsets.h
  HOSTCC  tools/gen_eth_addr
  HOSTCC  tools/img2srec
  HOSTCC  tools/mkenvimage.o
  HOSTCC  tools/os_support.o
  WRAPtools/lib/crc32.c
  HOSTCC  tools/lib/crc32.o
  HOSTLD  tools/mkenvimage
  HOSTCC  tools/aisimage.o
  HOSTCC  tools/atmelimage.o
  WRAPtools/common/bootm.c
  HOSTCC  tools/common/bootm.o
  HOSTCC  tools/default_image.o
  WRAPtools/lib/fdtdec_common.c
  HOSTCC  tools/lib/fdtdec_common.o
  WRAPtools/lib/fdtdec.c
  HOSTCC  tools/lib/fdtdec.o
  HOSTCC  tools/fit_common.o
  HOSTCC  tools/fit_image.o
  WRAPtools/common/image-fit.c
  HOSTCC  tools/common/image-fit.o
  HOSTCC  tools/image-host.o
  WRAPtools/common/image.c
  HOSTCC  tools/common/image.o
  HOSTCC  tools/imagetool.o
  HOSTCC  tools/imximage.o
  HOSTCC  tools/kwbimage.o
  WRAPtools/lib/md5.c
  HOSTCC  tools/lib/md5.o
  HOSTCC  tools/lpc32xximage.o
  HOSTCC  tools/mxsimage.o
  HOSTCC  tools/omapimage.o
  HOSTCC  tools/pblimage.o
  HOSTCC  tools/pbl_crc32.o
  WRAPtools/lib/rc4.c
  HOSTCC  tools/lib/rc4.o
  HOSTCC  tools/rkcommon.o
  HOSTCC  tools/rkimage.o
  HOSTCC  tools/rksd.o
  HOSTCC  tools/rkspi.o
  HOSTCC  tools/socfpgaimage.o
  WRAPtools/lib/sha1.c
  HOSTCC  tools/lib/sha1.o
  WRAPtools/lib/sha256.c
  HOSTCC  tools/lib/sha256.o
  WRAPtools/common/hash.c
  HOSTCC  tools/common/hash.o
  HOSTCC  tools/ublimage.o
  HOSTCC  tools/zynqimage.o
  HOSTCC  tools/zynqmpimage.o
  WRAPtools/lib/libfdt/fdt.c
  HOSTCC  tools/lib/libfdt/fdt.o
  WRAPtools/lib/libfdt/fdt_ro.c
  HOSTCC  tools/lib/libfdt/fdt_ro.o
  WRAPtools/lib/libfdt/fdt_rw.c
  HOSTCC  tools/lib/libfdt/fdt_rw.o
  WRAPtools/lib/libfdt/fdt_strerror.c
  HOSTCC  tools/lib/libfdt/fdt_strerror.o
  WRAPtools/lib/libfdt/fdt_wip.c
  HOSTCC  tools/lib/libfdt/fdt_wip.o
  WRAPtools/lib/libfdt/fdt_region.c
  HOSTCC  tools/lib/libfdt/fdt_region.o
  WRAPtools/lib/libfdt/fdt_sw.c
  HOSTCC  tools/lib/libfdt/fdt_sw.o
  HOSTCC  tools/gpimage.o
  HOSTCC  tools/gpimage-common.o
  HOSTCC  tools/dumpimage.o
  HOSTLD  tools/dumpimage
  HOSTCC  tools/mkimage.o
  HOSTLD  tools/mkimage
  HOSTCC  tools/proftool
  HOSTCC  tools/fdtgrep.o
  HOSTLD  tools/fdtgrep
  LD  arch/arm/cpu/built-in.o
  CC  arch/arm/cpu/armv7/cache_v7.o
  AS  arch/arm/cpu/armv7/cache_v7_asm.o
  CC  arch/arm/cpu/armv7/cpu.o
  CC  arch/arm/cpu/armv7/cp15.o
  CC  arch/arm/cpu/armv7/syslib.o
  AS  arch/arm/cpu/armv7/nonsec_virt.o
  CC  arch/arm/cpu/armv7/virt-v7.o
  CC  arch/arm/cpu/armv7/virt-dt.o
  AS  arch/arm/cpu/armv7/psci.o
  CC  arch/arm/cpu/armv7/psci-common.o
  LD  arch/arm/cpu/armv7/built-in.o
  AS  arch/arm/cpu/armv7/start.o
  AS  arch/arm/lib/vectors.o
  AS  arch/arm/lib/crt0.o
  AS  arch/arm/lib/relocate.o
  CC  arch/arm/lib/bootm-fdt.o
  CC  arch/arm/lib/bootm.o
  CC  arch/arm/lib/zimage.o
  AS  arch/arm/lib/memset.o
  AS  arch/arm/lib/memcpy.o
  CC  arch/arm/lib/sections.o
  CC  arch/arm/lib/stack.o
  CC  arch/arm/lib/interrupts.o
  CC  arch/arm/lib/reset.o
  CC  arch/arm/lib/cache.o
  CC  arch/arm/lib/cache-cp15.o
  CC  arch/arm/lib/psci-dt.o
  LD  arch/arm/lib/built-in.o
  AS  arch/arm/lib/ashldi3.o
  AS  arch/arm/lib/ashrdi3.o
  CC  arch/arm/lib/div0.o
  AS  arch/arm/lib/div64.o
  AS  arch/arm/lib/lib1funcs.o
  AS  arch/arm/lib/lshrdi3.o
  AS  arch/arm/lib/muldi3.o
  AS  arch/arm/lib/uldivmod.o
  AR  arch/arm/lib/lib.a
  CC  arch/arm/lib/eabi_compat.o
  CC  arch/arm/mach-uniphier/board_early_init_f.o
  CC  arch/arm/mach-uniphier/cpu_info.o
  CC  

Re: [U-Boot] [PATCH v2 1/5] mpc85xx/powerpc:cpu_init: Modified the errata A006261 according to endianness

[Sriram Dash]

>From: york sun
>
>Sriram,
>
>Please pay attention to the language. "errata" is the plural noun of 
>"erratum". You
>are dealing with one erratum, aren't you? And you are modifying the workaround,
>not the erratum itself.
>
>The tags in the subject should be separated by either "/", or ":", but not 
>both. I don't
>believe "cpu_init" should be in the tag.
>

Hello York,
Will take care from next time onwards. Will change in v3.

>
>On 07/17/2016 08:47 PM, Sriram Dash wrote:
>> Modifies errata implementation due to the fact that P3041,
>> P5020, and P5040 are all big endian for the USB PHY registers, but
>> they were specified little endian.
>
>If your change is correct, can you explain why the original format
>didn't cause any harm before?
>
>York
>

If it is working due to SWAP most likely reason would be bit[9] of
confige1 which might be getting mapped to HS Disconnect decrement
by 50mV. Whereas Errata intends to increase the threshold by 100mV
though bit C1[8:9] which map to C1[23:22] in BG.  I mean in full swap,
this value will have maximum impact, although complete write is
expected to be done properly.


>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>> Changes in v2:
>>   - Adds the errata number to title of patch
>>   - Makes separate patch for addition of errata to specific Socs.
>>
>>
>>  arch/powerpc/cpu/mpc85xx/cpu_init.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
>b/arch/powerpc/cpu/mpc85xx/cpu_init.c
>> index 61f5639..61dedfc 100644
>> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
>> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
>> @@ -114,10 +114,10 @@ void fsl_erratum_a006261_workaround(struct
>ccsr_usb_phy __iomem *usb_phy)
>>  setbits_be32(_phy->config2,
>>   CONFIG_SYS_FSL_USB_RX_AUTO_CAL_RD_WR_SEL);
>>
>> -temp = squelch_prog_rd_0_2 <<
>CONFIG_SYS_FSL_USB_SQUELCH_PROG_WR_0;
>> +temp = squelch_prog_rd_0_2 <<
>CONFIG_SYS_FSL_USB_SQUELCH_PROG_WR_3;
>>  out_be32(_phy->config2, in_be32(_phy->config2) | temp);
>>
>> -temp = squelch_prog_rd_3_5 <<
>CONFIG_SYS_FSL_USB_SQUELCH_PROG_WR_3;
>> +temp = squelch_prog_rd_3_5 <<
>CONFIG_SYS_FSL_USB_SQUELCH_PROG_WR_0;
>>  out_be32(_phy->config2, in_be32(_phy->config2) | temp);
>>  #endif
>>  }
>>

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

Re: [U-Boot] [PATCH] Revert "warp: Use imx_ddr_size() for calculating the DDR size"

[Otavio Salvador]

On Fri, Aug 12, 2016 at 2:12 PM, Breno Lima  wrote:
> Commit a13d3757f7df25d0 "warp: Use imx_ddr_size() for calculating the DDR 
> size"
> causes breakage on warp board.
>
> U-boot gets stuck in the DRAM line. It's necessary to revert this patch until
> a better solution is found, otherwise it's not possible to use the board.
>
> This reverts commit a13d3757f7df25d0f017e85551b899d598ad1bdb.
>
> Signed-off-by: Breno Lima 

Why is this happening? I am fine in reverting this but we need to fix
the detection. Is it due memory callibration problems?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] efi_loader: Expose SMBIOS table

[Alexander Graf]

On 12.08.16 19:20, Simon Glass wrote:
> Hi Alex,
> 
> On 10 August 2016 at 01:29, Alexander Graf  wrote:
>>
>>> On 09 Aug 2016, at 16:35, Simon Glass  wrote:
>>>
>>> Hi Alexander,
>>>
>>> On 9 August 2016 at 08:11, Alexander Graf  wrote:

 On 08/09/2016 03:57 PM, Simon Glass wrote:
>
> Hi Alexander,
>
> On 9 August 2016 at 00:48, Alexander Graf  wrote:
>>
>>
>>> Am 08.08.2016 um 23:44 schrieb Simon Glass :
>>>
>>> Hi Alexander,
>>>
 On 8 August 2016 at 08:06, Alexander Graf  wrote:
 We generate a few tables on x86 today that really can be used on ARM 
 just
 the same. One such example is the SMBIOS table, which people use with 
 tools
 like "dmidecode" to identify which hardware they are running on.

 We're slowly growing needs to collect serial numbers from various 
 devices
 on ARM and SMBIOS seems the natural choice. So this patch set moves the
 current SMBIOS generation into generic code and adds serial number 
 exposure
 to it.
>>>
>>> Shouldn't we use device tree? Why would an ARM device use SMBIOS?
>>
>> Mostly because SBBR dictates it and every ARM server platform out there 
>> provides SMBIOS tables ;).
>>
>> Also, both describe very different things. At least I have never seen 
>> things like "The chassy of this server has 2 power connectors and is 
>> blue" in device tree.
>
> So there is no DT binding for this information? Does this mean that
> U-Boot on ARM needs to pass information through just 'sitting in RAM
> somewhere' like x86?


 I don't think there's a non-EFI way on ARM to pass this through at all, 
 correct. That's nothing new though - things like KASLR also depend on EFI.
>>>
>>> That feels like it could just be done in U-Boot. The proliferation of
>>> bootloader stuff in Linux bugs me. It's the lowest-common-denominator
>>> problem. To me it seems that UEFI and U-Boot should implement these
>>> features, and then Linux doesn't need to.
>>>
>>> Anyway I do understand where you are going. Is it possible to provide
>>> EFI tables to Linux but not EFI boot/run-time services?
>>
>> I’m not aware of any way to do that today unfortunately. I don’t see why you 
>> couldn’t add a device tree property that points to random memory locations 
>> for tables though.
> 
> I was more thinking of whether this is defined in the device tree,  or
> only exists as a binary table in SMBIOS? I probably know the answer
> :-)
> 
>>
>> As a more fundamental question though, will we really care about the non-EFI 
>> boot path 5 or 10 years from now? It doesn’t add much complexity and allows 
>> for less divergence between classic embedded and server systems. Since Linux 
>> itself is a uEFI binary, you can simply replace “booti” with “bootefi” in 
>> most boot cases and shouldn’t even see much of a difference.
> 
> Linux can certainly be built as an EFI binary. I can't predict the

It does get built as EFI binary by default, no?

> future, but I'm not sure that 'classic embedded' (i.e. most devices in
> the world) want to become more like server systems. We'll see.

The nice thing about the EFI_LOADER support is that they really don't
have to. They can stay embedded in pretty much every aspect they are today.

> 
>>
>> I don’t think that the non-EFI boot path will disappear, but turns more and 
>> more into a second class citizen because a lot of work is happening in the 
>> server space which requires EFI.
> 
> OK, well let's see. Most of my objection to EFI is the
> complexity/size.obfuscation of the code. Maybe someone should work on
> that, or are you suggesting that UEFI dies and people use U-Boot with
> the EFI interface?

To get the naming right, uEFI is the specification as provided here:

  http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

while the main pain point that people (including me) have, is the edk2
code base which is Intel's reference implementation of the uEFI spec:

  https://github.com/tianocore/edk2

I don't think either of them will die. But I do believe that there is no
real disadvantage of running U-Boot + uEFI Linux entry point over U-Boot
+ native booti entry point.

Since some work (like kASLR) depends on the uEFI entry point, I don't
think there's much need for the booti in the future. But I like to be
proven wrong :).

> 
>>
>> But yes, please be my guest and suggest device tree properties to the Linux 
>> device tree list that allow exposure of tables (I’m not sure whether 
>> anything beyond SMBIOS makes sense for a dt based system) to Linux on 
>> non-EFI boot.
> 
> If I get a server system one day I might do that. I don't have one yet.

The easiest way to get one is to run QEMU! :)


Alex
___

Re: [U-Boot] [PATCH 0/2] efi_loader: Implement reset on RPi

[Simon Glass]

Hi Alex,

On 11 August 2016 at 05:49, Alexander Graf  wrote:
>
>
> On 08.08.16 23:44, Simon Glass wrote:
>> Hi,
>>
>> On 7 August 2016 at 10:59, Andreas Färber  wrote:
>>> Am 14.07.2016 um 08:18 schrieb Alexander Graf:
> Am 14.07.2016 um 06:48 schrieb Andreas Färber :
>
> Hi Alex,
>
>> Am 05.06.2016 um 23:17 schrieb Alexander Graf:
>> If Linux finds an EFI implementation it always uses the EFI reset 
>> handler to
>> reboot or power down the system.
>
> Hm, I thought my powerdown issues on the Jetson TK1 were for lack of
> CONFIG_AS3277_RESET - sounds like it could be due to EFI instead?

 It depends. IIRC the TK1 is 32bit, where you're probably using grub2 which 
 is not efi Linux aware, but instead boots over the zImage protocol. In 
 that case Linux doesn't know about efi runtime services.
>>>
>>> We've confirmed in the meantime that the Jetson TK1 issues were
>>> unrelated to EFI and could be worked around by enabling some as3722
>>> kernel option.
>>>
>> Unfortunately we haven't implemented that one yet. In fact, while we 
>> prepared
>> for RTS handling, we never actually implemented a single user.
>>
>> This is going to change today. This simple patch set enables RTS reset 
>> support
>> for the RPi systems, allowing you to reboot and shut down the rpi if 
>> booted
>> via EFI.
>>
>> It also lays the groundwork to show how to implement that functionality 
>> at all,
>> so I expect more boards to follow.
>>
>> Alexander Graf (2):
>>  efi_loader: Allow boards to implement get_time and reset_system
>>  ARM: bcm283x: Implement EFI RTS reset_system
>>
>> arch/arm/mach-bcm283x/include/mach/wdog.h |   2 +-
>> arch/arm/mach-bcm283x/reset.c |  59 +++--
>> cmd/bootefi.c |   4 ++
>> include/efi_loader.h  |  18 ++
>> lib/efi_loader/efi_runtime.c  | 101 
>> ++
>> 5 files changed, 166 insertions(+), 18 deletions(-)
>
> This all looks very non-generic and would mean that every board will
> need to be patched individually, which is unrealistic to be tested by
> just the two of us.
>
> Can't you patch the reset_cpu() declaration (common.h/sysreset.h)
> instead of all its implementations? We might still need to patch
> individual implementations but I don't see why any reset_cpu()
> implementation should be in a different section than others.

 Hmm. There are 2 minor problems:

   1) Efi also supports power off on top of reset
   2) We would have to convert all boards at once, rather than one by one, 
 as we couldn't distinguish between efi aware and unaware ones
>>>
>>> I don't see why we would need to convert everything at once either way.
>>>

 And one major issue:

 All device memory pointers used by the reset functions need to be marked 
 as such in the efi memory map and live relocated when entering runtime 
 mode. So we need to manually touch every function either way.
>>
>> I'm worried about this. It means that any code used from this run-time
>> needs to be so marked. This could be large tracts of U-Boot. In
>
> We only need to mark the few bits that are actually executed and used
> within RTS. That's usually just 2 or 3 functions.
>

At present you only have reset, and you've only implemented it for one
board. Are there other calls that we need to implement? This
EFI_RUNTIME is transitive - anything it calls must be in the runtime.
Does the linker prevent us from screwing up?

> Also, moving forward, we'll see more and more systems implement PSCI
> which means we can implement a generic PSCI RTS for reset/shutdown.

What system can I get that uses that today?

>
>> particular, as I have mentioned a few times, I think the UEFI tables
>> should be 'live' and not just created before booting, which means that
>> much of driver/core needs to be in the UEFI section.
>
> I don't fully understand what you're aiming for here. The tables are
> always static in a uEFI world. I don't see how they could get more
> "live" than creating them right before boot.

I'd prefer to see the EFI requests be processed as they are received,
rather than with pre-canned data. Your original justification (e.g.
for efi_disk_add_dev()) was that there was not authoritative list of
block devices in U-Boot. But there is now.

So do you think it would be feasible to drop these tables, and efi_obj_list?

What happens with the tables if I run an app and then come back to U-Boot?

>
>> Should we just adjust it so that the whole of U-Boot is in there? How
>> big is the UEFI run-time normally?
>
> It's really not a problem of putting things in one section or another.
> It's that if anything within a run time .text section tries to access
> 

Re: [U-Boot] [PATCH 3/5] config: evb-rk3399: enable pinctrl driver

[Simon Glass]

On 11 August 2016 at 19:48, Kever Yang  wrote:
> This patch enable rk3399 pinctrl driver and gpio driver which is sub-node
> of pinctrl.
>
> Signed-off-by: Kever Yang 
> ---
>
>  configs/evb-rk3399_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] building u-boot x86 with device tree disabled , still refers to device tree function

[Simon Glass]

+Bin

Hi,



On 11 August 2016 at 08:36, Ding, ChiX  wrote:
> Hi there
> I'm building u-boot as payload for x86 platform. I didn't enable device tree 
> in menuconfig (CONFIG_OF_CONTROL is not set) because I use a board config 
> file coreboot.h. When I built u-boot, it reports error during linking stage : 
> undefined reference to dm_scan_fdt_dev
>
> arch/x86/lib/built-in.o:(.u_boot_list_2_uclass_2_lpc+0x8): undefined 
> reference to `dm_scan_fdt_dev'
> common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/built-in.o:(.u_boot_list_2_uclass_2_pch+0x8): undefined reference to 
> `dm_scan_fdt_dev'
> drivers/pci/built-in.o:(.u_boot_list_2_uclass_2_pci+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/spi/built-in.o:(.u_boot_list_2_uclass_2_spi+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/usb/host/built-in.o:(.u_boot_list_2_uclass_2_usb+0x8): more undefined 
> references to `dm_scan_fdt_dev' follow
> Makefile:1189: recipe for target 'u-boot' failed
>
> I looked at the code and see arch/x86/lib/lpc-uclass.c refers to a function 
> "dm_scan_fdt_dev " which is defined in drivers/core/root.c and it looks like 
> a device tree function
>
>
> UCLASS_DRIVER(lpc) = {
> .id = UCLASS_LPC,
> .name   = "lpc",
> .post_bind  = dm_scan_fdt_dev,
> };
>
> Because device tree isn't enabled, the function isn't compiled and causes the 
> problem while linking.
> It's only compiled when the following is true
> #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> If I comment out the line, it would compile and build. But I'm not sure if 
> it's the right way to do it.
>
> Is it normal behavior? I thought that when not enabling device tree, the code 
> shouldn't use device tree function?
> Can anyone help on this please?

Even when running as a coreboot payload you should use DT. As Bin
says, this is described in README.x86 so you should be able to follow
along there.

If there is a specific reason for disabling the DT, can you explain it a bit?

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

Re: [U-Boot] [PATCH 4/5] rk3399: enable the pwm2/3 pinctrl in board init

[Simon Glass]

On 11 August 2016 at 19:48, Kever Yang  wrote:
> There is no interrupt line for each PWM which used by pinctrl to get the
> periph_id, so it's not able to enable the default pinctrl setting by pinctrl
> framework, let's enable it at board_init().
>
> Signed-off-by: Kever Yang 
> ---
>
>  board/rockchip/evb_rk3399/evb-rk3399.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] rockchip: use dummy byte only enable OF_PLATDATA

[Simon Glass]

On 12 August 2016 at 01:43, Ziyuan Xu  wrote:
> Add a condition to determine the rk3288_sdram_channel size.
>
> This patch fixes read sdram_channel property failed from DT on rk3288
> boards, which not enable OF_PLATDATA.
>
> Signed-off-by: Ziyuan Xu 
> ---
>
>  arch/arm/include/asm/arch-rockchip/sdram.h | 4 
>  1 file changed, 4 insertions(+)

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

Re: [U-Boot] [PATCH 0/7] efi_loader: Expose SMBIOS table

[Simon Glass]

Hi Alex,

On 10 August 2016 at 01:29, Alexander Graf  wrote:
>
>> On 09 Aug 2016, at 16:35, Simon Glass  wrote:
>>
>> Hi Alexander,
>>
>> On 9 August 2016 at 08:11, Alexander Graf  wrote:
>>>
>>> On 08/09/2016 03:57 PM, Simon Glass wrote:

 Hi Alexander,

 On 9 August 2016 at 00:48, Alexander Graf  wrote:
>
>
>> Am 08.08.2016 um 23:44 schrieb Simon Glass :
>>
>> Hi Alexander,
>>
>>> On 8 August 2016 at 08:06, Alexander Graf  wrote:
>>> We generate a few tables on x86 today that really can be used on ARM 
>>> just
>>> the same. One such example is the SMBIOS table, which people use with 
>>> tools
>>> like "dmidecode" to identify which hardware they are running on.
>>>
>>> We're slowly growing needs to collect serial numbers from various 
>>> devices
>>> on ARM and SMBIOS seems the natural choice. So this patch set moves the
>>> current SMBIOS generation into generic code and adds serial number 
>>> exposure
>>> to it.
>>
>> Shouldn't we use device tree? Why would an ARM device use SMBIOS?
>
> Mostly because SBBR dictates it and every ARM server platform out there 
> provides SMBIOS tables ;).
>
> Also, both describe very different things. At least I have never seen 
> things like "The chassy of this server has 2 power connectors and is 
> blue" in device tree.

 So there is no DT binding for this information? Does this mean that
 U-Boot on ARM needs to pass information through just 'sitting in RAM
 somewhere' like x86?
>>>
>>>
>>> I don't think there's a non-EFI way on ARM to pass this through at all, 
>>> correct. That's nothing new though - things like KASLR also depend on EFI.
>>
>> That feels like it could just be done in U-Boot. The proliferation of
>> bootloader stuff in Linux bugs me. It's the lowest-common-denominator
>> problem. To me it seems that UEFI and U-Boot should implement these
>> features, and then Linux doesn't need to.
>>
>> Anyway I do understand where you are going. Is it possible to provide
>> EFI tables to Linux but not EFI boot/run-time services?
>
> I’m not aware of any way to do that today unfortunately. I don’t see why you 
> couldn’t add a device tree property that points to random memory locations 
> for tables though.

I was more thinking of whether this is defined in the device tree,  or
only exists as a binary table in SMBIOS? I probably know the answer
:-)

>
> As a more fundamental question though, will we really care about the non-EFI 
> boot path 5 or 10 years from now? It doesn’t add much complexity and allows 
> for less divergence between classic embedded and server systems. Since Linux 
> itself is a uEFI binary, you can simply replace “booti” with “bootefi” in 
> most boot cases and shouldn’t even see much of a difference.

Linux can certainly be built as an EFI binary. I can't predict the
future, but I'm not sure that 'classic embedded' (i.e. most devices in
the world) want to become more like server systems. We'll see.

>
> I don’t think that the non-EFI boot path will disappear, but turns more and 
> more into a second class citizen because a lot of work is happening in the 
> server space which requires EFI.

OK, well let's see. Most of my objection to EFI is the
complexity/size.obfuscation of the code. Maybe someone should work on
that, or are you suggesting that UEFI dies and people use U-Boot with
the EFI interface?

>
> But yes, please be my guest and suggest device tree properties to the Linux 
> device tree list that allow exposure of tables (I’m not sure whether anything 
> beyond SMBIOS makes sense for a dt based system) to Linux on non-EFI boot.

If I get a server system one day I might do that. I don't have one yet.

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

Re: [U-Boot] [PATCH 2/5] pinctrl: add driver for rk3399

[Simon Glass]

Hi Kever,

On 11 August 2016 at 19:47, Kever Yang  wrote:
> This patch add pinctrl driver for rk3399.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/include/asm/arch-rockchip/grf_rk3399.h | 365 
> 
>  drivers/pinctrl/Kconfig |   9 +
>  drivers/pinctrl/rockchip/Makefile   |   1 +
>  drivers/pinctrl/rockchip/pinctrl_rk3399.c   | 282 ++
>  4 files changed, 657 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3399.h
>  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3399.c
>
> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3399.h 
> b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> new file mode 100644
> index 000..bcb5f97
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3399.h
> @@ -0,0 +1,365 @@
> +/*
> + * This file is part of the coreboot project.
> + *
> + * Copyright 2016 Rockchip Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __SOC_ROCKCHIP_RK3399_GRF_H__
> +#define __SOC_ROCKCHIP_RK3399_GRF_H__
> +
> +struct rk3399_grf_regs {
> +   u32 reserved[0x800];
> +   u32 usb3_perf_con0;
> +   u32 usb3_perf_con1;
> +   u32 usb3_perf_con2;
> +   u32 usb3_perf_rd_max_latency_num;
> +   u32 usb3_perf_rd_latency_samp_num;
> +   u32 usb3_perf_rd_latency_acc_num;
> +   u32 usb3_perf_rd_axi_total_byte;
> +   u32 usb3_perf_wr_axi_total_byte;
> +   u32 usb3_perf_working_cnt;
> +   u32 reserved1[0x103];
> +   u32 usb3otg0_con0;
> +   u32 usb3otg0_con1;
> +   u32 reserved2[2];
> +   u32 usb3otg1_con0;
> +   u32 usb3otg1_con1;
> +   u32 reserved3[2];
> +   u32 usb3otg0_status_lat0;
> +   u32 usb3otg0_status_lat1;
> +   u32 usb3otg0_status_cb;
> +   u32 reserved4;
> +   u32 usb3otg1_status_lat0;
> +   u32 usb3otg1_status_lat1;
> +   u32 usb3ogt1_status_cb;
> +   u32 reserved5[0x6e5];
> +   u32 pcie_perf_con0;
> +   u32 pcie_perf_con1;
> +   u32 pcie_perf_con2;
> +   u32 pcie_perf_rd_max_latency_num;
> +   u32 pcie_perf_rd_latency_samp_num;
> +   u32 pcie_perf_rd_laterncy_acc_num;
> +   u32 pcie_perf_rd_axi_total_byte;
> +   u32 pcie_perf_wr_axi_total_byte;
> +   u32 pcie_perf_working_cnt;
> +   u32 reserved6[0x37];
> +   u32 usb20_host0_con0;
> +   u32 usb20_host0_con1;
> +   u32 reserved7[2];
> +   u32 usb20_host1_con0;
> +   u32 usb20_host1_con1;
> +   u32 reserved8[2];
> +   u32 hsic_con0;
> +   u32 hsic_con1;
> +   u32 reserved9[6];
> +   u32 grf_usbhost0_status;
> +   u32 grf_usbhost1_Status;
> +   u32 grf_hsic_status;
> +   u32 reserved10[0xc9];
> +   u32 hsicphy_con0;
> +   u32 reserved11[3];
> +   u32 usbphy0_ctrl[26];
> +   u32 reserved12[6];
> +   u32 usbphy1[26];
> +   u32 reserved13[0x72f];
> +   u32 soc_con9;
> +   u32 reserved14[0x0a];
> +   u32 soc_con20;
> +   u32 soc_con21;
> +   u32 soc_con22;
> +   u32 soc_con23;
> +   u32 soc_con24;
> +   u32 soc_con25;
> +   u32 soc_con26;
> +   u32 reserved15[0xf65];
> +   u32 cpu_con[4];
> +   u32 reserved16[0x1c];
> +   u32 cpu_status[6];
> +   u32 reserved17[0x1a];
> +   u32 a53_perf_con[4];
> +   u32 a53_perf_rd_mon_st;
> +   u32 a53_perf_rd_mon_end;
> +   u32 a53_perf_wr_mon_st;
> +   u32 a53_perf_wr_mon_end;
> +   u32 a53_perf_rd_max_latency_num;
> +   u32 a53_perf_rd_latency_samp_num;
> +   u32 a53_perf_rd_laterncy_acc_num;
> +   u32 a53_perf_rd_axi_total_byte;
> +   u32 a53_perf_wr_axi_total_byte;
> +   u32 a53_perf_working_cnt;
> +   u32 a53_perf_int_status;
> +   u32 reserved18[0x31];
> +   u32 a72_perf_con[4];
> +   u32 a72_perf_rd_mon_st;
> +   u32 a72_perf_rd_mon_end;
> +   u32 a72_perf_wr_mon_st;
> +   u32 a72_perf_wr_mon_end;
> +   u32 a72_perf_rd_max_latency_num;
> +   u32 a72_perf_rd_latency_samp_num;
> +   u32 a72_perf_rd_laterncy_acc_num;
> +   u32 a72_perf_rd_axi_total_byte;
> +   u32 a72_perf_wr_axi_total_byte;
> +   u32 a72_perf_working_cnt;
> +   u32 a72_perf_int_status;
> +   u32 reserved19[0x7f6];
> +   u32 soc_con5;
> +   u32 soc_con6;
> +   u32 reserved20[0x779];
> +   u32 gpio2a_iomux;
> +   union {
> +   u32 iomux_spi2;
> +   u32 gpio2b_iomux;

Can we drop these unions and just 

[U-Boot] [PATCH 1/4] ext4: change structure fields to __le/__be types

[Michael Walle]

Change all the types of ext2/4 fields to little endian types and all the
JBD fields to big endian types. Now we can use sparse (make C=1) to check
for statements where we need byteswaps.

Signed-off-by: Michael Walle 
---
 fs/ext4/ext4_journal.h |  40 +++
 include/ext_common.h   | 136 -
 2 files changed, 88 insertions(+), 88 deletions(-)

diff --git a/fs/ext4/ext4_journal.h b/fs/ext4/ext4_journal.h
index d926094..d54165c 100644
--- a/fs/ext4/ext4_journal.h
+++ b/fs/ext4/ext4_journal.h
@@ -49,9 +49,9 @@ struct dirty_blocks {
 
 /* Standard header for all descriptor blocks: */
 struct journal_header_t {
-   __u32 h_magic;
-   __u32 h_blocktype;
-   __u32 h_sequence;
+   __be32 h_magic;
+   __be32 h_blocktype;
+   __be32 h_sequence;
 };
 
 /* The journal superblock.  All fields are in big-endian byte order. */
@@ -60,35 +60,35 @@ struct journal_superblock_t {
struct journal_header_t s_header;
 
/* Static information describing the journal */
-   __u32 s_blocksize;  /* journal device blocksize */
-   __u32 s_maxlen; /* total blocks in journal file */
-   __u32 s_first;  /* first block of log information */
+   __be32 s_blocksize; /* journal device blocksize */
+   __be32 s_maxlen;/* total blocks in journal file */
+   __be32 s_first; /* first block of log information */
 
/* Dynamic information describing the current state of the log */
-   __u32 s_sequence;   /* first commit ID expected in log */
-   __u32 s_start;  /* blocknr of start of log */
+   __be32 s_sequence;  /* first commit ID expected in log */
+   __be32 s_start; /* blocknr of start of log */
 
/* Error value, as set by journal_abort(). */
-   __s32 s_errno;
+   __be32 s_errno;
 
/* Remaining fields are only valid in a version-2 superblock */
-   __u32 s_feature_compat; /* compatible feature set */
-   __u32 s_feature_incompat;   /* incompatible feature set */
-   __u32 s_feature_ro_compat;  /* readonly-compatible feature set */
+   __be32 s_feature_compat;/* compatible feature set */
+   __be32 s_feature_incompat;  /* incompatible feature set */
+   __be32 s_feature_ro_compat; /* readonly-compatible feature set */
/* 0x0030 */
__u8 s_uuid[16];/* 128-bit uuid for journal */
 
/* 0x0040 */
-   __u32 s_nr_users;   /* Nr of filesystems sharing log */
+   __be32 s_nr_users;  /* Nr of filesystems sharing log */
 
-   __u32 s_dynsuper;   /* Blocknr of dynamic superblock copy */
+   __be32 s_dynsuper;  /* Blocknr of dynamic superblock copy */
 
/* 0x0048 */
-   __u32 s_max_transaction;/* Limit of journal blocks per trans. */
-   __u32 s_max_trans_data; /* Limit of data blocks per trans. */
+   __be32 s_max_transaction;   /* Limit of journal blocks per trans. */
+   __be32 s_max_trans_data;/* Limit of data blocks per trans. */
 
/* 0x0050 */
-   __u32 s_padding[44];
+   __be32 s_padding[44];
 
/* 0x0100 */
__u8 s_users[16 * 48];  /* ids of all fs'es sharing the log */
@@ -96,13 +96,13 @@ struct journal_superblock_t {
 } ;
 
 struct ext3_journal_block_tag {
-   uint32_t block;
-   uint32_t flags;
+   __be32 block;
+   __be32 flags;
 };
 
 struct journal_revoke_header_t {
struct journal_header_t r_header;
-   int r_count;/* Count of bytes used in the block */
+   __be32 r_count; /* Count of bytes used in the block */
 };
 
 struct revoke_blk_list {
diff --git a/include/ext_common.h b/include/ext_common.h
index 6cddf16..c12e526 100644
--- a/include/ext_common.h
+++ b/include/ext_common.h
@@ -66,92 +66,92 @@
 
 /* The ext2 superblock.  */
 struct ext2_sblock {
-   uint32_t total_inodes;
-   uint32_t total_blocks;
-   uint32_t reserved_blocks;
-   uint32_t free_blocks;
-   uint32_t free_inodes;
-   uint32_t first_data_block;
-   uint32_t log2_block_size;
-   uint32_t log2_fragment_size;
-   uint32_t blocks_per_group;
-   uint32_t fragments_per_group;
-   uint32_t inodes_per_group;
-   uint32_t mtime;
-   uint32_t utime;
-   uint16_t mnt_count;
-   uint16_t max_mnt_count;
-   uint16_t magic;
-   uint16_t fs_state;
-   uint16_t error_handling;
-   uint16_t minor_revision_level;
-   uint32_t lastcheck;
-   uint32_t checkinterval;
-   uint32_t creator_os;
-   uint32_t revision_level;
-   uint16_t uid_reserved;
-   uint16_t gid_reserved;
-   uint32_t first_inode;
-   uint16_t inode_size;
-   uint16_t block_group_number;
-   uint32_t feature_compatibility;
-   uint32_t feature_incompat;
-   uint32_t feature_ro_compat;
-   uint32_t unique_id[4];
+ 

Re: [U-Boot] [PATCH] efi_loader: disk: Fix CONFIG_BLK breakage

[Alexander Graf]

On 12.08.16 19:20, Simon Glass wrote:
> Hi Alex,
> 
> On 10 August 2016 at 13:01, Alexander Graf  wrote:
>>
>>> On 10 Aug 2016, at 18:25, Tom Rini  wrote:
>>>
>>> On Wed, Aug 10, 2016 at 03:25:16PM +0200, Alexander Graf wrote:


> Am 10.08.2016 um 15:16 schrieb Simon Glass :
>
> Hi Alex,
>
>> On 10 August 2016 at 07:02, Alexander Graf  wrote:
>>> On 08/10/2016 02:56 PM, Simon Glass wrote:
>>>
>>> +Tom
>>>
>>> Hi Alex,
>>>
>>> On 10 August 2016 at 01:47, Alexander Graf  wrote:
>
> On 08 Aug 2016, at 23:44, Simon Glass  wrote:
>
> Hi Alexander,
>
>> On 5 August 2016 at 06:49, Alexander Graf  wrote:
>>
>> When using CONFIG_BLK, there were 2 issues:
>>
>> 1) The name we generate the device with has to match the
>>name we set in efi_set_bootdev()
>>
>> 2) The device we pass into our block functions was wrong,
>>we should not rediscover it but just use the already known
>>pointer.
>>
>> This patch fixes both issues.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>> cmd/bootefi.c | 23 ++-
>> lib/efi_loader/efi_disk.c | 18 +++---
>> 2 files changed, 29 insertions(+), 12 deletions(-)
>>> [...]
>>>
>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
>> index c434c92..e00a747 100644
>> --- a/lib/efi_loader/efi_disk.c
>> +++ b/lib/efi_loader/efi_disk.c
>> @@ -31,6 +31,8 @@ struct efi_disk_obj {
>>   struct efi_device_path_file_path *dp;
>>   /* Offset into disk for simple partitions */
>>   lbaint_t offset;
>> +   /* Internal block device */
>> +   const struct blk_desc *desc;
>
> Rather than storing this, can you store the udevice?

 I could, but then I would diverge between the CONFIG_BLK and
 non-CONFIG_BLK path again, which would turn the code into an #ifdef 
 mess
 (read: hard to maintain), because the whole device creation path 
 relies on
 struct blk_desc * today and doesn’t pass the udevice anywhere.

 Do you feel strongly about this? To give you an idea how messy it gets,
 the diff is below.
>>>
>>> Actually I'd like to make this feature depend on CONFIG_BLK. If we add
>>> new features that don't use driver model, and then use the legacy data
>>> structures such that converting to driver model becomes harder, we'll
>>> never be done.
>>>
>>> I did mention this at the beginning and it seems to have come to pass.
>>>
>>> In order of preference from my side:
>>>
>>> 1. Make EFI_LOADER depend on BLK
>>
>>
>> If we make EFI_LOADER depend on BLK, doesn't that break all systems that
>> need storage that isn't converted to device model today? Like the SATA
>> breakage on Xilinx systems, just at a much bigger scale?
>
> No it just means that these platforms need to move to BLK before they
> can use the EFI loader. Given the embryonic nature of this feature,
> that seems reasonable, and the impact would be small. It will also
> encourage conversion and keep the code cleaner.

 No, it will simply make my life harder because I would have to sit
 down and vonvert every single board to BLK that I need EFI enabled.
>>>
>>> Seems like as good a place as any to jump in, of the boards that you
>>> need EFI enabled on, what isn't converted today?
>>
>> I want to make EFI the default boot path in openSUSE, which means any board 
>> that anyone out there wants to run openSUSE on would be on the list. 
>> Anything that keeps them from running EFI on a random board is a road block 
>> that I’d rather not have if I can avoid it.
> 
> Of course, I fully understand that. However as mentioned in this
> patch, you are creating future problems.

I don't see how I am creating future problems, really. Passing a
udevice* instead of the struct blk_desc* internally doesn't improve the
code really at the end of the day.

> Can you address Tom's question? I take it that it boots on Raspberry
> Pi (which I'd like to try actually - are there instructions
> somewhere?). We can easily convert that over. Anything else?

For a list of currently available "upstream" openSUSE images, see
https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/pre_checkin.sh?expand=1

Every one of those is on the short-term list. Any other board that
people want to run on is potentially on the mid-term to long-term list.

> 
>>
>> Again, I strongly object any dependency on BLK for EFI. If you want to push 
>> people to 

Re: [U-Boot] Help Falcon Mode on Wanboard

[Stefano Babic]

Hi Diego,

On 12/08/2016 19:19, Diego Dorta wrote:

>>
>> It was quite a while ago, but the patch sets Falcon mode, and it tries
>> to boot the kernel. Kernel is not in filesystem, but stored at a fixed
>> address on the SD card (0x1000). The error you reported seems when
>> U-Boot is starting - by pressing 'c' or if no kernel is stored.
> 
> Hi Stefano,
> 
> When I use your falcon mode pre-built image everything works fine, but when I 
> try to replace to use the binaries I've compiled,
> the normal mode (pressing C) doesn't work and shows this error: 
> 
> U-Boot 2016.01-rc4-26067-g04df0e7-dirty (Aug 12 2016 - 10:31:08 -0300)
> 
> CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: POR
> initcall sequence 178290d4 failed at call 178038bd (err=394279101)
> ### ERROR ### Please RESET the board ###
> 
> 
> I use the following commands to copy the binaries:
> 
> $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 oflag=sync status=none && sync
> 
> $ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 oflag=sync status=none && 
> sync

This does not seem an issue when you write inot the SD card, else SPL is
not started. But SPL works as expected and load correctly u-boot.img,
that crashes.

I do not know if this makes a difference, but I check my logs and I have
seen that I built with gcc 4.9.2 (Yocto-fido). This should not be an
issue, but...

You should take a look at u-boot.map, and check the address where it
happens. 0x178290d4 should be init_sequence_f, you have to see
in which function is 178038bd to make supposition.

For example, in my original u-boot.map (that I have still found on my
PC), I see:

.text.initr_malloc
0x178038a8   0x16 common/built-in.o
 .text.initr_caches
0x178038be0xa common/built-in.o


If binary was identical, it means a failure in initr_malloc. But your
build is surely different and you have to find it.

Best regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 1/5] mmc: sd: extracting erase timeout information from sd status

[Peng Fan]

Add function to read SD_STATUS information.
According to the information, get erase_timeout/erase_size/erase_offset.
Add a structure sd_ssr to include the erase related information.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Stefan Wahren 
Cc: Clemens Gruber 
Cc: Kever Yang 
Cc: Eric Nelson 
Cc: Stephen Warren 
---

V2:
 Address Jaehoon's comments for V1.

 drivers/mmc/mmc.c | 68 +++
 include/mmc.h |  8 +++
 2 files changed, 76 insertions(+)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 3daa748..a855acf 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -21,6 +21,14 @@
 #include 
 #include "mmc_private.h"
 
+static const unsigned int sd_au_size[] = {
+   0,  SZ_16K / 512,   SZ_32K / 512,
+   SZ_64K / 512,   SZ_128K / 512,  SZ_256K / 512,
+   SZ_512K / 512,  SZ_1M / 512,SZ_2M / 512,
+   SZ_4M / 512,SZ_8M / 512,(SZ_8M + SZ_4M) / 512,
+   SZ_16M / 512,   (SZ_16M + SZ_8M) / 512, SZ_32M / 512,   SZ_64M / 512,
+};
+
 #ifndef CONFIG_DM_MMC_OPS
 __weak int board_mmc_getwp(struct mmc *mmc)
 {
@@ -942,6 +950,62 @@ retry_scr:
return 0;
 }
 
+static int sd_read_ssr(struct mmc *mmc)
+{
+   int err, i;
+   struct mmc_cmd cmd;
+   ALLOC_CACHE_ALIGN_BUFFER(uint, ssr, 16);
+   struct mmc_data data;
+   int timeout = 3;
+   unsigned int au, eo, et, es;
+
+   cmd.cmdidx = MMC_CMD_APP_CMD;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = mmc->rca << 16;
+
+   err = mmc_send_cmd(mmc, , NULL);
+   if (err)
+   return err;
+
+   cmd.cmdidx = SD_CMD_APP_SD_STATUS;
+   cmd.resp_type = MMC_RSP_R1;
+   cmd.cmdarg = 0;
+
+retry_ssr:
+   data.dest = (char *)ssr;
+   data.blocksize = 64;
+   data.blocks = 1;
+   data.flags = MMC_DATA_READ;
+
+   err = mmc_send_cmd(mmc, , );
+   if (err) {
+   if (timeout--)
+   goto retry_ssr;
+
+   return err;
+   }
+
+   for (i = 0; i < 16; i++)
+   ssr[i] = be32_to_cpu(ssr[i]);
+
+   au = (ssr[2] >> 12) & 0xF;
+   if ((au <= 9) || (mmc->version == SD_VERSION_3)) {
+   mmc->ssr.au = sd_au_size[au];
+   es = (ssr[3] >> 24) & 0xFF;
+   es |= (ssr[2] & 0xFF) << 8;
+   et = (ssr[3] >> 18) & 0x3F;
+   if (es && et) {
+   eo = (ssr[3] >> 16) & 0x3;
+   mmc->ssr.erase_timeout = (et * 1000) / es;
+   mmc->ssr.erase_offset = eo * 1000;
+   }
+   } else {
+   debug("Invalid Allocation Unit Size.\n");
+   }
+
+   return 0;
+}
+
 /* frequency bases */
 /* divided by 10 to be nice to platforms without floating point */
 static const int fbase[] = {
@@ -1347,6 +1411,10 @@ static int mmc_startup(struct mmc *mmc)
mmc_set_bus_width(mmc, 4);
}
 
+   err = sd_read_ssr(mmc);
+   if (err)
+   return err;
+
if (mmc->card_caps & MMC_MODE_HS)
mmc->tran_speed = 5000;
else
diff --git a/include/mmc.h b/include/mmc.h
index aa6d5d1..af2595c 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -102,6 +102,7 @@
 #define SD_CMD_SWITCH_UHS18V   11
 
 #define SD_CMD_APP_SET_BUS_WIDTH   6
+#define SD_CMD_APP_SD_STATUS   13
 #define SD_CMD_ERASE_WR_BLK_START  32
 #define SD_CMD_ERASE_WR_BLK_END33
 #define SD_CMD_APP_SEND_OP_COND41
@@ -392,6 +393,12 @@ struct mmc_config {
unsigned char part_type;
 };
 
+struct sd_ssr {
+   unsigned int au;/* In sectors */
+   unsigned int erase_timeout; /* In milliseconds */
+   unsigned int erase_offset;  /* In milliseconds */
+};
+
 /*
  * With CONFIG_DM_MMC enabled, struct mmc can be accessed from the MMC device
  * with mmc_get_mmc_dev().
@@ -426,6 +433,7 @@ struct mmc {
uint write_bl_len;
uint erase_grp_size;/* in 512-byte sectors */
uint hc_wp_grp_size;/* in 512-byte sectors */
+   struct sd_ssr   ssr;/* SD status register */
u64 capacity;
u64 capacity_user;
u64 capacity_boot;
-- 
2.6.2

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

[U-Boot] [PATCH v3 3/3] Kconfig: DISTRO_DEFAULTS: Only enable CMD_BOOTZ for ARM

[Tom Rini]

The 'bootz' command is really only for ARM32 Linux Kernel 'zImage' files
but has also been adapted for testing with sandbox.  Given that sandbox
is a test platform, don't add that logic under DISTRO_DEFAULTS.

Cc: Hans de Goede 
Signed-off-by: Tom Rini 
---
Changes in v3:
- New patch
---
 Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 0bc06d859f75..423b877a6eaa 100644
--- a/Kconfig
+++ b/Kconfig
@@ -57,7 +57,7 @@ config DISTRO_DEFAULTS
bool "Select defaults suitable for booting general purpose Linux 
distributions"
default y if ARCH_SUNXI
default n
-   select CMD_BOOTZ
+   select CMD_BOOTZ if ARM && !ARM64
select CMD_BOOTI if ARM64
select CMD_DHCP
select CMD_EXT2
-- 
1.9.1

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

[U-Boot] [PATCH V2 3/5] mmc: sd: add erase timeout support

[Peng Fan]

Add timeout in mmc_cmd, we can use this in driver code.
Add mmc_sd_erase_timeout, this function is modified from linux kernel.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Stefan Wahren 
Cc: Clemens Gruber 
Cc: Kever Yang 
Cc: Eric Nelson 
Cc: Stephen Warren 
---
 drivers/mmc/mmc_write.c | 29 +
 include/mmc.h   |  1 +
 2 files changed, 30 insertions(+)

diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 4149f4a..3589f8e 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -15,6 +15,33 @@
 #include 
 #include "mmc_private.h"
 
+/*
+ * Modified from from Linux kernel mmc_sd_erase_timeout.
+ */
+static unsigned int mmc_sd_erase_timeout(struct mmc *mmc,
+unsigned int nr)
+{
+   unsigned int erase_timeout;
+
+   if (mmc->ssr.erase_timeout) {
+   /* Erase timeout specified in SD Status Register (SSR) */
+   erase_timeout = mmc->ssr.erase_timeout * nr +
+   mmc->ssr.erase_offset;
+   } else {
+   /*
+* Erase timeout not specified in SD Status Register (SSR) so
+* use 250ms per write block.
+*/
+   erase_timeout = 250 * nr;
+   }
+
+   /* Must not be less than 1 second */
+   if (erase_timeout < 1000)
+   erase_timeout = 1000;
+
+   return erase_timeout;
+}
+
 static ulong mmc_erase_t(struct mmc *mmc, ulong start, lbaint_t blkcnt)
 {
struct mmc_cmd cmd = {0};
@@ -54,6 +81,8 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start, 
lbaint_t blkcnt)
cmd.cmdidx = MMC_CMD_ERASE;
cmd.cmdarg = MMC_ERASE_ARG;
cmd.resp_type = MMC_RSP_R1b;
+   if (IS_SD(mmc))
+   cmd.timeout = mmc_sd_erase_timeout(mmc, blkcnt);
 
err = mmc_send_cmd(mmc, , NULL);
if (err)
diff --git a/include/mmc.h b/include/mmc.h
index af2595c..432e6ee 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -303,6 +303,7 @@ struct mmc_cmd {
uint resp_type;
uint cmdarg;
uint response[4];
+   int timeout;
 };
 
 struct mmc_data {
-- 
2.6.2

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

Re: [U-Boot] [PATCH v2] serial: bcm283x_mu: Detect disabled serial device

[Simon Glass]

Hi Alex,

On 11 August 2016 at 23:27, Alexander Graf  wrote:
>
>
>> Am 12.08.2016 um 00:38 schrieb Simon Glass :
>>
>> Hi Alex,
>>
>>> On 11 August 2016 at 05:33, Alexander Graf  wrote:
>>>
>>>
 On 09.08.16 06:28, Stephen Warren wrote:
> On 08/04/2016 05:15 PM, Alexander Graf wrote:
>
>> On 04 Aug 2016, at 20:11, Stephen Warren  wrote:
>>
>> On 08/04/2016 01:11 AM, Alexander Graf wrote:
>>> On the raspberry pi, you can disable the serial port to gain dynamic
>>> frequency
>>> scaling which can get handy at times.
>>>
>>> However, in such a configuration the serial controller gets its rx
>>> queue filled
>>> up with zero bytes which then happily get transmitted on to whoever
>>> calls
>>> getc() today.
>>>
>>> This patch adds detection logic for that case by checking whether
>>> the RX pin is
>>> mapped to GPIO15 and disables the mini uart if it is not mapped
>>> properly.
>>>
>>> That way we can leave the driver enabled in the tree and can
>>> determine during
>>> runtime whether serial is usable or not, having a single binary that
>>> allows for
>>> uart and non-uart operation.
>>
>>> diff --git a/drivers/serial/serial_bcm283x_mu.c
>>> b/drivers/serial/serial_bcm283x_mu.c
>>
>>> @@ -72,9 +87,18 @@ static int bcm283x_mu_serial_probe(struct udevice
>>> *dev)
>>> {
>>>struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
>>>struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>>> +struct bcm283x_gpio_regs *gpio = (struct bcm283x_gpio_regs
>>> *)plat->gpio;
>>>
>>>priv->regs = (struct bcm283x_mu_regs *)plat->base;
>>>
>>> +/*
>>> + * The RPi3 disables the mini uart by default. The easiest way
>>> to find
>>> + * out whether it is available is to check if the pin is muxed.
>>> + */
>>> +if (((readl(>gpfsel1) >> BCM283X_GPIO_GPFSEL1_F15_SHIFT) &
>>> +BCM283X_GPIO_ALTFUNC_MASK) != BCM283X_GPIO_ALTFUNC_5)
>>> +priv->disabled = true;
>>> +
>>>return 0;
>>
>> Comment on the current implementation: Can't probe() return an error
>> if the device should be disabled? That would avoid the need to check
>> priv->disabled in all the other functions.
>
> I guess I should’ve put that in a comment somewhere. Unfortunately we
> can’t. If I just return an error on probe, U-Boot will panic because
> we tell it in a CONFIG define that we require a serial port (grep for
> CONFIG_REQUIRE_SERIAL_CONSOLE).
>
> We could maybe try to unset that define instead?

 Yes, assuming that U-Boot runs just fine with HDMI console only, I think
 it's fine to unset CONFIG_REQUIRE_SERIAL_CONSOLE.

>> Overall comment: I'd rather not put this logic into the UART driver
>> itself; it is system-specific rather than device-specific. I'd also
>> rather not have the UART driver touching GPIO registers; that's not
>> very modular, and could cause problems if the Pi is converted to use
>> DT to instantiate devices.
>>
>> Instead, can we put the logic into board/raspberrypi/rpi/rpi.c? I.e.
>> have some early function come along and enable/disable the
>> bcm2837_serials device object as appropriate? That way it isolates
>> the code to the Pi specifically, and not any other bcm283x board.
>> We'd want to wrap that code in #ifdef CONFIG_PL01X_SERIAL.
>
> We can do that if we can fail at probe time. If we absolutely must
> have a serial driver to work in the first place, that doesn’t work. I
> can try to poke at it, but it’ll be a few days I think :).
>>>
>>> So I couldn't find a sane way to fail probing based on something defined
>>> in the board file, reusing the existing gpio device.
>>
>> Would it be possible to move this code into the serial driver?
>
> You mean like in v2 which Stephen nacked? :)

Yes :-(

Well you can put what you like in the board code, and if this is only
on the rpi, then it makes sense.

Really though, this is a pinctrl thing, so if there were a pinctrl
driver you could just use it. The GPIO driver should not deal with pin
muxing.

>
>>
>>>
>>> However, there's an easy alternative. We can make the console code just
>>> ignore our serial device if we set its pointer to NULL. That way we
>>> still have the device, but can contain all logic to disable usage of the
>>> mini uart to the board file.
>>
>> I'm not very keen on that - feels like a hack.  What is stopping
>> Stephen's idea from working? I could perhaps help with dm plumbing is
>> that is the issue...
>
> The problem is that we need the gpio device to determine whether the pin is 
> muxed. There is no temporal control that I could see that would allow me to 
> be in a place where the gpio device exists, the serial device does not 

Re: [U-Boot] [PATCH 3/5] rk_pwm: use clock framework API to get module clock

[Simon Glass]

Hi Kever,

On 12 August 2016 at 03:57, Kever Yang  wrote:
> This patch use clock API instead of hardcode for get pwm clock.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/pwm/rk_pwm.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)

Acked-by: Simon Glass 

nit below

>
> diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
> index 2d289a4..d69aab5 100644
> --- a/drivers/pwm/rk_pwm.c
> +++ b/drivers/pwm/rk_pwm.c
> @@ -6,6 +6,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -13,9 +14,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -23,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  struct rk_pwm_priv {
> struct rk3288_pwm *regs;
> struct rk3288_grf *grf;
> +   ulong freq;
>  };
>
>  static int rk_pwm_set_config(struct udevice *dev, uint channel, uint 
> period_ns,
> @@ -38,8 +40,8 @@ static int rk_pwm_set_config(struct udevice *dev, uint 
> channel, uint period_ns,
> RK_PWM_DISABLE,
> >ctrl);
>
> -   period = lldiv((uint64_t)(PD_BUS_PCLK_HZ / 1000) * period_ns, 
> 100);
> -   duty = lldiv((uint64_t)(PD_BUS_PCLK_HZ / 1000) * duty_ns, 100);
> +   period = lldiv((uint64_t)(priv->freq / 1000) * period_ns, 100);
> +   duty = lldiv((uint64_t)(priv->freq / 1000) * duty_ns, 100);
>
> writel(period, >period_hpr);
> writel(duty, >duty_lpr);
> @@ -76,9 +78,18 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
>  static int rk_pwm_probe(struct udevice *dev)
>  {
> struct rk_pwm_priv *priv = dev_get_priv(dev);
> +   struct clk clk;
> +   int ret = 0;
>
> rk_setreg(>grf->soc_con2, 1 << 0);
>
> +   ret = clk_get_by_index(dev, 0, );
> +   if (ret < 0) {
> +   printf("%s get clock fail!\n", __func__);

debug() please.

> +   return -EINVAL;
> +   }
> +   priv->freq = clk_get_rate();
> +
> return 0;
>  }
>
> --
> 1.9.1
>
>

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

Re: [U-Boot] [PATCH 4/5] rk_pwm: remove grf setting code from driver

[Simon Glass]

On 12 August 2016 at 03:58, Kever Yang  wrote:
> We consider the grf setting for pwm controller select as the system
> operation instead of driver operation, move it to soc init, let's
> remove it from pwm driver first.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/pwm/rk_pwm.c | 11 ---
>  1 file changed, 11 deletions(-)

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

Re: [U-Boot] [PATCH 1/5] clk: rk3399: add pmucru controller support

[Simon Glass]

On 12 August 2016 at 03:47, Kever Yang  wrote:
> pmucru is a module like cru which is a clock controller manage some PLL
> and module clocks.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/clk/rockchip/clk_rk3399.c | 177 
> +-
>  1 file changed, 173 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH V2] mmc: mmc_legacy: fix the compiler error with disabled CONFIG_DM_MMC_OPS

[Simon Glass]

On 11 August 2016 at 20:39, Jaehoon Chung  wrote:
> To prevent the compiler error, split the checking condition whether
> cfg->ops is NULL or not.
> It's more clearly, because it's not included in mmc_config structure
> when CONFIG_DM_MMC_OPS is disabled.
>
> drivers/mmc/mmc_legacy.c: In function ‘mmc_create’:
> drivers/mmc/mmc_legacy.c:118:31: error: ‘const struct mmc_config’ has no 
> member named ‘ops’
> drivers/mmc/mmc_legacy.c:118:58: error: ‘const struct mmc_config’ has no 
> member named ‘ops’
> make[1]: *** [drivers/mmc/mmc_legacy.o] Error 1
>
> Signed-off-by: Jaehoon Chung 
> ---
> Changes for V2:
> - Fixed the wrong condition checking
>
>  drivers/mmc/mmc_legacy.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

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

Re: [U-Boot] [PATCH 5/5] dts: rk3399: add pinctrl for sdmmc

[Simon Glass]

On 11 August 2016 at 19:48, Kever Yang  wrote:
> This patch add pinctrl for sdcard which may not be initialized before
> uboot.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/dts/rk3399.dtsi | 37 +
>  1 file changed, 37 insertions(+)

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

Re: [U-Boot] [PATCH 5/7] smbios: Expose in efi_loader as table

[Simon Glass]

Hi Alex,

On 8 August 2016 at 08:06, Alexander Graf  wrote:
> We can pass SMBIOS easily as EFI configuration table to an EFI payload. This
> patch adds enablement for that case.
>
> While at it, we also enable SMBIOS generation for ARM systems, since they 
> support
> EFI_LOADER.
>
> Signed-off-by: Alexander Graf 
> ---
>  cmd/bootefi.c|  3 +++
>  include/efi_api.h|  4 
>  include/efi_loader.h |  2 ++
>  include/smbios.h |  1 +
>  lib/Kconfig  |  4 ++--
>  lib/smbios.c | 36 
>  6 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 53a6ee3..e241b7d 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -205,6 +205,9 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
> if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
> loaded_image_info.device_handle = nethandle;
>  #endif
> +#ifdef CONFIG_GENERATE_SMBIOS_TABLE
> +   efi_smbios_register();
> +#endif
>
> /* Initialize EFI runtime services */
> efi_reset_system_init();
> diff --git a/include/efi_api.h b/include/efi_api.h
> index f572b88..bdb600e 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -201,6 +201,10 @@ struct efi_runtime_services {
> EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \
>  0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)
>
> +#define SMBIOS_TABLE_GUID \
> +   EFI_GUID(0xeb9d2d31, 0x2d88, 0x11d3,  \
> +0x9a, 0x16, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
> +
>  struct efi_configuration_table
>  {
> efi_guid_t guid;
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index ac8b77a..b0e8a7f 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -85,6 +85,8 @@ int efi_disk_register(void);
>  int efi_gop_register(void);
>  /* Called by bootefi to make the network interface available */
>  int efi_net_register(void **handle);
> +/* Called by bootefi to make SMBIOS tables available */
> +void efi_smbios_register(void);
>
>  /* Called by networking code to memorize the dhcp ack package */
>  void efi_net_set_dhcp_ack(void *pkt, int len);
> diff --git a/include/smbios.h b/include/smbios.h
> index 5962d4c..fb6396a 100644
> --- a/include/smbios.h
> +++ b/include/smbios.h
> @@ -55,6 +55,7 @@ struct __packed smbios_entry {
>  #define BIOS_CHARACTERISTICS_SELECTABLE_BOOT   (1 << 16)
>
>  #define BIOS_CHARACTERISTICS_EXT1_ACPI (1 << 0)
> +#define BIOS_CHARACTERISTICS_EXT1_UEFI (1 << 3)
>  #define BIOS_CHARACTERISTICS_EXT2_TARGET   (1 << 2)
>
>  struct __packed smbios_type0 {
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 5a14530..d7f75fe 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -150,12 +150,12 @@ config SPL_OF_LIBFDT
>   version of the device tree.
>
>  menu "System tables"
> -   depends on !EFI && !SYS_COREBOOT
> +   depends on (!EFI && !SYS_COREBOOT) || (ARM && EFI_LOADER)
>
>  config GENERATE_SMBIOS_TABLE
> bool "Generate an SMBIOS (System Management BIOS) table"
> default y
> -   depends on X86
> +   depends on X86 || EFI_LOADER
> help
>   The System Management BIOS (SMBIOS) specification addresses how
>   motherboard and system vendors present management information about
> diff --git a/lib/smbios.c b/lib/smbios.c
> index 8dfd486..b9aa741 100644
> --- a/lib/smbios.c
> +++ b/lib/smbios.c
> @@ -7,10 +7,13 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_X86
>  #include 
> +#endif
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -79,14 +82,20 @@ static int smbios_write_type0(uintptr_t *current, int 
> handle)
> t->vendor = smbios_add_string(t->eos, "U-Boot");
> t->bios_ver = smbios_add_string(t->eos, PLAIN_VERSION);
> t->bios_release_date = smbios_add_string(t->eos, U_BOOT_DMI_DATE);
> +#ifdef CONFIG_ROM_SIZE
> t->bios_rom_size = (CONFIG_ROM_SIZE / 65536) - 1;
> +#endif
> t->bios_characteristics = BIOS_CHARACTERISTICS_PCI_SUPPORTED |
>   BIOS_CHARACTERISTICS_SELECTABLE_BOOT |
>   BIOS_CHARACTERISTICS_UPGRADEABLE;
>  #ifdef CONFIG_GENERATE_ACPI_TABLE
> t->bios_characteristics_ext1 = BIOS_CHARACTERISTICS_EXT1_ACPI;
>  #endif
> +#ifdef CONFIG_EFI_LOADER
> +   t->bios_characteristics_ext1 |= BIOS_CHARACTERISTICS_EXT1_UEFI;
> +#endif
> t->bios_characteristics_ext2 = BIOS_CHARACTERISTICS_EXT2_TARGET;
> +
> t->bios_major_release = 0xff;
> t->bios_minor_release = 0xff;
> t->ec_major_release = 0xff;
> @@ -152,6 +161,7 @@ static int smbios_write_type3(uintptr_t *current, int 
> handle)
> return len;
>  }
>
> +#ifdef CONFIG_X86
>  static int smbios_write_type4(uintptr_t *current, int handle)
>  {
> struct smbios_type4 *t = (struct smbios_type4 *)*current;
> @@ -184,6 +194,7 @@ static int 

Re: [U-Boot] [PATCH 20/21] dm: mmc: intialize dev when probe

[Simon Glass]

On 11 August 2016 at 00:02, Peng Fan  wrote:
> Need to initialize mmc->dev when probe, or will met
> "dev_get_uclass_priv: null device", when `mmc dev 1`.
>
> Signed-off-by: Peng Fan 
> Cc: Stefano Babic 
> Cc: Simon Glass 
> Cc: Jaehoon Chung 
> ---
>  drivers/mmc/fsl_esdhc.c | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH] rockchip: rk3288-firefly: enable boot from eMMC

[Simon Glass]

On 9 August 2016 at 19:56, Jacob Chen  wrote:
> Add eMMC dt node and define fallback boot devices.
>
> Signed-off-by: Jacob Chen 
> ---
>
>  arch/arm/dts/rk3288-firefly.dts   | 5 +
>  board/firefly/firefly-rk3288/firefly-rk3288.c | 8 
>  2 files changed, 13 insertions(+)

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

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi,

This include a prerequisite for a forthcoming Tegra pull request.


The following changes since commit 28cd88baa3f11cdb52be3b6d0610dcf32c60871a:

  Merge branch 'master' of git://git.denx.de/u-boot-uniphier
(2016-08-11 10:45:53 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to b647f55420310beb8f576e23f3b6a69745126f71:

  misc: add "call" uclass op (2016-08-12 11:01:22 -0600)


John Keeping (2):
  power: regulator: act8846: fix reading values
  power: pmic: act8846: add missing newline to debug statements

Stephen Warren (3):
  fdt_support: fdt_translate_address() blob const correctness
  fdt: allow fdtdec_get_addr_size_*() to translate addresses
  misc: add "call" uclass op

 common/fdt_support.c  | 21 +++--
 drivers/core/device.c |  2 +-
 drivers/gpio/mpc85xx_gpio.c   |  2 +-
 drivers/i2c/fsl_i2c.c |  2 +-
 drivers/misc/misc-uclass.c| 11 +++
 drivers/mmc/msm_sdhci.c   |  3 ++-
 drivers/net/cpsw.c|  3 ++-
 drivers/power/pmic/act8846.c  |  4 ++--
 drivers/power/regulator/act8846.c |  4 ++--
 drivers/spmi/spmi-msm.c   |  5 +++--
 include/fdt_support.h |  5 +++--
 include/fdtdec.h  | 14 +++---
 include/misc.h| 35 +++
 lib/fdtdec.c  | 22 +++---
 14 files changed, 100 insertions(+), 33 deletions(-)


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

Re: [U-Boot] [PATCH 1/2] power: regulator: act8846: fix reading values

[Simon Glass]

On 8 August 2016 at 15:44, Simon Glass  wrote:
> On 7 August 2016 at 05:55, John Keeping  wrote:
>> The voltage and control registers need to be looked up from the value in
>> driver_data.  Adjust the get_value and get_enable functions to match the
>> corresponding set_* functions.
>>
>> Signed-off-by: John Keeping 
>> ---
>>
>>  drivers/power/regulator/act8846.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2 V4] misc: add "call" uclass op

[Simon Glass]

On 8 August 2016 at 13:47, Simon Glass  wrote:
> +Tom
>
> Hi Stephen,
>
> On 8 August 2016 at 10:41, Stephen Warren  wrote:
>> On 08/08/2016 10:38 AM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 8 August 2016 at 09:41, Stephen Warren  wrote:


 From: Stephen Warren 

 The call op requests that the callee pass a message to the underlying HW
 or device, wait for a response, and then pass back the response error
 code
 and message to the callee. It is useful for drivers that represent some
 kind of messaging or IPC channel to a remote device.

 Signed-off-by: Stephen Warren 
 Acked-by: Simon Glass 
 ---
 v4: Adjust misc_call() to return the response msg size on success.
 v3: New patch.
 ---
  drivers/misc/misc-uclass.c | 11 +++
  include/misc.h | 35 +++
  2 files changed, 46 insertions(+)
>>>
>>>
>>> Are you planning for the Tegra186 stuff to go into the upcoming release?
>>
>>
>> I'd like it to if at all possible; it's all pretty much Tegra-specific
>> drivers so shouldn't cause any fallout for other platforms. The only
>> exception is the fdt_translate_address() changes, which are a dependency,
>> which will be built into other platforms, but there's a simple Boolean
>> parameter that controls the new behaviour, so it should be pretty safe.
>
> OK, sounds reasonable to me. I'll pick these up later in the week and
> send a pull request. Can you bring any other dependencies in via
> Tegra?
>
> Regards,
> Simon

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] power: pmic: act8846: add missing newline to debug statements

[Simon Glass]

On 8 August 2016 at 15:44, Simon Glass  wrote:
> On 7 August 2016 at 05:55, John Keeping  wrote:
>> Signed-off-by: John Keeping 
>> ---
>>
>>  drivers/power/pmic/act8846.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Acked-by: Simon Glass 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2 V4] misc: add "call" uclass op

[Simon Glass]

Hi Stephen,

On 11 August 2016 at 16:17, Stephen Warren  wrote:
> On 08/08/2016 02:33 PM, Tom Warren wrote:
>>
>> Simon,
>>
>>> -Original Message-
>>> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
>>> Sent: Monday, August 08, 2016 12:54 PM
>>> To: Simon Glass 
>>> Cc: U-Boot Mailing List ; Tom Warren
>>> ; Stephen Warren ; Tom Rini
>>> 
>>> Subject: Re: [PATCH 1/2 V4] misc: add "call" uclass op
>>>
>>> On 08/08/2016 01:47 PM, Simon Glass wrote:

 +Tom

 Hi Stephen,

 On 8 August 2016 at 10:41, Stephen Warren 
>>>
>>> wrote:
>
> On 08/08/2016 10:38 AM, Simon Glass wrote:
>>
>>
>> Hi Stephen,
>>
>> On 8 August 2016 at 09:41, Stephen Warren 
>>>
>>> wrote:
>>>
>>>
>>>
>>> From: Stephen Warren 
>>>
>>> The call op requests that the callee pass a message to the
>>> underlying HW or device, wait for a response, and then pass back
>>> the response error code and message to the callee. It is useful for
>>> drivers that represent some kind of messaging or IPC channel to a
>>> remote device.
>>>
>>> Signed-off-by: Stephen Warren 
>>> Acked-by: Simon Glass 
>>> ---
>>> v4: Adjust misc_call() to return the response msg size on success.
>>> v3: New patch.
>>> ---
>>>  drivers/misc/misc-uclass.c | 11 +++
>>>  include/misc.h | 35 +++
>>>  2 files changed, 46 insertions(+)
>>
>>
>>
>> Are you planning for the Tegra186 stuff to go into the upcoming
>> release?
>
>
>
> I'd like it to if at all possible; it's all pretty much
> Tegra-specific drivers so shouldn't cause any fallout for other
> platforms. The only exception is the fdt_translate_address() changes,
> which are a dependency, which will be built into other platforms, but
> there's a simple Boolean parameter that controls the new behaviour, so
> it
>>>
>>> should be pretty safe.


 OK, sounds reasonable to me. I'll pick these up later in the week and
 send a pull request. Can you bring any other dependencies in via
 Tegra?
>>>
>>>
>>> Yes, I was assuming that TomW would take everything else; it's all Tegra
>>> drivers.
>
>>
>>
>> Stephen and I are working together to get it all packaged up and in to
>> u-boot-tegra ASAP.
>
>
> Simon, any word on the u-boot-dm pull request? TomW is waiting for it before
> applying all the Tegra commits on top of it so he won't have to rebase, and
> he'd probably best send a Tegra pull request on Friday in order to make
> -rc2, which would be good to do. Thanks.

Yes, I'm testing u-boot-dm/testing and will send it if all is well.

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

Re: [U-Boot] CACHE: Misaligned operation

[Simon Glass]

Hi,

On 12 August 2016 at 08:13, Clemens Gruber  wrote:
> Hi,
>
> I just tested the current U-Boot master on my i.MX6Q board and the
> following two warnings showed up on the console:
>
> U-Boot 2016.09-rc1-00377-gb8698a2
>
> CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
> Reset cause: POR
> DRAM:  1 GiB
> CACHE: Misaligned operation at range [4fff, 4fff0004]
> CACHE: Misaligned operation at range [4fff0024, 4fff0028]
>
> (But everything works fine, as far as I can tell for now)
>
> I did a git bisect and found out that these two warning messages are
> shown since commit 96e451bfa39b (arm: Show cache warnings in U-Boot
> proper only), where a debug statement was changed to a non-SPL warning.
>
> Was this intentional and is this warning something to be worried about?

Yes it means there is an error in the calling code. If you can figure
out who is calling this then it is worth fixing. But also see recent
discussions on the mailing list. Also possibly this patch?

http://patchwork.ozlabs.org/patch/656474/

>
> If not, we could add a new macro debug_non_spl with debug_cond
> !_SPL_BUILD && DEBUG and use that in check_cache_range.
>
> What do you think?

I'd rather fix the bugs :-)

>
> Thanks,
> Clemens

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

[U-Boot] CACHE: Misaligned operation

[Clemens Gruber]

Hi,

I just tested the current U-Boot master on my i.MX6Q board and the
following two warnings showed up on the console:

U-Boot 2016.09-rc1-00377-gb8698a2

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
Reset cause: POR
DRAM:  1 GiB
CACHE: Misaligned operation at range [4fff, 4fff0004]
CACHE: Misaligned operation at range [4fff0024, 4fff0028]

(But everything works fine, as far as I can tell for now)

I did a git bisect and found out that these two warning messages are
shown since commit 96e451bfa39b (arm: Show cache warnings in U-Boot
proper only), where a debug statement was changed to a non-SPL warning.

Was this intentional and is this warning something to be worried about?

If not, we could add a new macro debug_non_spl with debug_cond
!_SPL_BUILD && DEBUG and use that in check_cache_range.

What do you think? 

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

[U-Boot] [PATCH 2/4] ext4: use kernel names for byte swaps

[Michael Walle]

Instead of __{be,le}{16,32}_to_cpu use {be,le}{16,32}_to_cpu.

Signed-off-by: Michael Walle 
---
 fs/ext4/ext4_common.c | 90 +--
 fs/ext4/ext4_write.c  | 14 
 fs/ext4/ext4fs.c  |  2 +-
 include/ext_common.h  |  4 +--
 4 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index eb49fce..e8ed30a 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -1454,7 +1454,7 @@ static int ext4fs_blockgroup
 
desc_per_blk = EXT2_BLOCK_SIZE(data) / sizeof(struct ext2_block_group);
 
-   blkno = __le32_to_cpu(data->sblock.first_data_block) + 1 +
+   blkno = le32_to_cpu(data->sblock.first_data_block) + 1 +
group / desc_per_blk;
blkoff = (group % desc_per_blk) * sizeof(struct ext2_block_group);
 
@@ -1479,14 +1479,14 @@ int ext4fs_read_inode(struct ext2_data *data, int ino, 
struct ext2_inode *inode)
 
/* It is easier to calculate if the first inode is 0. */
ino--;
-   status = ext4fs_blockgroup(data, ino / __le32_to_cpu
+   status = ext4fs_blockgroup(data, ino / le32_to_cpu
   (sblock->inodes_per_group), );
if (status == 0)
return 0;
 
inodes_per_block = EXT2_BLOCK_SIZE(data) / fs->inodesz;
-   blkno = __le32_to_cpu(blkgrp.inode_table_id) +
-   (ino % __le32_to_cpu(sblock->inodes_per_group)) / inodes_per_block;
+   blkno = le32_to_cpu(blkgrp.inode_table_id) +
+   (ino % le32_to_cpu(sblock->inodes_per_group)) / inodes_per_block;
blkoff = (ino % inodes_per_block) * fs->inodesz;
/* Read the inode. */
status = ext4fs_devread((lbaint_t)blkno << (LOG2_BLOCK_SIZE(data) -
@@ -1559,7 +1559,7 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
 
/* Direct blocks. */
if (fileblock < INDIRECT_BLOCKS)
-   blknr = __le32_to_cpu(inode->b.blocks.dir_blocks[fileblock]);
+   blknr = le32_to_cpu(inode->b.blocks.dir_blocks[fileblock]);
 
/* Indirect. */
else if (fileblock < (INDIRECT_BLOCKS + (blksz / 4))) {
@@ -1586,10 +1586,10 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
}
ext4fs_indir1_size = blksz;
}
-   if ((__le32_to_cpu(inode->b.blocks.indir_block) <<
+   if ((le32_to_cpu(inode->b.blocks.indir_block) <<
 log2_blksz) != ext4fs_indir1_blkno) {
status =
-   ext4fs_devread((lbaint_t)__le32_to_cpu
+   ext4fs_devread((lbaint_t)le32_to_cpu
   (inode->b.blocks.
indir_block) << log2_blksz, 0,
   blksz, (char *)ext4fs_indir1_block);
@@ -1599,10 +1599,10 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
return 0;
}
ext4fs_indir1_blkno =
-   __le32_to_cpu(inode->b.blocks.
+   le32_to_cpu(inode->b.blocks.
   indir_block) << log2_blksz;
}
-   blknr = __le32_to_cpu(ext4fs_indir1_block
+   blknr = le32_to_cpu(ext4fs_indir1_block
  [fileblock - INDIRECT_BLOCKS]);
}
/* Double indirect. */
@@ -1635,10 +1635,10 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
}
ext4fs_indir1_size = blksz;
}
-   if ((__le32_to_cpu(inode->b.blocks.double_indir_block) <<
+   if ((le32_to_cpu(inode->b.blocks.double_indir_block) <<
 log2_blksz) != ext4fs_indir1_blkno) {
status =
-   ext4fs_devread((lbaint_t)__le32_to_cpu
+   ext4fs_devread((lbaint_t)le32_to_cpu
   (inode->b.blocks.
double_indir_block) << log2_blksz,
   0, blksz,
@@ -1649,7 +1649,7 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
return -1;
}
ext4fs_indir1_blkno =
-   __le32_to_cpu(inode->b.blocks.double_indir_block) <<
+   le32_to_cpu(inode->b.blocks.double_indir_block) <<
log2_blksz;
}
 
@@ -1676,9 +1676,9 @@ long int read_allocated_block(struct ext2_inode *inode, 
int fileblock)
}
ext4fs_indir2_size = blksz;
  

[U-Boot] [PATCH 4/4] ext4: fix wrong usage of le32_to_cpu()

[Michael Walle]

le32_to_cpu() must only convert the revision_level and not the boolean
result.

Signed-off-by: Michael Walle 
---
 fs/ext4/ext4_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 4eb4e18..b00b84f 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -2251,7 +2251,7 @@ int ext4fs_mount(unsigned part_length)
goto fail;
}
 
-   if (le32_to_cpu(data->sblock.revision_level == 0))
+   if (le32_to_cpu(data->sblock.revision_level) == 0)
fs->inodesz = 128;
else
fs->inodesz = le16_to_cpu(data->sblock.inode_size);
-- 
2.1.4

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

Re: [U-Boot] [PATCH] Please pull u-boot-mmc

[Andreas Bießmann]

On 2016-08-12 14:48, Tom Rini wrote:

On Fri, Aug 12, 2016 at 02:40:12PM +0200, andr...@biessmann.de wrote:

On 2016-08-12 14:04, Tom Rini wrote:
>On Fri, Aug 12, 2016 at 04:34:01PM +0900, Jaehoon Chung wrote:
>
>>Dear Tom,
>>
>>Here is the mmc updates.
>>- Supports the Driver model for atmel_sdhci.
>>- Fixed the build error for omap_hsmmc.
>>
>>Could you pull these patch to u-boot/master?
>>
>>Best Regards,
>>Jaehoon Chung
>>
>>The following changes since commit
>>28cd88baa3f11cdb52be3b6d0610dcf32c60871a:
>>
>>  Merge branch 'master' of git://git.denx.de/u-boot-uniphier
>>(2016-08-11 10:45:53 -0400)
>>
>>are available in the git repository at:
>>
>>
>>  http://git.denx.de/u-boot-mmc.git master
>>
>>for you to fetch changes up to
>>761326b33f1a14b19c0a4f7e8c336f8ed153d00c:
>>
>>  defconfig: k2g_evm_defconfig: Enable mmc driver model
>>(2016-08-12 16:23:07 +0900)
>>
>>
>>Sekhar Nori (4):
>>  drivers: mmc: omap_hsmmc: fix build breakage
>>  ARM: dts: K2G: Add support for MMC controller
>>  ARM: dts: k2g-evm: enable mmc/sd suppport
>>  defconfig: k2g_evm_defconfig: Enable mmc driver model
>>
>>Wenyou Yang (1):
>>  mmc: atmel_sdhci: Convert to the driver model support
>
>NAK.  This atmel change, like the all of the others in their
>series need
>to come in via Andreas' tree as it's introducing a warning due to some
>other patch being required:
>+   sama5d2_xplained_spiflash
>+(sama5d2_xplained_spiflash)  static int clk_get_by_name(struct
>udevice *dev, const char *name,
>+(sama5d2_xplained_spiflash) ^
>w+(sama5d2_xplained_spiflash) In file included from
>drivers/mmc/atmel_sdhci.c:9:0:
>w+(sama5d2_xplained_spiflash) include/clk.h:107:12: warning:
>'clk_get_by_name' defined but not used [-Wunused-function]

Sorry, I had no time to prepare a pull request early enough for rc1.
I'll have a look for outstanding patches next few days and could
also grab this one.


Thanks!  Note that Wenyou has a number of patches along these lines and
they're delegated to various people in patchwork, but please just grab
them all (unless someone nak'd them of course) once you've also found
the one that makes us also not have that warning :)


I think I know the right one (clk framework rework, ack'ed by at least 
simon). I will have prepared it by end of this weekend.


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

Re: [U-Boot] [PATCH] Please pull u-boot-mmc

[Tom Rini]

On Fri, Aug 12, 2016 at 02:40:12PM +0200, andr...@biessmann.de wrote:
> On 2016-08-12 14:04, Tom Rini wrote:
> >On Fri, Aug 12, 2016 at 04:34:01PM +0900, Jaehoon Chung wrote:
> >
> >>Dear Tom,
> >>
> >>Here is the mmc updates.
> >>- Supports the Driver model for atmel_sdhci.
> >>- Fixed the build error for omap_hsmmc.
> >>
> >>Could you pull these patch to u-boot/master?
> >>
> >>Best Regards,
> >>Jaehoon Chung
> >>
> >>The following changes since commit
> >>28cd88baa3f11cdb52be3b6d0610dcf32c60871a:
> >>
> >>  Merge branch 'master' of git://git.denx.de/u-boot-uniphier
> >>(2016-08-11 10:45:53 -0400)
> >>
> >>are available in the git repository at:
> >>
> >>
> >>  http://git.denx.de/u-boot-mmc.git master
> >>
> >>for you to fetch changes up to
> >>761326b33f1a14b19c0a4f7e8c336f8ed153d00c:
> >>
> >>  defconfig: k2g_evm_defconfig: Enable mmc driver model
> >>(2016-08-12 16:23:07 +0900)
> >>
> >>
> >>Sekhar Nori (4):
> >>  drivers: mmc: omap_hsmmc: fix build breakage
> >>  ARM: dts: K2G: Add support for MMC controller
> >>  ARM: dts: k2g-evm: enable mmc/sd suppport
> >>  defconfig: k2g_evm_defconfig: Enable mmc driver model
> >>
> >>Wenyou Yang (1):
> >>  mmc: atmel_sdhci: Convert to the driver model support
> >
> >NAK.  This atmel change, like the all of the others in their
> >series need
> >to come in via Andreas' tree as it's introducing a warning due to some
> >other patch being required:
> >+   sama5d2_xplained_spiflash
> >+(sama5d2_xplained_spiflash)  static int clk_get_by_name(struct
> >udevice *dev, const char *name,
> >+(sama5d2_xplained_spiflash) ^
> >w+(sama5d2_xplained_spiflash) In file included from
> >drivers/mmc/atmel_sdhci.c:9:0:
> >w+(sama5d2_xplained_spiflash) include/clk.h:107:12: warning:
> >'clk_get_by_name' defined but not used [-Wunused-function]
> 
> Sorry, I had no time to prepare a pull request early enough for rc1.
> I'll have a look for outstanding patches next few days and could
> also grab this one.

Thanks!  Note that Wenyou has a number of patches along these lines and
they're delegated to various people in patchwork, but please just grab
them all (unless someone nak'd them of course) once you've also found
the one that makes us also not have that warning :)

-- 
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] cmd: efi_loader: Return CMD_RET_USAGE in case of not enough arguments

[Alexander Graf]

On 08/12/2016 10:31 AM, Bin Meng wrote:

When typing 'bootefi' from U-Boot shell, nothing outputs. Like other
commands, return CMD_RET_USAGE so that it can print help message.

Signed-off-by: Bin Meng 


Reviewed-by: Alexander Graf 


Alex

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

[U-Boot] [PATCH V2 5/5] mmc: sd: optimize erase

[Peng Fan]

To SD, there is no erase group, then the value erase_grp_size
will be default 1. When erasing SD blocks, the blocks will be
erased one by one, which is time consuming.

We use AU_SIZE as a group to speed up the erasing.

Erasing 4MB with a SD2.0 Card with AU_SIZE 4MB.
`time mmc erase 0x10 0x2000`
time: 44.856 seconds (before optimization)
time: 0.335 seconds  (after optimization)

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Stefan Wahren 
Cc: Clemens Gruber 
Cc: Kever Yang 
Cc: Eric Nelson 
Cc: Stephen Warren 
---

V2:
 Add more commit log

 drivers/mmc/mmc_write.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc_write.c b/drivers/mmc/mmc_write.c
index 3589f8e..6221b4a 100644
--- a/drivers/mmc/mmc_write.c
+++ b/drivers/mmc/mmc_write.c
@@ -129,8 +129,13 @@ unsigned long mmc_berase(struct blk_desc *block_dev, 
lbaint_t start,
   & ~(mmc->erase_grp_size - 1)) - 1);
 
while (blk < blkcnt) {
-   blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
-   mmc->erase_grp_size : (blkcnt - blk);
+   if (IS_SD(mmc) && mmc->ssr.au) {
+   blk_r = ((blkcnt - blk) > mmc->ssr.au) ?
+   mmc->ssr.au : (blkcnt - blk);
+   } else {
+   blk_r = ((blkcnt - blk) > mmc->erase_grp_size) ?
+   mmc->erase_grp_size : (blkcnt - blk);
+   }
err = mmc_erase_t(mmc, start + blk, blk_r);
if (err)
break;
-- 
2.6.2

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

[U-Boot] [PATCH 5/5] rk3288: add arch_cpu_init for rk3288

[Kever Yang]

We do some SoC level one time setting initialization in
arch_cpu_init.

Signed-off-by: Kever Yang 
---

 arch/arm/mach-rockchip/rk3288/Makefile |  1 +
 arch/arm/mach-rockchip/rk3288/rk3288.c | 19 +++
 2 files changed, 20 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/rk3288/rk3288.c

diff --git a/arch/arm/mach-rockchip/rk3288/Makefile 
b/arch/arm/mach-rockchip/rk3288/Makefile
index 82b00a1..2e0be74 100644
--- a/arch/arm/mach-rockchip/rk3288/Makefile
+++ b/arch/arm/mach-rockchip/rk3288/Makefile
@@ -6,5 +6,6 @@
 
 obj-y += clk_rk3288.o
 obj-y += reset_rk3288.o
+obj-y += rk3288.o
 obj-y += sdram_rk3288.o
 obj-y += syscon_rk3288.o
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rk3288.c
new file mode 100644
index 000..92f34bb
--- /dev/null
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -0,0 +1,19 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#include 
+#include 
+
+#define GRF_SOC_CON2 0x24c
+
+int arch_cpu_init(void)
+{
+   /* We do some SoC one time setting here. */
+
+   /* Use rkpwm by default */
+   rk_setreg(GRF_SOC_CON2, 1 << 0);
+
+   return 0;
+}
-- 
1.9.1


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

[U-Boot] [PATCH 4/5] rk_pwm: remove grf setting code from driver

[Kever Yang]

We consider the grf setting for pwm controller select as the system
operation instead of driver operation, move it to soc init, let's
remove it from pwm driver first.

Signed-off-by: Kever Yang 
---

 drivers/pwm/rk_pwm.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index d69aab5..d3de429 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -13,17 +13,13 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
 struct rk_pwm_priv {
struct rk3288_pwm *regs;
-   struct rk3288_grf *grf;
ulong freq;
 };
 
@@ -64,13 +60,8 @@ static int rk_pwm_set_enable(struct udevice *dev, uint 
channel, bool enable)
 static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
 {
struct rk_pwm_priv *priv = dev_get_priv(dev);
-   struct regmap *map;
 
priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
-   map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
-   if (IS_ERR(map))
-   return PTR_ERR(map);
-   priv->grf = regmap_get_range(map, 0);
 
return 0;
 }
@@ -81,8 +72,6 @@ static int rk_pwm_probe(struct udevice *dev)
struct clk clk;
int ret = 0;
 
-   rk_setreg(>grf->soc_con2, 1 << 0);
-
ret = clk_get_by_index(dev, 0, );
if (ret < 0) {
printf("%s get clock fail!\n", __func__);
-- 
1.9.1


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

[U-Boot] Nvidia Trega Tk1 - /cpus/cpu@0 missing clock-frequency property

[vinoth eswaran]

Hi,

 Currently I am working on an Nvidia Jetson Tk1 board.

With u-boot v2016.05 I am seeing the following messages on the start up

[0.00] Tegra clk 127: register failed with -17
[0.004488] /cpus/cpu@0 missing clock-frequency property
[0.008002] /cpus/cpu@1 missing clock-frequency property
[0.013406] /cpus/cpu@2 missing clock-frequency property
[0.018751] /cpus/cpu@3 missing clock-frequency property
[0.879130] +USB0_VBUS_SW: Failed to request enable GPIO108: -517
[0.883400] reg-fixed-voltage regulators:regulator@7: Failed to
register regulator: -517
[0.891700] +5V_USB_HS: Failed to request enable GPIO109: -517
[0.897438] reg-fixed-voltage regulators:regulator@8: Failed to
register regulator: -517
[0.905852] +1.05V_RUN_AVDD_HDMI_PLL: Failed to request enable GPIO63: -517
[0.912605] reg-fixed-voltage regulators:regulator@11: Failed to
register regulator: -517
[0.920982] +5V_HDMI_CON: Failed to request enable GPIO86: -517
[0.926818] reg-fixed-voltage regulators:regulator@12: Failed to
register regulator: -517
[0.935194] +5V_SATA: Failed to request enable GPIO242: -517
[0.940771] reg-fixed-voltage regulators:regulator@13: Failed to
register regulator: -517
[0.949148] +12V_SATA: Failed to request enable GPIO242: -517
[0.954811] reg-fixed-voltage regulators:regulator@14: Failed to
register regulator: -517
[2.740489] tegra-xusb-padctl 7009f000.padctl: failed to setup XUSB
ports: -517
[2.757663] tegra-pcie 1003000.pcie-controller: Failed to get
supply 'avddio-pex': -517
[2.784372] serial-tegra serial@70006000: failed to get alias id, errno -19
[2.791460] serial-tegra serial@70006040: failed to get alias id, errno -19

I am not sure about what's the issue here. Google search shows
something might be missing in the device tree. Can you let me know
whats the issue here.

Mit Freundlichen Grüßen
VinothKumar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Please pull u-boot-mmc

[Jaehoon Chung]

Dear Tom,

Here is the mmc updates.
- Supports the Driver model for atmel_sdhci.
- Fixed the build error for omap_hsmmc.

Could you pull these patch to u-boot/master?

Best Regards,
Jaehoon Chung

The following changes since commit 28cd88baa3f11cdb52be3b6d0610dcf32c60871a:

  Merge branch 'master' of git://git.denx.de/u-boot-uniphier (2016-08-11 
10:45:53 -0400)

are available in the git repository at:


  http://git.denx.de/u-boot-mmc.git master

for you to fetch changes up to 761326b33f1a14b19c0a4f7e8c336f8ed153d00c:

  defconfig: k2g_evm_defconfig: Enable mmc driver model (2016-08-12 16:23:07 
+0900)


Sekhar Nori (4):
  drivers: mmc: omap_hsmmc: fix build breakage
  ARM: dts: K2G: Add support for MMC controller
  ARM: dts: k2g-evm: enable mmc/sd suppport
  defconfig: k2g_evm_defconfig: Enable mmc driver model

Wenyou Yang (1):
  mmc: atmel_sdhci: Convert to the driver model support

 arch/arm/dts/k2g-evm.dts  |   8 
 arch/arm/dts/k2g.dtsi |  23 +++
 configs/k2g_evm_defconfig |   1 +
 drivers/mmc/Kconfig   |  10 ++
 drivers/mmc/atmel_sdhci.c | 123 
+++
 drivers/mmc/omap_hsmmc.c  |   2 ++
 include/sdhci.h   |   2 ++
 7 files changed, 169 insertions(+)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v11] mmc: atmel_sdhci: Convert to the driver model support

[Jaehoon Chung]

Hi Wenyou,

On 08/11/2016 11:03 AM, Jaehoon Chung wrote:
> Hi,
> 
> On 08/10/2016 11:51 AM, Wenyou Yang wrote:
>> Convert the driver to the driver model while retaining the existing
>> legacy code. This allows the driver to support boards that have
>> converted to driver model as well as those that have not.
>>
>> Signed-off-by: Wenyou Yang 
>> Reviewed-by: Simon Glass 
>> Reviewed-by: Jaehoon Chung 
>> Reviewed-by: Heiko Schocher 
> 
> If others are ok, I will pick this patch to u-boot-mmc.

Applied on u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Best Regards,
> Jaehoon Chung
> 
>> ---
>>
>> Changes in v11:
>>  - Due the removal of unnecessary arguments for sdhci_setup_cfg(),
>>change accordingly.
>>
>> Changes in v10:
>>  - Add Reviewed-by tag.
>>
>> Changes in v9:
>>  - Add Reviewed-by tag.
>>
>> Changes in v8:
>>  - Make atmel_sdhci_get_clk() to get clock device.
>>  - Use ulong type for gck_rate.
>>  - Remove meaningless type casting before dev->name.
>>
>> Changes in v7:
>>  - Add support for using driver model for block devices and MMC operations.
>>  - Change clk_client.h -> clk.h to adapt to clk API conversion.
>>
>> Changes in v6:
>>  - Remove unnecessary white space.
>>  - Use sdhci_read(), instead of readl().
>>  - Remove the local variables min_clk.
>>
>> Changes in v5:
>>  - Add Reviewed-by tag.
>>
>> Changes in v4:
>>  - Update the clk API based on [PATCH] clk: convert API to match
>>reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
>>  - Remove check on dev_get_parent() return.
>>  - Fixed the return value, such as -ENODEV->-EINVAL.
>>
>> Changes in v3:
>>  - Remove the redundant log print.
>>
>> Changes in v2:
>>  - Add clock support, include enabling peripheral clock
>>and generated clock.
>>  - Retain the existing legacy code to support boards which have not
>>converted to driver model.
>>
>>  drivers/mmc/Kconfig   |  10 
>>  drivers/mmc/atmel_sdhci.c | 123 
>> ++
>>  include/sdhci.h   |   2 +
>>  3 files changed, 135 insertions(+)
>>
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index dc8f2b6..3616dee 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -34,6 +34,16 @@ config MSM_SDHCI
>>SD 3.0 specifications. Both SD and eMMC devices are supported.
>>Card-detect gpios are not supported.
>>  
>> +config ATMEL_SDHCI
>> +bool "Atmel SDHCI controller support"
>> +depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
>> +help
>> +  This enables support for the Atmel SDHCI controller, which supports
>> +  the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
>> +  Memory Card Specification V3.0, and the SDIO V3.0 specification.
>> +  It is compliant with the SD Host Controller Standard V3.0
>> +  specification.
>> +
>>  config ROCKCHIP_DWMMC
>>  bool "Rockchip SD/MMC controller support"
>>  depends on DM_MMC && OF_CONTROL
>> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
>> index 24b68b6..dd6bd33 100644
>> --- a/drivers/mmc/atmel_sdhci.c
>> +++ b/drivers/mmc/atmel_sdhci.c
>> @@ -6,12 +6,15 @@
>>   */
>>  
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  
>>  #define ATMEL_SDHC_MIN_FREQ 40
>>  
>> +#ifndef CONFIG_DM_MMC
>>  int atmel_sdhci_init(void *regbase, u32 id)
>>  {
>>  struct sdhci_host *host;
>> @@ -38,3 +41,123 @@ int atmel_sdhci_init(void *regbase, u32 id)
>>  
>>  return 0;
>>  }
>> +
>> +#else
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +struct atmel_sdhci_plat {
>> +struct mmc_config cfg;
>> +struct mmc mmc;
>> +};
>> +
>> +static int atmel_sdhci_get_clk(struct udevice *dev, int index, struct clk 
>> *clk)
>> +{
>> +struct udevice *dev_clk;
>> +int periph, ret;
>> +
>> +ret = clk_get_by_index(dev, index, clk);
>> +if (ret)
>> +return ret;
>> +
>> +periph = fdtdec_get_uint(gd->fdt_blob, clk->dev->of_offset, "reg", -1);
>> +if (periph < 0)
>> +return -EINVAL;
>> +
>> +dev_clk = dev_get_parent(clk->dev);
>> +ret = clk_request(dev_clk, clk);
>> +if (ret)
>> +return ret;
>> +
>> +clk->id = periph;
>> +
>> +return 0;
>> +}
>> +
>> +static int atmel_sdhci_probe(struct udevice *dev)
>> +{
>> +struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>> +struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
>> +struct sdhci_host *host = dev_get_priv(dev);
>> +u32 max_clk;
>> +u32 caps, caps_1;
>> +u32 clk_base, clk_mul;
>> +ulong gck_rate;
>> +struct clk clk;
>> +int ret;
>> +
>> +ret = atmel_sdhci_get_clk(dev, 0, );
>> +if (ret)
>> +return ret;
>> +
>> +ret = clk_enable();
>> +if (ret)
>> +return ret;
>> +
>> +host->name = dev->name;
>> +host->ioaddr = (void 

Re: [U-Boot] [PATCH] getting ubifs to run

[Hoefle Marco]

Hello Heiko,
You are right, there are two parts: the Microblaze part and the ubifs stuff.
To get u-boot compiled I added the following to the Microblaze architecture:
atomic.h based on the ARM architecture, was missing before.
Modified bitops.h to get rid of compiler warnings
The three ubifs files had #defines which didn't work for me.
With the changes of the patch I sent I can successfully load the Kernel from a 
ubifs partition on a Microblaze.


That were the problems:

CC  fs/ubifs/ubifs.o
In file included from /home/hoefle/projects/u-boot_patch/fs/ubifs/ubifs.c:17:0:
/home/hoefle/projects/u-boot_patch/fs/ubifs/ubifs.h:35:24: fatal error: 
asm/atomic.h: No such file or directory
 #include 
^
compilation terminated.


/home/hoefle/projects/u-boot_patch/arch/microblaze/include/asm/bitops.h:197:19: 
note: expected 'volatile void *' but argument is of type 'const long unsigned 
int *'
 static inline int __test_bit(int nr, volatile void *addr)
   ^
/home/hoefle/projects/u-boot_patch/fs/ubifs/misc.h: In function 
'ubifs_zn_obsolete':
/home/hoefle/projects/u-boot_patch/arch/microblaze/include/asm/bitops.h:210:18: 
warning: passing argument 2 of '__test_bit' discards 'const' qualifier from 
pointer target type
  __test_bit((nr),(addr)))
  ^
/home/hoefle/projects/u-boot_patch/fs/ubifs/misc.h:38:11: note: in expansion of 
macro 'test_bit'
  return !!test_bit(OBSOLETE_ZNODE, >flags);
   ^
/home/hoefle/projects/u-boot_patch/arch/microblaze/include/asm/bitops.h:197:19: 
note: expected 'volatile void *' but argument is of type 'const long unsigned 
int *'
 static inline int __test_bit(int nr, volatile void *addr)
   ^
/home/hoefle/projects/u-boot_patch/fs/ubifs/misc.h: In function 'ubifs_zn_cow':
/home/hoefle/projects/u-boot_patch/arch/microblaze/include/asm/bitops.h:210:18: 
warning: passing argument 2 of '__test_bit' discards 'const' qualifier from 
pointer target type
  __test_bit((nr),(addr)))
  ^
/home/hoefle/projects/u-boot_patch/fs/ubifs/misc.h:50:11: note: in expansion of 
macro 'test_bit'
  return !!test_bit(COW_ZNODE, >flags);
   ^
/home/hoefle/projects/u-boot_patch/arch/microblaze/include/asm/bitops.h:197:19: 
note: expected 'volatile void *' but argument is of type 'const long unsigned 
int *'
 static inline int __test_bit(int nr, volatile void *addr)
   ^



fs/built-in.o: In function `ubifs_lpt_start_commit':
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:1232: undefined 
reference to `dbg_chk_lpt_free_spc'
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:1235: undefined 
reference to `dbg_check_ltab'
fs/built-in.o: In function `layout_cnodes':
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:195: undefined 
reference to `dbg_chk_lpt_sz'
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:211: undefined 
reference to `dbg_chk_lpt_sz'
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:219: undefined 
reference to `dbg_chk_lpt_sz'
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:233: undefined 
reference to `dbg_chk_lpt_sz'
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:246: undefined 
reference to `dbg_chk_lpt_sz'
fs/built-in.o:/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:254: 
more undefined references to `dbg_chk_lpt_sz' follow
fs/built-in.o: In function `layout_cnodes':
/home/hoefle/projects/u-boot_patch/fs/ubifs/lpt_commit.c:322: undefined 
reference to `ubifs_dump_lpt_lebs'
fs/built-in.o: In function `ubifs_add_bud_to_log':
/home/hoefle/projects/u-boot_patch/fs/ubifs/log.c:194: undefined reference to 
`ubifs_commit_required'
/home/hoefle/projects/u-boot_patch/fs/ubifs/log.c:225: undefined reference to 
`ubifs_request_bg_commit'
/home/hoefle/projects/u-boot_patch/fs/ubifs/log.c:265: undefined reference to 
`ubifs_write_node'
fs/built-in.o: In function `ubifs_log_end_commit':
/home/hoefle/projects/u-boot_patch/fs/ubifs/log.c:479: undefined reference to 
`ubifs_write_master'
fs/built-in.o: In function `write_orph_node':
/home/hoefle/projects/u-boot_patch/fs/ubifs/orphan.c:248: undefined reference 
to `ubifs_write_node'


Regards,
Marco



> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Freitag, 12. August 2016 07:05
> To: Hoefle Marco 
> Cc: mon...@monstr.eu; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] getting ubifs to run
> 
> Hello Marco,
> 
> Am 11.08.2016 um 11:56 schrieb Marco:
> > Signed-off-by: Marco 
> > ---
> >   arch/microblaze/include/asm/atomic.h | 114
> +++
> >   arch/microblaze/include/asm/bitops.h |   8 +--
> >   fs/ubifs/io.c|   2 +-
> >   fs/ubifs/log.c   |  99 ++
> >   fs/ubifs/lpt_commit.c|  21 +++
> >   5 files changed, 239 insertions(+), 5 deletions(-)
> >   create mode 

[U-Boot] P4080DS ELBC UPM MODE

[yyurtcan]

Hi,
I have p4080ds board. I want to increase read speed from NOR Flash in order
to meet system requirements. I have measured read speed around 10 MByte/sec.
I think this speed is too low. I have searched it on internet and found that
NOR Flash has two mode; word and page mode. Page mode is faster than word
mode. I assume that NOR flash is in word mode. I have learned that by
default elbc is in GPCM mode which does not support page mode access. In
order to use page mode access UPM mode should be defined. I have searched
and finally found that CS_SYS_FLASH_BR_PRELIM, which is base register
definition.I think I need to set CS_SYS_FLASH_BR_PRELIM and
CS_SYS_FLASH_OR_PRELIM the followings 
#define CONFIG_SYS_FLASH_BR_PRELIM (BR_PHYS_ADDR(CONFIG_SYS_FLASH_BASE_PHYS
+ 0x800) | BR_PS_16 | BR_V | 0x0080)
#define CONFIG_SYS_FLASH_OR_PRELIM (OR_UPM_AM | OR_UPM_BCTLD | OR_UPM_BI |
OR_UPM_TRLX | OR_UPM_EHTR | OR_UPM_EAD)
 
However, the board does not boot. So, what is the problem by using UPM mode?
Is there anything I need to do?
Best regards.



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/P4080DS-ELBC-UPM-MODE-tp264139.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver

[Shengzhou Liu]

> -Original Message-
> From: york sun
> Sent: Friday, August 12, 2016 3:45 AM
> To: Shengzhou Liu ; u-boot@lists.denx.de
> Subject: Re: [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver
> 
> > +#define CMD_ADDR_MSB_MR_OP(x)  (x << 24)
> > +#define CMD_ADDR_LSB_MR_ADDR(x) (x << 16)
> > +#define MDSCR_DISABLE_CFG_REQ   (0 << 15)
> > +#define MDSCR_ENABLE_CON_REQ   (1 << 15)
> > +#define MDSCR_CON_ACK  (1 << 14)
> > +#define MDSCR_WL_EN(1 << 9)
> > +#defineCMD_NORMAL  (0 << 4)
> > +#defineCMD_PRECHARGE   (1 << 4)
> > +#defineCMD_AUTO_REFRESH(2 << 4)
> > +#defineCMD_LOAD_MODE_REG   (3 << 4)
> > +#defineCMD_ZQ_CALIBRATION  (4 << 4)
> > +#defineCMD_PRECHARGE_BANK_OPEN (5 << 4)
> > +#defineCMD_MRR (6 << 4)
> >  #define CMD_BANK_ADDR_00x0
> >  #define CMD_BANK_ADDR_10x1
> >  #define CMD_BANK_ADDR_20x2
> 
> Removing those macros causes compiling error for ls1012afrdm_qspi
> ls1012aqds_qspi ls1012ardb_qspi. Please rearrange the change.
> 
> York

Why do you want to remove those macros? They are needed and useful, I compiled 
it for ls1012a QDS/ RDB/FRDM without any issue, and worked fine on boards.

Shengzhou

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

Re: [U-Boot] [PATCH v2 4/5] mpc85xx/powerpc: P5040: Apply errata A006261 for P5040

[Sriram Dash]

>From: york sun
>
>Same comment to the subject line.
>

Ok. Will modify patch title and commit message in v3.

>On 07/17/2016 08:47 PM, Sriram Dash wrote:
>> Apply USB errata A006261 for P5040.
>
>Please add explanation the same erratum applies to P5040 rev 2.0.
>

Ok. Will modify patch title and commit message in v3.

>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>  drivers/usb/common/fsl-errata.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/common/fsl-errata.c
>> b/drivers/usb/common/fsl-errata.c index 122e17b..765b25a 100644
>> --- a/drivers/usb/common/fsl-errata.c
>> +++ b/drivers/usb/common/fsl-errata.c
>> @@ -73,7 +73,8 @@ bool has_erratum_a006261(void)
>>  case SVR_T2081:
>>  return IS_SVR_REV(svr, 1, 0);
>>  case SVR_P5040:
>> -return IS_SVR_REV(svr, 1, 0);
>> +return IS_SVR_REV(svr, 1, 0) ||
>> +IS_SVR_REV(svr, 2, 0) || IS_SVR_REV(svr, 2, 1);
>
>Because the official document doesn't include these versions, please add a
>comment saying this erratum applies to affected revisions.
>
>York
>

Ok. Will modify patch title and commit message in v3.

>
>>  #endif
>>  }
>>
>>

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

Re: [U-Boot] disabling mmc in spl when booting using bootrom

[Sandy Patterson]

On Fri, Aug 12, 2016 at 1:20 PM, Simon Glass  wrote:

> Hi Ziyuan,
>
> On 11 August 2016 at 05:35, Ziyuan Xu  wrote:
> >
> >
> > On 2016年08月11日 19:31, Sandy Patterson wrote:
> >>
> >> Simon,
> >>
> >> I am trying to format a patch to disable MMC in the SPL if booting main
> >> u-boot using BOOTROM, therefore the SPL MMC isn't needed.
> >>
> >> Is the best solution to wrap every header file (rock2.h
> firefly-rk3288.h,
> >> etc) with ifdefs on the BACK_TO_BROM define? Or would it be better to
> move
> >> the SPL MMC define into rk3288-common.h and just have chromebook_jerry
> undef
> >> it like it does the SPL GPIO code.
> >>
> >> With that change, enabling BOOT_TO_BROM shrinks the spl from 32K to 23K.
> >
> > Note that, firefly-rk3288 use OF_PLATDATA, we will use
> u-boot-spl-no-dtb.bin
> > instead of u-boot-spl-dtb.bin, and the size of u-boot-spl-no-dtb.bin is
> > almost 23K.
> >
> > @Simon, I think we will update doc/README.rockchip if you insist on
> > OF_PLATDATA for firefly-rk3288. we no longer use u-boot-spl-dtb.bin.:-)
>
> I don't insist :-)
>
> I really don't like OF_PLATDATA. But it cuts the size down a lot
> (~6KB) and we are otherwise always running out of space on rk3288.
>
> If there is a better idea, let's have it. Otherwise, yes we can update the
> docs.
>

@Ziyuan, I did my testing on rock2 which doesn't use OF_PLATDATA, the
firefly
board should see the same final size which is roughly equivalent to the
current
firefly SPL size.

We ran out of space in SPL. I too was afraid of using OF_PLATDATA mostly
from
Simon's commit message.

I would propose moving to using the BOOTROM to load U-Boot proper. You
shouldn't
need any of the media drivers since the BOOTROM was already able to load
the SPL
it should be fine loading the full U-Boot.

I get 9K from removing MMC from rock2. I'm happy to write a patch that
applies this logic
to the remainder of the rk3288 boards if that's the way you'd like to go.
You could test it by
enabling the BOOT_TO_BROM config.


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

Re: [U-Boot] [PATCH v2] serial: bcm283x_mu: Detect disabled serial device

[Alexander Graf]

> Am 12.08.2016 um 00:38 schrieb Simon Glass :
> 
> Hi Alex,
> 
>> On 11 August 2016 at 05:33, Alexander Graf  wrote:
>> 
>> 
>>> On 09.08.16 06:28, Stephen Warren wrote:
 On 08/04/2016 05:15 PM, Alexander Graf wrote:
 
> On 04 Aug 2016, at 20:11, Stephen Warren  wrote:
> 
> On 08/04/2016 01:11 AM, Alexander Graf wrote:
>> On the raspberry pi, you can disable the serial port to gain dynamic
>> frequency
>> scaling which can get handy at times.
>> 
>> However, in such a configuration the serial controller gets its rx
>> queue filled
>> up with zero bytes which then happily get transmitted on to whoever
>> calls
>> getc() today.
>> 
>> This patch adds detection logic for that case by checking whether
>> the RX pin is
>> mapped to GPIO15 and disables the mini uart if it is not mapped
>> properly.
>> 
>> That way we can leave the driver enabled in the tree and can
>> determine during
>> runtime whether serial is usable or not, having a single binary that
>> allows for
>> uart and non-uart operation.
> 
>> diff --git a/drivers/serial/serial_bcm283x_mu.c
>> b/drivers/serial/serial_bcm283x_mu.c
> 
>> @@ -72,9 +87,18 @@ static int bcm283x_mu_serial_probe(struct udevice
>> *dev)
>> {
>>struct bcm283x_mu_serial_platdata *plat = dev_get_platdata(dev);
>>struct bcm283x_mu_priv *priv = dev_get_priv(dev);
>> +struct bcm283x_gpio_regs *gpio = (struct bcm283x_gpio_regs
>> *)plat->gpio;
>> 
>>priv->regs = (struct bcm283x_mu_regs *)plat->base;
>> 
>> +/*
>> + * The RPi3 disables the mini uart by default. The easiest way
>> to find
>> + * out whether it is available is to check if the pin is muxed.
>> + */
>> +if (((readl(>gpfsel1) >> BCM283X_GPIO_GPFSEL1_F15_SHIFT) &
>> +BCM283X_GPIO_ALTFUNC_MASK) != BCM283X_GPIO_ALTFUNC_5)
>> +priv->disabled = true;
>> +
>>return 0;
> 
> Comment on the current implementation: Can't probe() return an error
> if the device should be disabled? That would avoid the need to check
> priv->disabled in all the other functions.
 
 I guess I should’ve put that in a comment somewhere. Unfortunately we
 can’t. If I just return an error on probe, U-Boot will panic because
 we tell it in a CONFIG define that we require a serial port (grep for
 CONFIG_REQUIRE_SERIAL_CONSOLE).
 
 We could maybe try to unset that define instead?
>>> 
>>> Yes, assuming that U-Boot runs just fine with HDMI console only, I think
>>> it's fine to unset CONFIG_REQUIRE_SERIAL_CONSOLE.
>>> 
> Overall comment: I'd rather not put this logic into the UART driver
> itself; it is system-specific rather than device-specific. I'd also
> rather not have the UART driver touching GPIO registers; that's not
> very modular, and could cause problems if the Pi is converted to use
> DT to instantiate devices.
> 
> Instead, can we put the logic into board/raspberrypi/rpi/rpi.c? I.e.
> have some early function come along and enable/disable the
> bcm2837_serials device object as appropriate? That way it isolates
> the code to the Pi specifically, and not any other bcm283x board.
> We'd want to wrap that code in #ifdef CONFIG_PL01X_SERIAL.
 
 We can do that if we can fail at probe time. If we absolutely must
 have a serial driver to work in the first place, that doesn’t work. I
 can try to poke at it, but it’ll be a few days I think :).
>> 
>> So I couldn't find a sane way to fail probing based on something defined
>> in the board file, reusing the existing gpio device.
> 
> Would it be possible to move this code into the serial driver?

You mean like in v2 which Stephen nacked? :)

> 
>> 
>> However, there's an easy alternative. We can make the console code just
>> ignore our serial device if we set its pointer to NULL. That way we
>> still have the device, but can contain all logic to disable usage of the
>> mini uart to the board file.
> 
> I'm not very keen on that - feels like a hack.  What is stopping
> Stephen's idea from working? I could perhaps help with dm plumbing is
> that is the issue...

The problem is that we need the gpio device to determine whether the pin is 
muxed. There is no temporal control that I could see that would allow me to be 
in a place where the gpio device exists, the serial device does not exist, and 
where I could then not spawn the serial device based on board logic.


Alex


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

Re: [U-Boot] [PATCH 2/2] serial: bcm283x_mu: Detect disabled serial device

[Alexander Graf]

> Am 12.08.2016 um 00:38 schrieb Simon Glass :
> 
> Hi Alex,
> 
>> On 11 August 2016 at 05:38, Alexander Graf  wrote:
>> On the raspberry pi, you can disable the serial port to gain dynamic 
>> frequency
>> scaling which can get handy at times.
>> 
>> However, in such a configuration the serial controller gets its rx queue 
>> filled
>> up with zero bytes which then happily get transmitted on to whoever calls
>> getc() today.
>> 
>> This patch adds detection logic for that case by checking whether the RX pin 
>> is
>> mapped to GPIO15 and disables the mini uart if it is not mapped properly.
>> 
>> That way we can leave the driver enabled in the tree and can determine during
>> runtime whether serial is usable or not, having a single binary that allows 
>> for
>> uart and non-uart operation.
>> 
>> Signed-off-by: Alexander Graf 
>> 
>> ---
>> 
>> v2 -> v3:
>> 
>>  - Disable and detect pinmux in board file
>> ---
>> board/raspberrypi/rpi/rpi.c | 29 +
>> configs/rpi_3_32b_defconfig |  1 +
>> configs/rpi_3_defconfig |  1 +
>> include/configs/rpi.h   |  1 +
>> 4 files changed, 32 insertions(+)
>> 
>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>> index 4c8253d..20b0d1b 100644
>> --- a/board/raspberrypi/rpi/rpi.c
>> +++ b/board/raspberrypi/rpi/rpi.c
>> @@ -453,6 +453,35 @@ int board_init(void)
>>return power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
>> }
>> 
>> +static bool rpi_is_serial_active(void)
>> +{
>> +#ifndef CONFIG_PL01X_SERIAL
>> +   int serial_gpio = 15;
>> +   struct udevice *dev;
>> +
>> +   /*
>> +* The RPi3 disables the mini uart by default. The easiest way to 
>> find
>> +* out whether it is available is to check if the pin is muxed.
>> +*/
>> +   if (uclass_first_device(UCLASS_GPIO, ) || !dev)
>> +   return true;
>> +
>> +   if (bcm2835_gpio_get_func_id(dev, serial_gpio) != BCM2835_GPIO_ALT5)
>> +   return false;
> 
> Do you mean gpio_get_function()?

That only tells me whether it's in/out/other, but I need to know whether the 
pin is configured to exactly function 5.


Alex


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

Re: [U-Boot] [PATCH] getting ubifs to run

[Heiko Schocher]

Hello Marco,

Am 11.08.2016 um 11:56 schrieb Marco:

Signed-off-by: Marco 
---
  arch/microblaze/include/asm/atomic.h | 114 +++
  arch/microblaze/include/asm/bitops.h |   8 +--
  fs/ubifs/io.c|   2 +-
  fs/ubifs/log.c   |  99 ++
  fs/ubifs/lpt_commit.c|  21 +++
  5 files changed, 239 insertions(+), 5 deletions(-)
  create mode 100644 arch/microblaze/include/asm/atomic.h


Hmm... what exactly do you fix? Can you add a commit message please?

It seems to me, you get ubifs working on microblaze arch?

And may you can split this patch into at least two pieces, one for the
arch fixes, and one for the ubifs fixes?

ubifs read support works for me on some arm based plattforms ...
what exactly do you fix with your fs/ubifs/* changes?

Thanks!

bye,
Heiko

diff --git a/arch/microblaze/include/asm/atomic.h 
b/arch/microblaze/include/asm/atomic.h
new file mode 100644
index 000..2872149
--- /dev/null
+++ b/arch/microblaze/include/asm/atomic.h
@@ -0,0 +1,114 @@
+/*
+ *  linux/include/asm-arm/atomic.h
+ *
+ *  Copyright (c) 1996 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *  Changelog:
+ *   27-06-1996RMK Created
+ *   13-04-1997RMK Made functions atomic!
+ *   07-12-1997RMK Upgraded for v2.1.
+ *   26-08-1998PJB Added #ifdef __KERNEL__
+ */
+#ifndef __ASM_ARM_ATOMIC_H
+#define __ASM_ARM_ATOMIC_H
+
+#ifdef CONFIG_SMP
+#error SMP not supported
+#endif
+
+typedef struct { volatile int counter; } atomic_t;
+
+#define ATOMIC_INIT(i) { (i) }
+
+#ifdef __KERNEL__
+#include 
+
+#define atomic_read(v) ((v)->counter)
+#define atomic_set(v,i)(((v)->counter) = (i))
+
+
+
+
+static inline void atomic_add(int i, volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter += i;
+   local_irq_restore(flags);
+}
+
+static inline void atomic_sub(int i, volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter -= i;
+   local_irq_restore(flags);
+}
+
+static inline void atomic_inc(volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter += 1;
+   local_irq_restore(flags);
+}
+
+static inline void atomic_dec(volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   v->counter -= 1;
+   local_irq_restore(flags);
+}
+
+static inline int atomic_dec_and_test(volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+   int val;
+
+   local_irq_save(flags);
+   val = v->counter;
+   v->counter = val -= 1;
+   local_irq_restore(flags);
+
+   return val == 0;
+}
+
+static inline int atomic_add_negative(int i, volatile atomic_t *v)
+{
+   unsigned long flags = 0;
+   int val;
+
+   local_irq_save(flags);
+   val = v->counter;
+   v->counter = val += i;
+   local_irq_restore(flags);
+
+   return val < 0;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+   unsigned long flags = 0;
+
+   local_irq_save(flags);
+   *addr &= ~mask;
+   local_irq_restore(flags);
+}
+
+/* Atomic operations are already serializing on ARM */
+#define smp_mb__before_atomic_dec()barrier()
+#define smp_mb__after_atomic_dec() barrier()
+#define smp_mb__before_atomic_inc()barrier()
+#define smp_mb__after_atomic_inc() barrier()
+
+#endif
+#endif
diff --git a/arch/microblaze/include/asm/bitops.h 
b/arch/microblaze/include/asm/bitops.h
index 2cab2ac..b3b17b9 100644
--- a/arch/microblaze/include/asm/bitops.h
+++ b/arch/microblaze/include/asm/bitops.h
@@ -204,10 +204,10 @@ static inline int __test_bit(int nr, volatile void *addr)
return ((mask & *a) != 0);
  }

-#define test_bit(nr,addr) \
-(__builtin_constant_p(nr) ? \
- __constant_test_bit((nr),(addr)) : \
- __test_bit((nr),(addr)))
+static inline int test_bit(int nr, const void * addr)
+{
+   return ((unsigned char *) addr)[nr >> 3] & (1U << (nr & 7));
+}

  #define find_first_zero_bit(addr, size) \
find_next_zero_bit((addr), (size), 0)
diff --git a/fs/ubifs/io.c b/fs/ubifs/io.c
index 51a95bb..685713e 100644
--- a/fs/ubifs/io.c
+++ b/fs/ubifs/io.c
@@ -847,6 +847,7 @@ out:
ubifs_dump_leb(c, wbuf->lnum);
return err;
  }
+#endif

  /**
   * ubifs_write_node - write node to the media.
@@ -885,7 +886,6 @@ int ubifs_write_node(struct ubifs_info *c, void *buf, int 
len, int lnum,

return err;
  }
-#endif

  /**
   * ubifs_read_node_wbuf - read node from the media or write-buffer.
diff --git a/fs/ubifs/log.c b/fs/ubifs/log.c
index a07fdef..10302b9 100644
--- a/fs/ubifs/log.c
+++ 

Re: [U-Boot] [PATCH] drivers: net: keystone_net: add rgmii link type support when parsing dt

[Sekhar Nori]

On Thursday 11 August 2016 08:04 PM, Mugunthan V N wrote:
> Add support to detect RGMII link interface from link-interface
> device tree entry. Also rename the existing link type enums so
> that it provides meaningful interface like SGMII.
> 
> Signed-off-by: Mugunthan V N 

Reported-by: Sekhar Nori 
Tested-by: Sekhar Nori 

Fixes crash on K2G on network access with mainline master.

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

Re: [U-Boot] SPL loading multiple binaries from FIT image?

[Simon Glass]

Hi Andre,

On 1 July 2016 at 04:03, Andre Przywara  wrote:
> Hi,
>
> (sorry if this has been discussed before, feel free to point me to any
> existing thread then)
>
> for the Pine64 I am looking into letting the SPL load multiple images
> from a FIT image.
> Looking at common/spl/spl-fit.c I see that the current SPL FIT support
> just loads the first image from the "loadables" list as the U-Boot image
> and then selects and loads the matching FDT right after it.
> Feature-wise that seems to match what a legacy U-Boot image provides,
> but I was wondering if anyone uses the multiple images feature that FIT
> adds to the game?
>
> I need to at least load another image (ARM Trusted Firmware(ATF)),
> possibly the management controller firmware in the future as well.
> This has to be done before the actual U-Boot starts, so from the SPL.
>
> So I hacked the code to iterate over all images enumerated in the
> "loadables" property and load them to their load addresses. That somehow
> seems to work, but now I was wondering how to make this as flexible as
> possible:
> 1) How do we know what image is for U-Boot? Shall there be a separate
> "uboot" property (next to kernel, loadables, etc)? Or do we stay with
> the current assumption that it's the first from the loadables list?

That assumption seems reasonable and it is documented in
source_file_format.txt. If it causes problems we could adjust this
later.

> 2) At the moment we don't honour the entry point. Is there any reason
> for that?

Probably because the first user was an FPGA or extra kernel image,
which the CPU just has to load.

> 3) Would it be feasible to load all images listed in the loadables
> property and then branch to the only one (or the first) that has an
> entry point property? In my case this would be ATF (which then later
> drops to U-Boot at its well known load address).

Yes that seems reasonable. Another option would be to add a new entry
type instead of using 'firmware'.

>
> I wonder if this has been discussed before and would be grateful if
> people would share their opinion on the best approach. I will be happy
> to post patches once we agreed on something.

There has been some discussion recently on ATF with rockchip I think.

Also I've been working on a 'binman' tool which handles the task of
actually building firmware images from the build output.

https://www.mail-archive.com/u-boot@lists.denx.de/msg219798.html

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

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

Re: [U-Boot] [PATCH 2/5] clk: rk3288: add PWM clock get rate

[Simon Glass]

On 12 August 2016 at 03:57, Kever Yang  wrote:
> This patch add clk_get_rate for PWM device.
>
> Signed-off-by: Kever Yang 
> ---
>
>  drivers/clk/rockchip/clk_rk3288.c | 2 ++
>  1 file changed, 2 insertions(+)
>

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

Re: [U-Boot] [PATCH 1/5] rk3399: syscon: add support for pmugrf

[Simon Glass]

On 11 August 2016 at 19:43, Kever Yang  wrote:
> pmugrf is a module like grf which contain some of the iomux registers
> and other registers.
>
> Signed-off-by: Kever Yang 
> ---
>
>  arch/arm/include/asm/arch-rockchip/clock.h| 1 +
>  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c | 1 +
>  2 files changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH] efi_loader: disk: Fix CONFIG_BLK breakage

[Simon Glass]

Hi Alex,

On 10 August 2016 at 13:01, Alexander Graf  wrote:
>
>> On 10 Aug 2016, at 18:25, Tom Rini  wrote:
>>
>> On Wed, Aug 10, 2016 at 03:25:16PM +0200, Alexander Graf wrote:
>>>
>>>
 Am 10.08.2016 um 15:16 schrieb Simon Glass :

 Hi Alex,

> On 10 August 2016 at 07:02, Alexander Graf  wrote:
>> On 08/10/2016 02:56 PM, Simon Glass wrote:
>>
>> +Tom
>>
>> Hi Alex,
>>
>> On 10 August 2016 at 01:47, Alexander Graf  wrote:

 On 08 Aug 2016, at 23:44, Simon Glass  wrote:

 Hi Alexander,

> On 5 August 2016 at 06:49, Alexander Graf  wrote:
>
> When using CONFIG_BLK, there were 2 issues:
>
> 1) The name we generate the device with has to match the
>name we set in efi_set_bootdev()
>
> 2) The device we pass into our block functions was wrong,
>we should not rediscover it but just use the already known
>pointer.
>
> This patch fixes both issues.
>
> Signed-off-by: Alexander Graf 
> ---
> cmd/bootefi.c | 23 ++-
> lib/efi_loader/efi_disk.c | 18 +++---
> 2 files changed, 29 insertions(+), 12 deletions(-)
>> [...]
>>
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index c434c92..e00a747 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -31,6 +31,8 @@ struct efi_disk_obj {
>   struct efi_device_path_file_path *dp;
>   /* Offset into disk for simple partitions */
>   lbaint_t offset;
> +   /* Internal block device */
> +   const struct blk_desc *desc;

 Rather than storing this, can you store the udevice?
>>>
>>> I could, but then I would diverge between the CONFIG_BLK and
>>> non-CONFIG_BLK path again, which would turn the code into an #ifdef mess
>>> (read: hard to maintain), because the whole device creation path relies 
>>> on
>>> struct blk_desc * today and doesn’t pass the udevice anywhere.
>>>
>>> Do you feel strongly about this? To give you an idea how messy it gets,
>>> the diff is below.
>>
>> Actually I'd like to make this feature depend on CONFIG_BLK. If we add
>> new features that don't use driver model, and then use the legacy data
>> structures such that converting to driver model becomes harder, we'll
>> never be done.
>>
>> I did mention this at the beginning and it seems to have come to pass.
>>
>> In order of preference from my side:
>>
>> 1. Make EFI_LOADER depend on BLK
>
>
> If we make EFI_LOADER depend on BLK, doesn't that break all systems that
> need storage that isn't converted to device model today? Like the SATA
> breakage on Xilinx systems, just at a much bigger scale?

 No it just means that these platforms need to move to BLK before they
 can use the EFI loader. Given the embryonic nature of this feature,
 that seems reasonable, and the impact would be small. It will also
 encourage conversion and keep the code cleaner.
>>>
>>> No, it will simply make my life harder because I would have to sit
>>> down and vonvert every single board to BLK that I need EFI enabled.
>>
>> Seems like as good a place as any to jump in, of the boards that you
>> need EFI enabled on, what isn't converted today?
>
> I want to make EFI the default boot path in openSUSE, which means any board 
> that anyone out there wants to run openSUSE on would be on the list. Anything 
> that keeps them from running EFI on a random board is a road block that I’d 
> rather not have if I can avoid it.

Of course, I fully understand that. However as mentioned in this
patch, you are creating future problems.

Can you address Tom's question? I take it that it boots on Raspberry
Pi (which I'd like to try actually - are there instructions
somewhere?). We can easily convert that over. Anything else?

>
> Again, I strongly object any dependency on BLK for EFI. If you want to push 
> people to using CONFIG_BLK, make CONFIG_ARM depend on CONFIG_BLK.

:-) That won't work. If we could wave a magic wand and convert
everything in one day, we would.

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

Re: [U-Boot] disabling mmc in spl when booting using bootrom

[Simon Glass]

Hi Ziyuan,

On 11 August 2016 at 05:35, Ziyuan Xu  wrote:
>
>
> On 2016年08月11日 19:31, Sandy Patterson wrote:
>>
>> Simon,
>>
>> I am trying to format a patch to disable MMC in the SPL if booting main
>> u-boot using BOOTROM, therefore the SPL MMC isn't needed.
>>
>> Is the best solution to wrap every header file (rock2.h firefly-rk3288.h,
>> etc) with ifdefs on the BACK_TO_BROM define? Or would it be better to move
>> the SPL MMC define into rk3288-common.h and just have chromebook_jerry undef
>> it like it does the SPL GPIO code.
>>
>> With that change, enabling BOOT_TO_BROM shrinks the spl from 32K to 23K.
>
> Note that, firefly-rk3288 use OF_PLATDATA, we will use u-boot-spl-no-dtb.bin
> instead of u-boot-spl-dtb.bin, and the size of u-boot-spl-no-dtb.bin is
> almost 23K.
>
> @Simon, I think we will update doc/README.rockchip if you insist on
> OF_PLATDATA for firefly-rk3288. we no longer use u-boot-spl-dtb.bin.:-)

I don't insist :-)

I really don't like OF_PLATDATA. But it cuts the size down a lot
(~6KB) and we are otherwise always running out of space on rk3288.

If there is a better idea, let's have it. Otherwise, yes we can update the docs.

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

Re: [U-Boot] [PATCH v2 7/7] smbios: Provide serial number

[Simon Glass]

On 11 August 2016 at 19:31, Bin Meng  wrote:
> On Fri, Aug 12, 2016 at 5:45 AM, Alexander Graf  wrote:
>> If the system has a valid "serial#" environment variable set (which boards 
>> that
>> can find it out programatically set automatically), use that as input for the
>> serial number and UUID fields in the SMBIOS tables.
>>
>> Signed-off-by: Alexander Graf 
>>
>> ---
>>
>> v1 -> v2:
>>
>>   - Also populate UUID
>> ---
>>  lib/smbios.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 2/6] efi: Fix missing EFIAPI specifiers

[Simon Glass]

Hi Alex,

On 10 August 2016 at 05:40, Alexander Graf  wrote:
> On 08/07/2016 01:23 AM, Simon Glass wrote:
>>
>> These are missing in some functions. Add them to keep things consistent.
>>
>> Signed-off-by: Simon Glass 
>
>
> Is there any way to change the EFIAPI definition so that we get build
> warnings for non matching function types on aarch64 as well?
>
> Reviewed-by: Alexander Graf 

It might be possible to add a bogus attribute that does nothing.
Perhaps regparm(0)?

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

Re: [U-Boot] [PATCH v2 3/5] mpc85xx/powerpc: P2041: Apply errata A006261 for P2041

[Sriram Dash]

>From: york sun
>
>Same comment to the subject.
>

Ok. Will modify patch title and commit message in v3.

>On 07/17/2016 08:47 PM, Sriram Dash wrote:
>> Apply USB errata A006261 for P2041, P2040.
>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>  drivers/usb/common/fsl-errata.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/common/fsl-errata.c
>> b/drivers/usb/common/fsl-errata.c index 183bf2b..122e17b 100644
>> --- a/drivers/usb/common/fsl-errata.c
>> +++ b/drivers/usb/common/fsl-errata.c
>> @@ -53,7 +53,8 @@ bool has_erratum_a006261(void)
>>  case SVR_P2041:
>>  case SVR_P2040:
>>  return IS_SVR_REV(svr, 1, 0) ||
>> -IS_SVR_REV(svr, 1, 1) || IS_SVR_REV(svr, 2, 1);
>> +IS_SVR_REV(svr, 1, 1) ||
>> +IS_SVR_REV(svr, 2, 0) || IS_SVR_REV(svr, 2, 1);
>
>Please explain in the commit message why you replace rev 1.1 with rev 2.0.
>
>York
>

I have not removed the rev 1.1 support, only added the rev 2.0 support.
Will modify patch title and commit message in v3.

>
>>  case SVR_P3041:
>>  return IS_SVR_REV(svr, 1, 0) ||
>>  IS_SVR_REV(svr, 1, 1) ||
>>

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

Re: [U-Boot] [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver

[Shengzhou Liu]

It needs to apply both patches before compiling. The second patch will remove 
the old board level code and apply common mmdc driver.
I understand that in theory we should keep every single patch is compileable, 
but to make it clean to customer I separated them to two patches.
Do I really need to combine the two to one patch?

Shengzhou

From: york sun
Sent: Friday, August 12, 2016 1:56 PM
To: Shengzhou Liu ; u-boot@lists.denx.de
Subject: RE: [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver


I am not suggesting remove the macros. Please try to compile after applying 
first patch. You will see the errors

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

[U-Boot] [PATCH v3 1/3] cmd: Split 'bootz' and 'booti' out from 'bootm'

[Tom Rini]

The bootz and booti commands rely on common functionality that is found
in common/bootm.c and common/bootm_os.c.  They do not however rely on
the rest of cmd/bootm.c to be implemented so split them into their own
files.  Have various Makefiles include the required infrastructure for
CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM.  Move the declaration
of 'images' over to common/bootm.c.

Cc: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
Changes in v3:
- Fix a number of problems found when Masahiro pointed out that this
  patch didn't allow for BOOTZ+!BOOTM to build
---
 arch/arm/lib/Makefile |   3 +-
 arch/sandbox/lib/Makefile |   1 +
 cmd/Makefile  |   2 +
 cmd/booti.c   | 161 +
 cmd/bootm.c   | 250 --
 cmd/bootz.c   | 106 
 common/Makefile   |   2 +
 common/bootm.c|   2 +
 8 files changed, 276 insertions(+), 251 deletions(-)
 create mode 100644 cmd/booti.c
 create mode 100644 cmd/bootz.c

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index a8d155762937..caa62c635589 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -26,8 +26,9 @@ endif
 
 obj-$(CONFIG_CPU_V7M) += cmd_boot.o
 obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
-obj-$(CONFIG_CMD_BOOTM) += zimage.o
+obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
 obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
 obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile
index 7820c55c8554..2e7802feac8a 100644
--- a/arch/sandbox/lib/Makefile
+++ b/arch/sandbox/lib/Makefile
@@ -12,3 +12,4 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_PCI)  += pci_io.o
 endif
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTZ) += bootm.o
diff --git a/cmd/Makefile b/cmd/Makefile
index a1731be70127..a1ecf73ef314 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
 obj-$(CONFIG_CMD_BOOTLDR) += bootldr.o
 obj-$(CONFIG_CMD_BOOTSTAGE) += bootstage.o
+obj-$(CONFIG_CMD_BOOTZ) += bootz.o
+obj-$(CONFIG_CMD_BOOTI) += booti.o
 obj-$(CONFIG_CMD_CACHE) += cache.o
 obj-$(CONFIG_CMD_CBFS) += cbfs.o
 obj-$(CONFIG_CMD_CLK) += clk.o
diff --git a/cmd/booti.c b/cmd/booti.c
new file mode 100644
index ..6c1c998a568c
--- /dev/null
+++ b/cmd/booti.c
@@ -0,0 +1,161 @@
+/*
+ * (C) Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset, LE */
+   uint64_timage_size; /* Effective Image size, LE */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tres4;   /* reserved */
+   uint32_tmagic;  /* Magic number */
+   uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+   struct Image_header *ih;
+   uint64_t dst;
+   uint64_t image_size;
+
+   ih = (struct Image_header *)map_sysmem(images->ep, 0);
+
+   if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+   puts("Bad Linux ARM64 Image magic!\n");
+   return 1;
+   }
+   
+   if (ih->image_size == 0) {
+   puts("Image lacks image_size field, assuming 16MiB\n");
+   image_size = 16 << 20;
+   } else {
+   image_size = le64_to_cpu(ih->image_size);
+   }
+
+   /*
+* If we are not at the correct run-time location, set the new
+* correct location and then move the image there.
+*/
+   dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset);
+
+   unmap_sysmem(ih);
+
+   if (images->ep != dst) {
+   void *src;
+
+   debug("Moving Image from 0x%lx to 0x%llx\n", images->ep, dst);
+
+   src = (void *)images->ep;
+   images->ep = dst;
+   memmove((void *)dst, src, image_size);
+   }
+
+   return 0;
+}
+
+/*
+ * Image booting support
+ */
+static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[], bootm_headers_t *images)
+{
+   int ret;
+   struct Image_header *ih;
+
+   ret = do_bootm_states(cmdtp, flag, 

Re: [U-Boot] [PATCH v2 1/2] cmd: Split 'bootz' and 'booti' out from 'bootm'

[Tom Rini]

On Fri, Aug 12, 2016 at 02:49:49PM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> 2016-08-02 0:28 GMT+09:00 Tom Rini :
> > The bootz and booti commands rely on common functionality that is found
> > in common/bootm.c and common/bootm_os.c.  They do not however rely on
> > the rest of cmd/bootm.c to be implemented so split them into their own
> > files.  Have various Makefiles include the required infrastructure for
> > CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM.
> >
> > Signed-off-by: Tom Rini 
> 
> 
> If I apply this patch,
> I got a build error for the combination of
> "CONFIG_CMD_BOOTZ=y" and "# CONFIG_CMD_BOOTM is not set".
> 
> 
> $ make CROSS_COMPILE=arm-linux-gnueabi-
> scripts/kconfig/conf  --silentoldconfig Kconfig
>   CHK include/config.h
>   UPD include/config.h
>   GEN include/autoconf.mk
>   GEN include/autoconf.mk.dep
>   GEN spl/include/autoconf.mk
>   CHK include/config/uboot.release
>   UPD include/config/uboot.release
>   CHK include/generated/version_autogenerated.h
>   UPD include/generated/version_autogenerated.h
>   CHK include/generated/timestamp_autogenerated.h
>   UPD include/generated/timestamp_autogenerated.h
>   CC  lib/asm-offsets.s
>   CHK include/generated/generic-asm-offsets.h
>   UPD include/generated/generic-asm-offsets.h
>   CC  arch/arm/lib/asm-offsets.s
>   CHK include/generated/asm-offsets.h
>   UPD include/generated/asm-offsets.h
>   HOSTCC  tools/gen_eth_addr
>   HOSTCC  tools/img2srec
>   HOSTCC  tools/mkenvimage.o
>   HOSTCC  tools/os_support.o
>   WRAPtools/lib/crc32.c
>   HOSTCC  tools/lib/crc32.o
>   HOSTLD  tools/mkenvimage
>   HOSTCC  tools/aisimage.o
>   HOSTCC  tools/atmelimage.o
>   WRAPtools/common/bootm.c
>   HOSTCC  tools/common/bootm.o
>   HOSTCC  tools/default_image.o
>   WRAPtools/lib/fdtdec_common.c
>   HOSTCC  tools/lib/fdtdec_common.o
>   WRAPtools/lib/fdtdec.c
>   HOSTCC  tools/lib/fdtdec.o
>   HOSTCC  tools/fit_common.o
>   HOSTCC  tools/fit_image.o
>   WRAPtools/common/image-fit.c
>   HOSTCC  tools/common/image-fit.o
>   HOSTCC  tools/image-host.o
>   WRAPtools/common/image.c
>   HOSTCC  tools/common/image.o
>   HOSTCC  tools/imagetool.o
>   HOSTCC  tools/imximage.o
>   HOSTCC  tools/kwbimage.o
>   WRAPtools/lib/md5.c
>   HOSTCC  tools/lib/md5.o
>   HOSTCC  tools/lpc32xximage.o
>   HOSTCC  tools/mxsimage.o
>   HOSTCC  tools/omapimage.o
>   HOSTCC  tools/pblimage.o
>   HOSTCC  tools/pbl_crc32.o
>   WRAPtools/lib/rc4.c
>   HOSTCC  tools/lib/rc4.o
>   HOSTCC  tools/rkcommon.o
>   HOSTCC  tools/rkimage.o
>   HOSTCC  tools/rksd.o
>   HOSTCC  tools/rkspi.o
>   HOSTCC  tools/socfpgaimage.o
>   WRAPtools/lib/sha1.c
>   HOSTCC  tools/lib/sha1.o
>   WRAPtools/lib/sha256.c
>   HOSTCC  tools/lib/sha256.o
>   WRAPtools/common/hash.c
>   HOSTCC  tools/common/hash.o
>   HOSTCC  tools/ublimage.o
>   HOSTCC  tools/zynqimage.o
>   HOSTCC  tools/zynqmpimage.o
>   WRAPtools/lib/libfdt/fdt.c
>   HOSTCC  tools/lib/libfdt/fdt.o
>   WRAPtools/lib/libfdt/fdt_ro.c
>   HOSTCC  tools/lib/libfdt/fdt_ro.o
>   WRAPtools/lib/libfdt/fdt_rw.c
>   HOSTCC  tools/lib/libfdt/fdt_rw.o
>   WRAPtools/lib/libfdt/fdt_strerror.c
>   HOSTCC  tools/lib/libfdt/fdt_strerror.o
>   WRAPtools/lib/libfdt/fdt_wip.c
>   HOSTCC  tools/lib/libfdt/fdt_wip.o
>   WRAPtools/lib/libfdt/fdt_region.c
>   HOSTCC  tools/lib/libfdt/fdt_region.o
>   WRAPtools/lib/libfdt/fdt_sw.c
>   HOSTCC  tools/lib/libfdt/fdt_sw.o
>   HOSTCC  tools/gpimage.o
>   HOSTCC  tools/gpimage-common.o
>   HOSTCC  tools/dumpimage.o
>   HOSTLD  tools/dumpimage
>   HOSTCC  tools/mkimage.o
>   HOSTLD  tools/mkimage
>   HOSTCC  tools/proftool
>   HOSTCC  tools/fdtgrep.o
>   HOSTLD  tools/fdtgrep
>   LD  arch/arm/cpu/built-in.o
>   CC  arch/arm/cpu/armv7/cache_v7.o
>   AS  arch/arm/cpu/armv7/cache_v7_asm.o
>   CC  arch/arm/cpu/armv7/cpu.o
>   CC  arch/arm/cpu/armv7/cp15.o
>   CC  arch/arm/cpu/armv7/syslib.o
>   AS  arch/arm/cpu/armv7/nonsec_virt.o
>   CC  arch/arm/cpu/armv7/virt-v7.o
>   CC  arch/arm/cpu/armv7/virt-dt.o
>   AS  arch/arm/cpu/armv7/psci.o
>   CC  arch/arm/cpu/armv7/psci-common.o
>   LD  arch/arm/cpu/armv7/built-in.o
>   AS  arch/arm/cpu/armv7/start.o
>   AS  arch/arm/lib/vectors.o
>   AS  arch/arm/lib/crt0.o
>   AS  arch/arm/lib/relocate.o
>   CC  arch/arm/lib/bootm-fdt.o
>   CC  arch/arm/lib/bootm.o
>   CC  arch/arm/lib/zimage.o
>   AS  arch/arm/lib/memset.o
>   AS  arch/arm/lib/memcpy.o
>   CC  arch/arm/lib/sections.o
>   CC  arch/arm/lib/stack.o
>   CC  arch/arm/lib/interrupts.o
>   CC  arch/arm/lib/reset.o
>   CC  arch/arm/lib/cache.o
>   CC  arch/arm/lib/cache-cp15.o
>   CC  arch/arm/lib/psci-dt.o
>   LD  arch/arm/lib/built-in.o
>   AS  arch/arm/lib/ashldi3.o
>   AS  arch/arm/lib/ashrdi3.o
>   CC  

Re: [U-Boot] [PATCH v2 1/2] cmd: Split 'bootz' and 'booti' out from 'bootm'

[Tom Rini]

On Fri, Aug 12, 2016 at 02:49:49PM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> 2016-08-02 0:28 GMT+09:00 Tom Rini :
> > The bootz and booti commands rely on common functionality that is found
> > in common/bootm.c and common/bootm_os.c.  They do not however rely on
> > the rest of cmd/bootm.c to be implemented so split them into their own
> > files.  Have various Makefiles include the required infrastructure for
> > CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM.
> >
> > Signed-off-by: Tom Rini 
> 
> 
> If I apply this patch,
> I got a build error for the combination of
> "CONFIG_CMD_BOOTZ=y" and "# CONFIG_CMD_BOOTM is not set".
> 
> 
> $ make CROSS_COMPILE=arm-linux-gnueabi-
> scripts/kconfig/conf  --silentoldconfig Kconfig
>   CHK include/config.h
>   UPD include/config.h
>   GEN include/autoconf.mk
>   GEN include/autoconf.mk.dep
>   GEN spl/include/autoconf.mk
>   CHK include/config/uboot.release
>   UPD include/config/uboot.release
>   CHK include/generated/version_autogenerated.h
>   UPD include/generated/version_autogenerated.h
>   CHK include/generated/timestamp_autogenerated.h
>   UPD include/generated/timestamp_autogenerated.h
>   CC  lib/asm-offsets.s
>   CHK include/generated/generic-asm-offsets.h
>   UPD include/generated/generic-asm-offsets.h
>   CC  arch/arm/lib/asm-offsets.s
>   CHK include/generated/asm-offsets.h
>   UPD include/generated/asm-offsets.h
>   HOSTCC  tools/gen_eth_addr
>   HOSTCC  tools/img2srec
>   HOSTCC  tools/mkenvimage.o
>   HOSTCC  tools/os_support.o
>   WRAPtools/lib/crc32.c
>   HOSTCC  tools/lib/crc32.o
>   HOSTLD  tools/mkenvimage
>   HOSTCC  tools/aisimage.o
>   HOSTCC  tools/atmelimage.o
>   WRAPtools/common/bootm.c
>   HOSTCC  tools/common/bootm.o
>   HOSTCC  tools/default_image.o
>   WRAPtools/lib/fdtdec_common.c
>   HOSTCC  tools/lib/fdtdec_common.o
>   WRAPtools/lib/fdtdec.c
>   HOSTCC  tools/lib/fdtdec.o
>   HOSTCC  tools/fit_common.o
>   HOSTCC  tools/fit_image.o
>   WRAPtools/common/image-fit.c
>   HOSTCC  tools/common/image-fit.o
>   HOSTCC  tools/image-host.o
>   WRAPtools/common/image.c
>   HOSTCC  tools/common/image.o
>   HOSTCC  tools/imagetool.o
>   HOSTCC  tools/imximage.o
>   HOSTCC  tools/kwbimage.o
>   WRAPtools/lib/md5.c
>   HOSTCC  tools/lib/md5.o
>   HOSTCC  tools/lpc32xximage.o
>   HOSTCC  tools/mxsimage.o
>   HOSTCC  tools/omapimage.o
>   HOSTCC  tools/pblimage.o
>   HOSTCC  tools/pbl_crc32.o
>   WRAPtools/lib/rc4.c
>   HOSTCC  tools/lib/rc4.o
>   HOSTCC  tools/rkcommon.o
>   HOSTCC  tools/rkimage.o
>   HOSTCC  tools/rksd.o
>   HOSTCC  tools/rkspi.o
>   HOSTCC  tools/socfpgaimage.o
>   WRAPtools/lib/sha1.c
>   HOSTCC  tools/lib/sha1.o
>   WRAPtools/lib/sha256.c
>   HOSTCC  tools/lib/sha256.o
>   WRAPtools/common/hash.c
>   HOSTCC  tools/common/hash.o
>   HOSTCC  tools/ublimage.o
>   HOSTCC  tools/zynqimage.o
>   HOSTCC  tools/zynqmpimage.o
>   WRAPtools/lib/libfdt/fdt.c
>   HOSTCC  tools/lib/libfdt/fdt.o
>   WRAPtools/lib/libfdt/fdt_ro.c
>   HOSTCC  tools/lib/libfdt/fdt_ro.o
>   WRAPtools/lib/libfdt/fdt_rw.c
>   HOSTCC  tools/lib/libfdt/fdt_rw.o
>   WRAPtools/lib/libfdt/fdt_strerror.c
>   HOSTCC  tools/lib/libfdt/fdt_strerror.o
>   WRAPtools/lib/libfdt/fdt_wip.c
>   HOSTCC  tools/lib/libfdt/fdt_wip.o
>   WRAPtools/lib/libfdt/fdt_region.c
>   HOSTCC  tools/lib/libfdt/fdt_region.o
>   WRAPtools/lib/libfdt/fdt_sw.c
>   HOSTCC  tools/lib/libfdt/fdt_sw.o
>   HOSTCC  tools/gpimage.o
>   HOSTCC  tools/gpimage-common.o
>   HOSTCC  tools/dumpimage.o
>   HOSTLD  tools/dumpimage
>   HOSTCC  tools/mkimage.o
>   HOSTLD  tools/mkimage
>   HOSTCC  tools/proftool
>   HOSTCC  tools/fdtgrep.o
>   HOSTLD  tools/fdtgrep
>   LD  arch/arm/cpu/built-in.o
>   CC  arch/arm/cpu/armv7/cache_v7.o
>   AS  arch/arm/cpu/armv7/cache_v7_asm.o
>   CC  arch/arm/cpu/armv7/cpu.o
>   CC  arch/arm/cpu/armv7/cp15.o
>   CC  arch/arm/cpu/armv7/syslib.o
>   AS  arch/arm/cpu/armv7/nonsec_virt.o
>   CC  arch/arm/cpu/armv7/virt-v7.o
>   CC  arch/arm/cpu/armv7/virt-dt.o
>   AS  arch/arm/cpu/armv7/psci.o
>   CC  arch/arm/cpu/armv7/psci-common.o
>   LD  arch/arm/cpu/armv7/built-in.o
>   AS  arch/arm/cpu/armv7/start.o
>   AS  arch/arm/lib/vectors.o
>   AS  arch/arm/lib/crt0.o
>   AS  arch/arm/lib/relocate.o
>   CC  arch/arm/lib/bootm-fdt.o
>   CC  arch/arm/lib/bootm.o
>   CC  arch/arm/lib/zimage.o
>   AS  arch/arm/lib/memset.o
>   AS  arch/arm/lib/memcpy.o
>   CC  arch/arm/lib/sections.o
>   CC  arch/arm/lib/stack.o
>   CC  arch/arm/lib/interrupts.o
>   CC  arch/arm/lib/reset.o
>   CC  arch/arm/lib/cache.o
>   CC  arch/arm/lib/cache-cp15.o
>   CC  arch/arm/lib/psci-dt.o
>   LD  arch/arm/lib/built-in.o
>   AS  arch/arm/lib/ashldi3.o
>   AS  arch/arm/lib/ashrdi3.o
>   CC  

[U-Boot] [PATCH 2/5] clk: rk3288: add PWM clock get rate

[Kever Yang]

This patch add clk_get_rate for PWM device.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3288.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/rockchip/clk_rk3288.c 
b/drivers/clk/rockchip/clk_rk3288.c
index c07203d..bd71a96 100644
--- a/drivers/clk/rockchip/clk_rk3288.c
+++ b/drivers/clk/rockchip/clk_rk3288.c
@@ -695,6 +695,8 @@ static ulong rk3288_clk_get_rate(struct clk *clk)
case PCLK_I2C4:
case PCLK_I2C5:
return gclk_rate;
+   case PCLK_PWM:
+   return PD_BUS_PCLK_HZ;
default:
return -ENOENT;
}
-- 
1.9.1


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

[U-Boot] [PATCH 3/5] rk_pwm: use clock framework API to get module clock

[Kever Yang]

This patch use clock API instead of hardcode for get pwm clock.

Signed-off-by: Kever Yang 
---

 drivers/pwm/rk_pwm.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 2d289a4..d69aab5 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -13,9 +14,9 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -23,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
 struct rk_pwm_priv {
struct rk3288_pwm *regs;
struct rk3288_grf *grf;
+   ulong freq;
 };
 
 static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns,
@@ -38,8 +40,8 @@ static int rk_pwm_set_config(struct udevice *dev, uint 
channel, uint period_ns,
RK_PWM_DISABLE,
>ctrl);
 
-   period = lldiv((uint64_t)(PD_BUS_PCLK_HZ / 1000) * period_ns, 100);
-   duty = lldiv((uint64_t)(PD_BUS_PCLK_HZ / 1000) * duty_ns, 100);
+   period = lldiv((uint64_t)(priv->freq / 1000) * period_ns, 100);
+   duty = lldiv((uint64_t)(priv->freq / 1000) * duty_ns, 100);
 
writel(period, >period_hpr);
writel(duty, >duty_lpr);
@@ -76,9 +78,18 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
 static int rk_pwm_probe(struct udevice *dev)
 {
struct rk_pwm_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   int ret = 0;
 
rk_setreg(>grf->soc_con2, 1 << 0);
 
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0) {
+   printf("%s get clock fail!\n", __func__);
+   return -EINVAL;
+   }
+   priv->freq = clk_get_rate();
+
return 0;
 }
 
-- 
1.9.1


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

Re: [U-Boot] [PATCH] Please pull u-boot-mmc

[Tom Rini]

On Fri, Aug 12, 2016 at 04:34:01PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Here is the mmc updates.
> - Supports the Driver model for atmel_sdhci.
> - Fixed the build error for omap_hsmmc.
> 
> Could you pull these patch to u-boot/master?
> 
> Best Regards,
> Jaehoon Chung
> 
> The following changes since commit 28cd88baa3f11cdb52be3b6d0610dcf32c60871a:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-uniphier (2016-08-11 
> 10:45:53 -0400)
> 
> are available in the git repository at:
> 
> 
>   http://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to 761326b33f1a14b19c0a4f7e8c336f8ed153d00c:
> 
>   defconfig: k2g_evm_defconfig: Enable mmc driver model (2016-08-12 16:23:07 
> +0900)
> 
> 
> Sekhar Nori (4):
>   drivers: mmc: omap_hsmmc: fix build breakage
>   ARM: dts: K2G: Add support for MMC controller
>   ARM: dts: k2g-evm: enable mmc/sd suppport
>   defconfig: k2g_evm_defconfig: Enable mmc driver model
> 
> Wenyou Yang (1):
>   mmc: atmel_sdhci: Convert to the driver model support

NAK.  This atmel change, like the all of the others in their series need
to come in via Andreas' tree as it's introducing a warning due to some
other patch being required:
+   sama5d2_xplained_spiflash
+(sama5d2_xplained_spiflash)  static int clk_get_by_name(struct udevice *dev, 
const char *name,
+(sama5d2_xplained_spiflash) ^
w+(sama5d2_xplained_spiflash) In file included from 
drivers/mmc/atmel_sdhci.c:9:0:
w+(sama5d2_xplained_spiflash) include/clk.h:107:12: warning: 'clk_get_by_name' 
defined but not used [-Wunused-function]

-- 
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 2/2 v2] armv8:ls1012a: Use common MMDC driver for ls1012a

[Shengzhou Liu]

Let's use common MMDC driver for DDR initialization on
LS1012ARDB, LS1012AQDS, LS1012AFRDM boards.

Signed-off-by: Shengzhou Liu 
---
v2: no change

 board/freescale/ls1012afrdm/ls1012afrdm.c | 116 --
 board/freescale/ls1012aqds/ls1012aqds.c   | 116 --
 board/freescale/ls1012ardb/ls1012ardb.c   | 116 --
 include/configs/ls1012afrdm.h |  22 --
 include/configs/ls1012aqds.h  |  23 +-
 include/configs/ls1012ardb.h  |  21 --
 6 files changed, 54 insertions(+), 360 deletions(-)

diff --git a/board/freescale/ls1012afrdm/ls1012afrdm.c 
b/board/freescale/ls1012afrdm/ls1012afrdm.c
index a94a458..0bbb558 100644
--- a/board/freescale/ls1012afrdm/ls1012afrdm.c
+++ b/board/freescale/ls1012afrdm/ls1012afrdm.c
@@ -18,20 +18,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static void set_wait_for_bits_clear(void *ptr, u32 value, u32 bits)
-{
-   int timeout = 1000;
-
-   out_be32(ptr, value);
-
-   while (in_be32(ptr) & bits) {
-   udelay(100);
-   timeout--;
-   }
-   if (timeout <= 0)
-   puts("Error: wait for clear timeout.\n");
-}
-
 int checkboard(void)
 {
puts("Board: LS1012AFRDM ");
@@ -39,108 +25,6 @@ int checkboard(void)
return 0;
 }
 
-void mmdc_init(void)
-{
-   struct mmdc_p_regs *mmdc =
-   (struct mmdc_p_regs *)CONFIG_SYS_FSL_DDR_ADDR;
-
-   out_be32(>mdscr, CONFIGURATION_REQ);
-
-   /* configure timing parms */
-   out_be32(>mdotc,  CONFIG_SYS_MMDC_CORE_ODT_TIMING);
-   out_be32(>mdcfg0, CONFIG_SYS_MMDC_CORE_TIMING_CFG_0);
-   out_be32(>mdcfg1, CONFIG_SYS_MMDC_CORE_TIMING_CFG_1);
-   out_be32(>mdcfg2, CONFIG_SYS_MMDC_CORE_TIMING_CFG_2);
-
-   /* other parms  */
-   out_be32(>mdmisc,CONFIG_SYS_MMDC_CORE_MISC);
-   out_be32(>mpmur0,CONFIG_SYS_MMDC_PHY_MEASURE_UNIT);
-   out_be32(>mdrwd, CONFIG_SYS_MMDC_CORE_RDWR_CMD_DELAY);
-   out_be32(>mpodtctrl, CONFIG_SYS_MMDC_PHY_ODT_CTRL);
-
-   /* out of reset delays */
-   out_be32(>mdor,  CONFIG_SYS_MMDC_CORE_OUT_OF_RESET_DELAY);
-
-   /* physical parms */
-   out_be32(>mdctl, CONFIG_SYS_MMDC_CORE_CONTROL_1);
-   out_be32(>mdasp, CONFIG_SYS_MMDC_CORE_ADDR_PARTITION);
-
-   /* Enable MMDC */
-   out_be32(>mdctl, CONFIG_SYS_MMDC_CORE_CONTROL_2);
-
-   /* dram init sequence: update MRs */
-   out_be32(>mdscr, (CMD_ADDR_LSB_MR_ADDR(0x8) | CONFIGURATION_REQ |
-   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_2));
-   out_be32(>mdscr, (CONFIGURATION_REQ | CMD_LOAD_MODE_REG |
-   CMD_BANK_ADDR_3));
-   out_be32(>mdscr, (CMD_ADDR_LSB_MR_ADDR(0x4) | CONFIGURATION_REQ |
-   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_1));
-   out_be32(>mdscr, (CMD_ADDR_MSB_MR_OP(0x19) |
-   CMD_ADDR_LSB_MR_ADDR(0x30) | CONFIGURATION_REQ |
-   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_0));
-
-   /* dram init sequence: ZQCL */
-   out_be32(>mdscr, (CMD_ADDR_MSB_MR_OP(0x4) | CONFIGURATION_REQ |
-   CMD_ZQ_CALIBRATION | CMD_BANK_ADDR_0));
-   set_wait_for_bits_clear(>mpzqhwctrl,
-   CONFIG_SYS_MMDC_PHY_ZQ_HW_CTRL,
-   FORCE_ZQ_AUTO_CALIBRATION);
-
-   /* Calibrations now: wr lvl */
-   out_be32(>mdscr, (CMD_ADDR_LSB_MR_ADDR(0x84) |
-   CONFIGURATION_REQ | CMD_LOAD_MODE_REG |
-   CMD_BANK_ADDR_1));
-   out_be32(>mdscr, (CONFIGURATION_REQ | WL_EN | CMD_NORMAL));
-   set_wait_for_bits_clear(>mpwlgcr, WR_LVL_HW_EN, WR_LVL_HW_EN);
-
-   mdelay(1);
-
-   out_be32(>mdscr, (CMD_ADDR_LSB_MR_ADDR(0x4) | CONFIGURATION_REQ |
-   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_1));
-   out_be32(>mdscr, CONFIGURATION_REQ);
-
-   mdelay(1);
-
-   /* Calibrations now: Read DQS gating calibration */
-   out_be32(>mdscr, (CMD_ADDR_MSB_MR_OP(0x4) | CONFIGURATION_REQ |
-   CMD_PRECHARGE_BANK_OPEN | CMD_BANK_ADDR_0));
-   out_be32(>mdscr, (CMD_ADDR_LSB_MR_ADDR(0x4) | CONFIGURATION_REQ |
-   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_3));
-   out_be32(>mppdcmpr2, MPR_COMPARE_EN);
-   out_be32(>mprddlctl, CONFIG_SYS_MMDC_PHY_RD_DLY_LINES_CFG);
-   set_wait_for_bits_clear(>mpdgctrl0,
-   AUTO_RD_DQS_GATING_CALIBRATION_EN,
-   AUTO_RD_DQS_GATING_CALIBRATION_EN);
-
-   out_be32(>mdscr, (CONFIGURATION_REQ | CMD_LOAD_MODE_REG |
-   CMD_BANK_ADDR_3));
-
-   /* Calibrations now: Read calibration */
-   out_be32(>mdscr, (CMD_ADDR_MSB_MR_OP(0x4) | CONFIGURATION_REQ |
-   CMD_PRECHARGE_BANK_OPEN | 

[U-Boot] [PATCH 1/2 v2] driver/ddr/fsl: Add general MMDC driver

[Shengzhou Liu]

This patch adds basic support for Freescale MMDC(Multi Mode DDR Controller).
Currently MMDC is integrated on ARMv8 LS1012A SoC for DDR3L, there will be a
update to this driver to support more flexible configuration if new features
(DDR4, multiple controllers/chip selections, etc) are implimented in future.

Signed-off-by: Shengzhou Liu 
---
v2: add a compiling condition to check if CONFIG_MMDC_* is defined. 

 Makefile  |   1 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h |   4 +-
 drivers/ddr/fsl/Makefile  |   1 +
 drivers/ddr/fsl/fsl_mmdc.c| 156 ++
 include/fsl_mmdc.h|  90 ++---
 5 files changed, 204 insertions(+), 48 deletions(-)
 create mode 100644 drivers/ddr/fsl/fsl_mmdc.c

diff --git a/Makefile b/Makefile
index 99cc8cf..1bf6c6a 100644
--- a/Makefile
+++ b/Makefile
@@ -647,6 +647,7 @@ libs-y += drivers/power/ \
 libs-y += drivers/spi/
 libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
 libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
+libs-$(CONFIG_SYS_FSL_MMDC) += drivers/ddr/fsl/
 libs-$(CONFIG_ALTERA_SDRAM) += drivers/ddr/altera/
 libs-y += drivers/serial/
 libs-y += drivers/usb/dwc3/
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index b0ad4b4..d1d76be 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -15,7 +15,9 @@
 #define CONFIG_SYS_FSL_DDRC_ARM_GEN3   /* Enable Freescale ARM DDR3 driver */
 #endif
 
-#ifndef CONFIG_LS1012A
+#ifdef CONFIG_LS1012A
+#define CONFIG_SYS_FSL_MMDC/* Freescale MMDC driver */
+#else
 #define CONFIG_SYS_FSL_DDR /* Freescale DDR driver */
 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
 #endif
diff --git a/drivers/ddr/fsl/Makefile b/drivers/ddr/fsl/Makefile
index 01ea862..00dea42 100644
--- a/drivers/ddr/fsl/Makefile
+++ b/drivers/ddr/fsl/Makefile
@@ -33,3 +33,4 @@ obj-$(CONFIG_SYS_FSL_DDRC_GEN3)   += mpc85xx_ddr_gen3.o
 obj-$(CONFIG_SYS_FSL_DDR_86XX) += mpc86xx_ddr.o
 obj-$(CONFIG_SYS_FSL_DDRC_ARM_GEN3)+= arm_ddr_gen3.o
 obj-$(CONFIG_SYS_FSL_DDRC_GEN4) += fsl_ddr_gen4.o
+obj-$(CONFIG_SYS_FSL_MMDC) += fsl_mmdc.o
diff --git a/drivers/ddr/fsl/fsl_mmdc.c b/drivers/ddr/fsl/fsl_mmdc.c
new file mode 100644
index 000..1e35967
--- /dev/null
+++ b/drivers/ddr/fsl/fsl_mmdc.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/*
+ * Generic driver for Freescale MMDC(Multi Mode DDR Controller).
+ */
+
+#include 
+#include 
+#include 
+
+static void set_wait_for_bits_clear(void *ptr, u32 value, u32 bits)
+{
+   int timeout = 1000;
+
+   out_be32(ptr, value);
+
+   while (in_be32(ptr) & bits) {
+   udelay(100);
+   timeout--;
+   }
+   if (timeout <= 0)
+   printf("Error: %p wait for clear timeout.\n", ptr);
+}
+
+void mmdc_init(void)
+{
+   struct mmdc_regs *mmdc = (struct mmdc_regs *)CONFIG_SYS_FSL_DDR_ADDR;
+   unsigned int tmp;
+
+   /* 1. set configuration request */
+   out_be32(>mdscr, MDSCR_ENABLE_CON_REQ);
+
+   /* 2. configure the desired timing parameters */
+   out_be32(>mdotc,  CONFIG_MMDC_MDOTC);
+   out_be32(>mdcfg0, CONFIG_MMDC_MDCFG0);
+   out_be32(>mdcfg1, CONFIG_MMDC_MDCFG1);
+   out_be32(>mdcfg2, CONFIG_MMDC_MDCFG2);
+
+   /* 3. configure DDR type and other miscellaneous parameters */
+   out_be32(>mdmisc, CONFIG_MMDC_MDMISC);
+   out_be32(>mpmur0, MMDC_MPMUR0_FRC_MSR);
+   out_be32(>mdrwd,  CONFIG_MMDC_MDRWD);
+   out_be32(>mpodtctrl, CONFIG_MMDC_MPODTCTRL);
+
+   /* 4. configure the required delay while leaving reset */
+   out_be32(>mdor,  CONFIG_MMDC_MDOR);
+
+   /* 5. configure DDR physical parameters */
+   /* set row/column address width, burst length, data bus width */
+   tmp = CONFIG_MMDC_MDCTL & ~(MDCTL_SDE0 | MDCTL_SDE1);
+   out_be32(>mdctl, tmp);
+   /* configure address space partition */
+   out_be32(>mdasp, CONFIG_MMDC_MDASP);
+
+   /* 6. perform a ZQ calibration - not needed here, doing in #8b */
+
+   /* 7. enable MMDC with the desired chip select */
+#if (CONFIG_CHIP_SELECTS_PER_CTRL == 1)
+   out_be32(>mdctl, tmp | MDCTL_SDE0);
+#elif (CONFIG_CHIP_SELECTS_PER_CTRL == 2)
+   out_be32(>mdctl, tmp | MDCTL_SDE0 | MDCTL_SDE1);
+#endif
+
+   /* 8a. dram init sequence: update MRs for ZQ, ODT, PRE, etc */
+   out_be32(>mdscr,  CMD_ADDR_LSB_MR_ADDR(8) | MDSCR_ENABLE_CON_REQ |
+   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_2);
+
+   out_be32(>mdscr,  CMD_ADDR_LSB_MR_ADDR(0) | MDSCR_ENABLE_CON_REQ |
+   CMD_LOAD_MODE_REG | CMD_BANK_ADDR_3);
+
+   out_be32(>mdscr,  CMD_ADDR_LSB_MR_ADDR(4) | 

[U-Boot] [PATCH 1/5] clk: rk3399: add pmucru controller support

[Kever Yang]

pmucru is a module like cru which is a clock controller manage some PLL
and module clocks.

Signed-off-by: Kever Yang 
---

 drivers/clk/rockchip/clk_rk3399.c | 177 +-
 1 file changed, 173 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/rockchip/clk_rk3399.c 
b/drivers/clk/rockchip/clk_rk3399.c
index 0b4ea82..ea0ce2a 100644
--- a/drivers/clk/rockchip/clk_rk3399.c
+++ b/drivers/clk/rockchip/clk_rk3399.c
@@ -23,6 +23,10 @@ struct rk3399_clk_priv {
ulong rate;
 };
 
+struct rk3399_pmuclk_priv {
+   struct rk3399_pmucru *pmucru;
+};
+
 struct pll_div {
u32 refdiv;
u32 fbdiv;
@@ -95,11 +99,11 @@ enum {
 
/* PMUCRU_CLKSEL_CON2 */
I2C_DIV_CON_MASK= 0x7f,
-   I2C8_DIV_CON_SHIFT  = 8,
-   I2C0_DIV_CON_SHIFT  = 0,
+   CLK_I2C8_DIV_CON_SHIFT  = 8,
+   CLK_I2C0_DIV_CON_SHIFT  = 0,
 
/* PMUCRU_CLKSEL_CON3 */
-   I2C4_DIV_CON_SHIFT  = 0,
+   CLK_I2C4_DIV_CON_SHIFT  = 0,
 
/* CLKSEL_CON0 */
ACLKM_CORE_L_DIV_CON_SHIFT  = 8,
@@ -507,6 +511,14 @@ void rk3399_configure_cpu(struct rk3399_cru *cru,
(con >> CLK_I2C ##bus## _DIV_CON_SHIFT) & \
I2C_DIV_CON_MASK;
 
+#define I2C_PMUCLK_REG_MASK(bus) \
+   (I2C_DIV_CON_MASK << \
+CLK_I2C ##bus## _DIV_CON_SHIFT)
+
+#define I2C_PMUCLK_REG_VALUE(bus, clk_div) \
+   ((clk_div - 1) << \
+   CLK_I2C ##bus## _DIV_CON_SHIFT)
+
 static ulong rk3399_i2c_get_clk(struct rk3399_cru *cru, ulong clk_id)
 {
u32 div, con;
@@ -754,7 +766,7 @@ static ulong rk3399_clk_set_rate(struct clk *clk, ulong 
rate)
break;
case DCLK_VOP0:
case DCLK_VOP1:
-   rate = rk3399_vop_set_clk(priv->cru, clk->id, rate);
+   ret = rk3399_vop_set_clk(priv->cru, clk->id, rate);
break;
default:
return -ENOENT;
@@ -830,3 +842,160 @@ U_BOOT_DRIVER(clk_rk3399) = {
.bind   = rk3399_clk_bind,
.probe  = rk3399_clk_probe,
 };
+
+static ulong rk3399_i2c_get_pmuclk(struct rk3399_pmucru *pmucru, ulong clk_id)
+{
+   u32 div, con;
+
+   switch (clk_id) {
+   case SCLK_I2C0_PMU:
+   con = readl(>pmucru_clksel[2]);
+   div = I2C_CLK_DIV_VALUE(con, 0);
+   break;
+   case SCLK_I2C4_PMU:
+   con = readl(>pmucru_clksel[3]);
+   div = I2C_CLK_DIV_VALUE(con, 4);
+   break;
+   case SCLK_I2C8_PMU:
+   con = readl(>pmucru_clksel[2]);
+   div = I2C_CLK_DIV_VALUE(con, 8);
+   break;
+   default:
+   printf("do not support this i2c bus\n");
+   return -EINVAL;
+   }
+
+   return DIV_TO_RATE(PPLL_HZ, div);
+}
+
+static ulong rk3399_i2c_set_pmuclk(struct rk3399_pmucru *pmucru, ulong clk_id,
+  uint hz)
+{
+   int src_clk_div;
+
+   src_clk_div = PPLL_HZ / hz;
+   assert(src_clk_div - 1 < 127);
+
+   switch (clk_id) {
+   case SCLK_I2C0_PMU:
+   rk_clrsetreg(>pmucru_clksel[2], I2C_PMUCLK_REG_MASK(0),
+I2C_PMUCLK_REG_VALUE(0, src_clk_div));
+   break;
+   case SCLK_I2C4_PMU:
+   rk_clrsetreg(>pmucru_clksel[3], I2C_PMUCLK_REG_MASK(4),
+I2C_PMUCLK_REG_VALUE(4, src_clk_div));
+   break;
+   case SCLK_I2C8_PMU:
+   rk_clrsetreg(>pmucru_clksel[2], I2C_PMUCLK_REG_MASK(8),
+I2C_PMUCLK_REG_VALUE(8, src_clk_div));
+   break;
+   default:
+   printf("do not support this i2c bus\n");
+   return -EINVAL;
+   }
+
+   return DIV_TO_RATE(PPLL_HZ, src_clk_div);
+}
+
+static ulong rk3399_pwm_get_clk(struct rk3399_pmucru *pmucru)
+{
+   u32 div, con;
+
+   /* PWM closk rate is same as pclk_pmu */
+   con = readl(>pmucru_clksel[0]);
+   div = con & PMU_PCLK_DIV_CON_MASK;
+
+   return DIV_TO_RATE(PPLL_HZ, div);
+}
+
+static ulong rk3399_pmuclk_get_rate(struct clk *clk)
+{
+   struct rk3399_pmuclk_priv *priv = dev_get_priv(clk->dev);
+   ulong rate = 0;
+
+   switch (clk->id) {
+   case PCLK_RKPWM_PMU:
+   rate = rk3399_pwm_get_clk(priv->pmucru);
+   break;
+   case SCLK_I2C0_PMU:
+   case SCLK_I2C4_PMU:
+   case SCLK_I2C8_PMU:
+   rate = rk3399_i2c_get_pmuclk(priv->pmucru, clk->id);
+   break;
+   default:
+   return -ENOENT;
+   }
+
+   return rate;
+}
+
+static ulong rk3399_pmuclk_set_rate(struct clk *clk, ulong rate)
+{
+   struct rk3399_pmuclk_priv *priv = dev_get_priv(clk->dev);
+   ulong ret = 0;
+
+   

[U-Boot] [PATCH 0/5] clean rkpwm driver

[Kever Yang]

This patch set clean the rkpwm driver by using clock API for module
clock instead of hardcode, move the grf setting to soc level init.



Kever Yang (5):
  clk: rk3399: add pmucru controller support
  clk: rk3288: add PWM clock get rate
  rk_pwm: use clock framework API to get module clock
  rk_pwm: remove grf setting code from driver
  rk3288: add arch_cpu_init for rk3288

 arch/arm/mach-rockchip/rk3288/Makefile |   1 +
 arch/arm/mach-rockchip/rk3288/rk3288.c |  19 
 drivers/clk/rockchip/clk_rk3288.c  |   2 +
 drivers/clk/rockchip/clk_rk3399.c  | 177 -
 drivers/pwm/rk_pwm.c   |  26 ++---
 5 files changed, 208 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/mach-rockchip/rk3288/rk3288.c

-- 
1.9.1


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

Re: [U-Boot] [PATCH v2 2/5] mpc85xx/powerpc:P1010: Apply errata A006261 for P1010

[Sriram Dash]

>From: york sun
>
>Sriram,
>
>Same comment here, please fix the subject.
>

Ok. Will modify patch title and commit message in v3.

>On 07/17/2016 08:47 PM, Sriram Dash wrote:
>> Apply USB errata A006261 for P1010.
>
>A006261 is already applied to P1010.
>
>
>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>  arch/powerpc/include/asm/config_mpc85xx.h | 1 +
>>  arch/powerpc/include/asm/immap_85xx.h | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
>> b/arch/powerpc/include/asm/config_mpc85xx.h
>> index 505d355..9b7feda 100644
>> --- a/arch/powerpc/include/asm/config_mpc85xx.h
>> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
>> @@ -162,6 +162,7 @@
>>  #define CONFIG_SYS_FSL_ERRATUM_I2C_A004447
>>  #define CONFIG_SYS_FSL_ERRATUM_A004508  #define
>> CONFIG_SYS_FSL_ERRATUM_A007075
>> +#define CONFIG_SYS_FSL_USB1_PHY_ENABLE
>
>This is not enabling A006261. Please rewrite the commit message.
>

Ok. Will modify patch title and commit message in v3.

>>  #define CONFIG_SYS_FSL_ERRATUM_A006261  #define
>> CONFIG_SYS_FSL_ERRATUM_A004477
>>  #define CONFIG_SYS_FSL_A004447_SVR_REV  0x10
>> diff --git a/arch/powerpc/include/asm/immap_85xx.h
>> b/arch/powerpc/include/asm/immap_85xx.h
>> index c045a24..07ad22d 100644
>> --- a/arch/powerpc/include/asm/immap_85xx.h
>> +++ b/arch/powerpc/include/asm/immap_85xx.h
>> @@ -2953,6 +2953,8 @@ struct ccsr_pman {
>>  #define CONFIG_SYS_MPC85xx_DMA_OFFSET   0x21000
>>  #define CONFIG_SYS_MPC85xx_USB1_OFFSET  0x22000
>>  #define CONFIG_SYS_MPC85xx_USB2_OFFSET  0x23000
>> +#define CONFIG_SYS_MPC85xx_USB1_PHY_OFFSET  0xE5000
>> +#define CONFIG_SYS_MPC85xx_USB2_PHY_OFFSET  0xE5100
>
>This is not for the workaround.
>
>York
>

Ok. Will modify patch title and commit message in v3.

>
>>  #ifdef CONFIG_TSECV2
>>  #define CONFIG_SYS_TSEC1_OFFSET 0xB
>>  #elif defined(CONFIG_TSECV2_1)
>>

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

Re: [U-Boot] [PATCH v2 5/5] mpc85xx/powerpc: Do not apply errata A006261 for T4160, T1040, T2080

[Sriram Dash]

>From: york sun
>On 07/17/2016 08:47 PM, Sriram Dash wrote:
>> Do not apply errata A006261 for T4160 and T4080(rev 1.0, 2.0),
>> T1040(rev 1.0), T2080(rev 1.0), T2081(rev 1.0).
>
>I don't see mentioning the revision numbers helps here. Your patch is removing 
>the
>erratum from T4160, T4080, T1040, T1042, T1020, T1022, T2080, T2081. It would
>be much clear if you put all A006261 related patches into one, and list all 
>the SoCs
>affected by this erratum since the official released document contradicts with 
>your
>list.
>
>York
>

Ok. I will divide the patchset into 3 patches. First patch for modifying the 
erratum.
Second patch for enabling the init for P1010 so that erratum can be applied on 
it.
Third patch to take care of the Socs addition and deletion.

>
>>
>> Signed-off-by: Sriram Dash 
>> Signed-off-by: Rajesh Bhagat 
>> ---
>>  arch/powerpc/include/asm/config_mpc85xx.h | 4 +---
>>  drivers/usb/common/fsl-errata.c   | 7 ---
>>  2 files changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
>> b/arch/powerpc/include/asm/config_mpc85xx.h
>> index 9b7feda..6d845e8 100644
>> --- a/arch/powerpc/include/asm/config_mpc85xx.h
>> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
>> @@ -641,6 +641,7 @@
>>  #define CONFIG_SYS_NUM_FM2_DTSEC8
>>  #define CONFIG_SYS_NUM_FM2_10GEC2
>>  #define CONFIG_NUM_DDR_CONTROLLERS  3
>> +#define CONFIG_SYS_FSL_ERRATUM_A006261
>>  #else
>>  #define CONFIG_SYS_NUM_FM1_DTSEC6
>>  #define CONFIG_SYS_NUM_FM1_10GEC1
>> @@ -682,7 +683,6 @@
>>  #define CONFIG_SYS_FSL_ERRATUM_A004468  #define
>> CONFIG_SYS_FSL_ERRATUM_A_004934  #define
>> CONFIG_SYS_FSL_ERRATUM_A005871 -#define
>CONFIG_SYS_FSL_ERRATUM_A006261
>> #define CONFIG_SYS_FSL_ERRATUM_A006379  #define
>> CONFIG_SYS_FSL_ERRATUM_A007186  #define
>CONFIG_SYS_FSL_ERRATUM_A006593
>> @@ -800,7 +800,6 @@ defined(CONFIG_PPC_T1020) ||
>defined(CONFIG_PPC_T1022)
>>  #define CONFIG_SYS_FSL_PCIE_COMPAT  "fsl,qoriq-pcie-v2.4"
>>  #define CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE
>>  #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY
>> -#define CONFIG_SYS_FSL_ERRATUM_A006261
>>  #define CONFIG_SYS_CCSRBAR_DEFAULT  0xfe00
>>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111  #define
>> ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE @@ -908,7 +907,6 @@
>> defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)  #define
>> CONFIG_SYS_FSL_SFP_VER_3_0
>>  #define CONFIG_SYS_FSL_ISBC_VER 2
>>  #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 -#define
>> CONFIG_SYS_FSL_ERRATUM_A006261  #define
>CONFIG_SYS_FSL_ERRATUM_A006593
>> #define CONFIG_SYS_FSL_ERRATUM_A007186  #define
>> CONFIG_SYS_FSL_ERRATUM_A006379 diff --git
>> a/drivers/usb/common/fsl-errata.c b/drivers/usb/common/fsl-errata.c
>> index 765b25a..972016c 100644
>> --- a/drivers/usb/common/fsl-errata.c
>> +++ b/drivers/usb/common/fsl-errata.c
>> @@ -64,14 +64,7 @@ bool has_erratum_a006261(void)
>>  case SVR_P5021:
>>  return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0);
>>  case SVR_T4240:
>> -case SVR_T4160:
>> -case SVR_T4080:
>>  return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 2, 0);
>> -case SVR_T1040:
>> -return IS_SVR_REV(svr, 1, 0);
>> -case SVR_T2080:
>> -case SVR_T2081:
>> -return IS_SVR_REV(svr, 1, 0);
>>  case SVR_P5040:
>>  return IS_SVR_REV(svr, 1, 0) ||
>>  IS_SVR_REV(svr, 2, 0) || IS_SVR_REV(svr, 2, 1);
>>

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

Re: [U-Boot] [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver

[york sun]

I am not suggesting remove the macros. Please try to compile after applying 
first patch. You will see the errors

York


 Original Message 
From: Shengzhou Liu 
Sent: Thursday, August 11, 2016 08:44 PM
To: york sun ,u-boot@lists.denx.de
Subject: RE: [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver


> -Original Message-
> From: york sun
> Sent: Friday, August 12, 2016 3:45 AM
> To: Shengzhou Liu ; u-boot@lists.denx.de
> Subject: Re: [PATCH 1/2] driver/ddr/fsl: Add general MMDC driver
>
> > +#define CMD_ADDR_MSB_MR_OP(x) (x << 24)
> > +#define CMD_ADDR_LSB_MR_ADDR(x) (x << 16)
> > +#define MDSCR_DISABLE_CFG_REQ   (0 << 15)
> > +#define MDSCR_ENABLE_CON_REQ (1 << 15)
> > +#define MDSCR_CON_ACK (1 << 14)
> > +#define MDSCR_WL_EN (1 << 9)
> > +#define CMD_NORMAL (0 << 4)
> > +#define CMD_PRECHARGE (1 << 4)
> > +#define CMD_AUTO_REFRESH (2 << 4)
> > +#define CMD_LOAD_MODE_REG (3 << 4)
> > +#define CMD_ZQ_CALIBRATION (4 << 4)
> > +#define CMD_PRECHARGE_BANK_OPEN (5 << 4)
> > +#define CMD_MRR (6 << 4)
> >  #define CMD_BANK_ADDR_0 0x0
> >  #define CMD_BANK_ADDR_1 0x1
> >  #define CMD_BANK_ADDR_2 0x2
>
> Removing those macros causes compiling error for ls1012afrdm_qspi
> ls1012aqds_qspi ls1012ardb_qspi. Please rearrange the change.
>
> York

Why do you want to remove those macros? They are needed and useful, I compiled 
it for ls1012a QDS/ RDB/FRDM without any issue, and worked fine on boards.

Shengzhou

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

Re: [U-Boot] Older u-boot mangles UBI from ubinize 1.5.2

[Heiko Schocher]

Hello Richard,

Am 11.08.2016 um 11:51 schrieb Richard Weinberger:

Hi!

On Thu, Aug 11, 2016 at 4:26 AM, J Mo  wrote:

I tried re-flashing my UBI and tftpbooting my kernel before u-boot could
ever get a chance to mangle it, and now I get much further, though I'm still
not able to mount my rootfs for unknown reasons:

 [3.772502] ubi0: attaching mtd11
 [3.826477] UBI: EOF marker found, PEBs from 40 will be erased


WTF is this?
Reading the corresponding patch makes me very sad.


 [3.826638] ubi0: scanning is finished
 [3.872936] ubi0: volume 2 ("rootfs_data") re-sized from 9 to 430
LEBs
 [3.873734] ubi0: attached mtd11 (name "rootfs", size 64 MiB)
 [3.878347] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976
bytes
 [3.884234] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size
2048
 [3.890936] ubi0: VID header offset: 2048 (aligned 2048), data
offset: 4096
 [3.897849] ubi0: good PEBs: 512, bad PEBs: 0, corrupted PEBs: 0
 [3.904627] ubi0: user volume: 3, internal volumes: 1, max. volumes
count: 128
 [3.910815] ubi0: max/mean erase counter: 1/0, WL threshold: 4096,
image sequence number: 2142265782
 [3.917902] ubi0: available PEBs: 0, total reserved PEBs: 512, PEBs
reserved for bad PEB handling: 40
 [3.927275] ubi0: background thread "ubi_bgt0d" started, PID 54
 [3.937007] block ubiblock0_1: created from ubi0:1(rootfs)
 [3.942096] hctosys: unable to open rtc device (rtc0)
 [3.956528] VFS: Cannot open root device "ubi0:rootfs" or
unknown-block(31,11): error -2
 [3.956556] Please append a correct "root=" boot option; here are the
available partitions:



Any advice on this? Any background information that I can read up on? My
google searches have not come up with much. Ram knew about this, but I don't
know if it's otherwise a known issue.

The process works fine on the OEM system, so I assume this is some ubinize
format change which is incompatible with the older u-boot. Or, the newer
kernel code doesn't know how to deal with the UBI once the older u-boot has
mangled/attached it.

Seems like a backwards incompatibility issue.


Since OpenWRT/LEDE folks did more or less a hard fork of UBI I'm
ignoring this issue.


Ufff thanks for this info!


If you encounter something like that using vanilla UBI I'm all ears.

That said, I kind of understand that you, OpenWRT/LEDE, have a pile of
patches for auto probing rootfs
and other runtime stuff but touching the UBI on-flash format is beyond funny.
Doing so opens a can of worms and is painful for all parties. There
are customers which build their
products using OpenWrt and when they change the kernel at some point
it will get nasty.

This situation needs to be improved now. I invite you to discuss this
changes here on linux-mtd.
Especially the stuff where you change the on-flash format.
If UBI, or MTD in general, can do a better job in some areas, please
tell such that a decent solution can be found.
But your ad-hoc hacks need to stop.


Full Ack.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] building u-boot x86 with device tree disabled , still refers to device tree function

[Bin Meng]

Hi,

On Thu, Aug 11, 2016 at 10:36 PM, Ding, ChiX  wrote:
> Hi there
> I'm building u-boot as payload for x86 platform. I didn't enable device tree 
> in menuconfig (CONFIG_OF_CONTROL is not set) because I use a board config 
> file coreboot.h. When I built u-boot, it reports error during linking stage : 
> undefined reference to dm_scan_fdt_dev
>

Which board are you building?

> arch/x86/lib/built-in.o:(.u_boot_list_2_uclass_2_lpc+0x8): undefined 
> reference to `dm_scan_fdt_dev'
> common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/built-in.o:(.u_boot_list_2_uclass_2_pch+0x8): undefined reference to 
> `dm_scan_fdt_dev'
> drivers/pci/built-in.o:(.u_boot_list_2_uclass_2_pci+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/spi/built-in.o:(.u_boot_list_2_uclass_2_spi+0x8): undefined reference 
> to `dm_scan_fdt_dev'
> drivers/usb/host/built-in.o:(.u_boot_list_2_uclass_2_usb+0x8): more undefined 
> references to `dm_scan_fdt_dev' follow
> Makefile:1189: recipe for target 'u-boot' failed
>
> I looked at the code and see arch/x86/lib/lpc-uclass.c refers to a function 
> "dm_scan_fdt_dev " which is defined in drivers/core/root.c and it looks like 
> a device tree function
>
>
> UCLASS_DRIVER(lpc) = {
> .id = UCLASS_LPC,
> .name   = "lpc",
> .post_bind  = dm_scan_fdt_dev,
> };
>
> Because device tree isn't enabled, the function isn't compiled and causes the 
> problem while linking.
> It's only compiled when the following is true
> #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
> If I comment out the line, it would compile and build. But I'm not sure if 
> it's the right way to do it.
>
> Is it normal behavior? I thought that when not enabling device tree, the code 
> shouldn't use device tree function?
> Can anyone help on this please?
>

Please refer to README.x86 for how to build U-Boot as the coreboot payload.

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