[U-Boot] [PATCH v2] arm: mvebu: theadorable: Enable video / LCD support with the new DM driver

2019-01-29 Thread Stefan Roese
With the new DM_VIDEO support in the Armada XP LCD driver, this patch
adds the needed DT node for the LCD controller to the theadorable dts
file. This DT property is not added to the Armada XP dtsi files, as this
LCD feature is pretty unusual for this SoC and I personally know of no
other board that uses this controller.

This patch also enables CONFIG_BMP_16BPP/24BPP/32BPP, as the "old" bmp
command supported these BMP files.

Signed-off-by: Stefan Roese 
Reviewed-by: Anatolij Gustschin 
---
v2:
- Remove theadorable_debug_config change (its included in the video driver
  patch now)
- Commit text reworded because of this

 arch/arm/dts/armada-xp-theadorable.dts | 25 +
 include/configs/theadorable.h  |  4 
 2 files changed, 29 insertions(+)

diff --git a/arch/arm/dts/armada-xp-theadorable.dts 
b/arch/arm/dts/armada-xp-theadorable.dts
index 9b66ec678d..5695e9b758 100644
--- a/arch/arm/dts/armada-xp-theadorable.dts
+++ b/arch/arm/dts/armada-xp-theadorable.dts
@@ -159,6 +159,31 @@
spi-max-frequency = <2777>;
};
};
+
+   /* The LCD controller is only used on this board */
+   lcd0: lcd-controller@e {
+   compatible = "marvell,armada-xp-lcd";
+   reg = <0xe 0x1>;
+   status = "okay";
+   u-boot,dm-pre-reloc;
+
+   display-timings {
+   native-mode = <>;
+   timing0: panel0 {
+   hactive = <240>;
+   vactive = <320>;
+   hfront-porch = <1>;
+   hback-porch = <45>;
+   vfront-porch = <1>;
+   vback-porch = <3>;
+
+   /* Some dummy parameters */
+   clock-frequency = <0>;
+   hsync-len = <0>;
+   vsync-len = <0>;
+   };
+   };
+   };
};
};
 };
diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h
index 6837d55507..d0c75757ed 100644
--- a/include/configs/theadorable.h
+++ b/include/configs/theadorable.h
@@ -65,6 +65,10 @@
 /* Enable LCD and reserve 512KB from top of memory*/
 #define CONFIG_SYS_MEM_TOP_HIDE0x8
 
+#define CONFIG_BMP_16BPP
+#define CONFIG_BMP_24BPP
+#define CONFIG_BMP_32BPP
+
 /* FPGA programming support */
 #define CONFIG_FPGA_STRATIX_V
 
-- 
2.20.1

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


[U-Boot] [PATCH v2] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Stefan Roese
This patch moves the Armada XP video / LCD driver to DM_VIDEO. With this
move, the legacy interface board_video_init() is removed from the
theadorable board code (only user of this video driver). The support
via DT will be added in a separate patch.

This patch also enables DM_VIDEO for the theadorable board, as this is
needed to not break git bisect'ability.

Signed-off-by: Stefan Roese 
Reviewed-by: Anatolij Gustschin 
---
v2:
- Add DM_VIDEO in theadorable_debug_defconfig in this patch

 arch/arm/mach-mvebu/include/mach/cpu.h |  12 -
 board/theadorable/theadorable.c|  16 --
 configs/theadorable_debug_defconfig|   3 +-
 drivers/video/mvebu_lcd.c  | 321 +++--
 4 files changed, 193 insertions(+), 159 deletions(-)

diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 85d7dd1610..9e23043a48 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -158,18 +158,6 @@ int serdes_phy_config(void);
  */
 int ddr3_init(void);
 
-struct mvebu_lcd_info {
-   u32 fb_base;
-   int x_res;
-   int y_res;
-   int x_fp;   /* frontporch */
-   int y_fp;
-   int x_bp;   /* backporch */
-   int y_bp;
-};
-
-int mvebu_lcd_register_init(struct mvebu_lcd_info *lcd_info);
-
 /*
  * get_ref_clk
  *
diff --git a/board/theadorable/theadorable.c b/board/theadorable/theadorable.c
index 1169d67746..acd46b0026 100644
--- a/board/theadorable/theadorable.c
+++ b/board/theadorable/theadorable.c
@@ -222,22 +222,6 @@ int board_eth_init(bd_t *bis)
 }
 #endif
 
-int board_video_init(void)
-{
-   struct mvebu_lcd_info lcd_info;
-
-   /* Reserved memory area via CONFIG_SYS_MEM_TOP_HIDE */
-   lcd_info.fb_base= gd->ram_size;
-   lcd_info.x_res  = 240;
-   lcd_info.x_fp   = 1;
-   lcd_info.x_bp   = 45;
-   lcd_info.y_res  = 320;
-   lcd_info.y_fp   = 1;
-   lcd_info.y_bp   = 3;
-
-   return mvebu_lcd_register_init(_info);
-}
-
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
diff --git a/configs/theadorable_debug_defconfig 
b/configs/theadorable_debug_defconfig
index ac6dfd6844..a7d02e957a 100644
--- a/configs/theadorable_debug_defconfig
+++ b/configs/theadorable_debug_defconfig
@@ -71,6 +71,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
+CONFIG_DM_VIDEO=y
 CONFIG_VIDEO_MVEBU=y
-CONFIG_VIDEO=y
-# CONFIG_VIDEO_SW_CURSOR is not set
diff --git a/drivers/video/mvebu_lcd.c b/drivers/video/mvebu_lcd.c
index 5bf0d01faa..dc6254514a 100644
--- a/drivers/video/mvebu_lcd.c
+++ b/drivers/video/mvebu_lcd.c
@@ -6,74 +6,96 @@
  */
 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#define MVEBU_LCD_WIN_CONTROL(w)(MVEBU_LCD_BASE + 0xf000 + ((w) << 4))
-#define MVEBU_LCD_WIN_BASE(w)   (MVEBU_LCD_BASE + 0xf004 + ((w) << 4))
-#define MVEBU_LCD_WIN_REMAP(w)  (MVEBU_LCD_BASE + 0xf00c + ((w) << 4))
-
-#define MVEBU_LCD_CFG_DMA_START_ADDR_0 (MVEBU_LCD_BASE + 0x00cc)
-#define MVEBU_LCD_CFG_DMA_START_ADDR_1 (MVEBU_LCD_BASE + 0x00dc)
-
-#define MVEBU_LCD_CFG_GRA_START_ADDR0  (MVEBU_LCD_BASE + 0x00f4)
-#define MVEBU_LCD_CFG_GRA_START_ADDR1  (MVEBU_LCD_BASE + 0x00f8)
-#define MVEBU_LCD_CFG_GRA_PITCH(MVEBU_LCD_BASE + 0x00fc)
-#define MVEBU_LCD_SPU_GRA_OVSA_HPXL_VLN(MVEBU_LCD_BASE + 0x0100)
-#define MVEBU_LCD_SPU_GRA_HPXL_VLN (MVEBU_LCD_BASE + 0x0104)
-#define MVEBU_LCD_SPU_GZM_HPXL_VLN (MVEBU_LCD_BASE + 0x0108)
-#define MVEBU_LCD_SPU_HWC_OVSA_HPXL_VLN(MVEBU_LCD_BASE + 0x010c)
-#define MVEBU_LCD_SPU_HWC_HPXL_VLN (MVEBU_LCD_BASE + 0x0110)
-#define MVEBU_LCD_SPUT_V_H_TOTAL   (MVEBU_LCD_BASE + 0x0114)
-#define MVEBU_LCD_SPU_V_H_ACTIVE   (MVEBU_LCD_BASE + 0x0118)
-#define MVEBU_LCD_SPU_H_PORCH  (MVEBU_LCD_BASE + 0x011c)
-#define MVEBU_LCD_SPU_V_PORCH  (MVEBU_LCD_BASE + 0x0120)
-#define MVEBU_LCD_SPU_BLANKCOLOR   (MVEBU_LCD_BASE + 0x0124)
-#define MVEBU_LCD_SPU_ALPHA_COLOR1 (MVEBU_LCD_BASE + 0x0128)
-#define MVEBU_LCD_SPU_ALPHA_COLOR2 (MVEBU_LCD_BASE + 0x012c)
-#define MVEBU_LCD_SPU_COLORKEY_Y   (MVEBU_LCD_BASE + 0x0130)
-#define MVEBU_LCD_SPU_COLORKEY_U   (MVEBU_LCD_BASE + 0x0134)
-#define MVEBU_LCD_SPU_COLORKEY_V   (MVEBU_LCD_BASE + 0x0138)
-#define MVEBU_LCD_CFG_RDREG4F  (MVEBU_LCD_BASE + 0x013c)
-#define MVEBU_LCD_SPU_SPI_RXDATA   (MVEBU_LCD_BASE + 0x0140)
-#define MVEBU_LCD_SPU_ISA_RXDATA   (MVEBU_LCD_BASE + 0x0144)
-#define MVEBU_LCD_SPU_DBG_ISA  (MVEBU_LCD_BASE + 0x0148)
-
-#define MVEBU_LCD_SPU_HWC_RDDAT(MVEBU_LCD_BASE + 0x0158)
-#define MVEBU_LCD_SPU_GAMMA_RDDAT  (MVEBU_LCD_BASE + 0x015c)
-#define MVEBU_LCD_SPU_PALETTE_RDDAT(MVEBU_LCD_BASE + 0x0160)
-#define MVEBU_LCD_SPU_IOPAD_IN (MVEBU_LCD_BASE + 0x0178)
-#define MVEBU_LCD_FRAME_COUNT   

[U-Boot] [PATCH v2] video: bmp: Add support for 24bpp BMP files on 16bpp displays

2019-01-29 Thread Stefan Roese
This patch adds support to load 24bpp BMP files on 16bpp displays. This
will be used by the theadorable board. The "old" bmp command did support
this operartion mode and to not break compatibility with the move to
DM_VIDEO, we need to add this support to the "new" bmp code.

Signed-off-by: Stefan Roese 
Reviewed-by: Anatolij Gustschin 
---
v2:
- No change

 drivers/video/video_bmp.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/video/video_bmp.c b/drivers/video/video_bmp.c
index 2898b0b55d..193f37d275 100644
--- a/drivers/video/video_bmp.c
+++ b/drivers/video/video_bmp.c
@@ -229,11 +229,12 @@ int video_bmp_display(struct udevice *dev, ulong 
bmp_image, int x, int y,
}
 
/*
-* We support displaying 8bpp BMPs on 16bpp LCDs
+* We support displaying 8bpp and 24bpp BMPs on 16bpp LCDs
 * and displaying 24bpp BMPs on 32bpp LCDs
-* */
+*/
if (bpix != bmp_bpix &&
!(bmp_bpix == 8 && bpix == 16) &&
+   !(bmp_bpix == 24 && bpix == 16) &&
!(bmp_bpix == 24 && bpix == 32)) {
printf("Error: %d bit/pixel mode, but BMP has %d bit/pixel\n",
   bpix, get_unaligned_le16(>header.bit_count));
@@ -318,12 +319,22 @@ int video_bmp_display(struct udevice *dev, ulong 
bmp_image, int x, int y,
case 24:
for (i = 0; i < height; ++i) {
for (j = 0; j < width; j++) {
-   *(fb++) = *(bmap++);
-   *(fb++) = *(bmap++);
-   *(fb++) = *(bmap++);
-   *(fb++) = 0;
+   if (bpix == 16) {
+   /* 16bit 555RGB format */
+   *(u16 *)fb = ((bmap[2] >> 3) << 10) |
+   ((bmap[1] >> 3) << 5) |
+   (bmap[0] >> 3);
+   bmap += 3;
+   fb += 2;
+   } else {
+   *(fb++) = *(bmap++);
+   *(fb++) = *(bmap++);
+   *(fb++) = *(bmap++);
+   *(fb++) = 0;
+   }
}
fb -= priv->line_length + width * (bpix / 8);
+   bmap += (padded_width - width) * 3;
}
break;
 #endif /* CONFIG_BMP_24BPP */
-- 
2.20.1

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


Re: [U-Boot] [PATCH] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Stefan Roese

Hi Anatolij,

On 30.01.19 08:46, Anatolij Gustschin wrote:

Hi Stefan,

On Wed, 30 Jan 2019 08:39:52 +0100
Stefan Roese s...@denx.de wrote:
...

Yes, this should work as well. I'll send v2 shortly.

Will you pull the video driver patch, or should I pull it via
the Marvell tree with the other updates?


Do you run Travis-CI build tests for Marvell tree? If yes, then
it is okay if it goes via Marvell tree.


Yes, I always run this test before sending the pull request the
Tom (even though it takes like half a day to complete).

Could you please send your Acked-by tag as well to the new video
patches (will come in a few minutes). This makes it more clear that
you are "okay" with me pulling them.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Anatolij Gustschin
Hi Stefan,

On Wed, 30 Jan 2019 08:39:52 +0100
Stefan Roese s...@denx.de wrote:
...
> Yes, this should work as well. I'll send v2 shortly.
> 
> Will you pull the video driver patch, or should I pull it via
> the Marvell tree with the other updates?

Do you run Travis-CI build tests for Marvell tree? If yes, then
it is okay if it goes via Marvell tree.

Thanks,

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


Re: [U-Boot] [PATCH] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Stefan Roese

Hi Anatolij,

On 30.01.19 08:34, Anatolij Gustschin wrote:

On Wed, 30 Jan 2019 07:32:20 +0100
Stefan Roese s...@denx.de wrote:
...

Thanks. I just noticed that this patch applied without the
theadorable move to DM_VIDEO will cause compilation errors.
Perhaps its better to squash both patches so not break
git bisect'ability. What do you think?


Does it build when you add theadorable_debug_defconfig updates
from third patch to this patch? If so, then I suggest to do so.


Yes, this should work as well. I'll send v2 shortly.

Will you pull the video driver patch, or should I pull it via
the Marvell tree with the other updates?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Anatolij Gustschin
Hi Stefan,

On Wed, 30 Jan 2019 07:32:20 +0100
Stefan Roese s...@denx.de wrote:
...
> Thanks. I just noticed that this patch applied without the
> theadorable move to DM_VIDEO will cause compilation errors.
> Perhaps its better to squash both patches so not break
> git bisect'ability. What do you think?

Does it build when you add theadorable_debug_defconfig updates
from third patch to this patch? If so, then I suggest to do so.

Thanks,

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


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-01-29 Thread AKASHI Takahiro
On Wed, Jan 30, 2019 at 07:49:37AM +0100, Heinrich Schuchardt wrote:
> On 1/30/19 6:48 AM, AKASHI Takahiro wrote:
> > On Tue, Jan 29, 2019 at 11:33:31PM +0100, Heinrich Schuchardt wrote:
> >> On 1/29/19 3:59 AM, AKASHI Takahiro wrote:
> >>> efi_disk_create() will initialize efi_disk attributes for each device,
> >>> either UCLASS_BLK or UCLASS_PARTITION.
> >>>
> >>> Currently (temporarily), efi_disk_obj structure is embedded into
> >>> blk_desc to hold efi-specific attributes.
> >>>
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  drivers/block/blk-uclass.c |   9 ++
> >>>  drivers/core/device.c  |   3 +
> >>>  include/blk.h  |  24 +
> >>>  include/dm/device.h|   4 +
> >>>  lib/efi_loader/efi_disk.c  | 192 ++---
> >>>  5 files changed, 174 insertions(+), 58 deletions(-)
> >>>
> >>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> >>> index d4ca30f23fc1..28c45d724113 100644
> >>> --- a/drivers/block/blk-uclass.c
> >>> +++ b/drivers/block/blk-uclass.c
> >>> @@ -657,6 +657,9 @@ UCLASS_DRIVER(blk) = {
> >>>   .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
> >>>  };
> >>>  
> >>> +/* FIXME */
> >>> +extern int efi_disk_create(struct udevice *dev);
> >>> +
> >>>  U_BOOT_DRIVER(blk_partition) = {
> >>>   .name   = "blk_partition",
> >>>   .id = UCLASS_PARTITION,
> >>> @@ -695,6 +698,12 @@ int blk_create_partitions(struct udevice *parent)
> >>>   part_data->partnum = part;
> >>>   part_data->gpt_part_info = info;
> >>>  
> >>> + ret = efi_disk_create(dev);
> >>> + if (ret) {
> >>> + device_unbind(dev);
> >>> + return ret;
> >>> + }
> >>> +
> >>>   disks++;
> >>>   }
> >>>  
> >>> diff --git a/drivers/core/device.c b/drivers/core/device.c
> >>> index 0d15e5062b66..8625fccb0dcb 100644
> >>> --- a/drivers/core/device.c
> >>> +++ b/drivers/core/device.c
> >>> @@ -67,6 +67,9 @@ static int device_bind_common(struct udevice *parent, 
> >>> const struct driver *drv,
> >>>   dev->parent = parent;
> >>>   dev->driver = drv;
> >>>   dev->uclass = uc;
> >>> +#ifdef CONFIG_EFI_LOADER
> >>> + INIT_LIST_HEAD(>efi_obj.protocols);
> >>
> >> This looks like an incomplete initialization of efi_obj. Why don't we
> >> use efi_create_handle.
> > 
> > I think that it is more or less a matter of implementation.
> > I will address this issue later if necessary.
> > 
> >> Why should a device be aware of struct efi_obj? We only need a handle to
> >> install protocols.
> >>
> >>> +#endif
> >>>  
> >>>   dev->seq = -1;
> >>>   dev->req_seq = -1;
> >>> diff --git a/include/blk.h b/include/blk.h
> >>> index d0c033aece0f..405f6f790d66 100644
> >>> --- a/include/blk.h
> >>> +++ b/include/blk.h
> >>> @@ -8,6 +8,7 @@
> >>>  #define BLK_H
> >>>  
> >>>  #include 
> >>> +#include 
> >>>  
> >>>  #ifdef CONFIG_SYS_64BIT_LBA
> >>>  typedef uint64_t lbaint_t;
> >>> @@ -53,6 +54,26 @@ enum sig_type {
> >>>   SIG_TYPE_COUNT  /* Number of signature types */
> >>>  };
> >>>  
> >>> +/* FIXME */
> >>
> >> Fix what?
> > 
> > For simplicity, this data structure was copied from efi_disk.c
> > in this initial release.
> > As the implementation goes *sophisticated*, some members may go away
> > or move somewhere, say in blk_desc itself.
> > 
> >>> +/**
> >>> + * struct efi_disk_obj - EFI disk object
> >>> + *
> >>> + * @ops: EFI disk I/O protocol interface
> >>> + * @media:   block I/O media information
> >>> + * @dp:  device path to the block device
> >>> + * @part:partition
> >>> + * @volume:  simple file system protocol of the partition
> >>> + * @offset:  offset into disk for simple partition
> >>> + */
> >>> +struct efi_disk_obj {
> >>> + struct efi_block_io ops;
> >>> + struct efi_block_io_media media;
> >>> + struct efi_device_path *dp;
> >>> + unsigned int part;
> >>> + struct efi_simple_file_system_protocol *volume;
> >>> + lbaint_t offset;
> >>> +};
> >>> +
> >>>  /*
> >>>   * With driver model (CONFIG_BLK) this is uclass platform data, 
> >>> accessible
> >>>   * with dev_get_uclass_platdata(dev)
> >>> @@ -92,6 +113,9 @@ struct blk_desc {
> >>>* device. Once these functions are removed we can drop this field.
> >>>*/
> >>>   struct udevice *bdev;
> >>> +#ifdef CONFIG_EFI_LOADER
> >>> + struct efi_disk_obj efi_disk;
> >>
> >> This must be a handle (i.e. a pointer). Otherwise when the last protocol
> >> is removed we try to free memory that was never malloc'ed.
> > 
> > Who actually frees?
> 
> see UEFI spec for UninstallProtocolInterface():
> 
> "If the last protocol interface is removed from a handle, the handle is
> freed and is no longer valid."

Got it.
So, under the current implementation, any efi_object must be allocated
by efi code itself and all derived efi objects have an efi_object
as the first member.
(We can lift this restriction by adding object-specific "free" function,
like calling 

[U-Boot] [PATCH v3] moveconfig: add a second pass for empty #if/#endif blocks

2019-01-29 Thread Chris Packham
Moveconfig already attempts to remove empty #if/#endif blocks when there
is a matching CONFIG_ being moved. Add a second pass which covers files
without a match.

Signed-off-by: Chris Packham 
---
This was previously submitted as
http://patchwork.ozlabs.org/patch/924901/ there still seems to be cases
of #if/#endif left over from Kconfig migrations so perhaps this is still
needed/wanted.

I've plumbed this in as a second pass because ultimately we may want to
make this a separate option. Also I couldn't figure out how to implement
this without using re.M so I couldn't make it work in with the line by
line parsing of cleanup_one_header().

Changes in v3:
- drop rfc

Changes in v2:
- use re.compile

 tools/moveconfig.py | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index caa81ac2ed77..1a214c560546 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -545,6 +545,28 @@ def confirm(options, prompt):
 
 return True
 
+def cleanup_empty_blocks(header_path, options):
+"""Clean up empty conditional blocks
+
+Arguments:
+  header_path: path to the cleaned file.
+  options: option flags.
+"""
+pattern = re.compile(r'^\s*#\s*if.*$\n^\s*#\s*endif.*$\n*', flags=re.M)
+with open(header_path) as f:
+data = f.read()
+
+new_data = pattern.sub('\n', data)
+
+show_diff(data.splitlines(True), new_data.splitlines(True), header_path,
+  options.color)
+
+if options.dry_run:
+return
+
+with open(header_path, 'w') as f:
+f.write(new_data)
+
 def cleanup_one_header(header_path, patterns, options):
 """Clean regex-matched lines away from a file.
 
@@ -626,8 +648,9 @@ def cleanup_headers(configs, options):
 continue
 for filename in filenames:
 if not fnmatch.fnmatch(filename, '*~'):
-cleanup_one_header(os.path.join(dirpath, filename),
-   patterns, options)
+header_path = os.path.join(dirpath, filename)
+cleanup_one_header(header_path, patterns, options)
+cleanup_empty_blocks(header_path, options)
 
 def cleanup_one_extra_option(defconfig_path, configs, options):
 """Delete config defines in CONFIG_SYS_EXTRA_OPTIONS in one defconfig file.
-- 
2.20.1

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


[U-Boot] [PATCH] omap3_cairo: remove empty #ifdef/#endif block

2019-01-29 Thread Chris Packham
The content between these guards was removed in commit 9baa2bce2890
("Removed unused references to CONFIG_SERIALx"). Remove the now
empty #ifdef/#endif block and the accompanying comment.

Signed-off-by: Chris Packham 
---

 include/configs/omap3_cairo.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/include/configs/omap3_cairo.h b/include/configs/omap3_cairo.h
index 04bce2f8b46f..ef69b24dd097 100644
--- a/include/configs/omap3_cairo.h
+++ b/include/configs/omap3_cairo.h
@@ -190,16 +190,6 @@
 /* env defaults */
 #define CONFIG_BOOTFILE"uImage"
 
-/* Override OMAP3 common serial console configuration from UART3
- * to UART2.
- *
- * Attention: for UART2, special MUX settings (MUX_DEFAULT(), MCBSP3)
- * are needed and peripheral clocks for UART2 must be enabled in
- * function per_clocks_enable().
- */
-#ifdef CONFIG_SPL_BUILD
-#endif
-
 /* Provide the MACH_TYPE value the vendor kernel requires */
 #define CONFIG_MACH_TYPE   3063
 
-- 
2.20.1

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


Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM

2019-01-29 Thread Peng Fan


> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年1月30日 14:47
> To: Peng Fan 
> Cc: sba...@denx.de; Fabio Estevam ;
> dl-uboot-imx ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM
> 
> Hi Peng,
> 
> > Hi Lukasz,
> >
> > > -Original Message-
> > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > Sent: 2019年1月30日 6:55
> > > To: Peng Fan 
> > > Cc: sba...@denx.de; Fabio Estevam ;
> > > dl-uboot-imx ; u-boot@lists.denx.de
> > > Subject: Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for
> > > i.MX8MM
> > >
> > > Hi Peng,
> > >
> > > > Introduce clk implementation for i.MX8MM, including pll
> > > > configuration, pll decoding, ccm configuration.
> > > >
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >  arch/arm/include/asm/arch-imx8m/clock.h|   2 +
> > > >  arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387
> +++
> > > >  arch/arm/mach-imx/imx8m/Makefile   |   1 +
> > > >  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 866
> > > > +
> > > > arch/arm/mach-imx/imx8m/clock_slice.c  | 461
> > > + 5
> > > > files changed, 1717 insertions(+) create mode 100644
> > > > arch/arm/include/asm/arch-imx8m/clock_imx8mm.h create mode
> 100644
> > > > arch/arm/mach-imx/imx8m/clock_imx8mm.c
> > >
> > > As fair as I see this approach is not similar to the one from Linux
> > > kernel:
> > >
> > >
> https://elixir.bootlin.com/linux/v5.0-rc3/source/drivers/clk/imx/clk-imx8mq.
> > > c
> > > or simpler:
> > >
> https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx8mq.c
> > >
> > > Also Fabio pointed out in the other mail that we shall stick to
> > > Linux kernel Common Clock Framework.
> > >
> > > IMHO we shall add the simple CCF look alike code (I'm going to post
> > > imx6q port in a few days).
> >
> > That will be too complicated for SPL and it will bring more efforts
> > when we do pre/post silicon bringup.
> 
> If we use OF_PLATDATA to avoid DTB inclusion (and provide necessary
> information for the SPL driver) then we may do the trick.
> 
> As of now - the problem is that SPL on IMX{568} get bloated very
> rapidly when converted to DM/DTS..., but this shall not be the case for
> generic EVAL board.

Ok. I'll wait for your work about CCF, then check whether that could
be used on i.MX8MM. On some platform, there are limited SRAM,
hope we not goes into use TPL.

Thanks,
Peng.

> 
> >
> > Regards,
> > Peng.
> >
> > >
> > > >
> > > > diff --git a/arch/arm/include/asm/arch-imx8m/clock.h
> > > > b/arch/arm/include/asm/arch-imx8m/clock.h index
> > > > 7225c760fe..ead4b8d3dc 100644 ---
> > > > a/arch/arm/include/asm/arch-imx8m/clock.h +++
> > > > b/arch/arm/include/asm/arch-imx8m/clock.h @@ -7,6 +7,8 @@
> > > >
> > > >  #ifdef CONFIG_IMX8MQ
> > > >  #include 
> > > > +#elif defined(CONFIG_IMX8MM)
> > > > +#include 
> > > >  #else
> > > >  #error "Error no clock.h"
> > > >  #endif
> > > > diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > > > b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h new file mode
> > > 100644
> > > > index 00..305514a4ec
> > > > --- /dev/null
> > > > +++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > > > @@ -0,0 +1,387 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > +/*
> > > > + * Copyright 2018-2019 NXP
> > > > + *
> > > > + * Peng Fan 
> > > > + */
> > > > +
> > > > +#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
> > > > +#define _ASM_ARCH_IMX8MM_CLOCK_H
> > > > +
> > > > +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)
> > > > \
> > > > +   {
> > > > \
> > > > +   .rate   =
> > > > (_rate),\
> > > > +   .mdiv   =
> > > > (_m),   \
> > > > +   .pdiv   =
> > > > (_p),   \
> > > > +   .sdiv   =
> > > > (_s),   \
> > > > +   .kdiv   =
> > > > (_k),   \
> > > > +   }
> > > > +
> > > > +#define LOCK_STATUSBIT(31)
> > > > +#define LOCK_SEL_MASK  BIT(29)
> > > > +#define CLKE_MASK  BIT(11)
> > > > +#define RST_MASK   BIT(9)
> > > > +#define BYPASS_MASKBIT(4)
> > > > +#defineMDIV_SHIFT  12
> > > > +#defineMDIV_MASK   GENMASK(21, 12)
> > > > +#define PDIV_SHIFT 4
> > > > +#define PDIV_MASK  GENMASK(9, 4)
> > > > +#define SDIV_SHIFT 0
> > > > +#define SDIV_MASK  GENMASK(2, 0)
> > > > +#define KDIV_SHIFT 0
> > > > +#define KDIV_MASK  GENMASK(15, 0)
> > > > +
> > > > +struct imx_int_pll_rate_table {
> > > > +   u32 rate;
> > > > +   int mdiv;
> > > > +   int pdiv;
> > > > +   int sdiv;
> > > > +   int kdiv;
> > > > +};
> > > > +
> > > > +enum pll_clocks {
> > > > +   ANATOP_ARM_PLL,
> > > > +   ANATOP_VPU_PLL,
> > > > +   ANATOP_GPU_PLL,
> > > > +   ANATOP_SYSTEM_PLL1,
> > > > +   ANATOP_SYSTEM_PLL2,
> > > > +   

[U-Boot] [PATCH 1/1] test: provide unit test for memory functions

2019-01-29 Thread Heinrich Schuchardt
Memory functions may have architecture specific implementations. These
should be tested.

Provide unit tests for memset(), memcpy(), memmove().

Provide a 'ut lib' sub-command to execute the tests.

Signed-off-by: Heinrich Schuchardt 
---
v2
vary alignment and length of copied or set memory region
---
 include/test/lib.h|  14 +++
 include/test/suites.h |   1 +
 test/Kconfig  |   8 ++
 test/cmd_ut.c |   6 ++
 test/lib/Makefile |   2 +
 test/lib/cmd_ut_lib.c |  20 +
 test/lib/string.c | 194 ++
 7 files changed, 245 insertions(+)
 create mode 100644 include/test/lib.h
 create mode 100644 test/lib/cmd_ut_lib.c
 create mode 100644 test/lib/string.c

diff --git a/include/test/lib.h b/include/test/lib.h
new file mode 100644
index 00..12cca61e8b
--- /dev/null
+++ b/include/test/lib.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 Heinrich Schuchardt 
+ */
+
+#ifndef __TEST_LIB_H__
+#define __TEST_LIB_H__
+
+#include 
+
+/* Declare a new library function test */
+#define LIB_TEST(_name, _flags)UNIT_TEST(_name, _flags, lib_test)
+
+#endif /* __TEST_LIB_H__ */
diff --git a/include/test/suites.h b/include/test/suites.h
index 77d863b4a6..01bee09346 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -27,6 +27,7 @@ int do_ut_bloblist(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[]);
 int do_ut_compression(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
argv[]);
 int do_ut_dm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 int do_ut_env(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+int do_ut_lib(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 int do_ut_time(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 int do_ut_unicode(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
diff --git a/test/Kconfig b/test/Kconfig
index de16d179d0..48a0e501f8 100644
--- a/test/Kconfig
+++ b/test/Kconfig
@@ -6,6 +6,14 @@ menuconfig UNIT_TEST
  This does not require sandbox to be included, but it is most
  often used there.
 
+config UT_LIB
+   bool "Unit tests for library functions"
+   depends on UNIT_TEST
+   default y
+   help
+ Enables the 'ut lib' command which tests library functions like
+ memcat(), memcyp(), memmove().
+
 config UT_TIME
bool "Unit tests for time functions"
depends on UNIT_TEST
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 56924a5272..e3b89504e7 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -46,6 +46,9 @@ static cmd_tbl_t cmd_ut_sub[] = {
 #ifdef CONFIG_UT_OVERLAY
U_BOOT_CMD_MKENT(overlay, CONFIG_SYS_MAXARGS, 1, do_ut_overlay, "", ""),
 #endif
+#ifdef CONFIG_UT_LIB
+   U_BOOT_CMD_MKENT(lib, CONFIG_SYS_MAXARGS, 1, do_ut_lib, "", ""),
+#endif
 #ifdef CONFIG_UT_TIME
U_BOOT_CMD_MKENT(time, CONFIG_SYS_MAXARGS, 1, do_ut_time, "", ""),
 #endif
@@ -108,6 +111,9 @@ static char ut_help_text[] =
 #ifdef CONFIG_UT_ENV
"ut env [test-name]\n"
 #endif
+#ifdef CONFIG_UT_LIB
+   "ut lib [test-name] - test library functions\n"
+#endif
 #ifdef CONFIG_UT_OVERLAY
"ut overlay [test-name]\n"
 #endif
diff --git a/test/lib/Makefile b/test/lib/Makefile
index 5a636aac74..308c61708e 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -2,5 +2,7 @@
 #
 # (C) Copyright 2018
 # Mario Six, Guntermann & Drunck GmbH, mario@gdsys.cc
+obj-y += cmd_ut_lib.o
 obj-y += hexdump.o
 obj-y += lmb.o
+obj-y += string.o
diff --git a/test/lib/cmd_ut_lib.c b/test/lib/cmd_ut_lib.c
new file mode 100644
index 00..eb90e53914
--- /dev/null
+++ b/test/lib/cmd_ut_lib.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Heinrich Schuchardt 
+ *
+ * Unit tests for library functions
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int do_ut_lib(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   struct unit_test *tests = ll_entry_start(struct unit_test, lib_test);
+   const int n_ents = ll_entry_count(struct unit_test, lib_test);
+
+   return cmd_ut_category("lib", tests, n_ents, argc, argv);
+}
diff --git a/test/lib/string.c b/test/lib/string.c
new file mode 100644
index 00..9b835e3e93
--- /dev/null
+++ b/test/lib/string.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Heinrich Schuchardt 
+ *
+ * Unit tests for memory functions
+ *
+ * The architecture dependent implementations run through different lines of
+ * code depending on the alignment and length of memory regions copied or set.
+ * This has to be considered in testing.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Xor mask used for marking memory regions */
+#define MASK 0xA5
+/* Number of different alignment values */
+#define SWEEP 16
+/* Allow for 

Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to mmc2 for i.MX8MM

2019-01-29 Thread Peng Fan


> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年1月30日 14:50
> To: Peng Fan 
> Cc: sba...@denx.de; Fabio Estevam ;
> dl-uboot-imx ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to
> mmc2 for i.MX8MM
> 
> Hi Peng,
> 
> > > -Original Message-
> > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > Sent: 2019年1月30日 6:58
> > > To: Peng Fan 
> > > Cc: sba...@denx.de; Fabio Estevam ;
> > > dl-uboot-imx ; u-boot@lists.denx.de
> > > Subject: Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc
> > > to mmc2 for i.MX8MM
> > >
> > > Hi Peng,
> > >
> > > > Since the SD is usdhc2 and eMMC is usdhc3,
> > >
> > > Is this true on all IMX8M boards? Or is it only on the development
> > > kit you do have?
> >
> > This is a hack for board, needs to be fixed in next version.
> >
> > >
> > > My point is that this shall be setup by DTS aliases or maybe by
> > > Kconfig option.
> >
> > Could you share more information?
> 
> For example:
> 
> / {
>   model = "K+P iMX6Q";
>   compatible = "kp,imx6-kp", "fsl,imx6";
> 
>   aliases {
>   mmc0 = 
>   mmc1 = 
>   usb1 = 
>   };
> 
>   chosen {
>   stdout-path = 
>   };
> 
> 
> And the "aliases" set the order in which you get the devices (like mmc0,
> mmc1 above).

Then we need SPL to have Device tree support, right?

Thanks,
Peng.

> 
> >
> > Thanks,
> > Peng.
> >
> > >
> > > > this cause mapping problem
> > > > for spl_boot_device. So far hard coded them to correct MMC index,
> > > > so that SD and eMMC boot can work.
> > > >
> > > > Signed-off-by: Peng Fan 
> > > > ---
> > > >  arch/arm/mach-imx/spl.c | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> > > > index ebd8ff9290..0048832be8 100644
> > > > --- a/arch/arm/mach-imx/spl.c
> > > > +++ b/arch/arm/mach-imx/spl.c
> > > > @@ -147,9 +147,18 @@ u32 spl_boot_device(void)
> > > > case SD1_BOOT:
> > > > case MMC1_BOOT:
> > > > return BOOT_DEVICE_MMC1;
> > > > +#if defined(CONFIG_IMX8MM)
> > > > +   case SD2_BOOT:
> > > > +   case MMC2_BOOT:
> > > > +   return BOOT_DEVICE_MMC1;
> > > > +   case SD3_BOOT:
> > > > +   case MMC3_BOOT:
> > > > +   return BOOT_DEVICE_MMC2;
> > > > +#else
> > > > case SD2_BOOT:
> > > > case MMC2_BOOT:
> > > > return BOOT_DEVICE_MMC2;
> > > > +#endif
> > > >  #endif
> > > > case NAND_BOOT:
> > > > return BOOT_DEVICE_NAND;
> > >
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Lukasz Majewski
> > >
> > > --
> > >
> > > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > > lu...@denx.de
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4] arm64: mvebu: Add basic support for uDPU board

2019-01-29 Thread Stefan Roese

On 28.01.19 17:27, Vladimir Vid wrote:

This adds initial support for micro-DPU (uDPU) board which is based on 
Armada-3720 SoC.
micro-DPU is the single-port FTTdp "distribution point unit" made by Methode 
Electronics
which offers complete modularity with replaceable SFP modules both for uplink 
and downlink
(G.hn over twisted-pair, G.hn over coax, 1G and 2.5G Ethernet over Cat-5e 
cable).

On-board features:
- 512 MiB DDR3
- 2 x 2.5G SFP via HSGMII SERDES interface to the A3720 SoC
- USB 2.0 Type-C connector
- 4GB eMMC
- ETSI TS 101548 reverse powering via twisted pair (RJ45) or coax (F Type)

Cc: Luka Perkov 
Cc: Luis Torres 
Cc: Scott Roberts 
Cc: Paul Arola 
Cc: Stefan Roese 
Signed-off-by: Vladimir Vid 
---

v4 changes:

- moved u-boot specific properties to armada-3720-uDPU-u-boot.dtsi
- added additional 'u-boot,dm-pre-reloc' on sdhci1 (eMMC)

---
  arch/arm/dts/Makefile   |   1 +
  arch/arm/dts/armada-3720-uDPU-u-boot.dtsi   |  13 ++
  arch/arm/dts/armada-3720-uDPU.dts   | 200 
  board/Marvell/mvebu_armada-37xx/MAINTAINERS |   5 +
  configs/uDPU_defconfig  |  94 +
  5 files changed, 313 insertions(+)
  create mode 100644 arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
  create mode 100644 arch/arm/dts/armada-3720-uDPU.dts
  create mode 100644 configs/uDPU_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5c3225bcbf..9e1e1ad8e9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   \
armada-3720-db.dtb  \
armada-3720-espressobin.dtb \
armada-3720-turris-mox.dtb  \
+   armada-3720-uDPU.dts\
armada-375-db.dtb   \
armada-388-clearfog.dtb \
armada-388-gp.dtb   \
diff --git a/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi 
b/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
new file mode 100644
index 00..ef178bdc86
--- /dev/null
+++ b/arch/arm/dts/armada-3720-uDPU-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+ {
+   u-boot,dm-pre-reloc;
+
+   spi-flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};


I'm wondering, why you don't need any "u-boot,dm-pre-reloc" in your
UART DT node.

Other than that:

Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to mmc2 for i.MX8MM

2019-01-29 Thread Lukasz Majewski
Hi Peng,

> > -Original Message-
> > From: Lukasz Majewski [mailto:lu...@denx.de]
> > Sent: 2019年1月30日 6:58
> > To: Peng Fan 
> > Cc: sba...@denx.de; Fabio Estevam ;
> > dl-uboot-imx ; u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc
> > to mmc2 for i.MX8MM
> > 
> > Hi Peng,
> >   
> > > Since the SD is usdhc2 and eMMC is usdhc3,  
> > 
> > Is this true on all IMX8M boards? Or is it only on the development
> > kit you do have?  
> 
> This is a hack for board, needs to be fixed in next version.
> 
> > 
> > My point is that this shall be setup by DTS aliases or maybe by
> > Kconfig option.  
> 
> Could you share more information?

For example:

/ {
model = "K+P iMX6Q";
compatible = "kp,imx6-kp", "fsl,imx6";

aliases {
mmc0 = 
mmc1 = 
usb1 = 
};

chosen {
stdout-path = 
};


And the "aliases" set the order in which you get the devices (like
mmc0, mmc1 above).

> 
> Thanks,
> Peng.
> 
> >   
> > > this cause mapping problem
> > > for spl_boot_device. So far hard coded them to correct MMC index,
> > > so that SD and eMMC boot can work.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  arch/arm/mach-imx/spl.c | 9 +
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> > > index ebd8ff9290..0048832be8 100644
> > > --- a/arch/arm/mach-imx/spl.c
> > > +++ b/arch/arm/mach-imx/spl.c
> > > @@ -147,9 +147,18 @@ u32 spl_boot_device(void)
> > >   case SD1_BOOT:
> > >   case MMC1_BOOT:
> > >   return BOOT_DEVICE_MMC1;
> > > +#if defined(CONFIG_IMX8MM)
> > > + case SD2_BOOT:
> > > + case MMC2_BOOT:
> > > + return BOOT_DEVICE_MMC1;
> > > + case SD3_BOOT:
> > > + case MMC3_BOOT:
> > > + return BOOT_DEVICE_MMC2;
> > > +#else
> > >   case SD2_BOOT:
> > >   case MMC2_BOOT:
> > >   return BOOT_DEVICE_MMC2;
> > > +#endif
> > >  #endif
> > >   case NAND_BOOT:
> > >   return BOOT_DEVICE_NAND;  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> > lu...@denx.de  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpZBtLYqMHFp.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-01-29 Thread Heinrich Schuchardt
On 1/30/19 6:48 AM, AKASHI Takahiro wrote:
> On Tue, Jan 29, 2019 at 11:33:31PM +0100, Heinrich Schuchardt wrote:
>> On 1/29/19 3:59 AM, AKASHI Takahiro wrote:
>>> efi_disk_create() will initialize efi_disk attributes for each device,
>>> either UCLASS_BLK or UCLASS_PARTITION.
>>>
>>> Currently (temporarily), efi_disk_obj structure is embedded into
>>> blk_desc to hold efi-specific attributes.
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  drivers/block/blk-uclass.c |   9 ++
>>>  drivers/core/device.c  |   3 +
>>>  include/blk.h  |  24 +
>>>  include/dm/device.h|   4 +
>>>  lib/efi_loader/efi_disk.c  | 192 ++---
>>>  5 files changed, 174 insertions(+), 58 deletions(-)
>>>
>>> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
>>> index d4ca30f23fc1..28c45d724113 100644
>>> --- a/drivers/block/blk-uclass.c
>>> +++ b/drivers/block/blk-uclass.c
>>> @@ -657,6 +657,9 @@ UCLASS_DRIVER(blk) = {
>>> .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
>>>  };
>>>  
>>> +/* FIXME */
>>> +extern int efi_disk_create(struct udevice *dev);
>>> +
>>>  U_BOOT_DRIVER(blk_partition) = {
>>> .name   = "blk_partition",
>>> .id = UCLASS_PARTITION,
>>> @@ -695,6 +698,12 @@ int blk_create_partitions(struct udevice *parent)
>>> part_data->partnum = part;
>>> part_data->gpt_part_info = info;
>>>  
>>> +   ret = efi_disk_create(dev);
>>> +   if (ret) {
>>> +   device_unbind(dev);
>>> +   return ret;
>>> +   }
>>> +
>>> disks++;
>>> }
>>>  
>>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>>> index 0d15e5062b66..8625fccb0dcb 100644
>>> --- a/drivers/core/device.c
>>> +++ b/drivers/core/device.c
>>> @@ -67,6 +67,9 @@ static int device_bind_common(struct udevice *parent, 
>>> const struct driver *drv,
>>> dev->parent = parent;
>>> dev->driver = drv;
>>> dev->uclass = uc;
>>> +#ifdef CONFIG_EFI_LOADER
>>> +   INIT_LIST_HEAD(>efi_obj.protocols);
>>
>> This looks like an incomplete initialization of efi_obj. Why don't we
>> use efi_create_handle.
> 
> I think that it is more or less a matter of implementation.
> I will address this issue later if necessary.
> 
>> Why should a device be aware of struct efi_obj? We only need a handle to
>> install protocols.
>>
>>> +#endif
>>>  
>>> dev->seq = -1;
>>> dev->req_seq = -1;
>>> diff --git a/include/blk.h b/include/blk.h
>>> index d0c033aece0f..405f6f790d66 100644
>>> --- a/include/blk.h
>>> +++ b/include/blk.h
>>> @@ -8,6 +8,7 @@
>>>  #define BLK_H
>>>  
>>>  #include 
>>> +#include 
>>>  
>>>  #ifdef CONFIG_SYS_64BIT_LBA
>>>  typedef uint64_t lbaint_t;
>>> @@ -53,6 +54,26 @@ enum sig_type {
>>> SIG_TYPE_COUNT  /* Number of signature types */
>>>  };
>>>  
>>> +/* FIXME */
>>
>> Fix what?
> 
> For simplicity, this data structure was copied from efi_disk.c
> in this initial release.
> As the implementation goes *sophisticated*, some members may go away
> or move somewhere, say in blk_desc itself.
> 
>>> +/**
>>> + * struct efi_disk_obj - EFI disk object
>>> + *
>>> + * @ops:   EFI disk I/O protocol interface
>>> + * @media: block I/O media information
>>> + * @dp:device path to the block device
>>> + * @part:  partition
>>> + * @volume:simple file system protocol of the partition
>>> + * @offset:offset into disk for simple partition
>>> + */
>>> +struct efi_disk_obj {
>>> +   struct efi_block_io ops;
>>> +   struct efi_block_io_media media;
>>> +   struct efi_device_path *dp;
>>> +   unsigned int part;
>>> +   struct efi_simple_file_system_protocol *volume;
>>> +   lbaint_t offset;
>>> +};
>>> +
>>>  /*
>>>   * With driver model (CONFIG_BLK) this is uclass platform data, accessible
>>>   * with dev_get_uclass_platdata(dev)
>>> @@ -92,6 +113,9 @@ struct blk_desc {
>>>  * device. Once these functions are removed we can drop this field.
>>>  */
>>> struct udevice *bdev;
>>> +#ifdef CONFIG_EFI_LOADER
>>> +   struct efi_disk_obj efi_disk;
>>
>> This must be a handle (i.e. a pointer). Otherwise when the last protocol
>> is removed we try to free memory that was never malloc'ed.
> 
> Who actually frees?

see UEFI spec for UninstallProtocolInterface():

"If the last protocol interface is removed from a handle, the handle is
freed and is no longer valid."

Best regards

Heinrich

> 
>>> +#endif
>>>  #else
>>> unsigned long   (*block_read)(struct blk_desc *block_dev,
>>>   lbaint_t start,
>>> diff --git a/include/dm/device.h b/include/dm/device.h
>>> index 27a6d7b9fdb0..121bfb46b1a0 100644
>>> --- a/include/dm/device.h
>>> +++ b/include/dm/device.h
>>> @@ -12,6 +12,7 @@
>>>  
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -146,6 +147,9 @@ struct udevice {
>>>  #ifdef CONFIG_DEVRES
>>> struct list_head 

Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM

2019-01-29 Thread Lukasz Majewski
Hi Peng,

> Hi Lukasz,
> 
> > -Original Message-
> > From: Lukasz Majewski [mailto:lu...@denx.de]
> > Sent: 2019年1月30日 6:55
> > To: Peng Fan 
> > Cc: sba...@denx.de; Fabio Estevam ;
> > dl-uboot-imx ; u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for
> > i.MX8MM
> > 
> > Hi Peng,
> >   
> > > Introduce clk implementation for i.MX8MM, including pll
> > > configuration, pll decoding, ccm configuration.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  arch/arm/include/asm/arch-imx8m/clock.h|   2 +
> > >  arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 +++
> > >  arch/arm/mach-imx/imx8m/Makefile   |   1 +
> > >  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 866
> > > +
> > > arch/arm/mach-imx/imx8m/clock_slice.c  | 461  
> > + 5  
> > > files changed, 1717 insertions(+) create mode 100644
> > > arch/arm/include/asm/arch-imx8m/clock_imx8mm.h create mode 100644
> > > arch/arm/mach-imx/imx8m/clock_imx8mm.c  
> > 
> > As fair as I see this approach is not similar to the one from Linux
> > kernel:
> > 
> > https://elixir.bootlin.com/linux/v5.0-rc3/source/drivers/clk/imx/clk-imx8mq.
> > c
> > or simpler:
> > https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx8mq.c
> > 
> > Also Fabio pointed out in the other mail that we shall stick to
> > Linux kernel Common Clock Framework.
> > 
> > IMHO we shall add the simple CCF look alike code (I'm going to post
> > imx6q port in a few days).  
> 
> That will be too complicated for SPL and it will bring more efforts
> when we do pre/post silicon bringup.

If we use OF_PLATDATA to avoid DTB inclusion (and provide necessary
information for the SPL driver) then we may do the trick.

As of now - the problem is that SPL on IMX{568} get bloated very
rapidly when converted to DM/DTS..., but this shall not be the case for
generic EVAL board.

> 
> Regards,
> Peng.
> 
> >   
> > >
> > > diff --git a/arch/arm/include/asm/arch-imx8m/clock.h
> > > b/arch/arm/include/asm/arch-imx8m/clock.h index
> > > 7225c760fe..ead4b8d3dc 100644 ---
> > > a/arch/arm/include/asm/arch-imx8m/clock.h +++
> > > b/arch/arm/include/asm/arch-imx8m/clock.h @@ -7,6 +7,8 @@
> > >
> > >  #ifdef CONFIG_IMX8MQ
> > >  #include 
> > > +#elif defined(CONFIG_IMX8MM)
> > > +#include 
> > >  #else
> > >  #error "Error no clock.h"
> > >  #endif
> > > diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > > b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h new file mode  
> > 100644  
> > > index 00..305514a4ec
> > > --- /dev/null
> > > +++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > > @@ -0,0 +1,387 @@
> > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > +/*
> > > + * Copyright 2018-2019 NXP
> > > + *
> > > + * Peng Fan 
> > > + */
> > > +
> > > +#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
> > > +#define _ASM_ARCH_IMX8MM_CLOCK_H
> > > +
> > > +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)
> > > \
> > > + {
> > > \
> > > + .rate   =
> > > (_rate),  \
> > > + .mdiv   =
> > > (_m), \
> > > + .pdiv   =
> > > (_p), \
> > > + .sdiv   =
> > > (_s), \
> > > + .kdiv   =
> > > (_k), \
> > > + }
> > > +
> > > +#define LOCK_STATUS  BIT(31)
> > > +#define LOCK_SEL_MASKBIT(29)
> > > +#define CLKE_MASKBIT(11)
> > > +#define RST_MASK BIT(9)
> > > +#define BYPASS_MASK  BIT(4)
> > > +#define  MDIV_SHIFT  12
> > > +#define  MDIV_MASK   GENMASK(21, 12)
> > > +#define PDIV_SHIFT   4
> > > +#define PDIV_MASKGENMASK(9, 4)
> > > +#define SDIV_SHIFT   0
> > > +#define SDIV_MASKGENMASK(2, 0)
> > > +#define KDIV_SHIFT   0
> > > +#define KDIV_MASKGENMASK(15, 0)
> > > +
> > > +struct imx_int_pll_rate_table {
> > > + u32 rate;
> > > + int mdiv;
> > > + int pdiv;
> > > + int sdiv;
> > > + int kdiv;
> > > +};
> > > +
> > > +enum pll_clocks {
> > > + ANATOP_ARM_PLL,
> > > + ANATOP_VPU_PLL,
> > > + ANATOP_GPU_PLL,
> > > + ANATOP_SYSTEM_PLL1,
> > > + ANATOP_SYSTEM_PLL2,
> > > + ANATOP_SYSTEM_PLL3,
> > > + ANATOP_AUDIO_PLL1,
> > > + ANATOP_AUDIO_PLL2,
> > > + ANATOP_VIDEO_PLL,
> > > + ANATOP_DRAM_PLL,
> > > +};
> > > +
> > > +enum clk_root_index {
> > > + ARM_A53_CLK_ROOT= 0,
> > > + ARM_M4_CLK_ROOT = 1,
> > > + VPU_A53_CLK_ROOT= 2,
> > > + GPU3D_CLK_ROOT  = 3,
> > > + GPU2D_CLK_ROOT  = 4,
> > > + MAIN_AXI_CLK_ROOT   = 16,
> > > + ENET_AXI_CLK_ROOT   = 17,
> > > + NAND_USDHC_BUS_CLK_ROOT = 18,
> > > + VPU_BUS_CLK_ROOT= 19,
> > > + DISPLAY_AXI_CLK_ROOT= 20,
> > > + DISPLAY_APB_CLK_ROOT= 21,
> > > + DISPLAY_RTRM_CLK_ROOT   = 22,
> > > + USB_BUS_CLK_ROOT= 23,
> > > + GPU_AXI_CLK_ROOT= 

Re: [U-Boot] [PATCH] video: Armada XP: Move driver to DM_VIDEO

2019-01-29 Thread Stefan Roese

Hi Anatolij,

On 29.01.19 14:13, Anatolij Gustschin wrote:

Hi Stefan,

On Tue, 29 Jan 2019 11:44:43 +0100
Stefan Roese s...@denx.de wrote:


This patch moves the Armada XP video / LCD driver to DM_VIDEO. With this
move, the legacy interface board_video_init() is removed from the
theadorable board code (only user of this video driver). The support
via DT will be added in a separate patch.

Signed-off-by: Stefan Roese 
Cc: Anatolij Gustschin 


Reviewed-by: Anatolij Gustschin 


Thanks. I just noticed that this patch applied without the
theadorable move to DM_VIDEO will cause compilation errors.
Perhaps its better to squash both patches so not break
git bisect'ability. What do you think?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 12/13] mmc: sdhci: Add support for HOST_CONTROL2 and setting UHS timings

2019-01-29 Thread Faiz Abbas
Hi Tom,

On 30/01/19 7:50 AM, Tom Rini wrote:
> On Mon, Jan 28, 2019 at 12:15:30PM +0530, Faiz Abbas wrote:
> 
>> From: Faiz Abbas 
>>
>> The HOST_CONTROL2 register is a part of SDHC v3.00 and not just specific
>> to arasan/zynq controllers. Add the same to sdhci.h.
>>
>> Also create a common API to set UHS timings in HOST_CONTROL2.
>>
>> Signed-off-by: Faiz Abbas 
> [snip]
>> diff --git a/include/sdhci.h b/include/sdhci.h
>> index 725520b0b4..1e5f249eab 100644
>> --- a/include/sdhci.h
>> +++ b/include/sdhci.h
>> @@ -144,7 +144,23 @@
>>  
>>  #define SDHCI_ACMD12_ERR0x3C
>>  
>> -/* 3E-3F reserved */
>> +#define SDHCI_HOST_CONTROL2 0x3E
>> +#define  SDHCI_CTRL_UHS_MASK0x0007
>> +#define   SDHCI_CTRL_UHS_SDR12  0x
>> +#define   SDHCI_CTRL_UHS_SDR25  0x0001
>> +#define   SDHCI_CTRL_UHS_SDR50  0x0002
>> +#define   SDHCI_CTRL_UHS_SDR104 0x0003
>> +#define   SDHCI_CTRL_UHS_DDR50  0x0004
>> +#define   SDHCI_CTRL_HS400  0x0005 /* Non-standard */
>> +#define  SDHCI_CTRL_VDD_180 0x0008
>> +#define  SDHCI_CTRL_DRV_TYPE_MASK   0x0030
>> +#define   SDHCI_CTRL_DRV_TYPE_B 0x
>> +#define   SDHCI_CTRL_DRV_TYPE_A 0x0010
>> +#define   SDHCI_CTRL_DRV_TYPE_C 0x0020
>> +#define   SDHCI_CTRL_DRV_TYPE_D 0x0030
>> +#define  SDHCI_CTRL_EXEC_TUNING 0x0040
>> +#define  SDHCI_CTRL_TUNED_CLK   0x0080
>> +#define  SDHCI_CTRL_PRESET_VAL_ENABLE   0x8000
> 
> The defines had consistent spacing before and now don't, why?  Or please
> fix.  Thanks!
> 

Fixing.

Thanks,
Faiz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 09/13] mmc: sdhci: Make set_ios_post() return int

2019-01-29 Thread Faiz Abbas
Hi Tom,

On 30/01/19 7:50 AM, Tom Rini wrote:
> On Mon, Jan 28, 2019 at 12:15:27PM +0530, Faiz Abbas wrote:
> 
>> Make set_ios_post() return int to faciliate error handling in
>> platform drivers.
>>
>> Signed-off-by: Faiz Abbas 
>> ---
>>  drivers/mmc/sdhci.c   | 6 +-
>>  drivers/mmc/xenon_sdhci.c | 4 +++-
>>  include/sdhci.h   | 2 +-
>>  3 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>> index 635f5396c4..b7b7ff6f7d 100644
>> --- a/drivers/mmc/sdhci.c
>> +++ b/drivers/mmc/sdhci.c
>> @@ -461,6 +461,7 @@ static int sdhci_set_ios(struct mmc *mmc)
>>  #endif
>>  u32 ctrl;
>>  struct sdhci_host *host = mmc->priv;
>> +int ret;
>>  
>>  if (host->ops && host->ops->set_control_reg)
>>  host->ops->set_control_reg(host);
>> @@ -500,8 +501,11 @@ static int sdhci_set_ios(struct mmc *mmc)
>>  sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
>>  
>>  /* If available, call the driver specific "post" set_ios() function */
>> -if (host->ops && host->ops->set_ios_post)
>> +if (host->ops && host->ops->set_ios_post) {
>>  host->ops->set_ios_post(host);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  return 0;
>>  }
> 
> Isn't something going to complain about either unused or uninitialized
> (or, both) variables?  In fact, re-reading this and follow-up patches, I
> think you forgot to turn:
>   host->ops->set_ios_post(host);
> in to:
>   ret = host->ops->set_ios_post(host);
> above.  And could probably simplfy the whole thing to:
>   if (host->ops && host->ops->set_ios_post)
>   return host->ops->set_ios_post(host);
> 
>   return 0;
> 
> Or is there more to the function that I'm missing?  That's just based on
> the patch context alone.

You're right. Missed the ret = during some refactoring. Will fix

Thanks,
Faiz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-01-29 Thread AKASHI Takahiro
On Tue, Jan 29, 2019 at 11:33:31PM +0100, Heinrich Schuchardt wrote:
> On 1/29/19 3:59 AM, AKASHI Takahiro wrote:
> > efi_disk_create() will initialize efi_disk attributes for each device,
> > either UCLASS_BLK or UCLASS_PARTITION.
> > 
> > Currently (temporarily), efi_disk_obj structure is embedded into
> > blk_desc to hold efi-specific attributes.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/block/blk-uclass.c |   9 ++
> >  drivers/core/device.c  |   3 +
> >  include/blk.h  |  24 +
> >  include/dm/device.h|   4 +
> >  lib/efi_loader/efi_disk.c  | 192 ++---
> >  5 files changed, 174 insertions(+), 58 deletions(-)
> > 
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > index d4ca30f23fc1..28c45d724113 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -657,6 +657,9 @@ UCLASS_DRIVER(blk) = {
> > .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
> >  };
> >  
> > +/* FIXME */
> > +extern int efi_disk_create(struct udevice *dev);
> > +
> >  U_BOOT_DRIVER(blk_partition) = {
> > .name   = "blk_partition",
> > .id = UCLASS_PARTITION,
> > @@ -695,6 +698,12 @@ int blk_create_partitions(struct udevice *parent)
> > part_data->partnum = part;
> > part_data->gpt_part_info = info;
> >  
> > +   ret = efi_disk_create(dev);
> > +   if (ret) {
> > +   device_unbind(dev);
> > +   return ret;
> > +   }
> > +
> > disks++;
> > }
> >  
> > diff --git a/drivers/core/device.c b/drivers/core/device.c
> > index 0d15e5062b66..8625fccb0dcb 100644
> > --- a/drivers/core/device.c
> > +++ b/drivers/core/device.c
> > @@ -67,6 +67,9 @@ static int device_bind_common(struct udevice *parent, 
> > const struct driver *drv,
> > dev->parent = parent;
> > dev->driver = drv;
> > dev->uclass = uc;
> > +#ifdef CONFIG_EFI_LOADER
> > +   INIT_LIST_HEAD(>efi_obj.protocols);
> 
> This looks like an incomplete initialization of efi_obj. Why don't we
> use efi_create_handle.

I think that it is more or less a matter of implementation.
I will address this issue later if necessary.

> Why should a device be aware of struct efi_obj? We only need a handle to
> install protocols.
> 
> > +#endif
> >  
> > dev->seq = -1;
> > dev->req_seq = -1;
> > diff --git a/include/blk.h b/include/blk.h
> > index d0c033aece0f..405f6f790d66 100644
> > --- a/include/blk.h
> > +++ b/include/blk.h
> > @@ -8,6 +8,7 @@
> >  #define BLK_H
> >  
> >  #include 
> > +#include 
> >  
> >  #ifdef CONFIG_SYS_64BIT_LBA
> >  typedef uint64_t lbaint_t;
> > @@ -53,6 +54,26 @@ enum sig_type {
> > SIG_TYPE_COUNT  /* Number of signature types */
> >  };
> >  
> > +/* FIXME */
> 
> Fix what?

For simplicity, this data structure was copied from efi_disk.c
in this initial release.
As the implementation goes *sophisticated*, some members may go away
or move somewhere, say in blk_desc itself.

> > +/**
> > + * struct efi_disk_obj - EFI disk object
> > + *
> > + * @ops:   EFI disk I/O protocol interface
> > + * @media: block I/O media information
> > + * @dp:device path to the block device
> > + * @part:  partition
> > + * @volume:simple file system protocol of the partition
> > + * @offset:offset into disk for simple partition
> > + */
> > +struct efi_disk_obj {
> > +   struct efi_block_io ops;
> > +   struct efi_block_io_media media;
> > +   struct efi_device_path *dp;
> > +   unsigned int part;
> > +   struct efi_simple_file_system_protocol *volume;
> > +   lbaint_t offset;
> > +};
> > +
> >  /*
> >   * With driver model (CONFIG_BLK) this is uclass platform data, accessible
> >   * with dev_get_uclass_platdata(dev)
> > @@ -92,6 +113,9 @@ struct blk_desc {
> >  * device. Once these functions are removed we can drop this field.
> >  */
> > struct udevice *bdev;
> > +#ifdef CONFIG_EFI_LOADER
> > +   struct efi_disk_obj efi_disk;
> 
> This must be a handle (i.e. a pointer). Otherwise when the last protocol
> is removed we try to free memory that was never malloc'ed.

Who actually frees?

> > +#endif
> >  #else
> > unsigned long   (*block_read)(struct blk_desc *block_dev,
> >   lbaint_t start,
> > diff --git a/include/dm/device.h b/include/dm/device.h
> > index 27a6d7b9fdb0..121bfb46b1a0 100644
> > --- a/include/dm/device.h
> > +++ b/include/dm/device.h
> > @@ -12,6 +12,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -146,6 +147,9 @@ struct udevice {
> >  #ifdef CONFIG_DEVRES
> > struct list_head devres_head;
> >  #endif
> > +#ifdef CONFIG_EFI_LOADER
> > +   struct efi_object efi_obj;
> > +#endif
> >  };
> >  
> >  /* Maximum sequence number supported */
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index 

Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to mmc2 for i.MX8MM

2019-01-29 Thread Peng Fan


> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年1月30日 6:58
> To: Peng Fan 
> Cc: sba...@denx.de; Fabio Estevam ;
> dl-uboot-imx ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to
> mmc2 for i.MX8MM
> 
> Hi Peng,
> 
> > Since the SD is usdhc2 and eMMC is usdhc3,
> 
> Is this true on all IMX8M boards? Or is it only on the development kit you do
> have?

This is a hack for board, needs to be fixed in next version.

> 
> My point is that this shall be setup by DTS aliases or maybe by Kconfig 
> option.

Could you share more information?

Thanks,
Peng.

> 
> > this cause mapping problem
> > for spl_boot_device. So far hard coded them to correct MMC index, so
> > that SD and eMMC boot can work.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/mach-imx/spl.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index
> > ebd8ff9290..0048832be8 100644
> > --- a/arch/arm/mach-imx/spl.c
> > +++ b/arch/arm/mach-imx/spl.c
> > @@ -147,9 +147,18 @@ u32 spl_boot_device(void)
> > case SD1_BOOT:
> > case MMC1_BOOT:
> > return BOOT_DEVICE_MMC1;
> > +#if defined(CONFIG_IMX8MM)
> > +   case SD2_BOOT:
> > +   case MMC2_BOOT:
> > +   return BOOT_DEVICE_MMC1;
> > +   case SD3_BOOT:
> > +   case MMC3_BOOT:
> > +   return BOOT_DEVICE_MMC2;
> > +#else
> > case SD2_BOOT:
> > case MMC2_BOOT:
> > return BOOT_DEVICE_MMC2;
> > +#endif
> >  #endif
> > case NAND_BOOT:
> > return BOOT_DEVICE_NAND;
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lu...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM

2019-01-29 Thread Peng Fan
Hi Lukasz,

> -Original Message-
> From: Lukasz Majewski [mailto:lu...@denx.de]
> Sent: 2019年1月30日 6:55
> To: Peng Fan 
> Cc: sba...@denx.de; Fabio Estevam ;
> dl-uboot-imx ; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM
> 
> Hi Peng,
> 
> > Introduce clk implementation for i.MX8MM, including pll configuration,
> > pll decoding, ccm configuration.
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm/include/asm/arch-imx8m/clock.h|   2 +
> >  arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 +++
> >  arch/arm/mach-imx/imx8m/Makefile   |   1 +
> >  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 866
> > +
> > arch/arm/mach-imx/imx8m/clock_slice.c  | 461
> + 5
> > files changed, 1717 insertions(+) create mode 100644
> > arch/arm/include/asm/arch-imx8m/clock_imx8mm.h create mode 100644
> > arch/arm/mach-imx/imx8m/clock_imx8mm.c
> 
> As fair as I see this approach is not similar to the one from Linux
> kernel:
> 
> https://elixir.bootlin.com/linux/v5.0-rc3/source/drivers/clk/imx/clk-imx8mq.
> c
> or simpler:
> https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx8mq.c
> 
> Also Fabio pointed out in the other mail that we shall stick to Linux
> kernel Common Clock Framework.
> 
> IMHO we shall add the simple CCF look alike code (I'm going to post
> imx6q port in a few days).

That will be too complicated for SPL and it will bring more efforts when
we do pre/post silicon bringup.

Regards,
Peng.

> 
> >
> > diff --git a/arch/arm/include/asm/arch-imx8m/clock.h
> > b/arch/arm/include/asm/arch-imx8m/clock.h index
> > 7225c760fe..ead4b8d3dc 100644 ---
> > a/arch/arm/include/asm/arch-imx8m/clock.h +++
> > b/arch/arm/include/asm/arch-imx8m/clock.h @@ -7,6 +7,8 @@
> >
> >  #ifdef CONFIG_IMX8MQ
> >  #include 
> > +#elif defined(CONFIG_IMX8MM)
> > +#include 
> >  #else
> >  #error "Error no clock.h"
> >  #endif
> > diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h new file mode
> 100644
> > index 00..305514a4ec
> > --- /dev/null
> > +++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> > @@ -0,0 +1,387 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright 2018-2019 NXP
> > + *
> > + * Peng Fan 
> > + */
> > +
> > +#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
> > +#define _ASM_ARCH_IMX8MM_CLOCK_H
> > +
> > +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)
> > \
> > +   {   \
> > +   .rate   =
> > (_rate),\
> > +   .mdiv   =
> > (_m),   \
> > +   .pdiv   =
> > (_p),   \
> > +   .sdiv   =
> > (_s),   \
> > +   .kdiv   =
> > (_k),   \
> > +   }
> > +
> > +#define LOCK_STATUSBIT(31)
> > +#define LOCK_SEL_MASK  BIT(29)
> > +#define CLKE_MASK  BIT(11)
> > +#define RST_MASK   BIT(9)
> > +#define BYPASS_MASKBIT(4)
> > +#defineMDIV_SHIFT  12
> > +#defineMDIV_MASK   GENMASK(21, 12)
> > +#define PDIV_SHIFT 4
> > +#define PDIV_MASK  GENMASK(9, 4)
> > +#define SDIV_SHIFT 0
> > +#define SDIV_MASK  GENMASK(2, 0)
> > +#define KDIV_SHIFT 0
> > +#define KDIV_MASK  GENMASK(15, 0)
> > +
> > +struct imx_int_pll_rate_table {
> > +   u32 rate;
> > +   int mdiv;
> > +   int pdiv;
> > +   int sdiv;
> > +   int kdiv;
> > +};
> > +
> > +enum pll_clocks {
> > +   ANATOP_ARM_PLL,
> > +   ANATOP_VPU_PLL,
> > +   ANATOP_GPU_PLL,
> > +   ANATOP_SYSTEM_PLL1,
> > +   ANATOP_SYSTEM_PLL2,
> > +   ANATOP_SYSTEM_PLL3,
> > +   ANATOP_AUDIO_PLL1,
> > +   ANATOP_AUDIO_PLL2,
> > +   ANATOP_VIDEO_PLL,
> > +   ANATOP_DRAM_PLL,
> > +};
> > +
> > +enum clk_root_index {
> > +   ARM_A53_CLK_ROOT= 0,
> > +   ARM_M4_CLK_ROOT = 1,
> > +   VPU_A53_CLK_ROOT= 2,
> > +   GPU3D_CLK_ROOT  = 3,
> > +   GPU2D_CLK_ROOT  = 4,
> > +   MAIN_AXI_CLK_ROOT   = 16,
> > +   ENET_AXI_CLK_ROOT   = 17,
> > +   NAND_USDHC_BUS_CLK_ROOT = 18,
> > +   VPU_BUS_CLK_ROOT= 19,
> > +   DISPLAY_AXI_CLK_ROOT= 20,
> > +   DISPLAY_APB_CLK_ROOT= 21,
> > +   DISPLAY_RTRM_CLK_ROOT   = 22,
> > +   USB_BUS_CLK_ROOT= 23,
> > +   GPU_AXI_CLK_ROOT= 24,
> > +   GPU_AHB_CLK_ROOT= 25,
> > +   NOC_CLK_ROOT= 26,
> > +   NOC_APB_CLK_ROOT= 27,
> > +   AHB_CLK_ROOT= 32,
> > +   IPG_CLK_ROOT= 33,
> > +   AUDIO_AHB_CLK_ROOT  = 34,
> > +   MIPI_DSI_ESC_RX_CLK_ROOT= 36,
> > +   DRAM_SEL_CFG= 48,
> > +   CORE_SEL_CFG= 49,
> > +   DRAM_ALT_CLK_ROOT   = 64,
> > +   DRAM_APB_CLK_ROOT   = 

Re: [U-Boot] [RFC 1/3] dm: blk: add UCLASS_PARTITION

2019-01-29 Thread AKASHI Takahiro
On Tue, Jan 29, 2019 at 11:20:01PM +0100, Heinrich Schuchardt wrote:
> On 1/29/19 3:59 AM, AKASHI Takahiro wrote:
> > UCLASS_PARTITION device will be created as a child node of
> > UCLASS_BLK device.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  drivers/block/blk-uclass.c | 52 ++
> >  include/dm/uclass-id.h |  1 +
> >  2 files changed, 53 insertions(+)
> > 
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> > index baaf431e5e0c..d4ca30f23fc1 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -10,6 +10,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  
> >  static const char *if_typename_str[IF_TYPE_COUNT] = {
> > [IF_TYPE_IDE]   = "ide",
> > @@ -654,3 +656,53 @@ UCLASS_DRIVER(blk) = {
> > .post_probe = blk_post_probe,
> > .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
> >  };
> > +
> > +U_BOOT_DRIVER(blk_partition) = {
> > +   .name   = "blk_partition",
> > +   .id = UCLASS_PARTITION,
> > +   .platdata_auto_alloc_size = sizeof(struct disk_part),
> > +};
> > +
> > +UCLASS_DRIVER(partition) = {
> > +   .id = UCLASS_PARTITION,
> > +   .name   = "partition",
> > +};
> > +
> > +#if defined(CONFIG_PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
> > +int blk_create_partitions(struct udevice *parent)
> > +{
> > +   int part;
> > +   struct blk_desc *desc = dev_get_uclass_platdata(parent);
> > +   disk_partition_t info;
> > +   struct disk_part *part_data;
> > +   char devname[32];
> > +   struct udevice *dev;
> > +   int disks = 0, ret;
> > +
> > +   /* Add devices for each partition */
> > +   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
> > +   if (part_get_info(desc, part, ))
> > +   continue;
> > +   snprintf(devname, sizeof(devname), "%s:%d", parent->name,
> > +part);
> > +
> > +   ret = device_bind_driver(parent, "blk_partition",
> > +strdup(devname), );
> > +   if (ret)
> 
> This looks like a memory leak for the output of strdup().

Yes, I'm aware of that, but please note that this is a prototype
and so I haven't paid much attention to failure cases (error recovery).
First of all, even in the current implementation, we don't support
*unplugging* (or unbind in EFI jargon?) devices.
It's a more fundamental issue.

> > +   return ret;
> 
> Why would we leave here if one partition fails?
> Does this imply that all further partitions will fail?
> Should we use continue here?

Ditto. Please be patient for the time being :)

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > +
> > +   part_data = dev_get_uclass_platdata(dev);
> > +   part_data->partnum = part;
> > +   part_data->gpt_part_info = info;
> > +
> > +   disks++;
> > +   }
> > +
> > +   return disks;
> > +}
> > +#else
> > +int blk_create_partitions(struct udevice *dev)
> > +{
> > +   return 0;
> > +}
> > +#endif
> > diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> > index f3bafb3c6353..e02b5f8fda42 100644
> > --- a/include/dm/uclass-id.h
> > +++ b/include/dm/uclass-id.h
> > @@ -65,6 +65,7 @@ enum uclass_id {
> > UCLASS_NVME,/* NVM Express device */
> > UCLASS_PANEL,   /* Display panel, such as an LCD */
> > UCLASS_PANEL_BACKLIGHT, /* Backlight controller for panel */
> > +   UCLASS_PARTITION,   /* Logical disk partition device */
> > UCLASS_PCH, /* x86 platform controller hub */
> > UCLASS_PCI, /* PCI bus */
> > UCLASS_PCI_GENERIC, /* Generic PCI bus device */
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 0/3] dm, efi: integrate efi_disk into DM

2019-01-29 Thread AKASHI Takahiro
Heinrich,

On Tue, Jan 29, 2019 at 11:48:37PM +0100, Heinrich Schuchardt wrote:
> On 1/29/19 5:20 PM, Alexander Graf wrote:
> > On 01/29/2019 03:59 AM, AKASHI Takahiro wrote:
> >> This patch set came from the past discussion[1] on my "removable device
> >> support" patch and is intended to be an attempt to integrate efi_disk
> >> (more precisely, EFI_BLOCK_IO_PROTOCOL-capable efi object) into u-boot's
> >> Driver Model as much seamlessly as possible
> >>
> >> [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html
> >>
> >> Basic idea is
> >> * create UCLASS_PARTITION
> >> * enumerate all the partitions when a block device is probed
> >> * hook up a creation of UCLASS_BLK or UCLASS_PARTITION device
> >>    to efi handler for efi_disk attributes to be properly set up
> >>
> >> Since this patch is a prototype (or POC, proof-of-concept), the aim here
> >> is to discuss further about how in a better shape we will be able to
> >> merge the two worlds.
> > 
> > I like the approach. It seems pretty clean and gives us a smooth
> > transition from the split world to a unified all-dm world. Eventually
> > the efi object list will just naturally disappear and we can drop all
> > calls to add efi object handles.
> > 
> > 
> > Alex
> > 
> > 
> 
> Thanks Takahiro, it is good to have a reference to work on to bring the
> worlds together.
> 
> I still have some issues:
> 
> The implementation lacks the driver binding protocol to handle block
> devices that are not discovered by U-Boot but supplied by an EFI driver
> or application. I would prefer if the block uclass would provide this
> protocol.

I don't yet have deep understandings of DM, but I believe that any
UCLASS_BLK instance should have a backing block device, blk_desc, which is
pointed to by uclass_platdata.
But your efi block device, UCLASS_BLK/IF_TYPE_EFI, does never initialize
this structure, in particular "ops," and so it won't work as a block device
on u-boot side.

I guess that it is one of reasons that EFI block driver doesn't work
with my patch.

If you agree with me, it would be much easier for you to modify
EFI block driver :)

> In EFI a handle can always be deleted by first stopping all controllers
> and then removing all protocols.

What do you mean by "delete?"
Some efi object will directly use efi_add_handle().
Efi object is solely responsible for maintaining a handle.

> The current implementation of partitions tries to use a struct efi_obj
> instead of a handle. This is incompatible to the rest of the EFI subsystem.

How incompatible?
A handle is always a pointer to opaque data outside the implementation.
struct efi_obj in blk_desc is explicitly handled only in efi_disk.c.
What's wrong with that?

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 27/40] x86: mrccache: Add more debugging

2019-01-29 Thread Simon Glass
When the MRC cache fails to save it is useful to have some debugging info
to indicate what when wrong. Add some more debug() calls.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/mrccache.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
index f37a732a45..be107627b8 100644
--- a/arch/x86/lib/mrccache.c
+++ b/arch/x86/lib/mrccache.c
@@ -113,8 +113,10 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
ulong base_addr;
int ret;
 
-   if (!is_mrc_cache(cur))
+   if (!is_mrc_cache(cur)) {
+   debug("%s: Cache data not valid\n", __func__);
return -EINVAL;
+   }
 
/* Find the last used block */
base_addr = entry->base + entry->offset;
@@ -205,17 +207,23 @@ int mrccache_get_region(struct udevice **devp, struct 
mrc_region *entry)
return -ENOENT;
}
 
-   if (fdtdec_get_int_array(blob, node, "memory-map", reg, 2))
+   if (fdtdec_get_int_array(blob, node, "memory-map", reg, 2)) {
+   debug("%s: Cannot find memory map\n", __func__);
return -EINVAL;
+   }
entry->base = reg[0];
 
/* Find the place where we put the MRC cache */
mrc_node = fdt_subnode_offset(blob, node, "rw-mrc-cache");
-   if (mrc_node < 0)
+   if (mrc_node < 0) {
+   debug("%s: Cannot find node\n", __func__);
return -EPERM;
+   }
 
-   if (fdtdec_get_int_array(blob, mrc_node, "reg", reg, 2))
+   if (fdtdec_get_int_array(blob, mrc_node, "reg", reg, 2)) {
+   debug("%s: Cannot find address\n", __func__);
return -EINVAL;
+   }
entry->offset = reg[0];
entry->length = reg[1];
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 31/40] x86: Don't generate a bootstage report in SPL

2019-01-29 Thread Simon Glass
This report is normally generated by U-Boot proper. Correct the condition
here so that it respects the Kconfig options for bootstage.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/bootm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 832b1f901c..5443a862ab 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -35,7 +35,7 @@ void bootm_announce_and_cleanup(void)
timestamp_add_now(TS_U_BOOT_START_KERNEL);
 #endif
bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, "start_kernel");
-#ifdef CONFIG_BOOTSTAGE_REPORT
+#if CONFIG_IS_ENABLED(BOOTSTAGE_REPORT)
bootstage_report();
 #endif
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 21/40] x86: Allow 16-bit init to be in TPL

2019-01-29 Thread Simon Glass
At present we support having 16-bit init be in SPL or U-Boot proper, but
not TPL. Add support for this so that TPL can boot.

Signed-off-by: Simon Glass 
---

 Makefile   |  1 +
 arch/x86/Makefile  |  4 ++--
 arch/x86/cpu/intel_common/Makefile |  2 +-
 arch/x86/cpu/u-boot-spl.lds|  2 +-
 scripts/Makefile.spl   | 10 +-
 5 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index c73b116480..86b21a1a78 100644
--- a/Makefile
+++ b/Makefile
@@ -1399,6 +1399,7 @@ cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
 
 u-boot.rom: u-boot-x86-16bit.bin u-boot.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
+   $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
$(if $(CONFIG_HAVE_REFCODE),refcode.bin) FORCE
$(call if_changed,binman)
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 9fd6cf2d3b..f1afc74fff 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -20,8 +20,8 @@ endif
 endif
 endif # EFI
 
-head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/start16.o
-head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/resetvec.o
+head-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += arch/x86/cpu/start16.o
+head-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += arch/x86/cpu/resetvec.o
 
 libs-y += arch/x86/cpu/
 libs-y += arch/x86/lib/
diff --git a/arch/x86/cpu/intel_common/Makefile 
b/arch/x86/cpu/intel_common/Makefile
index bf798c287f..80fbc7ab66 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -3,7 +3,7 @@
 # Copyright (c) 2016 Google, Inc
 
 ifdef CONFIG_HAVE_MRC
-obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += car.o
+obj-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += car.o
 obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += me_status.o
 obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += report_platform.o
 obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += mrc.o
diff --git a/arch/x86/cpu/u-boot-spl.lds b/arch/x86/cpu/u-boot-spl.lds
index 4e656dc4e5..f20c0b810d 100644
--- a/arch/x86/cpu/u-boot-spl.lds
+++ b/arch/x86/cpu/u-boot-spl.lds
@@ -54,7 +54,7 @@ SECTIONS
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
 
-#ifdef CONFIG_SPL_X86_16BIT_INIT
+#if defined(CONFIG_SPL_X86_16BIT_INIT) || defined(CONFIG_TPL_X86_16BIT_INIT)
/*
 * The following expressions place the 16-bit Real-Mode code and
 * Reset Vector at the end of the Flash ROM
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index c9eea629dd..107f1e257a 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -230,7 +230,11 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
 ALL-y  += boot.bin
 endif
 
+ifdef CONFIG_TPL_BUILD
+ALL-$(CONFIG_TPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-16bit-tpl.bin
+else
 ALL-$(CONFIG_SPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-16bit-spl.bin
+endif
 
 ALL-$(CONFIG_ARCH_ZYNQ)+= $(obj)/boot.bin
 ALL-$(CONFIG_ARCH_ZYNQMP)  += $(obj)/boot.bin
@@ -330,7 +334,7 @@ quiet_cmd_objcopy = OBJCOPY $@
 cmd_objcopy = $(OBJCOPY) $(OBJCOPYFLAGS) $(OBJCOPYFLAGS_$(@F)) $< $@
 
 OBJCOPYFLAGS_$(SPL_BIN)-nodtb.bin = $(SPL_OBJCFLAGS) -O binary \
-   $(if $(CONFIG_SPL_X86_16BIT_INIT),-R .start16 -R .resetvec)
+   $(if $(CONFIG_$(SPL_TPL_)X86_16BIT_INIT),-R .start16 -R 
.resetvec)
 
 $(obj)/$(SPL_BIN)-nodtb.bin: $(obj)/$(SPL_BIN) FORCE
$(call if_changed,objcopy)
@@ -339,6 +343,10 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j 
.start16 -j .resetvec
 $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
$(call if_changed,objcopy)
 
+OBJCOPYFLAGS_u-boot-x86-16bit-tpl.bin := -O binary -j .start16 -j .resetvec
+$(obj)/u-boot-x86-16bit-tpl.bin: $(obj)/u-boot-tpl FORCE
+   $(call if_changed,objcopy)
+
 LDFLAGS_$(SPL_BIN) += -T u-boot-spl.lds $(LDFLAGS_FINAL)
 
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 32/40] x86: Support PCI VGA ROM when TPL is used

2019-01-29 Thread Simon Glass
When TPL is in use, U-Boot proper should support initing the VGA ROM even
though the 32-bit init portion is in SPL. Update the condition to handle
this.

Signed-off-by: Simon Glass 
---

 drivers/pci/pci_rom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 7d9b75c2c4..2cede1211b 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -306,7 +306,7 @@ int dm_pci_run_vga_bios(struct udevice *dev, int 
(*int15_handler)(void),
goto err;
 #endif
} else {
-#if defined(CONFIG_X86) && CONFIG_IS_ENABLED(X86_32BIT_INIT)
+#if defined(CONFIG_X86) && (CONFIG_IS_ENABLED(X86_32BIT_INIT) || CONFIG_TPL)
bios_set_interrupt_handler(0x15, int15_handler);
 
bios_run_on_x86(dev, (unsigned long)ram, vesa_mode,
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 28/40] x86: Add a sysreset driver for the Intel PCH

2019-01-29 Thread Simon Glass
Intel SoCs support a fairly stardard reset mechanism which can support
powering off the device. Add support for this and enable it by default on
broadwell, which already has the necessary pm.h header file.

This driver augments the standard x86 sysreset driver.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/Kconfig|   1 +
 drivers/sysreset/Kconfig  |   9 ++
 drivers/sysreset/Makefile |   1 +
 drivers/sysreset/sysreset_intel_pch.c | 125 ++
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/sysreset/sysreset_intel_pch.c

diff --git a/arch/x86/cpu/broadwell/Kconfig b/arch/x86/cpu/broadwell/Kconfig
index 5b015c89d9..2955ffc55b 100644
--- a/arch/x86/cpu/broadwell/Kconfig
+++ b/arch/x86/cpu/broadwell/Kconfig
@@ -18,6 +18,7 @@ config INTEL_BROADWELL
imply USB
imply USB_EHCI_HCD
imply VIDEO_BROADWELL_IGD
+   imply SYSRESET_INTEL_PCH
 
 if INTEL_BROADWELL
 
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..f88412adcc 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -23,6 +23,15 @@ config SYSRESET_GPIO
  example on Microblaze where reset logic can be controlled via GPIO
  pin which triggers cpu reset.
 
+config SYSRESET_INTEL_PCH
+   bool "Enable support for Intel PCH reset driver"
+   depends on X86
+   help
+ Enable this option to get reset support on Intel SoCs which have
+ a common Platform-Controller Hub (PCH). This driver supports powering
+ off the device. It augments the standard x86 sysreset driver which
+ provides normal reset options.
+
 config SYSRESET_MICROBLAZE
bool "Enable support for Microblaze soft reset"
depends on MICROBLAZE
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..2add6cb37a 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += sysreset_rockchip.o
 obj-$(CONFIG_ARCH_STI) += sysreset_sti.o
 obj-$(CONFIG_SANDBOX) += sysreset_sandbox.o
 obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
+obj-$(CONFIG_SYSRESET_INTEL_PCH) += sysreset_intel_pch.o
 obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
 obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
 obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
diff --git a/drivers/sysreset/sysreset_intel_pch.c 
b/drivers/sysreset/sysreset_intel_pch.c
new file mode 100644
index 00..b60fa40dda
--- /dev/null
+++ b/drivers/sysreset/sysreset_intel_pch.c
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Google Inc,
+ * Written by Simon Glass 
+ *
+ * Reset driver for intel x86 processors with a PCH. Supports powering the
+ * device off.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct x86_reset_platdata {
+   struct udevice *pch;
+};
+
+/*
+ * Power down the machine by using the power management sleep control
+ * of the chipset. This will currently only work on Intel chipsets.
+ * However, adapting it to new chipsets is fairly simple. You will
+ * have to find the IO address of the power management register block
+ * in your southbridge, and look up the appropriate SLP_TYP_S5 value
+ * from your southbridge's data sheet.
+ *
+ * This function never returns.
+ */
+int pch_sysreset_power_off(struct udevice *dev)
+{
+   struct x86_reset_platdata *plat = dev_get_platdata(dev);
+   u16 pmbase;
+   u32 reg32;
+   int ret;
+
+   if (!plat->pch)
+   return -ENOENT;
+
+   /* Find the base address of the powermanagement registers */
+   ret = dm_pci_read_config16(plat->pch, 0x40, );
+   if (ret)
+   return ret;
+
+   pmbase &= 0xfffe;
+
+   /* Mask interrupts or system might stay in a coma
+* (not executing code anymore, but not powered off either)
+*/
+   asm("cli");
+
+   /*
+* Avoid any GPI waking the system from S5* or the system might stay in
+* a coma
+*/
+   outl(0x, pmbase + GPE0_EN(0));
+
+   /* Clear Power Button Status */
+   outw(PWRBTN_STS, pmbase + PM1_STS);
+
+   /* PMBASE + 4, Bit 10-12, Sleeping Type, * set to 111 -> S5, soft_off */
+   reg32 = inl(pmbase + PM1_CNT);
+
+   /* Set Sleeping Type to S5 (poweroff) */
+   reg32 &= ~(SLP_EN | SLP_TYP);
+   reg32 |= SLP_TYP_S5;
+   outl(reg32, pmbase + PM1_CNT);
+
+   /* Now set the Sleep Enable bit */
+   reg32 |= SLP_EN;
+   outl(reg32, pmbase + PM1_CNT);
+
+   for (;;)
+   asm("hlt");
+}
+
+static int pch_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+   int ret;
+
+   switch (type) {
+   case SYSRESET_POWER_OFF:
+   ret = pch_sysreset_power_off(dev);
+   if (ret)
+   return ret;
+   break;
+   default:
+

[U-Boot] [PATCH 36/40] x86: samus: Update device tree for verified boot

2019-01-29 Thread Simon Glass
Add nvdata drivers for the TPM and RTC as used on samus. These are needed
for Chromium OS verified boot on samus.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/chromebook_samus.dts | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/x86/dts/chromebook_samus.dts 
b/arch/x86/dts/chromebook_samus.dts
index 348d012e23..7c5b1e4010 100644
--- a/arch/x86/dts/chromebook_samus.dts
+++ b/arch/x86/dts/chromebook_samus.dts
@@ -9,6 +9,12 @@
 /include/ "rtc.dtsi"
 /include/ "tsc_timer.dtsi"
 
+#ifdef CONFIG_CHROMEOS
+#include "chromeos-x86.dtsi"
+#include "flashmap-x86-ro.dtsi"
+#include "flashmap-8mb-rw.dtsi"
+#endif
+
 / {
model = "Google Samus";
compatible = "google,samus", "intel,broadwell";
@@ -552,7 +558,7 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "intel,ich9-spi";
-   spi-flash@0 {
+   fwstore_spi: spi-flash@0 {
u-boot,dm-pre-reloc;
#size-cells = <1>;
#address-cells = <1>;
@@ -646,6 +652,10 @@
u-boot,dm-pre-reloc;
reg = <0xfed4 0x5000>;
compatible = "infineon,slb9635lpc";
+   secdata {
+   u-boot,dm-pre-reloc;
+   compatible = "google,tpm-secdata";
+   };
};
 
microcode {
@@ -657,3 +667,13 @@
};
 
 };
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   nvdata {
+   u-boot,dm-pre-reloc;
+   compatible = "google,cmos-nvdata";
+   reg = <0x26>;
+   };
+};
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 30/40] x86: Don't set up MTRRs in SPL

2019-01-29 Thread Simon Glass
The MTRRs are normally set up in U-Boot proper, so avoid setting them up
in SPL as well.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/init_helpers.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 0481f453ca..ac85278cdf 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -18,7 +18,10 @@ __weak ulong board_get_usable_ram_top(ulong total_size)
 
 int init_cache_f_r(void)
 {
-#if CONFIG_IS_ENABLED(X86_32BIT_INIT) && !defined(CONFIG_HAVE_FSP)
+#if (CONFIG_IS_ENABLED(X86_32BIT_INIT) || \
+ (!defined(CONFIG_SPL_BUILD) && \
+  !CONFIG_IS_ENABLED(CONFIG_X86_RUN_64BIT))) && \
+!defined(CONFIG_HAVE_FSP)
int ret;
 
ret = mtrr_commit(false);
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 23/40] x86: broadwell: Select refcode and CPU code for SPL

2019-01-29 Thread Simon Glass
Allow broadwell to build for SPL and include the reference code.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/Makefile | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/broadwell/Makefile b/arch/x86/cpu/broadwell/Makefile
index 11d30b03e5..394a794f91 100644
--- a/arch/x86/cpu/broadwell/Makefile
+++ b/arch/x86/cpu/broadwell/Makefile
@@ -2,13 +2,14 @@
 #
 # Copyright (c) 2016 Google, Inc
 
-obj-y += cpu.o
-obj-y += cpu_full.o
+obj-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += cpu.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += cpu_full.o
 
 ifdef CONFIG_SPL
 ifndef CONFIG_SPL_BUILD
 obj-y += cpu_from_spl.o
 obj-y += cpu_full.o
+obj-y += refcode.o
 endif
 ifndef CONFIG_SPL_BUILD
 # obj-y += cpu_from_spl.o
@@ -26,6 +27,6 @@ obj-y += northbridge.o
 obj-y += pch.o
 obj-y += pinctrl_broadwell.o
 obj-y += power_state.o
-obj-y += refcode.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += refcode.o
 obj-y += sata.o
 obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += sdram.o
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 38/40] x86: Update device tree for Chromium OS verified boot

2019-01-29 Thread Simon Glass
The standard image generated by U-Boot on x86 is u-boot.rom. Add a
separate image called image.bin for verified boot. This supports
verification in TPL of which SPL/U-Boot to start, then jumping to the
correct one, with SPL setting up the SDRAM and U-Boot proper providing
the user interface if needed.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/u-boot.dtsi | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 70e9c8f7ac..5943619b86 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -6,9 +6,23 @@
 
 #include 
 
-#ifdef CONFIG_ROM_SIZE
+#ifdef CONFIG_CHROMEOS
 / {
binman {
+   multiple-images;
+   rom: rom {
+   };
+   };
+};
+#else
+/ {
+   rom: binman {
+   };
+};
+#endif
+
+#ifdef CONFIG_ROM_SIZE
+ {
filename = "u-boot.rom";
end-at-4gb;
sort-by-offset;
@@ -108,6 +122,5 @@
offset = ;
};
 #endif
-   };
 };
 #endif
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 39/40] x86: Fix device-tree indentation

2019-01-29 Thread Simon Glass
With the use of a phandle we can outdent the device tree nodes a little.
Fix this.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/u-boot.dtsi | 147 +++
 1 file changed, 73 insertions(+), 74 deletions(-)

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 5943619b86..8bb1318a2c 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -23,104 +23,103 @@
 
 #ifdef CONFIG_ROM_SIZE
  {
-   filename = "u-boot.rom";
-   end-at-4gb;
-   sort-by-offset;
-   pad-byte = <0xff>;
-   size = ;
+   filename = "u-boot.rom";
+   end-at-4gb;
+   sort-by-offset;
+   pad-byte = <0xff>;
+   size = ;
 #ifdef CONFIG_HAVE_INTEL_ME
-   intel-descriptor {
-   filename = CONFIG_FLASH_DESCRIPTOR_FILE;
-   };
-   intel-me {
-   filename = CONFIG_INTEL_ME_FILE;
-   };
+   intel-descriptor {
+   filename = CONFIG_FLASH_DESCRIPTOR_FILE;
+   };
+   intel-me {
+   filename = CONFIG_INTEL_ME_FILE;
+   };
 #endif
 #ifdef CONFIG_TPL
-   u-boot-spl {
-   offset = ;
-   };
-   u-boot-spl-dtb {
-   };
-   u-boot-tpl-with-ucode-ptr {
-   offset = ;
-   };
-   u-boot-tpl-dtb {
-   };
-   u-boot {
-   offset = ;
-   };
+   u-boot-spl {
+   offset = ;
+   };
+   u-boot-spl-dtb {
+   };
+   u-boot-tpl-with-ucode-ptr {
+   offset = ;
+   };
+   u-boot-tpl-dtb {
+   };
+   u-boot {
+   offset = ;
+   };
 #elif defined(CONFIG_SPL)
-   u-boot-spl-with-ucode-ptr {
-   offset = ;
-   };
-
-   u-boot-dtb-with-ucode2 {
-   type = "u-boot-dtb-with-ucode";
-   };
-   u-boot {
+   u-boot-spl-with-ucode-ptr {
+   offset = ;
+   };
+   u-boot-dtb-with-ucode2 {
+   type = "u-boot-dtb-with-ucode";
+   };
+   u-boot {
 #if CONFIG_SYS_TEXT_BASE == 0x111
-   offset = <0xfff0>;
+   offset = <0xfff0>;
 #else
-   offset = ;
+   offset = ;
 #endif
-   };
+   };
 #else
-   u-boot-with-ucode-ptr {
-   offset = ;
-   };
+   u-boot-with-ucode-ptr {
+   offset = ;
+   };
 #endif
-   u-boot-dtb-with-ucode {
-   };
-   u-boot-ucode {
-   align = <16>;
-   };
+   u-boot-dtb-with-ucode {
+   };
+   u-boot-ucode {
+   align = <16>;
+   };
 #ifdef CONFIG_HAVE_MRC
-   intel-mrc {
-   offset = ;
-   };
+   intel-mrc {
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_HAVE_FSP
-   intel-fsp {
-   filename = CONFIG_FSP_FILE;
-   offset = ;
-   };
+   intel-fsp {
+   filename = CONFIG_FSP_FILE;
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_HAVE_CMC
-   intel-cmc {
-   filename = CONFIG_CMC_FILE;
-   offset = ;
-   };
+   intel-cmc {
+   filename = CONFIG_CMC_FILE;
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_HAVE_VGA_BIOS
-   intel-vga {
-   filename = CONFIG_VGA_BIOS_FILE;
-   offset = ;
-   };
+   intel-vga {
+   filename = CONFIG_VGA_BIOS_FILE;
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_HAVE_VBT
-   intel-vbt {
-   filename = CONFIG_VBT_FILE;
-   offset = ;
-   };
+   intel-vbt {
+   filename = CONFIG_VBT_FILE;
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_HAVE_REFCODE
-   intel-refcode {
-   offset = ;
-   };
+   intel-refcode {
+   offset = ;
+   };
 #endif
 #ifdef CONFIG_TPL
-   x86-start16-tpl {
-   offset = ;
-   };
+   x86-start16-tpl {
+   offset = ;
+   };
 #elif defined(CONFIG_SPL)
-   x86-start16-spl {
-   offset = ;
-   };
+   x86-start16-spl {
+   offset = ;
+   };
 #else
-   x86-start16 {
-   offset = ;
-   };
+   x86-start16 {
+   offset = ;
+   };
 #endif
 };
 #endif
-- 
2.20.1.495.gaa96b0ce6b-goog

___
U-Boot mailing list

[U-Boot] [PATCH 16/40] x86: broadwell: Improve SDRAM debugging output

2019-01-29 Thread Simon Glass
Add debugging during SDRAM init so that problems are easier to
diagnose.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/sdram.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/arch/x86/cpu/broadwell/sdram.c b/arch/x86/cpu/broadwell/sdram.c
index 03a35bcf73..1b9f9840c6 100644
--- a/arch/x86/cpu/broadwell/sdram.c
+++ b/arch/x86/cpu/broadwell/sdram.c
@@ -204,16 +204,18 @@ int dram_init(void)
 
/* Print ME state before MRC */
ret = syscon_get_by_driver_data(X86_SYSCON_ME, _dev);
-   if (ret)
+   if (ret) {
+   debug("Cannot get ME (err=%d)\n", ret);
return ret;
+   }
intel_me_status(me_dev);
 
/* Save ME HSIO version */
-   ret = uclass_first_device(UCLASS_PCH, _dev);
-   if (ret)
+   ret = uclass_first_device_err(UCLASS_PCH, _dev);
+   if (ret) {
+   debug("Cannot get PCH (err=%d)\n", ret);
return ret;
-   if (!pch_dev)
-   return -ENODEV;
+   }
power_state_get(pch_dev, );
 
intel_me_hsio_version(me_dev, _version, _checksum);
@@ -221,15 +223,17 @@ int dram_init(void)
broadwell_fill_pei_data(pei_data);
mainboard_fill_pei_data(pei_data);
 
-   ret = uclass_first_device(UCLASS_NORTHBRIDGE, );
-   if (ret)
+   ret = uclass_first_device_err(UCLASS_NORTHBRIDGE, );
+   if (ret) {
+   debug("Cannot get Northbridge (err=%d)\n", ret);
return ret;
-   if (!dev)
-   return -ENODEV;
+   }
size = 256;
ret = mrc_locate_spd(dev, size, _data);
-   if (ret)
+   if (ret) {
+   debug("Cannot locate SPD (err=%d)\n", ret);
return ret;
+   }
memcpy(pei_data->spd_data[0][0], spd_data, size);
memcpy(pei_data->spd_data[1][0], spd_data, size);
 
@@ -239,13 +243,17 @@ int dram_init(void)
 
debug("PEI version %#x\n", pei_data->pei_version);
ret = mrc_common_init(dev, pei_data, true);
-   if (ret)
+   if (ret) {
+   debug("mrc_common_init() failed(err=%d)\n", ret);
return ret;
+   }
debug("Memory init done\n");
 
ret = sdram_find(dev);
-   if (ret)
+   if (ret) {
+   debug("sdram_find() failed (err=%d)\n", ret);
return ret;
+   }
gd->ram_size = gd->arch.meminfo.total_32bit_memory;
debug("RAM size %llx\n", (unsigned long long)gd->ram_size);
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 19/40] x86: broadwell: Split CPU init

2019-01-29 Thread Simon Glass
Split the CPU init into two parts - the 'full' init which happens in the
first U-Boot phase, and the rest of the init that happens on subsequent
stages.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/Makefile   |   1 +
 arch/x86/cpu/broadwell/cpu.c  | 673 -
 arch/x86/cpu/broadwell/cpu_full.c | 694 ++
 3 files changed, 695 insertions(+), 673 deletions(-)
 create mode 100644 arch/x86/cpu/broadwell/cpu_full.c

diff --git a/arch/x86/cpu/broadwell/Makefile b/arch/x86/cpu/broadwell/Makefile
index 55f2c93719..303d2b274b 100644
--- a/arch/x86/cpu/broadwell/Makefile
+++ b/arch/x86/cpu/broadwell/Makefile
@@ -3,6 +3,7 @@
 # Copyright (c) 2016 Google, Inc
 
 obj-y += cpu.o
+obj-y += cpu_full.o
 obj-y += iobp.o
 obj-y += lpc.o
 obj-y += me.o
diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
index d53c7b863f..bb7c361408 100644
--- a/arch/x86/cpu/broadwell/cpu.c
+++ b/arch/x86/cpu/broadwell/cpu.c
@@ -21,68 +21,6 @@
 #include 
 #include 
 
-struct cpu_broadwell_priv {
-   bool ht_disabled;
-};
-
-/* Convert time in seconds to POWER_LIMIT_1_TIME MSR value */
-static const u8 power_limit_time_sec_to_msr[] = {
-   [0]   = 0x00,
-   [1]   = 0x0a,
-   [2]   = 0x0b,
-   [3]   = 0x4b,
-   [4]   = 0x0c,
-   [5]   = 0x2c,
-   [6]   = 0x4c,
-   [7]   = 0x6c,
-   [8]   = 0x0d,
-   [10]  = 0x2d,
-   [12]  = 0x4d,
-   [14]  = 0x6d,
-   [16]  = 0x0e,
-   [20]  = 0x2e,
-   [24]  = 0x4e,
-   [28]  = 0x6e,
-   [32]  = 0x0f,
-   [40]  = 0x2f,
-   [48]  = 0x4f,
-   [56]  = 0x6f,
-   [64]  = 0x10,
-   [80]  = 0x30,
-   [96]  = 0x50,
-   [112] = 0x70,
-   [128] = 0x11,
-};
-
-/* Convert POWER_LIMIT_1_TIME MSR value to seconds */
-static const u8 power_limit_time_msr_to_sec[] = {
-   [0x00] = 0,
-   [0x0a] = 1,
-   [0x0b] = 2,
-   [0x4b] = 3,
-   [0x0c] = 4,
-   [0x2c] = 5,
-   [0x4c] = 6,
-   [0x6c] = 7,
-   [0x0d] = 8,
-   [0x2d] = 10,
-   [0x4d] = 12,
-   [0x6d] = 14,
-   [0x0e] = 16,
-   [0x2e] = 20,
-   [0x4e] = 24,
-   [0x6e] = 28,
-   [0x0f] = 32,
-   [0x2f] = 40,
-   [0x4f] = 48,
-   [0x6f] = 56,
-   [0x10] = 64,
-   [0x30] = 80,
-   [0x50] = 96,
-   [0x70] = 112,
-   [0x11] = 128,
-};
-
 int arch_cpu_init_dm(void)
 {
struct udevice *dev;
@@ -168,614 +106,3 @@ void board_debug_uart_init(void)
pci_x86_write_config(bus, PCH_DEV_LPC, LPC_EN, COMA_LPC_EN,
 PCI_SIZE_16);
 }
-
-/*
- * The core 100MHz BLCK is disabled in deeper c-states. One needs to calibrate
- * the 100MHz BCLCK against the 24MHz BLCK to restore the clocks properly
- * when a core is woken up
- */
-static int pcode_ready(void)
-{
-   int wait_count;
-   const int delay_step = 10;
-
-   wait_count = 0;
-   do {
-   if (!(readl(MCHBAR_REG(BIOS_MAILBOX_INTERFACE)) &
-   MAILBOX_RUN_BUSY))
-   return 0;
-   wait_count += delay_step;
-   udelay(delay_step);
-   } while (wait_count < 1000);
-
-   return -ETIMEDOUT;
-}
-
-static u32 pcode_mailbox_read(u32 command)
-{
-   int ret;
-
-   ret = pcode_ready();
-   if (ret) {
-   debug("PCODE: mailbox timeout on wait ready\n");
-   return ret;
-   }
-
-   /* Send command and start transaction */
-   writel(command | MAILBOX_RUN_BUSY, MCHBAR_REG(BIOS_MAILBOX_INTERFACE));
-
-   ret = pcode_ready();
-   if (ret) {
-   debug("PCODE: mailbox timeout on completion\n");
-   return ret;
-   }
-
-   /* Read mailbox */
-   return readl(MCHBAR_REG(BIOS_MAILBOX_DATA));
-}
-
-static int pcode_mailbox_write(u32 command, u32 data)
-{
-   int ret;
-
-   ret = pcode_ready();
-   if (ret) {
-   debug("PCODE: mailbox timeout on wait ready\n");
-   return ret;
-   }
-
-   writel(data, MCHBAR_REG(BIOS_MAILBOX_DATA));
-
-   /* Send command and start transaction */
-   writel(command | MAILBOX_RUN_BUSY, MCHBAR_REG(BIOS_MAILBOX_INTERFACE));
-
-   ret = pcode_ready();
-   if (ret) {
-   debug("PCODE: mailbox timeout on completion\n");
-   return ret;
-   }
-
-   return 0;
-}
-
-/* @dev is the CPU device */
-static void initialize_vr_config(struct udevice *dev)
-{
-   int ramp, min_vid;
-   msr_t msr;
-
-   debug("Initializing VR config\n");
-
-   /* Configure VR_CURRENT_CONFIG */
-   msr = msr_read(MSR_VR_CURRENT_CONFIG);
-   /*
-* Preserve bits 63 and 62. Bit 62 is PSI4 enable, but it is only valid
-* on ULT systems
-*/
-   msr.hi &= 0xc000;
-   msr.hi |= (0x01 << (52 - 32)); /* PSI3 threshold -  1A */
-   msr.hi |= (0x05 << (42 - 32)); /* PSI2 threshold -  5A */
-   

[U-Boot] [PATCH 40/40] x86: samus: Add a target to boot through TPL

2019-01-29 Thread Simon Glass
Add a version of samus which supports booting from TPL to SPL and then
to U-Boot. This allows TPL to select from an A or B SPL to support
verified boot with field upgrade.

Signed-off-by: Simon Glass 
---

 board/google/Kconfig  |  8 +++
 board/google/chromebook_samus/Kconfig | 14 +++-
 board/google/chromebook_samus/MAINTAINERS |  7 ++
 configs/chromebook_samus_tpl_defconfig| 80 +++
 include/configs/chromebook_samus.h|  3 +
 5 files changed, 110 insertions(+), 2 deletions(-)
 create mode 100644 configs/chromebook_samus_tpl_defconfig

diff --git a/board/google/Kconfig b/board/google/Kconfig
index d98a5e818f..679a0f1023 100644
--- a/board/google/Kconfig
+++ b/board/google/Kconfig
@@ -52,6 +52,14 @@ config TARGET_CHROMEBOOK_SAMUS
  Chrome OS EC connected on LPC, and it provides a 2560x1700 high
  resolution touch-enabled LCD display.
 
+config TARGET_CHROMEBOOK_SAMUS_TPL
+   bool "Chromebook samus booting from TPL"
+   help
+ This is a version of Samus which boots into TPL, then to SPL and
+ U-Boot proper. This is useful where verified boot must select
+ between different A/B versions of SPL/U-Boot, to allow upgrading of
+ almost all U-Boot code in the field.
+
 endchoice
 
 source "board/google/chromebook_link/Kconfig"
diff --git a/board/google/chromebook_samus/Kconfig 
b/board/google/chromebook_samus/Kconfig
index afbfe53deb..90c23cba1b 100644
--- a/board/google/chromebook_samus/Kconfig
+++ b/board/google/chromebook_samus/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_CHROMEBOOK_SAMUS
+if TARGET_CHROMEBOOK_SAMUS || TARGET_CHROMEBOOK_SAMUS_TPL
 
 config SYS_BOARD
default "chromebook_samus"
@@ -10,7 +10,8 @@ config SYS_SOC
default "broadwell"
 
 config SYS_CONFIG_NAME
-   default "chromebook_samus"
+   default "chromebook_samus" if TARGET_CHROMEBOOK_SAMUS
+   default "chromebook_samus" if TARGET_CHROMEBOOK_SAMUS_TPL
 
 config SYS_TEXT_BASE
default 0xffe0
@@ -39,3 +40,12 @@ config SYS_CAR_SIZE
default 0x4
 
 endif
+
+if TARGET_CHROMEBOOK_SAMUS_TPL
+
+config BOARD_SPECIFIC_OPTIONS_TPL # dummy
+   def_bool y
+   select SPL
+   select TPL
+
+endif
diff --git a/board/google/chromebook_samus/MAINTAINERS 
b/board/google/chromebook_samus/MAINTAINERS
index 5500e46b40..ca4b16500a 100644
--- a/board/google/chromebook_samus/MAINTAINERS
+++ b/board/google/chromebook_samus/MAINTAINERS
@@ -4,3 +4,10 @@ S: Maintained
 F: board/google/chromebook_samus/
 F: include/configs/chromebook_samus.h
 F: configs/chromebook_samus_defconfig
+
+CHROMEBOOK SAMUS TPL BOARD
+M: Simon Glass 
+S: Maintained
+F: board/google/chromebook_samus/
+F: include/configs/chromebook_samus.h
+F: configs/chromebook_samus_tpl_defconfig
diff --git a/configs/chromebook_samus_tpl_defconfig 
b/configs/chromebook_samus_tpl_defconfig
new file mode 100644
index 00..0a379e5b1c
--- /dev/null
+++ b/configs/chromebook_samus_tpl_defconfig
@@ -0,0 +1,80 @@
+CONFIG_X86=y
+CONFIG_SYS_TEXT_BASE=0xffed
+CONFIG_SYS_MALLOC_F_LEN=0x1a00
+CONFIG_DEBUG_UART_BOARD_INIT=y
+CONFIG_DEBUG_UART_BASE=0x3f8
+CONFIG_DEBUG_UART_CLOCK=1843200
+CONFIG_VENDOR_GOOGLE=y
+CONFIG_TARGET_CHROMEBOOK_SAMUS_TPL=y
+CONFIG_DEBUG_UART=y
+CONFIG_HAVE_MRC=y
+CONFIG_HAVE_REFCODE=y
+CONFIG_SMP=y
+CONFIG_HAVE_VGA_BIOS=y
+CONFIG_NR_DRAM_BANKS=8
+CONFIG_BOOTSTAGE=y
+CONFIG_BOOTSTAGE_REPORT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_MISC_INIT_R=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CPU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_BOOTSTAGE=y
+CONFIG_CMD_TPM=y
+CONFIG_CMD_TPM_TEST=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_DEFAULT_DEVICE_TREE="chromebook_samus"
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_CPU=y
+CONFIG_CROS_EC=y
+CONFIG_CROS_EC_LPC=y
+CONFIG_SYS_NS16550=y
+CONFIG_SPI=y
+CONFIG_TPM_TIS_LPC=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
+CONFIG_FRAMEBUFFER_VESA_MODE_11A=y
+CONFIG_CONSOLE_SCROLL_LINES=5
+CONFIG_TPM=y
+CONFIG_SPL=y
+CONFIG_TPL=y
+CONFIG_HANDOFF=y
+CONFIG_BLOBLIST_ADDR=0xff7c
+CONFIG_BLOBLIST_SIZE=0x1000
+CONFIG_BLOBLIST=y
+CONFIG_SPL_PCI=y
+CONFIG_SPL_PCH_SUPPORT=y
+CONFIG_SPL_NET_SUPPORT=y
+CONFIG_TPL_PCI=y
+CONFIG_TPL_PCH_SUPPORT=y
+CONFIG_TPL_MISC=y
+# CONFIG_NET is not set
+# CONFIG_SPL_ENV_SUPPORT is not set
+# CONFIG_TPL_ENV_SUPPORT is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+# 

[U-Boot] [PATCH 34/40] x86: Add documention on the samus flashmap

2019-01-29 Thread Simon Glass
There are quite a few variables which control where things appear in the
final ROM image. Add a flashmap in the documentation to make this easier
to figure out.

Signed-off-by: Simon Glass 
---

 doc/README.x86 | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/doc/README.x86 b/doc/README.x86
index fa49cb8b8a..d5224b7536 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -185,6 +185,20 @@ If you are using em100, then this command will flash write 
-Boot:
 
em100 -s -d filename.rom -c W25Q64CV -r
 
+Flash map for samus / broadwell:
+
+   f800SYS_X86_START16
+   RESET_SEG_START
+   fffd8000TPL_TEXT_BASE
+   fffaX86_MRC_ADDR
+   fff9VGA_BIOS_ADDR
+   ffedSYS_TEXT_BASE
+   ffeaX86_REFCODE_ADDR
+   ffe7SPL_TEXT_BASE
+   ffa0
+   ff801000intel-me (address set by descriptor.bin)
+   ff80intel-descriptor
+
 ---
 
 Intel Crown Bay specific instructions for bare mode:
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 26/40] x86: Add a simple TPL implementations

2019-01-29 Thread Simon Glass
Add the required CPU code so that TPL builds correctly. Also update the
SPL code to deal with being booted from TPL.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/spl.h|  17 -
 arch/x86/lib/Makefile |   9 ++-
 arch/x86/lib/spl.c|  44 ++-
 arch/x86/lib/tpl.c| 118 ++
 include/configs/chromebook_link.h |   3 -
 include/configs/qemu-x86.h|   3 -
 6 files changed, 183 insertions(+), 11 deletions(-)
 create mode 100644 arch/x86/lib/tpl.c

diff --git a/arch/x86/include/asm/spl.h b/arch/x86/include/asm/spl.h
index 8cf59d14e7..27432b2897 100644
--- a/arch/x86/include/asm/spl.h
+++ b/arch/x86/include/asm/spl.h
@@ -2,6 +2,19 @@
 /*
  * Copyright (C) 2017 Google, Inc
  * Written by Simon Glass 
- *
- * This file is required for SPL to build, but is empty.
  */
+
+#ifndef __asm_spl_h
+#define __asm_spl_h
+
+#define CONFIG_SPL_BOARD_LOAD_IMAGE
+
+enum {
+   BOOT_DEVICE_SPI = 10,
+   BOOT_DEVICE_BOARD,
+   BOOT_DEVICE_CROS_VBOOT,
+};
+
+void jump_to_spl(ulong entry);
+
+#endif
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 1e8efcc44f..a72378c0aa 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -43,7 +43,14 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_CMD_ZBOOT)+= zimage.o
 endif
 obj-$(CONFIG_HAVE_FSP) += fsp/
-obj-$(CONFIG_SPL_BUILD) += spl.o
+
+ifdef CONFIG_SPL_BUILD
+ifdef CONFIG_TPL_BUILD
+obj-y += tpl.o
+else
+obj-y += spl.o
+endif
+endif
 
 lib-$(CONFIG_USE_PRIVATE_LIBGCC) += div64.o
 
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index 7d290740bf..5d5d1a9ca7 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -5,8 +5,10 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -20,6 +22,7 @@ __weak int arch_cpu_init_dm(void)
 
 static int x86_spl_init(void)
 {
+#ifndef CONFIG_TPL
/*
 * TODO(s...@chromium.org): We use this area of RAM for the stack
 * and global_data in SPL. Once U-Boot starts up and releocates it
@@ -27,6 +30,7 @@ static int x86_spl_init(void)
 * place it immediately below CONFIG_SYS_TEXT_BASE.
 */
char *ptr = (char *)0x11;
+#endif
int ret;
 
debug("%s starting\n", __func__);
@@ -35,27 +39,44 @@ static int x86_spl_init(void)
debug("%s: spl_init() failed\n", __func__);
return ret;
}
+#ifdef CONFIG_TPL
+   /* Do a mini-init if TPL has already done the full init */
+   ret = x86_cpu_reinit_f();
+#else
ret = arch_cpu_init();
+#endif
if (ret) {
debug("%s: arch_cpu_init() failed\n", __func__);
return ret;
}
+#ifndef CONFIG_TPL
ret = arch_cpu_init_dm();
if (ret) {
debug("%s: arch_cpu_init_dm() failed\n", __func__);
return ret;
}
+#endif
preloader_console_init();
+#ifndef CONFIG_TPL
ret = print_cpuinfo();
if (ret) {
debug("%s: print_cpuinfo() failed\n", __func__);
return ret;
}
+#endif
ret = dram_init();
if (ret) {
debug("%s: dram_init() failed\n", __func__);
return ret;
}
+   if (IS_ENABLED(CONFIG_ENABLE_MRC_CACHE)) {
+   ret = mrccache_spl_save();
+   if (ret)
+   debug("%s: Failed to write to mrccache (err=%d)\n",
+ __func__, ret);
+   }
+
+#ifndef CONFIG_TPL
memset(&__bss_start, 0, (ulong)&__bss_end - (ulong)&__bss_start);
 
/* TODO(s...@chromium.org): Consider calling cpu_init_r() here */
@@ -80,9 +101,11 @@ static int x86_spl_init(void)
   (1ULL << 32) - CONFIG_XIP_ROM_SIZE,
   CONFIG_XIP_ROM_SIZE);
if (ret) {
-   debug("%s: SPI cache setup failed\n", __func__);
+   debug("%s: SPI cache setup failed (err=%d)\n", __func__, ret);
return ret;
}
+   mtrr_commit(true);
+#endif
 
return 0;
 }
@@ -96,9 +119,17 @@ void board_init_f(ulong flags)
debug("Error %d\n", ret);
hang();
}
-
+#ifdef CONFIG_TPL
+   gd->bd = malloc(sizeof(*gd->bd));
+   if (!gd->bd) {
+   printf("Out of memory for bd_info size %x\n", sizeof(*gd->bd));
+   hang();
+   }
+   board_init_r(gd, 0);
+#else
/* Uninit CAR and jump to board_init_f_r() */
board_init_f_r_trampoline(gd->start_addr_sp);
+#endif
 }
 
 void board_init_f_r(void)
@@ -144,6 +175,7 @@ int spl_spi_load_image(void)
return -EPERM;
 }
 
+#ifdef CONFIG_X86_RUN_64BIT
 void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 {
int ret;
@@ -154,3 +186,11 @@ void __noreturn jump_to_image_no_args(struct 
spl_image_info *spl_image)
while (1)
;
 }

[U-Boot] [PATCH 09/40] x86: mp_init: Use proper error numbers

2019-01-29 Thread Simon Glass
At present many of the functions in this file return -1 as an error
number. which is -EPERM. Update the code to use real error numbers.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/mp_init.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
index ea64c2ee57..fefbf8f728 100644
--- a/arch/x86/cpu/mp_init.c
+++ b/arch/x86/cpu/mp_init.c
@@ -322,7 +322,7 @@ static int start_aps(int ap_count, atomic_t *num_aps)
if (sipi_vector > max_vector_loc) {
printf("SIPI vector too large! 0x%08x\n",
   sipi_vector);
-   return -1;
+   return -ENOSPC;
}
 
debug("Attempting to start %d APs\n", ap_count);
@@ -364,7 +364,7 @@ static int start_aps(int ap_count, atomic_t *num_aps)
if (wait_for_aps(num_aps, ap_count, 1, 50)) {
debug("Not all APs checked in: %d/%d\n",
  atomic_read(num_aps), ap_count);
-   return -1;
+   return -EIO;
}
 
return 0;
@@ -387,7 +387,7 @@ static int bsp_do_flight_plan(struct udevice *cpu, struct 
mp_params *mp_params)
if (wait_for_aps(>cpus_entered, num_aps,
 timeout_us, step_us)) {
debug("MP record %d timeout\n", i);
-   ret = -1;
+   ret = -ETIMEDOUT;
}
}
 
@@ -508,7 +508,7 @@ int mp_init(struct mp_params *p)
 
if (p == NULL || p->flight_plan == NULL || p->num_records < 1) {
printf("Invalid MP parameters\n");
-   return -1;
+   return -EINVAL;
}
 
num_cpus = cpu_get_count(cpu);
@@ -531,7 +531,7 @@ int mp_init(struct mp_params *p)
/* Load the SIPI vector */
ret = load_sipi_vector(_count, num_cpus);
if (ap_count == NULL)
-   return -1;
+   return -ENOENT;
 
/*
 * Make sure SIPI data hits RAM so the APs that come up will see
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 17/40] x86: broadwell: Allow SDRAM init from SPL

2019-01-29 Thread Simon Glass
At present SDRAM is always set up in U-Boot proper. Allow this to be done
in SPL instead so that U-Boot proper can be loaded into SDRAM and run
from there. This allows U-Boot to be compressed to reduce space, since
it is not necessary to run it directly from flash.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/Makefile  |  2 +-
 arch/x86/cpu/broadwell/northbridge.c | 93 
 arch/x86/cpu/broadwell/sdram.c   | 93 
 3 files changed, 94 insertions(+), 94 deletions(-)

diff --git a/arch/x86/cpu/broadwell/Makefile b/arch/x86/cpu/broadwell/Makefile
index a032861e57..55f2c93719 100644
--- a/arch/x86/cpu/broadwell/Makefile
+++ b/arch/x86/cpu/broadwell/Makefile
@@ -12,4 +12,4 @@ obj-y += pinctrl_broadwell.o
 obj-y += power_state.o
 obj-y += refcode.o
 obj-y += sata.o
-obj-y += sdram.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += sdram.o
diff --git a/arch/x86/cpu/broadwell/northbridge.c 
b/arch/x86/cpu/broadwell/northbridge.c
index 3055880bb7..93f2dc25b5 100644
--- a/arch/x86/cpu/broadwell/northbridge.c
+++ b/arch/x86/cpu/broadwell/northbridge.c
@@ -6,8 +6,101 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+
+void broadwell_fill_pei_data(struct pei_data *pei_data)
+{
+   pei_data->pei_version = PEI_VERSION;
+   pei_data->board_type = BOARD_TYPE_ULT;
+   pei_data->pciexbar = MCFG_BASE_ADDRESS;
+   pei_data->smbusbar = SMBUS_BASE_ADDRESS;
+   pei_data->ehcibar = EARLY_EHCI_BAR;
+   pei_data->xhcibar = EARLY_XHCI_BAR;
+   pei_data->gttbar = EARLY_GTT_BAR;
+   pei_data->pmbase = ACPI_BASE_ADDRESS;
+   pei_data->gpiobase = GPIO_BASE_ADDRESS;
+   pei_data->tseg_size = CONFIG_SMM_TSEG_SIZE;
+   pei_data->temp_mmio_base = EARLY_TEMP_MMIO;
+   pei_data->tx_byte = sdram_console_tx_byte;
+   pei_data->ddr_refresh_2x = 1;
+}
+
+static void pei_data_usb2_port(struct pei_data *pei_data, int port, uint 
length,
+  uint enable, uint oc_pin, uint location)
+{
+   pei_data->usb2_ports[port].length   = length;
+   pei_data->usb2_ports[port].enable   = enable;
+   pei_data->usb2_ports[port].oc_pin   = oc_pin;
+   pei_data->usb2_ports[port].location = location;
+}
+
+static void pei_data_usb3_port(struct pei_data *pei_data, int port, uint 
enable,
+  uint oc_pin, uint fixed_eq)
+{
+   pei_data->usb3_ports[port].enable   = enable;
+   pei_data->usb3_ports[port].oc_pin   = oc_pin;
+   pei_data->usb3_ports[port].fixed_eq = fixed_eq;
+}
+
+void mainboard_fill_pei_data(struct pei_data *pei_data)
+{
+   /* DQ byte map for Samus board */
+   const u8 dq_map[2][6][2] = {
+   { { 0x0F, 0xF0 }, { 0x00, 0xF0 }, { 0x0F, 0xF0 },
+ { 0x0F, 0x00 }, { 0xFF, 0x00 }, { 0xFF, 0x00 } },
+   { { 0x0F, 0xF0 }, { 0x00, 0xF0 }, { 0x0F, 0xF0 },
+ { 0x0F, 0x00 }, { 0xFF, 0x00 }, { 0xFF, 0x00 } } };
+   /* DQS CPU<>DRAM map for Samus board */
+   const u8 dqs_map[2][8] = {
+   { 2, 0, 1, 3, 6, 4, 7, 5 },
+   { 2, 1, 0, 3, 6, 5, 4, 7 } };
+
+   pei_data->ec_present = 1;
+
+   /* One installed DIMM per channel */
+   pei_data->dimm_channel0_disabled = 2;
+   pei_data->dimm_channel1_disabled = 2;
+
+   memcpy(pei_data->dq_map, dq_map, sizeof(dq_map));
+   memcpy(pei_data->dqs_map, dqs_map, sizeof(dqs_map));
+
+   /* P0: HOST PORT */
+   pei_data_usb2_port(pei_data, 0, 0x0080, 1, 0,
+  USB_PORT_BACK_PANEL);
+   /* P1: HOST PORT */
+   pei_data_usb2_port(pei_data, 1, 0x0080, 1, 1,
+  USB_PORT_BACK_PANEL);
+   /* P2: RAIDEN */
+   pei_data_usb2_port(pei_data, 2, 0x0080, 1, USB_OC_PIN_SKIP,
+  USB_PORT_BACK_PANEL);
+   /* P3: SD CARD */
+   pei_data_usb2_port(pei_data, 3, 0x0040, 1, USB_OC_PIN_SKIP,
+  USB_PORT_INTERNAL);
+   /* P4: RAIDEN */
+   pei_data_usb2_port(pei_data, 4, 0x0080, 1, USB_OC_PIN_SKIP,
+  USB_PORT_BACK_PANEL);
+   /* P5: WWAN (Disabled) */
+   pei_data_usb2_port(pei_data, 5, 0x, 0, USB_OC_PIN_SKIP,
+  USB_PORT_SKIP);
+   /* P6: CAMERA */
+   pei_data_usb2_port(pei_data, 6, 0x0040, 1, USB_OC_PIN_SKIP,
+  USB_PORT_INTERNAL);
+   /* P7: BT */
+   pei_data_usb2_port(pei_data, 7, 0x0040, 1, USB_OC_PIN_SKIP,
+  USB_PORT_INTERNAL);
+
+   /* P1: HOST PORT */
+   pei_data_usb3_port(pei_data, 0, 1, 0, 0);
+   /* P2: HOST PORT */
+   pei_data_usb3_port(pei_data, 1, 1, 1, 0);
+   /* P3: RAIDEN */
+   pei_data_usb3_port(pei_data, 2, 1, USB_OC_PIN_SKIP, 0);
+   /* P4: RAIDEN */
+   pei_data_usb3_port(pei_data, 3, 1, USB_OC_PIN_SKIP, 0);
+}
 
 static int broadwell_northbridge_early_init(struct udevice *dev)
 {
diff --git 

[U-Boot] [PATCH 20/40] x86: Add support for starting from SPL/TPL

2019-01-29 Thread Simon Glass
When a previous phase of U-Boot has run we need to adjust the init of
subsequent states to avoid messing up the CPU state.

Add a new version of the start logic for SPL, when it boots from TPL
(start_from tpl.c) and a new version for U-Boot when it boots from SPL.

Signed-off-by: Simon Glass 
---

 arch/x86/Makefile | 12 ++
 arch/x86/cpu/Makefile | 15 +++-
 arch/x86/cpu/start_from_spl.S | 71 +++
 arch/x86/cpu/start_from_tpl.S | 50 
 4 files changed, 147 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/start_from_spl.S
 create mode 100644 arch/x86/cpu/start_from_tpl.S

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index fec14847cc..9fd6cf2d3b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -4,9 +4,21 @@ ifeq ($(CONFIG_EFI_APP),)
 ifdef CONFIG_$(SPL_)X86_64
 head-y := arch/x86/cpu/start64.o
 else
+ifeq ($(CONFIG_$(SPL_TPL_)X86_16BIT_INIT),y)
 head-y := arch/x86/cpu/start.o
+else
+ifndef CONFIG_SPL
+head-y := arch/x86/cpu/start.o
+else
+ifdef CONFIG_SPL_BUILD
+head-y = arch/x86/cpu/start_from_tpl.o
+else
+head-y = arch/x86/cpu/start_from_spl.o
+endif
+endif
 endif
 endif
+endif # EFI
 
 head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/start16.o
 head-$(CONFIG_$(SPL_)X86_16BIT_INIT) += arch/x86/cpu/resetvec.o
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 54668aab24..85fd5e616e 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -9,9 +9,22 @@
 ifeq ($(CONFIG_$(SPL_)X86_64),y)
 extra-y= start64.o
 else
+ifeq ($(CONFIG_$(SPL_TPL_)X86_16BIT_INIT),y)
 extra-y= start.o
+else
+ifndef CONFIG_SPL
+extra-y= start.o
+else
+ifdef CONFIG_SPL_BUILD
+extra-y= start_from_tpl.o
+else
+extra-y= start_from_spl.o
 endif
-extra-$(CONFIG_$(SPL_)X86_16BIT_INIT) += resetvec.o start16.o
+endif
+endif
+endif
+
+extra-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += resetvec.o start16.o
 
 obj-y  += cpu.o cpu_x86.o
 
diff --git a/arch/x86/cpu/start_from_spl.S b/arch/x86/cpu/start_from_spl.S
new file mode 100644
index 00..4d4e5d0758
--- /dev/null
+++ b/arch/x86/cpu/start_from_spl.S
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * 32-bit x86 Startup Code when running from SPL
+ *
+ * Copyright 2018 Google, Inc
+ * Written by Simon Glass 
+ */
+
+#include 
+
+.section .text.start
+.code32
+.globl _start
+.type _start, @function
+_start:
+   /* Set up memory using the existing stack */
+   movl$(CONFIG_SYS_CAR_ADDR + CONFIG_SYS_CAR_SIZE - 4), %eax
+#ifdef CONFIG_DCACHE_RAM_MRC_VAR_SIZE
+   subl$CONFIG_DCACHE_RAM_MRC_VAR_SIZE, %eax
+#endif
+   /*
+* We don't subject CONFIG_DCACHE_RAM_MRC_VAR_SIZE since memory is
+* already set up. This has the happy side-effect of putting gd in a
+* new place separate from SPL, so the memset() in
+* board_init_f_init_reserve() does not cause any problems (otherwise
+* it would zero out the gd and crash)
+*/
+   callboard_init_f_alloc_reserve
+   mov %eax, %esp
+
+   callboard_init_f_init_reserve
+
+   xorl%eax, %eax
+   callboard_init_f
+   callboard_init_f_r
+
+   /* Should not return here */
+   jmp .
+
+.globl board_init_f_r_trampoline
+.type board_init_f_r_trampoline, @function
+board_init_f_r_trampoline:
+   /*
+* SPL has been executed and SDRAM has been initialised, U-Boot code
+* has been copied into RAM, BSS has been cleared and relocation
+* adjustments have been made. It is now time to jump into the in-RAM
+* copy of U-Boot
+*
+* %eax = Address of top of new stack
+*/
+
+   /* Stack grows down from top of SDRAM */
+   movl%eax, %esp
+
+   /* Re-enter U-Boot by calling board_init_f_r() */
+   callboard_init_f_r
+
+die:
+   hlt
+   jmp die
+   hlt
+
+   .align 4
+_dt_ucode_base_size:
+   /* These next two fields are filled in by binman */
+.globl ucode_base
+ucode_base:/* Declared in microcode.h */
+   .long   0   /* microcode base */
+.globl ucode_size
+ucode_size:/* Declared in microcode.h */
+   .long   0   /* microcode size */
diff --git a/arch/x86/cpu/start_from_tpl.S b/arch/x86/cpu/start_from_tpl.S
new file mode 100644
index 00..e27f39eddf
--- /dev/null
+++ b/arch/x86/cpu/start_from_tpl.S
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * 32-bit x86 Startup Code when running from SPL
+ *
+ * Copyright 2018 Google, Inc
+ * Written by Simon Glass 
+ */
+
+#include 
+
+.section .text.start
+.code32
+.globl _start
+.type _start, @function
+_start:
+   /* Set up memory using the existing stack */
+   mov %esp, %eax
+   callboard_init_f_alloc_reserve
+   mov %eax, %esp
+
+   callboard_init_f_init_reserve
+
+   callboard_init_f
+   call

[U-Boot] [PATCH 29/40] x86: Support TPL in Intel common code

2019-01-29 Thread Simon Glass
Update the Makefie rules to ensure that the correct files are built when
TPL is being used.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/intel_common/Makefile | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/intel_common/Makefile 
b/arch/x86/cpu/intel_common/Makefile
index 57cca0b930..07f27c29ec 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -4,15 +4,18 @@
 
 ifdef CONFIG_HAVE_MRC
 obj-$(CONFIG_$(SPL_TPL_)X86_16BIT_INIT) += car.o
-obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += me_status.o
-obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += report_platform.o
-obj-$(CONFIG_$(SPL_)X86_32BIT_INIT) += mrc.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += me_status.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += report_platform.o
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += mrc.o
 endif
 obj-y += cpu.o
 obj-y += lpc.o
 ifndef CONFIG_TARGET_EFI_APP
+obj-$(CONFIG_$(SPL_TPL_)X86_32BIT_INIT) += microcode.o
+ifndef CONFIG_$(SPL_)X86_64
 obj-y += microcode.o
 endif
+endif
 obj-y += pch.o
 
 ifdef CONFIG_SPL
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 24/40] x86: Add common Intel code for SPL

2019-01-29 Thread Simon Glass
Add an implementation of arch_cpu_init_f() so that the x86 SPL code builds
and identifies the CPU.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/intel_common/Makefile   |  6 ++
 arch/x86/cpu/intel_common/cpu_from_spl.c | 27 
 2 files changed, 33 insertions(+)
 create mode 100644 arch/x86/cpu/intel_common/cpu_from_spl.c

diff --git a/arch/x86/cpu/intel_common/Makefile 
b/arch/x86/cpu/intel_common/Makefile
index 80fbc7ab66..57cca0b930 100644
--- a/arch/x86/cpu/intel_common/Makefile
+++ b/arch/x86/cpu/intel_common/Makefile
@@ -14,3 +14,9 @@ ifndef CONFIG_TARGET_EFI_APP
 obj-y += microcode.o
 endif
 obj-y += pch.o
+
+ifdef CONFIG_SPL
+ifndef CONFIG_SPL_BUILD
+obj-y += cpu_from_spl.o
+endif
+endif
diff --git a/arch/x86/cpu/intel_common/cpu_from_spl.c 
b/arch/x86/cpu/intel_common/cpu_from_spl.c
new file mode 100644
index 00..a6233c75ce
--- /dev/null
+++ b/arch/x86/cpu/intel_common/cpu_from_spl.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016 Google, Inc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int arch_cpu_init(void)
+{
+   int ret;
+
+   ret = x86_cpu_reinit_f();
+
+   return ret;
+}
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 35/40] x86: samus: Update device tree for SPL

2019-01-29 Thread Simon Glass
Add tags to allow required nodes to be present in SPL / TPL. Also enable
the sysreset driver.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/chromebook_samus.dts | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/arch/x86/dts/chromebook_samus.dts 
b/arch/x86/dts/chromebook_samus.dts
index b58936b4ac..348d012e23 100644
--- a/arch/x86/dts/chromebook_samus.dts
+++ b/arch/x86/dts/chromebook_samus.dts
@@ -17,6 +17,7 @@
spi0 = 
usb0 = _0;
usb1 = _1;
+   cros-ec0 = _ec;
};
 
config {
@@ -73,6 +74,7 @@
 
/* Put this first: it is the default */
gpio_unused: gpio-unused {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
owner = ;
@@ -80,6 +82,7 @@
};
 
gpio_acpi_sci: acpi-sci {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
invert;
@@ -87,6 +90,7 @@
};
 
gpio_acpi_smi: acpi-smi {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
invert;
@@ -94,12 +98,14 @@
};
 
gpio_input: gpio-input {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
owner = ;
};
 
gpio_input_invert: gpio-input-invert {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
owner = ;
@@ -107,9 +113,11 @@
};
 
gpio_native: gpio-native {
+   u-boot,dm-pre-reloc;
};
 
gpio_out_high: gpio-out-high {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
output-value = <1>;
@@ -118,6 +126,7 @@
};
 
gpio_out_low: gpio-out-low {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
output-value = <0>;
@@ -126,6 +135,7 @@
};
 
gpio_pirq: gpio-pirq {
+   u-boot,dm-pre-reloc;
mode-gpio;
direction = ;
owner = ;
@@ -133,6 +143,7 @@
};
 
soc_gpio@0 {
+   u-boot,dm-pre-reloc;
config =
<0 _unused 0>, /* unused */
<1 _unused 0>, /* unused */
@@ -250,8 +261,10 @@
spd {
#address-cells = <1>;
#size-cells = <0>;
+   u-boot,dm-pre-reloc;
samsung_4 {
reg = <6>;
+   u-boot,dm-pre-reloc;
data = [91 20 f1 03 04 11 05 0b
03 11 01 08 0a 00 50 01
78 78 90 50 90 11 50 e0
@@ -291,6 +304,7 @@
 * columns 10, density 4096 mb, x32
 */
reg = <8>;
+   u-boot,dm-pre-reloc;
data = [91 20 f1 03 04 11 05 0b
03 11 01 08 0a 00 50 01
78 78 90 50 90 11 50 e0
@@ -326,6 +340,7 @@
};
samsung_8 {
reg = <10>;
+   u-boot,dm-pre-reloc;
data = [91 20 f1 03 04 12 05 0a
03 11 01 08 0a 00 50 01
78 78 90 50 90 11 50 e0
@@ -365,6 +380,7 @@
 * columns 11, density 4096 mb, x16
 */
reg = <12>;
+   u-boot,dm-pre-reloc;
data = [91 20 f1 03 04 12 05 0a
03 11 01 08 0a 00 50 01
78 78 90 50 90 11 50 e0
@@ -404,6 +420,7 @@
 * columns 11, density 8192 mb, x16
 

[U-Boot] [PATCH 22/40] x86: broadwell: Allow booting from SPL

2019-01-29 Thread Simon Glass
At present broadwell only supports booting straight into U-Boot proper.
Add a separate init file to boot from SPL into U-Boot proper, and select
it when SPL is in use.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/Makefile   | 15 +++
 arch/x86/cpu/broadwell/cpu_from_spl.c | 63 +++
 2 files changed, 78 insertions(+)
 create mode 100644 arch/x86/cpu/broadwell/cpu_from_spl.c

diff --git a/arch/x86/cpu/broadwell/Makefile b/arch/x86/cpu/broadwell/Makefile
index 303d2b274b..11d30b03e5 100644
--- a/arch/x86/cpu/broadwell/Makefile
+++ b/arch/x86/cpu/broadwell/Makefile
@@ -4,6 +4,21 @@
 
 obj-y += cpu.o
 obj-y += cpu_full.o
+
+ifdef CONFIG_SPL
+ifndef CONFIG_SPL_BUILD
+obj-y += cpu_from_spl.o
+obj-y += cpu_full.o
+endif
+ifndef CONFIG_SPL_BUILD
+# obj-y += cpu_from_spl.o
+endif
+endif
+
+ifeq ($(CONFIG_$(SPL_TPL_)X86_32BIT_INIT),)
+#obj-y += cpu_from_spl.o
+endif
+
 obj-y += iobp.o
 obj-y += lpc.o
 obj-y += me.o
diff --git a/arch/x86/cpu/broadwell/cpu_from_spl.c 
b/arch/x86/cpu/broadwell/cpu_from_spl.c
new file mode 100644
index 00..c3d4a8d547
--- /dev/null
+++ b/arch/x86/cpu/broadwell/cpu_from_spl.c
@@ -0,0 +1,63 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2016 Google, Inc
+ * Written by Simon Glass 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int misc_init_r(void)
+{
+   return 0;
+}
+
+int dram_init(void)
+{
+   struct spl_handoff *ho;
+
+   ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(*ho));
+   if (!ho)
+   return log_msg_ret("Missing SPL hand-off info", -ENOENT);
+   handoff_load_dram_size(ho);
+#ifdef CONFIG_TPL
+   /* TODO(s...@chromium.org): MTRR cannot be adjusted without a hang */
+   mtrr_add_request(MTRR_TYPE_WRBACK, 0, 2ULL << 30);
+#else
+   mtrr_add_request(MTRR_TYPE_WRBACK, 0, gd->ram_size);
+   mtrr_commit(true);
+#endif
+
+   return 0;
+}
+
+int checkcpu(void)
+{
+   return 0;
+}
+
+int print_cpuinfo(void)
+{
+   return 0;
+}
+
+void board_debug_uart_init(void)
+{
+}
+
+int dram_init_banksize(void)
+{
+#ifdef CONFIG_NR_DRAM_BANKS
+   struct spl_handoff *ho;
+
+   ho = bloblist_find(BLOBLISTT_SPL_HANDOFF, sizeof(*ho));
+   if (!ho)
+   return log_msg_ret("Missing SPL hand-off info", -ENOENT);
+   handoff_load_dram_banks(ho);
+#endif
+
+   return 0;
+}
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 14/40] x86: Support booting with TPL

2019-01-29 Thread Simon Glass
Some boards want to use TPL as the first phase of U-Boot. This allows
selection of A or B SPL phases, thus allowing the memory init to be
upgraded in the field.

Add a new Kconfig option for this.

Signed-off-by: Simon Glass 
---

 arch/x86/Kconfig | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 185f0ef8c4..45a533625a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -176,10 +176,17 @@ config X86_16BIT_INIT
 config SPL_X86_16BIT_INIT
bool
depends on X86_RESET_VECTOR
-   default y if X86_RESET_VECTOR && SPL
+   default y if X86_RESET_VECTOR && SPL && !TPL
help
  This is enabled when 16-bit init is in SPL
 
+config TPL_X86_16BIT_INIT
+   bool
+   depends on X86_RESET_VECTOR
+   default y if X86_RESET_VECTOR && TPL
+   help
+ This is enabled when 16-bit init is in TPL
+
 config X86_32BIT_INIT
bool
depends on X86_RESET_VECTOR
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 37/40] x86: Update device tree for TPL

2019-01-29 Thread Simon Glass
Add TPL binaries to the device x86 binman desciption. When enabled, TPL
will start first, doing the 16-bit init, then jump to SPL and finally
U-Boot proper.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/u-boot.dtsi | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 1050236330..70e9c8f7ac 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -22,7 +22,21 @@
filename = CONFIG_INTEL_ME_FILE;
};
 #endif
-#ifdef CONFIG_SPL
+#ifdef CONFIG_TPL
+   u-boot-spl {
+   offset = ;
+   };
+   u-boot-spl-dtb {
+   };
+   u-boot-tpl-with-ucode-ptr {
+   offset = ;
+   };
+   u-boot-tpl-dtb {
+   };
+   u-boot {
+   offset = ;
+   };
+#elif defined(CONFIG_SPL)
u-boot-spl-with-ucode-ptr {
offset = ;
};
@@ -31,7 +45,11 @@
type = "u-boot-dtb-with-ucode";
};
u-boot {
+#if CONFIG_SYS_TEXT_BASE == 0x111
offset = <0xfff0>;
+#else
+   offset = ;
+#endif
};
 #else
u-boot-with-ucode-ptr {
@@ -77,7 +95,11 @@
offset = ;
};
 #endif
-#ifdef CONFIG_SPL
+#ifdef CONFIG_TPL
+   x86-start16-tpl {
+   offset = ;
+   };
+#elif defined(CONFIG_SPL)
x86-start16-spl {
offset = ;
};
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 05/40] cros_ec: Use a hyphen in the uclass name

2019-01-29 Thread Simon Glass
Device-tree rules require that aliases use a hyphen rather than a
underscore. Update the uclass name to fit with this.

Signed-off-by: Simon Glass 
---

 drivers/misc/cros_ec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/cros_ec.c b/drivers/misc/cros_ec.c
index 565de040fe..382f826286 100644
--- a/drivers/misc/cros_ec.c
+++ b/drivers/misc/cros_ec.c
@@ -1482,7 +1482,7 @@ int cros_ec_set_lid_shutdown_mask(struct udevice *dev, 
int enable)
 
 UCLASS_DRIVER(cros_ec) = {
.id = UCLASS_CROS_EC,
-   .name   = "cros_ec",
+   .name   = "cros-ec",
.per_device_auto_alloc_size = sizeof(struct cros_ec_dev),
.post_bind  = dm_scan_fdt_dev,
.flags  = DM_UC_FLAG_ALLOC_PRIV_DMA,
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 08/40] x86: start64: Fix copyright message

2019-01-29 Thread Simon Glass
There is a typo in this header. Fix it.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/start64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/start64.S b/arch/x86/cpu/start64.S
index a78a3316b6..7be834788b 100644
--- a/arch/x86/cpu/start64.S
+++ b/arch/x86/cpu/start64.S
@@ -2,7 +2,7 @@
 /*
  * 64-bit x86 Startup Code
  *
- * (C) Copyright 216 Google, Inc
+ * Copyright 2019 Google, Inc
  * Written by Simon Glass 
  */
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 18/40] x86: Move init of debug UART to cpu.c

2019-01-29 Thread Simon Glass
At present the debug UART is set up in sdram.c which is not the best place
since it has nothing in particular to do with SDRAM. Since we want to
support initing this in SPL too, move it to a common file.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/broadwell/cpu.c   | 13 +
 arch/x86/cpu/broadwell/sdram.c | 11 ---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
index 232fa40eb5..d53c7b863f 100644
--- a/arch/x86/cpu/broadwell/cpu.c
+++ b/arch/x86/cpu/broadwell/cpu.c
@@ -12,7 +12,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -156,6 +158,17 @@ int print_cpuinfo(void)
return 0;
 }
 
+void board_debug_uart_init(void)
+{
+   struct udevice *bus = NULL;
+
+   /* com1 / com2 decode range */
+   pci_x86_write_config(bus, PCH_DEV_LPC, LPC_IO_DEC, 1 << 4, PCI_SIZE_16);
+
+   pci_x86_write_config(bus, PCH_DEV_LPC, LPC_EN, COMA_LPC_EN,
+PCI_SIZE_16);
+}
+
 /*
  * The core 100MHz BLCK is disabled in deeper c-states. One needs to calibrate
  * the 100MHz BCLCK against the 24MHz BLCK to restore the clocks properly
diff --git a/arch/x86/cpu/broadwell/sdram.c b/arch/x86/cpu/broadwell/sdram.c
index b8450cc9d2..b31d78c092 100644
--- a/arch/x86/cpu/broadwell/sdram.c
+++ b/arch/x86/cpu/broadwell/sdram.c
@@ -194,17 +194,6 @@ int misc_init_r(void)
return 0;
 }
 
-void board_debug_uart_init(void)
-{
-   struct udevice *bus = NULL;
-
-   /* com1 / com2 decode range */
-   pci_x86_write_config(bus, PCH_DEV_LPC, LPC_IO_DEC, 1 << 4, PCI_SIZE_16);
-
-   pci_x86_write_config(bus, PCH_DEV_LPC, LPC_EN, COMA_LPC_EN,
-PCI_SIZE_16);
-}
-
 static const struct udevice_id broadwell_syscon_ids[] = {
{ .compatible = "intel,me", .data = X86_SYSCON_ME },
{ }
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 25/40] x86: Support saving MRC data from SPL

2019-01-29 Thread Simon Glass
When SPL is used to set up the memory controller we want to save the MRC
data in SPL to avoid needing to pass it up to U-Boot proper to save. Add a
function to handle that.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/mrccache.h | 11 ++
 arch/x86/lib/mrccache.c | 36 -
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/mrccache.h b/arch/x86/include/asm/mrccache.h
index 04783cd329..40fda856ff 100644
--- a/arch/x86/include/asm/mrccache.h
+++ b/arch/x86/include/asm/mrccache.h
@@ -103,4 +103,15 @@ int mrccache_get_region(struct udevice **devp, struct 
mrc_region *entry);
  */
 int mrccache_save(void);
 
+/**
+ * mrccache_spl_save() - Save to the MRC region from SPL
+ *
+ * When SPL is used to set up the memory controller we want to save the MRC
+ * data in SPL to avoid needing to pass it up to U-Boot proper to save. This
+ * function handles that.
+ *
+ * @return 0 if saved to SPI flash successfully, other error if failed
+ */
+int mrccache_spl_save(void);
+
 #endif /* _ASM_MRCCACHE_H */
diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
index 2a8919885b..f37a732a45 100644
--- a/arch/x86/lib/mrccache.c
+++ b/arch/x86/lib/mrccache.c
@@ -159,18 +159,11 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
return 0;
 }
 
-int mrccache_reserve(void)
+static void mrccache_setup(void *data)
 {
-   struct mrc_data_container *cache;
+   struct mrc_data_container *cache = data;
u16 checksum;
 
-   if (!gd->arch.mrc_output_len)
-   return 0;
-
-   /* adjust stack pointer to store pure cache data plus the header */
-   gd->start_addr_sp -= (gd->arch.mrc_output_len + MRC_DATA_HEADER_SIZE);
-   cache = (struct mrc_data_container *)gd->start_addr_sp;
-
cache->signature = MRC_DATA_SIGNATURE;
cache->data_size = gd->arch.mrc_output_len;
checksum = compute_ip_checksum(gd->arch.mrc_output, cache->data_size);
@@ -182,6 +175,16 @@ int mrccache_reserve(void)
 
/* gd->arch.mrc_output now points to the container */
gd->arch.mrc_output = (char *)cache;
+}
+
+int mrccache_reserve(void)
+{
+   if (!gd->arch.mrc_output_len)
+   return 0;
+
+   /* adjust stack pointer to store pure cache data plus the header */
+   gd->start_addr_sp -= (gd->arch.mrc_output_len + MRC_DATA_HEADER_SIZE);
+   mrccache_setup((void *)gd->start_addr_sp);
 
gd->start_addr_sp &= ~0xf;
 
@@ -256,3 +259,18 @@ err_entry:
debug("%s: Failed: %d\n", __func__, ret);
return ret;
 }
+
+int mrccache_spl_save(void)
+{
+   void *data;
+   int size;
+
+   size = gd->arch.mrc_output_len + MRC_DATA_HEADER_SIZE;
+   data = malloc(size);
+   if (!data)
+   return log_msg_ret("Allocate MRC cache block", -ENOMEM);
+   mrccache_setup(data);
+   gd->arch.mrc_output = data;
+
+   return mrccache_save();
+}
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 06/40] spl: Allow sandbox to build a device-tree file

2019-01-29 Thread Simon Glass
At present only OF_SEPARATE is considered valid for building a device-tree
file in SPL. However sandbox uses OF_HOSTFILE instead. Update the logic to
handle this and make it easier to understand.

Signed-off-by: Simon Glass 
---

 scripts/Makefile.spl | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 1430d7d851..c9eea629dd 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -255,8 +255,20 @@ else
 FINAL_DTB_CONTAINER = $(obj)/$(SPL_BIN).multidtb.fit
 endif
 
+# Build the .dtb file if:
+#   - we are not using OF_PLATDATA
+#   - we are using OF_CONTROL
+#   - we have either OF_SEPARATE or OF_HOSTFILE
+build_dtb :=
+ifeq ($(CONFIG_$(SPL_TPL_)OF_PLATDATA),)
+ifneq ($(CONFIG_$(SPL_TPL_)OF_CONTROL),)
+ifeq ($(CONFIG_OF_SEPARATE)$(CONFIG_OF_HOSTFILE),y)
+build_dtb := y
+endif
+endif
+endif
 
-ifeq 
($(CONFIG_$(SPL_TPL_)OF_CONTROL)$(CONFIG_OF_SEPARATE)$(CONFIG_$(SPL_TPL_)OF_PLATDATA),yy)
+ifneq ($(build_dtb),)
 $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
$(if $(CONFIG_SPL_SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
$(FINAL_DTB_CONTAINER)  FORCE
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 33/40] x86: sysreset: Implement the get_last() method

2019-01-29 Thread Simon Glass
Add a default implementation of this method which always indicates that
the last reset was a power-on reset. This is the most likely type of reset
and without a PCH-specific driver we cannot determine any other type.

Signed-off-by: Simon Glass 
---

 drivers/sysreset/sysreset_x86.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
index 20b958cfd4..2a8ec6b0d2 100644
--- a/drivers/sysreset/sysreset_x86.c
+++ b/drivers/sysreset/sysreset_x86.c
@@ -31,6 +31,11 @@ static int x86_sysreset_request(struct udevice *dev, enum 
sysreset_t type)
return -EINPROGRESS;
 }
 
+static int x86_sysreset_get_last(struct udevice *dev)
+{
+   return SYSRESET_POWER;
+}
+
 static const struct udevice_id x86_sysreset_ids[] = {
{ .compatible = "x86,reset" },
{ }
@@ -38,6 +43,7 @@ static const struct udevice_id x86_sysreset_ids[] = {
 
 static struct sysreset_ops x86_sysreset_ops = {
.request = x86_sysreset_request,
+   .get_last = x86_sysreset_get_last,
 };
 
 U_BOOT_DRIVER(x86_sysreset) = {
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 15/40] x86: Add a handoff header file

2019-01-29 Thread Simon Glass
Add an arch-specific handoff header so that we can use the HANDOFF feature
on x86 devices.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/handoff.h | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 arch/x86/include/asm/handoff.h

diff --git a/arch/x86/include/asm/handoff.h b/arch/x86/include/asm/handoff.h
new file mode 100644
index 00..4d18d59efe
--- /dev/null
+++ b/arch/x86/include/asm/handoff.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Architecture-specific SPL handoff information for x86
+ *
+ * Copyright 2018 Google, Inc
+ * Written by Simon Glass 
+ */
+
+#ifndef __x86_asm_handoff_h
+#define __x86_asm_handoff_h
+
+struct arch_spl_handoff {
+};
+
+#endif
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 13/40] x86: Support SPL and TPL

2019-01-29 Thread Simon Glass
At present only chromebook_link64 supports SPL. It is useful to eb able to
support both TPL and SPL to implement verified boot on x86.

Enable the options for both along with some suitable default options
needed to boot through these phases.

Signed-off-by: Simon Glass 
---

 arch/Kconfig | 30 ++
 arch/x86/Kconfig |  1 -
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 35e2712fce..7cb207fe35 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -124,6 +124,8 @@ config SH
 
 config X86
bool "x86 architecture"
+   select SUPPORT_SPL
+   select SUPPORT_TPL
select CREATE_ARCH_SYMLINK
select DM
select DM_PCI
@@ -160,6 +162,34 @@ config X86
imply USB_ETHER_ASIX
imply USB_ETHER_SMSC95XX
imply USB_HOST_ETHER
+   # Thing to enable for when SPL/TPL are enabled: SPL
+   imply SPL_DM
+   imply SPL_OF_LIBFDT
+   imply SPL_DRIVERS_MISC_SUPPORT
+   imply SPL_GPIO_SUPPORT
+   imply SPL_LIBCOMMON_SUPPORT
+   imply SPL_LIBGENERIC_SUPPORT
+   imply SPL_SERIAL_SUPPORT
+   imply SPL_SPI_FLASH_SUPPORT
+   imply SPL_SPI_SUPPORT
+   imply SPL_OF_CONTROL
+   imply SPL_TIMER
+   imply SPL_REGMAP
+   imply SPL_SYSCON
+   # TPL
+   imply TPL_DM
+   imply TPL_OF_LIBFDT
+   imply TPL_DRIVERS_MISC_SUPPORT
+   imply TPL_GPIO_SUPPORT
+   imply TPL_LIBCOMMON_SUPPORT
+   imply TPL_LIBGENERIC_SUPPORT
+   imply TPL_SERIAL_SUPPORT
+   imply TPL_SPI_FLASH_SUPPORT
+   imply TPL_SPI_SUPPORT
+   imply TPL_OF_CONTROL
+   imply TPL_TIMER
+   imply TPL_REGMAP
+   imply TPL_SYSCON
 
 config XTENSA
bool "Xtensa architecture"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e052093775..185f0ef8c4 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -32,7 +32,6 @@ config X86_RUN_32BIT
 config X86_RUN_64BIT
bool "64-bit"
select X86_64
-   select SUPPORT_SPL
select SPL
select SPL_SEPARATE_BSS
help
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 11/40] x86: dts: Add device-tree labels for rtc and reset

2019-01-29 Thread Simon Glass
Add labels for these nodes so that board DT files can reference them.

Signed-off-by: Simon Glass 
---

 arch/x86/dts/reset.dtsi | 2 +-
 arch/x86/dts/rtc.dtsi   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/dts/reset.dtsi b/arch/x86/dts/reset.dtsi
index f979d83757..555d0dd960 100644
--- a/arch/x86/dts/reset.dtsi
+++ b/arch/x86/dts/reset.dtsi
@@ -1,5 +1,5 @@
 / {
-   reset {
+   reset: reset {
compatible = "x86,reset";
u-boot,dm-pre-reloc;
};
diff --git a/arch/x86/dts/rtc.dtsi b/arch/x86/dts/rtc.dtsi
index 1797e042da..d0bbd84e50 100644
--- a/arch/x86/dts/rtc.dtsi
+++ b/arch/x86/dts/rtc.dtsi
@@ -1,5 +1,5 @@
 / {
-   rtc {
+   rtc: rtc {
compatible = "motorola,mc146818";
u-boot,dm-pre-reloc;
reg = <0x70 2>;
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 12/40] x86: Update a stale comment about ifdtool

2019-01-29 Thread Simon Glass
We use binman to build the x86 image now. Update a comment which still
refers to ifdtool.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/intel_common/car.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/cpu/intel_common/car.S b/arch/x86/cpu/intel_common/car.S
index 52a77bb2d1..00308dbdef 100644
--- a/arch/x86/cpu/intel_common/car.S
+++ b/arch/x86/cpu/intel_common/car.S
@@ -235,7 +235,7 @@ mtrr_table_end:
 
.align 4
 _dt_ucode_base_size:
-   /* These next two fields are filled in by ifdtool */
+   /* These next two fields are filled in by binman */
 .globl ucode_base
 ucode_base:/* Declared in microcode.h */
.long   0   /* microcode base */
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 07/40] RFC: binman: Allow sections to have an offset

2019-01-29 Thread Simon Glass
At present sections are always placed automatically. Even if an 'offset'
property is provided it is ignored. Update the logic to support an offset
for sections.

Note: Needs a test updates

Signed-off-by: Simon Glass 
---

 tools/binman/bsection.py  | 5 +++--
 tools/binman/etype/section.py | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/binman/bsection.py b/tools/binman/bsection.py
index ccf2920c5b..4a5ced201e 100644
--- a/tools/binman/bsection.py
+++ b/tools/binman/bsection.py
@@ -57,7 +57,7 @@ class Section(object):
 self._name = name
 self._node = node
 self._image = image
-self._offset = 0
+self._offset = None
 self._size = None
 self._align_size = None
 self._pad_before = 0
@@ -75,6 +75,7 @@ class Section(object):
 
 def _ReadNode(self):
 """Read properties from the section node"""
+self._offset = fdt_util.GetInt(self._node, 'offset')
 self._size = fdt_util.GetInt(self._node, 'size')
 self._align_size = fdt_util.GetInt(self._node, 'align-size')
 if tools.NotPowerOfTwo(self._align_size):
@@ -130,7 +131,7 @@ class Section(object):
 entry.AddMissingProperties()
 
 def SetCalculatedProperties(self):
-state.SetInt(self._node, 'offset', self._offset)
+state.SetInt(self._node, 'offset', self._offset or 0)
 state.SetInt(self._node, 'size', self._size)
 image_pos = self._image_pos
 if self._parent_section:
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index 7f1b413604..3681a48468 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -67,7 +67,8 @@ class Entry_section(Entry):
 def Pack(self, offset):
 """Pack all entries into the section"""
 self._section.PackEntries()
-self._section.SetOffset(offset)
+if self._section._offset is None:
+self._section.SetOffset(offset)
 self.size = self._section.GetSize()
 return super(Entry_section, self).Pack(offset)
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 10/40] x86: Add a way to reinit the cpu

2019-01-29 Thread Simon Glass
We cannot init the CPU fully both than once during a boot. Add a new
function which can be called to figure out the CPU identity, but which
does not change anything. For x86_64, this is empty for now.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/i386/cpu.c   | 113 ++
 arch/x86/cpu/x86_64/cpu.c |   5 ++
 arch/x86/include/asm/u-boot-x86.h |  20 ++
 3 files changed, 94 insertions(+), 44 deletions(-)

diff --git a/arch/x86/cpu/i386/cpu.c b/arch/x86/cpu/i386/cpu.c
index 208ef08562..4c362f4adc 100644
--- a/arch/x86/cpu/i386/cpu.c
+++ b/arch/x86/cpu/i386/cpu.c
@@ -309,21 +309,22 @@ u32 cpu_get_stepping(void)
return gd->arch.x86_mask;
 }
 
-int x86_cpu_init_f(void)
+/* initialise FPU, reset EM, set MP and NE */
+static void setup_cpu_features(void)
 {
const u32 em_rst = ~X86_CR0_EM;
const u32 mp_ne_set = X86_CR0_MP | X86_CR0_NE;
 
-   if (ll_boot_init()) {
-   /* initialize FPU, reset EM, set MP and NE */
-   asm ("fninit\n" \
-   "movl %%cr0, %%eax\n" \
-   "andl %0, %%eax\n" \
-   "orl  %1, %%eax\n" \
-   "movl %%eax, %%cr0\n" \
-   : : "i" (em_rst), "i" (mp_ne_set) : "eax");
-   }
+   asm ("fninit\n" \
+   "movl %%cr0, %%eax\n" \
+   "andl %0, %%eax\n" \
+   "orl  %1, %%eax\n" \
+   "movl %%eax, %%cr0\n" \
+   : : "i" (em_rst), "i" (mp_ne_set) : "eax");
+}
 
+static void setup_identity(void)
+{
/* identify CPU via cpuid and store the decoded info into gd->arch */
if (has_cpuid()) {
struct cpu_device_id cpu;
@@ -339,46 +340,70 @@ int x86_cpu_init_f(void)
 
gd->arch.has_mtrr = has_mtrr();
}
-   /* Don't allow PCI region 3 to use memory in the 2-4GB memory hole */
+}
+
+/* Don't allow PCI region 3 to use memory in the 2-4GB memory hole */
+static void setup_pci_ram_top(void)
+{
gd->pci_ram_top = 0x8000U;
+}
+
+static void setup_mtrr(void)
+{
+   u64 mtrr_cap;
 
/* Configure fixed range MTRRs for some legacy regions */
-   if (gd->arch.has_mtrr) {
-   u64 mtrr_cap;
-
-   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
-   if (mtrr_cap & MTRR_CAP_FIX) {
-   /* Mark the VGA RAM area as uncacheable */
-   native_write_msr(MTRR_FIX_16K_A_MSR,
-MTRR_FIX_TYPE(MTRR_TYPE_UNCACHEABLE),
-MTRR_FIX_TYPE(MTRR_TYPE_UNCACHEABLE));
-
-   /*
-* Mark the PCI ROM area as cacheable to improve ROM
-* execution performance.
-*/
-   native_write_msr(MTRR_FIX_4K_C_MSR,
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
-   native_write_msr(MTRR_FIX_4K_C8000_MSR,
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
-   native_write_msr(MTRR_FIX_4K_D_MSR,
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
-   native_write_msr(MTRR_FIX_4K_D8000_MSR,
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
-MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
-
-   /* Enable the fixed range MTRRs */
-   msr_setbits_64(MTRR_DEF_TYPE_MSR, MTRR_DEF_TYPE_FIX_EN);
-   }
+   if (!gd->arch.has_mtrr)
+   return;
+
+   mtrr_cap = native_read_msr(MTRR_CAP_MSR);
+   if (mtrr_cap & MTRR_CAP_FIX) {
+   /* Mark the VGA RAM area as uncacheable */
+   native_write_msr(MTRR_FIX_16K_A_MSR,
+MTRR_FIX_TYPE(MTRR_TYPE_UNCACHEABLE),
+MTRR_FIX_TYPE(MTRR_TYPE_UNCACHEABLE));
+
+   /*
+* Mark the PCI ROM area as cacheable to improve ROM
+* execution performance.
+*/
+   native_write_msr(MTRR_FIX_4K_C_MSR,
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
+   native_write_msr(MTRR_FIX_4K_C8000_MSR,
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
+   native_write_msr(MTRR_FIX_4K_D_MSR,
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK),
+MTRR_FIX_TYPE(MTRR_TYPE_WRBACK));
+   native_write_msr(MTRR_FIX_4K_D8000_MSR,
+

[U-Boot] [PATCH 03/40] binman: Add a missing comment in Entry_vblock

2019-01-29 Thread Simon Glass
An important property is missing. Update the entry comment to include
this.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/vblock.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/binman/etype/vblock.py b/tools/binman/etype/vblock.py
index c4d970ed16..334ff9f966 100644
--- a/tools/binman/etype/vblock.py
+++ b/tools/binman/etype/vblock.py
@@ -18,6 +18,7 @@ class Entry_vblock(Entry):
 """An entry which contains a Chromium OS verified boot block
 
 Properties / Entry arguments:
+- content: List of phandles to entries to sign
 - keydir: Directory containing the public keys to use
 - keyblock: Name of the key file to use (inside keydir)
 - signprivate: Name of provide key file to use (inside keydir)
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 04/40] dm: core: Fix translate condition in ofnode_get_addr_size()

2019-01-29 Thread Simon Glass
Update the condition to translate only if this is enabled for SPL.

Signed-off-by: Simon Glass 
---

 drivers/core/ofnode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 0e584c12dc..34f3c88b92 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -547,7 +547,7 @@ fdt_addr_t ofnode_get_addr_size(ofnode node, const char 
*property,
ns = of_n_size_cells(np);
*sizep = of_read_number(prop + na, ns);
 
-   if (IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0)
+   if (CONFIG_IS_ENABLED(OF_TRANSLATE) && ns > 0)
return of_translate_address(np, prop);
else
return of_read_number(prop, na);
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 01/40] binman: Don't generate an error in 'text' entry constructor

2019-01-29 Thread Simon Glass
It is not good practice to raise an exception in a constructor. In this
case the 'text' entry may not actually be used, if -i is used to filter
out the images that get built.

Move the exception to where the data is actually used.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/text.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/binman/etype/text.py b/tools/binman/etype/text.py
index 6e99819487..c4aa510a87 100644
--- a/tools/binman/etype/text.py
+++ b/tools/binman/etype/text.py
@@ -51,10 +51,10 @@ class Entry_text(Entry):
 self.text_label, = self.GetEntryArgsOrProps(
 [EntryArg('text-label', str)])
 self.value, = self.GetEntryArgsOrProps([EntryArg(self.text_label, 
str)])
+
+def ObtainContents(self):
 if not self.value:
 self.Raise("No value provided for text label '%s'" %
self.text_label)
-
-def ObtainContents(self):
 self.SetContents(self.value)
 return True
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 02/40] binman: Don't show image-skip message by default

2019-01-29 Thread Simon Glass
This message is not very important since it is simply indicating that the
user's instructions are being followed. Only show it when the verbosity
level is above the default.

Signed-off-by: Simon Glass 
---

 tools/binman/control.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index 3446e2e79c..b32e4e1996 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -133,8 +133,8 @@ def Binman(options, args):
 if name not in options.image:
 del images[name]
 skip.append(name)
-if skip:
-print 'Skipping images: %s\n' % ', '.join(skip)
+if skip and options.verbosity >= 2:
+print 'Skipping images: %s' % ', '.join(skip)
 
 state.Prepare(images, dtb)
 
-- 
2.20.1.495.gaa96b0ce6b-goog

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


[U-Boot] [PATCH 00/40] x86: Add support for booting from TPL

2019-01-29 Thread Simon Glass
At present SPL is used on 64-bit platforms, to allow SPL to be built as
a 32-bit program and U-Boot proper to be built as 64-bit.

However it is useful to be able to use SPL on any x86 platform, where
U-Boot needs to be updated in the field. Then SPL can select which U-Boot
to run (A or B) and most of the code can be updated. Similarly, using TPL
allows both SPL and U-Boot to be updated. This is the best approach, since
it means that all of U-Boot proper as well as SPL (in particular SDRAM
init) can be updated in the field. This provides for the smallest possible
amount of read-only (non-updateable) code: just the TPL code.

This series contains a number of changes to allow x86 boards to use TPL,
SPL and U-Boot proper. As a test, it is enabled for samus with a new
chromebook_samus_tpl board.


Simon Glass (40):
  binman: Don't generate an error in 'text' entry constructor
  binman: Don't show image-skip message by default
  binman: Add a missing comment in Entry_vblock
  dm: core: Fix translate condition in ofnode_get_addr_size()
  cros_ec: Use a hyphen in the uclass name
  spl: Allow sandbox to build a device-tree file
  RFC: binman: Allow sections to have an offset
  x86: start64: Fix copyright message
  x86: mp_init: Use proper error numbers
  x86: Add a way to reinit the cpu
  x86: dts: Add device-tree labels for rtc and reset
  x86: Update a stale comment about ifdtool
  x86: Support SPL and TPL
  x86: Support booting with TPL
  x86: Add a handoff header file
  x86: broadwell: Improve SDRAM debugging output
  x86: broadwell: Allow SDRAM init from SPL
  x86: Move init of debug UART to cpu.c
  x86: broadwell: Split CPU init
  x86: Add support for starting from SPL/TPL
  x86: Allow 16-bit init to be in TPL
  x86: broadwell: Allow booting from SPL
  x86: broadwell: Select refcode and CPU code for SPL
  x86: Add common Intel code for SPL
  x86: Support saving MRC data from SPL
  x86: Add a simple TPL implementations
  x86: mrccache: Add more debugging
  x86: Add a sysreset driver for the Intel PCH
  x86: Support TPL in Intel common code
  x86: Don't set up MTRRs in SPL
  x86: Don't generate a bootstage report in SPL
  x86: Support PCI VGA ROM when TPL is used
  x86: sysreset: Implement the get_last() method
  x86: Add documention on the samus flashmap
  x86: samus: Update device tree for SPL
  x86: samus: Update device tree for verified boot
  x86: Update device tree for TPL
  x86: Update device tree for Chromium OS verified boot
  x86: Fix device-tree indentation
  x86: samus: Add a target to boot through TPL

 Makefile  |   1 +
 arch/Kconfig  |  30 +
 arch/x86/Kconfig  |  10 +-
 arch/x86/Makefile |  16 +-
 arch/x86/cpu/Makefile |  15 +-
 arch/x86/cpu/broadwell/Kconfig|   1 +
 arch/x86/cpu/broadwell/Makefile   |  23 +-
 arch/x86/cpu/broadwell/cpu.c  | 676 +
 arch/x86/cpu/broadwell/cpu_from_spl.c |  63 ++
 arch/x86/cpu/broadwell/cpu_full.c | 694 ++
 arch/x86/cpu/broadwell/northbridge.c  |  93 +++
 arch/x86/cpu/broadwell/sdram.c| 136 +
 arch/x86/cpu/i386/cpu.c   | 113 ++--
 arch/x86/cpu/intel_common/Makefile|  17 +-
 arch/x86/cpu/intel_common/car.S   |   2 +-
 arch/x86/cpu/intel_common/cpu_from_spl.c  |  27 +
 arch/x86/cpu/mp_init.c|  10 +-
 arch/x86/cpu/start64.S|   2 +-
 arch/x86/cpu/start_from_spl.S |  71 +++
 arch/x86/cpu/start_from_tpl.S |  50 ++
 arch/x86/cpu/u-boot-spl.lds   |   2 +-
 arch/x86/cpu/x86_64/cpu.c |   5 +
 arch/x86/dts/chromebook_samus.dts |  60 +-
 arch/x86/dts/reset.dtsi   |   2 +-
 arch/x86/dts/rtc.dtsi |   2 +-
 arch/x86/dts/u-boot.dtsi  | 154 +++--
 arch/x86/include/asm/handoff.h|  15 +
 arch/x86/include/asm/mrccache.h   |  11 +
 arch/x86/include/asm/spl.h|  17 +-
 arch/x86/include/asm/u-boot-x86.h |  20 +
 arch/x86/lib/Makefile |   9 +-
 arch/x86/lib/bootm.c  |   2 +-
 arch/x86/lib/init_helpers.c   |   5 +-
 arch/x86/lib/mrccache.c   |  52 +-
 arch/x86/lib/spl.c|  44 +-
 arch/x86/lib/tpl.c| 118 
 board/google/Kconfig  |   8 +
 board/google/chromebook_samus/Kconfig |  14 +-
 board/google/chromebook_samus/MAINTAINERS |   7 +
 configs/chromebook_samus_tpl_defconfig|  80 +++
 doc/README.x86|  14 +
 drivers/core/ofnode.c |   2 +-
 drivers/misc/cros_ec.c|   2 +-
 drivers/pci/pci_rom.c |   2 +-
 drivers/sysreset/Kconfig  |   9 +
 drivers/sysreset/Makefile |   1 +
 

Re: [U-Boot] [PATCH 13/13] mmc: am654_sdhci: Add a platform specific set_control_reg() callback

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:31PM +0530, Faiz Abbas wrote:

> From: Faiz Abbas 
> 
> Add a platform specific set_control_reg() callback to help switch to
> UHS speed modes.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 08/13] arm: dts: k3: Add phy specific properties to SD card node

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:26PM +0530, Faiz Abbas wrote:

> With changes in the driver requiring phy related properties,
> add the same for the SD card node to prevent breaking boot with
> the driver update.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 07/13] mmc: sdhci: Make sdhci_set_clock() non static

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:25PM +0530, Faiz Abbas wrote:

> The am654_sdhci driver needs to switch the clock off
> before disabling its phy dll and needs to re-enable
> the clock before enabling the phy again.
> 
> Therefore, make the sdhci_set_clock() function accessible
> in the am654_sdhci driver.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 06/13] mmc: sdhci: Add support for sdhci-caps-mask

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:24PM +0530, Faiz Abbas wrote:

> Add Support for masking some bits in the capabilities
> register of a host controller.
> 
> Also remove the redundant readl() into caps1.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 03/13] mmc: am654_sdhci: Remove quirks

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:21PM +0530, Faiz Abbas wrote:

> The host controller works perfectly well without having to add any
> quirks. Remove them.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 09/13] mmc: sdhci: Make set_ios_post() return int

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:27PM +0530, Faiz Abbas wrote:

> Make set_ios_post() return int to faciliate error handling in
> platform drivers.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  drivers/mmc/sdhci.c   | 6 +-
>  drivers/mmc/xenon_sdhci.c | 4 +++-
>  include/sdhci.h   | 2 +-
>  3 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index 635f5396c4..b7b7ff6f7d 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -461,6 +461,7 @@ static int sdhci_set_ios(struct mmc *mmc)
>  #endif
>   u32 ctrl;
>   struct sdhci_host *host = mmc->priv;
> + int ret;
>  
>   if (host->ops && host->ops->set_control_reg)
>   host->ops->set_control_reg(host);
> @@ -500,8 +501,11 @@ static int sdhci_set_ios(struct mmc *mmc)
>   sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
>  
>   /* If available, call the driver specific "post" set_ios() function */
> - if (host->ops && host->ops->set_ios_post)
> + if (host->ops && host->ops->set_ios_post) {
>   host->ops->set_ios_post(host);
> + if (ret)
> + return ret;
> + }
>  
>   return 0;
>  }

Isn't something going to complain about either unused or uninitialized
(or, both) variables?  In fact, re-reading this and follow-up patches, I
think you forgot to turn:
host->ops->set_ios_post(host);
in to:
ret = host->ops->set_ios_post(host);
above.  And could probably simplfy the whole thing to:
if (host->ops && host->ops->set_ios_post)
return host->ops->set_ios_post(host);

return 0;

Or is there more to the function that I'm missing?  That's just based on
the patch context alone.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190129

2019-01-29 Thread Tom Rini
On Tue, Jan 29, 2019 at 11:22:15AM +0100, Neil Armstrong wrote:

> Hi Tom,
> 
> Here is single patch adding support for pinconf on the amlogic pinctrl driver,
> fixed after a build failure report from Anatolij.
> This PR replaces u-boot-amlogic-20190128.
> 
> Thanks,
> Neil
> 
> The following changes since commit 0da90255083681a02b24528f80da9d4062ff634a:
> 
>   Merge branch '2019-01-25-master-imports' (2019-01-26 22:47:55 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190129
> 
> for you to fetch changes up to c4c726c26bdc09a2c907e230fdf6c75adcc2b674:
> 
>   pinctrl: meson: add pinconf support (2019-01-29 11:19:15 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 12/13] mmc: sdhci: Add support for HOST_CONTROL2 and setting UHS timings

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:30PM +0530, Faiz Abbas wrote:

> From: Faiz Abbas 
> 
> The HOST_CONTROL2 register is a part of SDHC v3.00 and not just specific
> to arasan/zynq controllers. Add the same to sdhci.h.
> 
> Also create a common API to set UHS timings in HOST_CONTROL2.
> 
> Signed-off-by: Faiz Abbas 
[snip]
> diff --git a/include/sdhci.h b/include/sdhci.h
> index 725520b0b4..1e5f249eab 100644
> --- a/include/sdhci.h
> +++ b/include/sdhci.h
> @@ -144,7 +144,23 @@
>  
>  #define SDHCI_ACMD12_ERR 0x3C
>  
> -/* 3E-3F reserved */
> +#define SDHCI_HOST_CONTROL2  0x3E
> +#define  SDHCI_CTRL_UHS_MASK 0x0007
> +#define   SDHCI_CTRL_UHS_SDR12   0x
> +#define   SDHCI_CTRL_UHS_SDR25   0x0001
> +#define   SDHCI_CTRL_UHS_SDR50   0x0002
> +#define   SDHCI_CTRL_UHS_SDR104  0x0003
> +#define   SDHCI_CTRL_UHS_DDR50   0x0004
> +#define   SDHCI_CTRL_HS400   0x0005 /* Non-standard */
> +#define  SDHCI_CTRL_VDD_180  0x0008
> +#define  SDHCI_CTRL_DRV_TYPE_MASK0x0030
> +#define   SDHCI_CTRL_DRV_TYPE_B  0x
> +#define   SDHCI_CTRL_DRV_TYPE_A  0x0010
> +#define   SDHCI_CTRL_DRV_TYPE_C  0x0020
> +#define   SDHCI_CTRL_DRV_TYPE_D  0x0030
> +#define  SDHCI_CTRL_EXEC_TUNING  0x0040
> +#define  SDHCI_CTRL_TUNED_CLK0x0080
> +#define  SDHCI_CTRL_PRESET_VAL_ENABLE0x8000

The defines had consistent spacing before and now don't, why?  Or please
fix.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 05/13] regmap: Add support for polling on a register

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:23PM +0530, Faiz Abbas wrote:

> Add an API to continuously read a register until a condition is
> satisfied or a timeout occurs.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 10/13] mmc: am654_sdhci: Add Support for PHY

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:28PM +0530, Faiz Abbas wrote:

> Add support in the driver for handling phy specific registers.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] arm: stm32mp1: deploy spl in root folder

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 11:13:27AM +0100, Patrick Delaunay wrote:

> Update generation of spl binaries
> - continue to generate all SPL files in spl sub-directory
> - copy in root folder the needed file for user (YOCTO, buildroot):
>   u-boot-spl.stm32
> 
> 
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 11/13] configs: am65x_evm: Enable CONFIG_REGMAP

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:29PM +0530, Faiz Abbas wrote:

> Add Support for CONFIG_REGMAP.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 02/13] mmc: am654_mmc: Change driver name

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:20PM +0530, Faiz Abbas wrote:

> This driver works with the sdhci controller present on TI's AM65x devices.
> Change the name to make this clearer and match the compatible with
> kernel.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 04/13] regmap: Add API regmap_init_mem_index()

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:22PM +0530, Faiz Abbas wrote:

> In device nodes with more than one entry in the reg property,
> it is sometimes useful to regmap only of the entries. Add an
> API regmap_init_mem_index() to facilitate this.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 01/13] arm64: dts: k3: Sync sdhci0 node from kernel

2019-01-29 Thread Tom Rini
On Mon, Jan 28, 2019 at 12:15:19PM +0530, Faiz Abbas wrote:

> Sync the sdhci0 node from kernel. This changes the compatible that is
> required to be there in the driver. Change the same for the SD card node
> which is not yet supported in kernel.
> 
> Also sync the main_pmx0 node as a side effect.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Probing flash before Env setup (Env in UBI)

2019-01-29 Thread Dominik Vogt
Hi folks,

I'm new to uboot and couldn't figure out how to get
"CONFIG_ENV_IS_IN_UBI" to work (on a nor flash) yet.

Basically, ubi and ubifs work fine.  The mtd device (a nor flash)
is supported and works.  It is formatted with ubiformat and
contains two volumes with a ubifs on each of them.

The "partition" is named "nor0" and the volumes are "env-uboot"
and "env-uboot-redund".

--

Now, when the board boots, it tries to load the envorinment and
fails:

-- snip --
  Loading Environment from SPI Flash... SF: Detected n25q128 with page size 256 
Bytes, erase size 64 KiB, total 16 MiB
  *** Warning - bad CRC, using default environment

  Loading Environment from UBI... Partition nor0 not found!

  ** Cannot find mtd partition "nor0"
-- snip --

The first line looks like the output from "sf probe", but "mtd
list" just says:

  List of MTD devices:
  No MTD device found

Well, I guess I just have to run

  sf probe
  ubi part nor0

before loading he environment, but I couldn't figure out how to do
that, except by adding some C code to board_init_f().

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/9] sunxi: clk: enable clk and reset for CCU devices

2019-01-29 Thread Andre Przywara
On Tue, 29 Jan 2019 23:40:26 +0530
Jagan Teki  wrote:

> On Tue, Jan 29, 2019 at 9:25 PM Andre Przywara
>  wrote:
> >
> > Some Allwinner clock devices have parent clocks and reset gates
> > itself, which need to be activated for them to work.
> >
> > Add some code to just assert all resets and enable all clocks given.
> > This should enable the A80 MMC config clock, which requires both to
> > be activated. The full CCU devices typically don't require resets,
> > and have just fixed clocks as their parents. Since we treat both as
> > optional and enabling fixed clocks is a NOP, this works for all
> > cases, without the need to differentiate between those clock types.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  drivers/clk/sunxi/clk_sunxi.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/clk/sunxi/clk_sunxi.c
> > b/drivers/clk/sunxi/clk_sunxi.c index 62ce2994e4..6d4aeb5315 100644
> > --- a/drivers/clk/sunxi/clk_sunxi.c
> > +++ b/drivers/clk/sunxi/clk_sunxi.c
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -61,6 +62,9 @@ struct clk_ops sunxi_clk_ops = {
> >  int sunxi_clk_probe(struct udevice *dev)
> >  {
> > struct ccu_priv *priv = dev_get_priv(dev);
> > +   struct clk_bulk clk_bulk;
> > +   struct reset_ctl_bulk rst_bulk;
> > +   int ret;
> >
> > priv->base = dev_read_addr_ptr(dev);
> > if (!priv->base)
> > @@ -70,5 +74,13 @@ int sunxi_clk_probe(struct udevice *dev)
> > if (!priv->desc)
> > return -EINVAL;
> >
> > +   ret = clk_get_bulk(dev, _bulk);
> > +   if (!ret)
> > +   clk_enable_bulk(_bulk);
> > +
> > +   ret = reset_get_bulk(dev, _bulk);
> > +   if (!ret)
> > +   reset_deassert_bulk(_bulk);
> > +  
> 
> Can't we do this locally to clk_a80 probe?

That's the point: there is no such thing. For all SoCs we use the shared
sunxi_clk_probe() function. Doing this only for the A80 would mean to
split this up, which is duplicating a lot of code for very little
effect. The code here just enables every clock and reset given, which
is generic and should always be the right thing.

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


Re: [U-Boot] imx8mq-evk: Outbound network packets lost

2019-01-29 Thread Sergey Kubushyn

On Sat, 26 Jan 2019, Chris Spencer wrote:


On Sat, 26 Jan 2019 at 01:14, Sergey Kubushyn  wrote:

Thanks for a reply. The problem here is not with leftover descriptors -- it
is MDIO bus not working at all. It is either bogus speed/clock in DM mode or
something else that I haven't found yet. Reading all zeroes means there is
no communication with the PHY whatsoever, it comes from bare wire. And there
is no need for the PHY to be present at all for an MDIO transaction to
complete successfully -- PHY is a slave device with all clocks coming from
FEC MDIO so it WILL complete successfully even if it not connected to a PHY.
It is kinda like SPI that always succeeds for the master.


What I found when debugging the Linux driver is that an MII interrupt
was being delivered too early after the first MDIO read the driver
issues, resulting in it reading back the wrong value. I was able to
reliably stop this from happening by zeroing out ENET_MMFR immediately
before the driver sets ENET_MSCR. If I disable networking in U-Boot
then the problem in the Linux driver doesn't occur at all, so the only
explanation I can come up with is that U-Boot is somehow leaving
something in ENET_MMFR which is being unintentionally triggered when
the Linux driver sets ENET_MSCR. You have a very good point though
because the reads are still completing in U-Boot, even if they always
come back zero, so I'm not really sure how there would end up being
something left over in ENET_MMFR.


OK, I've got it working. The problem was DM FEC driver does _NOT_ do pin
muxing and FEC pins in i.MX8MQ come up as GPIOs after rest so no wonder it
can't talk to the PHY or whatever else.

I don't know yet if there is some setting that I've missed to force it to do
pin muxing but didn't find anything appropriate in reference fsl-imx8mq-evk
board configs or board source files.

Once pin muxing is done in the board file FEC comes up as expected, finds
the PHY and all network stuff works as expected.

Dedicated "regulator" and PHY reset works OK from DTB provided FEC driver is
patched for regulator (regulator_set_enable instead of regulator_autoset)
and PHY reset GPIO set "ACTIVE_LOW" in the board's DTS file (fec driver sets
it to "1" to reset then resets it to "0").

So it is either pin muxing is missing and one should do it in his board's
file or I've missed some setting that I can't find to get the DM FEC driver
to do it itself from DTS file.

---
**
*  KSI@homeKOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC 3/3] drivers: align block device drivers with DM-efi integration

2019-01-29 Thread AKASHI Takahiro
Alex,

On Tue, Jan 29, 2019 at 05:19:38PM +0100, Alexander Graf wrote:
> On 01/29/2019 03:59 AM, AKASHI Takahiro wrote:
> >Efi_disk_create() should be hook up at every creation of block device
> >at each driver. Associated blk_desc must be properly set up before
> >calling this function.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  common/usb_storage.c  | 27 +--
> >  drivers/scsi/scsi.c   | 22 ++
> >  lib/efi_driver/efi_block_device.c | 30 +-
> >  3 files changed, 56 insertions(+), 23 deletions(-)
> >
> >diff --git a/common/usb_storage.c b/common/usb_storage.c
> >index 8c889bb1a648..ff895c0e4557 100644
> >--- a/common/usb_storage.c
> >+++ b/common/usb_storage.c
> >@@ -46,6 +46,10 @@
> >  #include 
> >  #include 
> >+/* FIXME */
> >+extern int efi_disk_create(struct udevice *dev);
> >+extern int blk_create_partitions(struct udevice *parent);
> >+
> >  #undef BBB_COMDAT_TRACE
> >  #undef BBB_XPORT_TRACE
> >@@ -227,8 +231,27 @@ static int usb_stor_probe_device(struct usb_device 
> >*udev)
> > ret = usb_stor_get_info(udev, data, blkdev);
> > if (ret == 1) {
> >-usb_max_devs++;
> >-debug("%s: Found device %p\n", __func__, udev);
> >+ret = efi_disk_create(dev);
> >+if (ret) {
> >+debug("Cannot create efi_disk device\n");
> >+ret = device_unbind(dev);
> >+if (ret)
> >+return ret;
> >+} else {
> >+usb_max_devs++;
> >+ret = blk_create_partitions(dev);
> >+if (ret < 0) {
> >+debug("Cannot create disk partition 
> >device\n");
> >+/* TODO: undo create */
> >+
> >+ret = device_unbind(dev);
> >+if (ret)
> >+return ret;
> >+}
> >+usb_max_devs += ret;
> >+debug("%s: Found device %p, partitions:%d\n",
> >+  __func__, udev, ret);
> >+}
> 
> Why do we need to do this in device specific code?

Good point.

* efi_disk_create()
As I said in the past, efi_disk_create() will expect that blk_desc has
been initialized before it is called.
(There may be some possibility of removing this assumption.)

Blk_desc is often initialized after blk_create_device() in a driver.
So it won't be able to be placed in blk_create_device().

If, however, we have a "delayed" execution mechanism (like timer event as
you suggested before), we may put this function in a single point.

* blk_create_partions()
I initially thought of putting this function in part_init() which is
to be called at "probe," but was concerned that there might be a chance
that efi API be called before probing.
If this is not the case, we may also place this function in a single point.
(Unfortunately, "scsi rescan" won't kick off a probe hook though.)

Thanks,
-Takahiro Akashi

> Alex
> 
> 
> > } else {
> > debug("usb_stor_get_info: Invalid device\n");
> > ret = device_unbind(dev);
> >diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> >index df47e2fc78bd..f0f8cbc0bf26 100644
> >--- a/drivers/scsi/scsi.c
> >+++ b/drivers/scsi/scsi.c
> >@@ -11,6 +11,10 @@
> >  #include 
> >  #include 
> >+/* FIXME */
> >+int efi_disk_create(struct udevice *dev);
> >+int blk_create_partitions(struct udevice *parent);
> >+
> >  #if !defined(CONFIG_DM_SCSI)
> >  # ifdef CONFIG_SCSI_DEV_LIST
> >  #  define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
> >@@ -593,9 +597,27 @@ static int do_scsi_scan_one(struct udevice *dev, int 
> >id, int lun, bool verbose)
> > memcpy(>product, , sizeof(bd.product));
> > memcpy(>revision, ,  sizeof(bd.revision));
> >+ret = efi_disk_create(bdev);
> >+if (ret) {
> >+debug("Can't create efi_disk device\n");
> >+ret = device_unbind(bdev);
> >+
> >+return ret;
> >+}
> >+ret = blk_create_partitions(bdev);
> >+if (ret < 0) {
> >+debug("Can't create efi_disk partitions\n");
> >+/* TODO: undo create */
> >+
> >+ret = device_unbind(bdev);
> >+
> >+return ret;
> >+}
> >+
> > if (verbose) {
> > printf("  Device %d: ", 0);
> > dev_print(bdesc);
> >+debug("Found %d partitions\n", ret);
> > }
> > return 0;
> >  }
> >diff --git a/lib/efi_driver/efi_block_device.c 
> >b/lib/efi_driver/efi_block_device.c
> >index 3f147cf60879..4ab3402d6768 100644
> >--- a/lib/efi_driver/efi_block_device.c
> >+++ b/lib/efi_driver/efi_block_device.c
> >@@ 

Re: [U-Boot] input in flex scanner failed (for rpi_0_w_defconfig)

2019-01-29 Thread Philipp Tomsich

> On 29.01.2019, at 21:37, Belisko Marek  wrote:
> 
> Hi,
> 
> I'm trying to build u-boot in docker on osx (installed build-essentials +
> gcc-arm) but hit this issue (with verbose make) during config phase. I
> tried same on linux and it works fine. Any ideas what can cause this (or
> how to debug)?

‘grep’ would have been a good start...

> make ARCH=arm rpi_0_w_defconfig V=1
> 
> make -f ./scripts/Makefile.build obj=scripts/basic
> 
>  cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer  -o scripts/basic/fixdep scripts/basic/fixdep.c
> 
> rm -f .tmp_quiet_recordmcount
> 
> make -f ./scripts/Makefile.build obj=scripts/kconfig rpi_0_w_defconfig
> 
>  cc -Wp,-MD,scripts/kconfig/.conf.o.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer-DCURSES_LOC="" -DLOCALE   -c -o
> scripts/kconfig/conf.o scripts/kconfig/conf.c
> 
>  cc -Wp,-MD,scripts/kconfig/.zconf.tab.o.d -Wall -Wstrict-prototypes -O2
> -fomit-frame-pointer-DCURSES_LOC="" -DLOCALE  -Iscripts/kconfig
> -c -o scripts/kconfig/zconf.tab.o scripts/kconfig/zconf.tab.c
> 
>  cc  -o scripts/kconfig/conf scripts/kconfig/conf.o
> scripts/kconfig/zconf.tab.o
> 
> scripts/kconfig/conf  --defconfig=arch/../configs/rpi_0_w_defconfig Kconfig
> 
> input in flex scanner failed

Huh. I haven’t seen that error message in a long time.
This will be printed by a flex-generated lexer, if the input file can’t
be read.

Case in point (from scripts/kconfig/zconf.lex.c_shipped):

/* Gets input and stuffs it into "buf".  number of characters read, or YY_NULL,
 * is returned in "result".
 */
#ifndef YY_INPUT
#define YY_INPUT(buf,result,max_size) \
errno=0; \
while ( (result = read( fileno(zconfin), (char *) buf, max_size )) < 0 )
 \
{ \
if( errno != EINTR) \
{ \
YY_FATAL_ERROR( "input in flex scanner failed" ); \
break; \
} \
errno=0; \
clearerr(zconfin); \
}\
\


> 
> scripts/kconfig/Makefile:121: recipe for target 'rpi_0_w_defconfig' failed
> 
> make[1]: *** [rpi_0_w_defconfig] Error 2
> 
> Makefile:478: recipe for target 'rpi_0_w_defconfig' failed
> 
> make: *** [rpi_0_w_defconfig] Error 2
> 
> BR,
> 
> marek
> 
> -- 
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
> 
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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


Re: [U-Boot] [PATCH v6 6/7] cmd: efidebug: add images command

2019-01-29 Thread AKASHI Takahiro
On Tue, Jan 29, 2019 at 04:35:32PM +0100, Alexander Graf wrote:
> On 01/24/2019 12:04 PM, AKASHI Takahiro wrote:
> >"images" command prints loaded images-related information.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  cmd/efidebug.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> >diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> >index a1852e8ea4b9..81ab3654f746 100644
> >--- a/cmd/efidebug.c
> >+++ b/cmd/efidebug.c
> >@@ -301,6 +301,14 @@ static int do_efi_show_handles(cmd_tbl_t *cmdtp, int 
> >flag,
> > return CMD_RET_SUCCESS;
> >  }
> >+static int do_efi_show_images(cmd_tbl_t *cmdtp, int flag,
> >+  int argc, char * const argv[])
> >+{
> >+efi_print_image_infos(NULL);
> 
> Where does this function get defined?

in efi_image_loader.c by Heinrich.

-Takahiro Akashi

> 
> Alex
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset

2019-01-29 Thread Heinrich Schuchardt
On 1/30/19 12:15 AM, Alexander Graf wrote:
> 
> 
> On 30.01.19 00:08, Heinrich Schuchardt wrote:
>> On 1/28/19 4:42 PM, Alexander Graf wrote:
>>> Our selftest will soon test the actual runtime reset function rather than
>>> the boot time one. For this, we need to ensure that the runtime version
>>> actually succeeds on x86 to keep our travis tests work.
>>>
>>> So this patch implements an x86 runtime reset function. It is missing
>>> shutdown functionality today, but OSs usually implement that via ACPI
>>> and this function does more than the stub from before, so it's at least
>>> an improvement.
>>>
>>> Signed-off-by: Alexander Graf 
>>> ---
>>>  drivers/sysreset/sysreset_x86.c | 23 +++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git a/drivers/sysreset/sysreset_x86.c 
>>> b/drivers/sysreset/sysreset_x86.c
>>> index 20b958cfd4..efed45ccb7 100644
>>> --- a/drivers/sysreset/sysreset_x86.c
>>> +++ b/drivers/sysreset/sysreset_x86.c
>>> @@ -10,6 +10,29 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +
>>> +#ifdef CONFIG_EFI_LOADER
>>> +void __efi_runtime EFIAPI efi_reset_system(
>>> +   enum efi_reset_type reset_type,
>>> +   efi_status_t reset_status,
>>> +   unsigned long data_size, void *reset_data)
>>> +{
>>> +   u32 value = 0;
>>> +
>>> +   if (reset_type == EFI_RESET_COLD)
>>> +   value = SYS_RST | RST_CPU | FULL_RST;
>>> +   else if (reset_type == EFI_RESET_WARM)
>>> +   value = SYS_RST | RST_CPU;
>>> +
>>> +   /* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
>>> +
>>> +   if (value)
>>> +   outb(value, IO_PORT_RESET);
>>
>> This does not look ACPI compliant. Shouldn't we read the ACPI table to
>> identify the reset register?
> 
> There are about 500 different ways to reset the system, CPU, something
> on x86. I don't think U-Boot should do anything with ACPI. It's an ACPI
> producer, not an ACPI consumer.
> 
>> When we do the reset CPUs in several sockets may be running multiple
>> cores each. Are all of these stopped via this register? Or do we first
>> have to halt all but one core before doing the reset?
> 
> I don't know what the reset protocol dictates here. But it probably also
> heavily depends on the target platform we're looking at. IIUC this
> particular reset is the keyboard controller one which just pulls the
> reset line of the primary CPU socket.
> 
> I am not aware of any multi-socket targets that U-Boot supports, so it
> should work in all of today's cases?
> 
> Realistically, I would not expect anyone to care too much about U-Boot
> on multi-socket (x86) systems :).

Your code resembles loosely BOOT_CF9_SAFE in
native_machine_emergency_restart() in Linux arch/x86/kernel/reboot.c
which is tried before using the keyboard controller as last resort.

u8 reboot_code = reboot_mode == REBOOT_WARM ?  0x06 : 0x0E;
u8 cf9 = inb(0xcf9) & ~reboot_code;
outb(cf9|2, 0xcf9); /* Request hard reset */
udelay(50);
/* Actually do the reset */
outb(cf9|reboot_code, 0xcf9);
udelay(50);

So the Kernel first switches bit 2 off and bit 1 on, waits, and then
switches bit 2 on, cf.
http://smackerelofopinion.blogspot.com/2011/02/resetting-pc-using-reset-control.html

Shouldn't we do it the same way as the Kernel does it?

Best regards

Heinrich

> 
> 
> Alex
> 

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


Re: [U-Boot] [PATCH v1 0/3] Add support for symlink creation in EXT4

2019-01-29 Thread Tom Rini
On Wed, Jan 30, 2019 at 12:24:29AM +0100, Lukasz Majewski wrote:
> On Tue, 29 Jan 2019 14:40:08 +0100
> Jean-Jacques Hiblot  wrote:
> 
> > This series adds support for the creation of symbolic links on ext4
> > file-systems.
> > The motivation behind this work is to have the ability to "do" the job
> > of update-alternatives in u-boot.
> > Firmware on TI's platform are usually managed with
> > update-alternatives and are thus targeted by a symbolic link. In some
> > situations we need the ability to select an alternate firmware before
> > the linux kernel is started so that when a early driver needing the
> > firmware comes up, it can be fed the firmware of our choice.
> > 
> > Tested on a am57xx_evm, using a EXT4 partition on external SDcard.
> > The filesystem can be checked later with: fsck.ext4 -f 
> > 
> > usage example:
> > => ln mmc 0:2 zImage /boot/the_linux_kernel 
> 
> Could you also add a test for symlink to sandbox? This is a high level
> code (FS ext4), so it can be nice tested there.
>  
> > 
> > 
> > Jean-Jacques Hiblot (3):
> >   fs: ext4: constify the buffer passed to write functions
> >   fs: ext4: Add support for the creation of symbolic links
> >   fs: Add a new command to create symbolic links
> > 
> >  cmd/fs.c  | 14 
> >  fs/ext4/ext4_common.c |  6 ++---
> >  fs/ext4/ext4_common.h |  2 +-
> >  fs/ext4/ext4_write.c  | 51
> > --- fs/fs.c   |
> > 44 + include/ext4fs.h  |  5
> > +++-- include/fs.h  |  2 ++
> >  7 files changed, 105 insertions(+), 19 deletions(-)

Yes, now that we have tests under pytest, we need to drop something for
this under test/py/tests/test_fs/ and my first thought is in a new
test_symlink.py file so that someday when we get more than just FAT/EXTn
tests the next FS that supports symlinks gets the tests for free if/when
it supports symlinks.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 20/20] imx: add i.MX8MM EVK board support

2019-01-29 Thread Lukasz Majewski
Hi Peng,

> Add i.MX8MM EVK board support.
> 
> Add board and SoC dts
> Add ddr training code
> support SD/MMC/GPIO/PINCTRL/UART
> 
> U-Boot SPL 2019.01-00148-g1179cffe66 (Jan 28 2019 - 17:37:34 +0800)
> Normal Boot
> Trying to boot from MMC1
> 
> U-Boot 2019.01-00148-g1179cffe66 (Jan 28 2019 - 17:37:34 +0800)
> 
> CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> Reset cause: POR
> Model: NXP i.MX8MM EVK board
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 1, FSL_SDHC: 2
> In:serial
> Out:   serial
> Err:   serial
> DM

You set/adjust latter in the code the fec network driver. Why it is not
found?

Could you also share the output of "dm tree" command?

I suppose/guess that this board shall support as much as possible of
the DT/DM conversions?

> Hit any key to stop autoboot:  2
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/dts/fsl-imx8mm-evk.dts|  203 +++
>  arch/arm/dts/fsl-imx8mm.dtsi   |  586 
>  arch/arm/mach-imx/imx8m/Kconfig|7 +
>  board/freescale/imx8mm_evk/Kconfig |   12 +
>  board/freescale/imx8mm_evk/MAINTAINERS |6 +
>  board/freescale/imx8mm_evk/Makefile|   12 +
>  board/freescale/imx8mm_evk/imx8mm_evk.c|  144 ++
>  board/freescale/imx8mm_evk/lpddr4_timing.c | 1980
> 
> board/freescale/imx8mm_evk/spl.c   |  187 +++
> configs/imx8mm_evk_defconfig   |   41 +
> include/configs/imx8mm_evk.h   |  221  11 files
> changed, 3399 insertions(+) create mode 100644
> arch/arm/dts/fsl-imx8mm-evk.dts create mode 100644
> arch/arm/dts/fsl-imx8mm.dtsi create mode 100644
> board/freescale/imx8mm_evk/Kconfig create mode 100644
> board/freescale/imx8mm_evk/MAINTAINERS create mode 100644
> board/freescale/imx8mm_evk/Makefile create mode 100644
> board/freescale/imx8mm_evk/imx8mm_evk.c create mode 100644
> board/freescale/imx8mm_evk/lpddr4_timing.c create mode 100644
> board/freescale/imx8mm_evk/spl.c create mode 100644
> configs/imx8mm_evk_defconfig create mode 100644
> include/configs/imx8mm_evk.h
> 
> diff --git a/arch/arm/dts/fsl-imx8mm-evk.dts
> b/arch/arm/dts/fsl-imx8mm-evk.dts new file mode 100644
> index 00..df409eca47
> --- /dev/null
> +++ b/arch/arm/dts/fsl-imx8mm-evk.dts
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 NXP
> + */
> +
> +/dts-v1/;
> +
> +#include "fsl-imx8mm.dtsi"
> +
> +/ {
> + model = "NXP i.MX8MM EVK board";
> + compatible = "fsl,imx8mm-evk", "fsl,imx8mm";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_usdhc2_vmmc: regulator-usdhc2 {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = < 19 GPIO_ACTIVE_HIGH>;
> + off-on-delay = <2>;
> + enable-active-high;
> + };
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> +
> + imx8mm-evk {
> + pinctrl_fec1: fec1grp {
> + fsl,pins = <
> +
> MX8MM_IOMUXC_ENET_MDC_ENET1_MDC   0x3
> +
> MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
> +
> MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
> +
> MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
> +
> MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
> +
> MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
> +
> MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
> +
> MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
> +
> MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
> +
> MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
> +
> MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
> +
> MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
> +
> MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL   0x91
> +
> MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL   0x1f
> +
> MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22  0x19
> + >;
> + };
> +
> + pinctrl_gpio_led: gpioledgrp {
> + fsl,pins = <
> +
> MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16  0x19
> + >;
> + };
> +
> + pinctrl_uart2: uart2grp {
> + fsl,pins = <
> +
> MX8MM_IOMUXC_UART2_RXD_UART2_DCE_RX   0x140
> +
> MX8MM_IOMUXC_UART2_TXD_UART2_DCE_TX   0x140
> + >;
> + };
> +
> + pinctrl_usdhc2_gpio: usdhc2grpgpio {
> + fsl,pins = <
> +
> MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO150x1c4
> +
> MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19   0x41
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> +
> 

Re: [U-Boot] [PATCH v1 0/3] Add support for symlink creation in EXT4

2019-01-29 Thread Lukasz Majewski
On Tue, 29 Jan 2019 14:40:08 +0100
Jean-Jacques Hiblot  wrote:

> This series adds support for the creation of symbolic links on ext4
> file-systems.
> The motivation behind this work is to have the ability to "do" the job
> of update-alternatives in u-boot.
> Firmware on TI's platform are usually managed with
> update-alternatives and are thus targeted by a symbolic link. In some
> situations we need the ability to select an alternate firmware before
> the linux kernel is started so that when a early driver needing the
> firmware comes up, it can be fed the firmware of our choice.
> 
> Tested on a am57xx_evm, using a EXT4 partition on external SDcard.
> The filesystem can be checked later with: fsck.ext4 -f 
> 
> usage example:
> => ln mmc 0:2 zImage /boot/the_linux_kernel 

Could you also add a test for symlink to sandbox? This is a high level
code (FS ext4), so it can be nice tested there.
 
> 
> 
> Jean-Jacques Hiblot (3):
>   fs: ext4: constify the buffer passed to write functions
>   fs: ext4: Add support for the creation of symbolic links
>   fs: Add a new command to create symbolic links
> 
>  cmd/fs.c  | 14 
>  fs/ext4/ext4_common.c |  6 ++---
>  fs/ext4/ext4_common.h |  2 +-
>  fs/ext4/ext4_write.c  | 51
> --- fs/fs.c   |
> 44 + include/ext4fs.h  |  5
> +++-- include/fs.h  |  2 ++
>  7 files changed, 105 insertions(+), 19 deletions(-)
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpuQog7HNZEJ.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Two u boot environment on eMMC

2019-01-29 Thread Lukasz Majewski
On Mon, 28 Jan 2019 15:18:15 +0200
Сергей Сахно  wrote:

> Hello everyone. I have one question: do i can use two u boot
> environment on eMMC in raw mode? If yes, how?

Do you think of using "redundant" eMMC envs?

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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp2u1kczYDHz.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] x86: #define CONFIG_LOADADDR 0x1100000

2019-01-29 Thread Heinrich Schuchardt
On 1/24/19 9:18 PM, Heinrich Schuchardt wrote:
> arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x100.
> Loading via the `dhcp` command to this address leads to a crash on
> qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x110.
> 
> Reported-by: Alexander Graf 
> Signed-off-by: Heinrich Schuchardt 
> ---
> compatible='pci-x86' is a U-Boot specific device tree binding.
> Unfortunately it is not documented. Simon, it would be helpful
> if you could provide some README.
> ---
>  include/configs/x86-common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
> index 4180b25f97..e936230157 100644
> --- a/include/configs/x86-common.h
> +++ b/include/configs/x86-common.h
> @@ -99,7 +99,7 @@
>  #define CONFIG_ROOTPATH  "/opt/nfsroot"
>  #define CONFIG_HOSTNAME  "x86"
>  #define CONFIG_BOOTFILE  "bzImage"
> -#define CONFIG_LOADADDR  0x100
> +#define CONFIG_LOADADDR  0x110
>  #define CONFIG_RAMDISK_ADDR  0x400
>  #if defined(CONFIG_GENERATE_ACPI_TABLE) || defined(CONFIG_EFI_STUB)
>  #define CONFIG_OTHBOOTARGS   "othbootargs=\0"
> 

Hello Bin, hello Simon,

this is one of the three patches missing in U-Boot master that are
putting the EFI patch queue on hold. What is your opinion on the patch?

Best regards

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


Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset

2019-01-29 Thread Alexander Graf


On 30.01.19 00:08, Heinrich Schuchardt wrote:
> On 1/28/19 4:42 PM, Alexander Graf wrote:
>> Our selftest will soon test the actual runtime reset function rather than
>> the boot time one. For this, we need to ensure that the runtime version
>> actually succeeds on x86 to keep our travis tests work.
>>
>> So this patch implements an x86 runtime reset function. It is missing
>> shutdown functionality today, but OSs usually implement that via ACPI
>> and this function does more than the stub from before, so it's at least
>> an improvement.
>>
>> Signed-off-by: Alexander Graf 
>> ---
>>  drivers/sysreset/sysreset_x86.c | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/sysreset/sysreset_x86.c 
>> b/drivers/sysreset/sysreset_x86.c
>> index 20b958cfd4..efed45ccb7 100644
>> --- a/drivers/sysreset/sysreset_x86.c
>> +++ b/drivers/sysreset/sysreset_x86.c
>> @@ -10,6 +10,29 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +
>> +#ifdef CONFIG_EFI_LOADER
>> +void __efi_runtime EFIAPI efi_reset_system(
>> +enum efi_reset_type reset_type,
>> +efi_status_t reset_status,
>> +unsigned long data_size, void *reset_data)
>> +{
>> +u32 value = 0;
>> +
>> +if (reset_type == EFI_RESET_COLD)
>> +value = SYS_RST | RST_CPU | FULL_RST;
>> +else if (reset_type == EFI_RESET_WARM)
>> +value = SYS_RST | RST_CPU;
>> +
>> +/* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
>> +
>> +if (value)
>> +outb(value, IO_PORT_RESET);
> 
> This does not look ACPI compliant. Shouldn't we read the ACPI table to
> identify the reset register?

There are about 500 different ways to reset the system, CPU, something
on x86. I don't think U-Boot should do anything with ACPI. It's an ACPI
producer, not an ACPI consumer.

> When we do the reset CPUs in several sockets may be running multiple
> cores each. Are all of these stopped via this register? Or do we first
> have to halt all but one core before doing the reset?

I don't know what the reset protocol dictates here. But it probably also
heavily depends on the target platform we're looking at. IIUC this
particular reset is the keyboard controller one which just pulls the
reset line of the primary CPU socket.

I am not aware of any multi-socket targets that U-Boot supports, so it
should work in all of today's cases?

Realistically, I would not expect anyone to care too much about U-Boot
on multi-socket (x86) systems :).


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


Re: [U-Boot] [PATCH v2 1/2] x86: Add efi runtime reset

2019-01-29 Thread Heinrich Schuchardt
On 1/28/19 4:42 PM, Alexander Graf wrote:
> Our selftest will soon test the actual runtime reset function rather than
> the boot time one. For this, we need to ensure that the runtime version
> actually succeeds on x86 to keep our travis tests work.
> 
> So this patch implements an x86 runtime reset function. It is missing
> shutdown functionality today, but OSs usually implement that via ACPI
> and this function does more than the stub from before, so it's at least
> an improvement.
> 
> Signed-off-by: Alexander Graf 
> ---
>  drivers/sysreset/sysreset_x86.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/sysreset/sysreset_x86.c b/drivers/sysreset/sysreset_x86.c
> index 20b958cfd4..efed45ccb7 100644
> --- a/drivers/sysreset/sysreset_x86.c
> +++ b/drivers/sysreset/sysreset_x86.c
> @@ -10,6 +10,29 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#ifdef CONFIG_EFI_LOADER
> +void __efi_runtime EFIAPI efi_reset_system(
> + enum efi_reset_type reset_type,
> + efi_status_t reset_status,
> + unsigned long data_size, void *reset_data)
> +{
> + u32 value = 0;
> +
> + if (reset_type == EFI_RESET_COLD)
> + value = SYS_RST | RST_CPU | FULL_RST;
> + else if (reset_type == EFI_RESET_WARM)
> + value = SYS_RST | RST_CPU;
> +
> + /* TODO EFI_RESET_PLATFORM_SPECIFIC and EFI_RESET_SHUTDOWN */
> +
> + if (value)
> + outb(value, IO_PORT_RESET);

This does not look ACPI compliant. Shouldn't we read the ACPI table to
identify the reset register?

When we do the reset CPUs in several sockets may be running multiple
cores each. Are all of these stopped via this register? Or do we first
have to halt all but one core before doing the reset?

Best regards

Heinrich


> +
> + while (1) { }
> +}
> +#endif
>  
>  static int x86_sysreset_request(struct udevice *dev, enum sysreset_t type)
>  {
> 

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


Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to mmc2 for i.MX8MM

2019-01-29 Thread Lukasz Majewski
Hi Peng,

> Since the SD is usdhc2 and eMMC is usdhc3,

Is this true on all IMX8M boards? Or is it only on the development kit
you do have?

My point is that this shall be setup by DTS aliases or maybe by Kconfig
option.

> this cause mapping problem
> for spl_boot_device. So far hard coded them to correct MMC index, so
> that SD and eMMC boot can work.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/mach-imx/spl.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> index ebd8ff9290..0048832be8 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -147,9 +147,18 @@ u32 spl_boot_device(void)
>   case SD1_BOOT:
>   case MMC1_BOOT:
>   return BOOT_DEVICE_MMC1;
> +#if defined(CONFIG_IMX8MM)
> + case SD2_BOOT:
> + case MMC2_BOOT:
> + return BOOT_DEVICE_MMC1;
> + case SD3_BOOT:
> + case MMC3_BOOT:
> + return BOOT_DEVICE_MMC2;
> +#else
>   case SD2_BOOT:
>   case MMC2_BOOT:
>   return BOOT_DEVICE_MMC2;
> +#endif
>  #endif
>   case NAND_BOOT:
>   return BOOT_DEVICE_NAND;




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpwj2z1Kjr2d.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 16/20] imx8m: fix sd to mmc1 and emmc to mmc2 for i.MX8MM

2019-01-29 Thread Fabio Estevam
On Tue, Jan 29, 2019 at 8:58 PM Lukasz Majewski  wrote:

> Is this true on all IMX8M boards? Or is it only on the development kit
> you do have?
>
> My point is that this shall be setup by DTS aliases or maybe by Kconfig
> option.

Yes, it seems that setting up the alias in the board dts should do the trick.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 10/20] imx8m: add clk support for i.MX8MM

2019-01-29 Thread Lukasz Majewski
Hi Peng,

> Introduce clk implementation for i.MX8MM, including pll configuration,
> pll decoding, ccm configuration.
> 
> Signed-off-by: Peng Fan 
> ---
>  arch/arm/include/asm/arch-imx8m/clock.h|   2 +
>  arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 +++
>  arch/arm/mach-imx/imx8m/Makefile   |   1 +
>  arch/arm/mach-imx/imx8m/clock_imx8mm.c | 866
> +
> arch/arm/mach-imx/imx8m/clock_slice.c  | 461 + 5
> files changed, 1717 insertions(+) create mode 100644
> arch/arm/include/asm/arch-imx8m/clock_imx8mm.h create mode 100644
> arch/arm/mach-imx/imx8m/clock_imx8mm.c

As fair as I see this approach is not similar to the one from Linux
kernel:

https://elixir.bootlin.com/linux/v5.0-rc3/source/drivers/clk/imx/clk-imx8mq.c
or simpler:
https://git.pengutronix.de/cgit/barebox/tree/drivers/clk/imx/clk-imx8mq.c

Also Fabio pointed out in the other mail that we shall stick to Linux
kernel Common Clock Framework.

IMHO we shall add the simple CCF look alike code (I'm going to post
imx6q port in a few days).

> 
> diff --git a/arch/arm/include/asm/arch-imx8m/clock.h
> b/arch/arm/include/asm/arch-imx8m/clock.h index
> 7225c760fe..ead4b8d3dc 100644 ---
> a/arch/arm/include/asm/arch-imx8m/clock.h +++
> b/arch/arm/include/asm/arch-imx8m/clock.h @@ -7,6 +7,8 @@
>  
>  #ifdef CONFIG_IMX8MQ
>  #include 
> +#elif defined(CONFIG_IMX8MM)
> +#include 
>  #else
>  #error "Error no clock.h"
>  #endif
> diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h new file mode 100644
> index 00..305514a4ec
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
> @@ -0,0 +1,387 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2018-2019 NXP
> + *
> + * Peng Fan 
> + */
> +
> +#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
> +#define _ASM_ARCH_IMX8MM_CLOCK_H
> +
> +#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)
> \
> + {   \
> + .rate   =
> (_rate),  \
> + .mdiv   =
> (_m), \
> + .pdiv   =
> (_p), \
> + .sdiv   =
> (_s), \
> + .kdiv   =
> (_k), \
> + }
> +
> +#define LOCK_STATUS  BIT(31)
> +#define LOCK_SEL_MASKBIT(29)
> +#define CLKE_MASKBIT(11)
> +#define RST_MASK BIT(9)
> +#define BYPASS_MASK  BIT(4)
> +#define  MDIV_SHIFT  12
> +#define  MDIV_MASK   GENMASK(21, 12)
> +#define PDIV_SHIFT   4
> +#define PDIV_MASKGENMASK(9, 4)
> +#define SDIV_SHIFT   0
> +#define SDIV_MASKGENMASK(2, 0)
> +#define KDIV_SHIFT   0
> +#define KDIV_MASKGENMASK(15, 0)
> +
> +struct imx_int_pll_rate_table {
> + u32 rate;
> + int mdiv;
> + int pdiv;
> + int sdiv;
> + int kdiv;
> +};
> +
> +enum pll_clocks {
> + ANATOP_ARM_PLL,
> + ANATOP_VPU_PLL,
> + ANATOP_GPU_PLL,
> + ANATOP_SYSTEM_PLL1,
> + ANATOP_SYSTEM_PLL2,
> + ANATOP_SYSTEM_PLL3,
> + ANATOP_AUDIO_PLL1,
> + ANATOP_AUDIO_PLL2,
> + ANATOP_VIDEO_PLL,
> + ANATOP_DRAM_PLL,
> +};
> +
> +enum clk_root_index {
> + ARM_A53_CLK_ROOT= 0,
> + ARM_M4_CLK_ROOT = 1,
> + VPU_A53_CLK_ROOT= 2,
> + GPU3D_CLK_ROOT  = 3,
> + GPU2D_CLK_ROOT  = 4,
> + MAIN_AXI_CLK_ROOT   = 16,
> + ENET_AXI_CLK_ROOT   = 17,
> + NAND_USDHC_BUS_CLK_ROOT = 18,
> + VPU_BUS_CLK_ROOT= 19,
> + DISPLAY_AXI_CLK_ROOT= 20,
> + DISPLAY_APB_CLK_ROOT= 21,
> + DISPLAY_RTRM_CLK_ROOT   = 22,
> + USB_BUS_CLK_ROOT= 23,
> + GPU_AXI_CLK_ROOT= 24,
> + GPU_AHB_CLK_ROOT= 25,
> + NOC_CLK_ROOT= 26,
> + NOC_APB_CLK_ROOT= 27,
> + AHB_CLK_ROOT= 32,
> + IPG_CLK_ROOT= 33,
> + AUDIO_AHB_CLK_ROOT  = 34,
> + MIPI_DSI_ESC_RX_CLK_ROOT= 36,
> + DRAM_SEL_CFG= 48,
> + CORE_SEL_CFG= 49,
> + DRAM_ALT_CLK_ROOT   = 64,
> + DRAM_APB_CLK_ROOT   = 65,
> + VPU_G1_CLK_ROOT = 66,
> + VPU_G2_CLK_ROOT = 67,
> + DISPLAY_DTRC_CLK_ROOT   = 68,
> + DISPLAY_DC8000_CLK_ROOT = 69,
> + PCIE_CTRL_CLK_ROOT  = 70,
> + PCIE_PHY_CLK_ROOT   = 71,
> + PCIE_AUX_CLK_ROOT   = 72,
> + DC_PIXEL_CLK_ROOT   = 73,
> + LCDIF_PIXEL_CLK_ROOT= 74,
> + SAI1_CLK_ROOT   = 75,
> + SAI2_CLK_ROOT   = 76,
> + SAI3_CLK_ROOT   = 77,
> + SAI4_CLK_ROOT   = 

Re: [U-Boot] [RFC 0/3] dm, efi: integrate efi_disk into DM

2019-01-29 Thread Heinrich Schuchardt
On 1/29/19 5:20 PM, Alexander Graf wrote:
> On 01/29/2019 03:59 AM, AKASHI Takahiro wrote:
>> This patch set came from the past discussion[1] on my "removable device
>> support" patch and is intended to be an attempt to integrate efi_disk
>> (more precisely, EFI_BLOCK_IO_PROTOCOL-capable efi object) into u-boot's
>> Driver Model as much seamlessly as possible
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2019-January/354010.html
>>
>> Basic idea is
>> * create UCLASS_PARTITION
>> * enumerate all the partitions when a block device is probed
>> * hook up a creation of UCLASS_BLK or UCLASS_PARTITION device
>>    to efi handler for efi_disk attributes to be properly set up
>>
>> Since this patch is a prototype (or POC, proof-of-concept), the aim here
>> is to discuss further about how in a better shape we will be able to
>> merge the two worlds.
> 
> I like the approach. It seems pretty clean and gives us a smooth
> transition from the split world to a unified all-dm world. Eventually
> the efi object list will just naturally disappear and we can drop all
> calls to add efi object handles.
> 
> 
> Alex
> 
> 

Thanks Takahiro, it is good to have a reference to work on to bring the
worlds together.

I still have some issues:

The implementation lacks the driver binding protocol to handle block
devices that are not discovered by U-Boot but supplied by an EFI driver
or application. I would prefer if the block uclass would provide this
protocol.

In EFI a handle can always be deleted by first stopping all controllers
and then removing all protocols.

The current implementation of partitions tries to use a struct efi_obj
instead of a handle. This is incompatible to the rest of the EFI subsystem.

Best regards

Heinrich


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


Re: [U-Boot] [RFC 2/3] efi_loader: associate BLK/PARTITION device to efi_disk

2019-01-29 Thread Heinrich Schuchardt
On 1/29/19 3:59 AM, AKASHI Takahiro wrote:
> efi_disk_create() will initialize efi_disk attributes for each device,
> either UCLASS_BLK or UCLASS_PARTITION.
> 
> Currently (temporarily), efi_disk_obj structure is embedded into
> blk_desc to hold efi-specific attributes.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  drivers/block/blk-uclass.c |   9 ++
>  drivers/core/device.c  |   3 +
>  include/blk.h  |  24 +
>  include/dm/device.h|   4 +
>  lib/efi_loader/efi_disk.c  | 192 ++---
>  5 files changed, 174 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index d4ca30f23fc1..28c45d724113 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -657,6 +657,9 @@ UCLASS_DRIVER(blk) = {
>   .per_device_platdata_auto_alloc_size = sizeof(struct blk_desc),
>  };
>  
> +/* FIXME */
> +extern int efi_disk_create(struct udevice *dev);
> +
>  U_BOOT_DRIVER(blk_partition) = {
>   .name   = "blk_partition",
>   .id = UCLASS_PARTITION,
> @@ -695,6 +698,12 @@ int blk_create_partitions(struct udevice *parent)
>   part_data->partnum = part;
>   part_data->gpt_part_info = info;
>  
> + ret = efi_disk_create(dev);
> + if (ret) {
> + device_unbind(dev);
> + return ret;
> + }
> +
>   disks++;
>   }
>  
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 0d15e5062b66..8625fccb0dcb 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -67,6 +67,9 @@ static int device_bind_common(struct udevice *parent, const 
> struct driver *drv,
>   dev->parent = parent;
>   dev->driver = drv;
>   dev->uclass = uc;
> +#ifdef CONFIG_EFI_LOADER
> + INIT_LIST_HEAD(>efi_obj.protocols);

This looks like an incomplete initialization of efi_obj. Why don't we
use efi_create_handle.

Why should a device be aware of struct efi_obj? We only need a handle to
install protocols.

> +#endif
>  
>   dev->seq = -1;
>   dev->req_seq = -1;
> diff --git a/include/blk.h b/include/blk.h
> index d0c033aece0f..405f6f790d66 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -8,6 +8,7 @@
>  #define BLK_H
>  
>  #include 
> +#include 
>  
>  #ifdef CONFIG_SYS_64BIT_LBA
>  typedef uint64_t lbaint_t;
> @@ -53,6 +54,26 @@ enum sig_type {
>   SIG_TYPE_COUNT  /* Number of signature types */
>  };
>  
> +/* FIXME */

Fix what?

> +/**
> + * struct efi_disk_obj - EFI disk object
> + *
> + * @ops: EFI disk I/O protocol interface
> + * @media:   block I/O media information
> + * @dp:  device path to the block device
> + * @part:partition
> + * @volume:  simple file system protocol of the partition
> + * @offset:  offset into disk for simple partition
> + */
> +struct efi_disk_obj {
> + struct efi_block_io ops;
> + struct efi_block_io_media media;
> + struct efi_device_path *dp;
> + unsigned int part;
> + struct efi_simple_file_system_protocol *volume;
> + lbaint_t offset;
> +};
> +
>  /*
>   * With driver model (CONFIG_BLK) this is uclass platform data, accessible
>   * with dev_get_uclass_platdata(dev)
> @@ -92,6 +113,9 @@ struct blk_desc {
>* device. Once these functions are removed we can drop this field.
>*/
>   struct udevice *bdev;
> +#ifdef CONFIG_EFI_LOADER
> + struct efi_disk_obj efi_disk;

This must be a handle (i.e. a pointer). Otherwise when the last protocol
is removed we try to free memory that was never malloc'ed.

> +#endif
>  #else
>   unsigned long   (*block_read)(struct blk_desc *block_dev,
> lbaint_t start,
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 27a6d7b9fdb0..121bfb46b1a0 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -12,6 +12,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -146,6 +147,9 @@ struct udevice {
>  #ifdef CONFIG_DEVRES
>   struct list_head devres_head;
>  #endif
> +#ifdef CONFIG_EFI_LOADER
> + struct efi_object efi_obj;
> +#endif
>  };
>  
>  /* Maximum sequence number supported */
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index c037526ad2d0..84fa0ddfba14 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -14,33 +14,6 @@
>  
>  const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
>  
> -/**
> - * struct efi_disk_obj - EFI disk object
> - *
> - * @header:  EFI object header
> - * @ops: EFI disk I/O protocol interface
> - * @ifname:  interface name for block device
> - * @dev_index:   device index of block device
> - * @media:   block I/O media information
> - * @dp:  device path to the block device
> - * @part:partition
> - * @volume:  simple file system protocol of the partition
> - * @offset:  

  1   2   3   >