Re: [U-Boot] [PATCH] drivers:usb:fsl: Return if USB_MAX_CONTROLLER_COUNT is incorrect

[Badola Nikhil]

> -Original Message-
> From: Nikhil Badola [mailto:nikhil.bad...@freescale.com]
> Sent: Tuesday, May 12, 2015 2:58 PM
> To: u-boot@lists.denx.de
> Cc: Badola Nikhil-B46172
> Subject: [PATCH] drivers:usb:fsl: Return if USB_MAX_CONTROLLER_COUNT
> is incorrect
> 
> Return if USB_MAX_CONTROLLER_COUNT hence the index of the controller
> to be initialised is incorrect
> 
> Signed-off-by: Nikhil Badola 
> ---
>  drivers/usb/host/ehci-fsl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index
> ed83eb4..1973e0b 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -76,7 +76,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   break;
>   default:
>   printf("ERROR: wrong controller index!!\n");
> - break;
> + return -1;
>   };
> 
>   *hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
> --
> 1.7.11.7
> 

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

Re: [U-Boot] [PATCH] moveconfig: Add a new --git-ref option

[Masahiro Yamada]

Hi Joe,


2015-05-30 6:23 GMT+09:00 Joe Hershberger :
> This option allows the 'make *_defconfig' step to run against a former
> repo state, while the savedefconfig step runs against the current repo
> state. This is convenient for the case where something in the Kconfig
> has changed such that the defconfig is no longer complete with the new
> Kconfigs. This feature allows the .config to be built assuming those old
> Kconfigs, but then savedefconfig based on the new state of the Kconfigs.
>
> Signed-off-by: Joe Hershberger 


This idea seems nice, but I have some comments about the implementation.



> +defconfig_src_dir = ''
> +
> +if options.git_ref:
> +work_dir = WorkDir()
> +defconfig_src_dir = work_dir.get()
> +cwd = os.getcwd()
> +print 'Cloning git repo for \'make *_defconfig\' step...'

You can use signle quotes without escape sequences inside "...", and vice versa.





> diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py
> index 9e739d8..138f989 100644
> --- a/tools/patman/gitutil.py
> +++ b/tools/patman/gitutil.py
> @@ -61,6 +61,21 @@ def CountCommitsToBranch():
>  patch_count = int(stdout)
>  return patch_count
>
> +def CommitHash(commit_ref):
> +"""Gets the hash for a commit
> +
> +Args:
> +commit_ref: Commit ref to look up
> +
> +Return:
> +Hash of revision, if any, else None
> +"""
> +pipe = ['git', 'rev-parse', '--short', commit_ref]
> +stdout = command.RunPipe([pipe], capture=True, oneline=True).stdout
> +
> +hash = stdout.strip()
> +return hash
> +
>  def NameRevision(commit_hash):
>  """Gets the revision name for a commit



Finally, this tool is going to depend on patman.  I am afraid this
tool is getting messy.

gitutils.py depends on command.py, and then command.py depends on
cros_subprocess.py.

Do you really need to invoke such a chain of libraries
to run a sub-process?


For example, you can get a hash in a single line like this:

subprocess.check_output(['git', 'rev-parse', '--short', 'HEAD'])





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

Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default

[Masahiro Yamada]

Hi Joe,


2015-06-05 2:54 GMT+09:00 Joe Hershberger :
> Hi Masahiro-san,
>
> On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada
>  wrote:
>> Hi.
>>
>>
>> 2015-06-04 7:55 GMT+09:00 Joe Hershberger :
>>> On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini  wrote:
 On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote:
> Hi Tom,
>
> On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini  wrote:
> > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote:
> >
> >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then
> >> needing to have this in every sunxi defconfig file.
> >>
> >> This also fixes the Merrii_A80_Optimus defconfig no longer building.
> >>
> >> Cc: Maxin B. John 
> >> Reported-by: Maxin B. John 
> >> Signed-off-by: Hans de Goede 
> >
> > Joe? Masahiro?  It feels like something has gone wrong with the
> > conversion here.  Or do people need to get used to the defconfig files
> > being a non-trivial size?  Or do we need some more default y if ...
> > lines around things?  Or a few of the above?  Thanks!
>>
>>
>> I think too much (ab)use of "default y if ..." in board Kconfigs is wrong.
>
> I completely agree. I'd like to see them all go away, but maybe that's
> just me. Doing this even causes the help for the option to incorrectly
> indicate where that token is defined - it indicates the first default
> setting inside some arch that's not even yours and not the real
> definition location.

Joe, you are not alone.

I see another problem for adding default entries to board Kconfigs.

If you see commit ece26f623c93afe95821f89d4dd53ae8f3cfa1b6,
you will notice CONFIG_NET=y and CONFIG_NET_RANDOM_ETHADDR=y
were added to separate places in defconfig files.
(Please note the defconfigs were sorted by savedefconfig.)

They should have been lined up together because their real definitions
are placed in net/Kconfig.

At the point when I posted the patch, board/sunxi/Kconfig had the
default setting:

config NET
default y

so savedefconfig put CONFIG_NET=y much earlier than it should be.


Periodical attempt for cleaning defconfigs by savedefconfig comes to nothing
because the order changes every single time someone adds a default
entry into his board Kconfig.



> It seems we should select good defaults. Maybe we should try to agree
> which way we should err. Make u-boot bigger by default, and boards
> that are limited can disable features? Or should we enable commands on
> boards that "need" a feature and keep u-boot slim by default?
>
> I don't like the half measure of defining a different default for one
> platform than another unless it is actually something inherent in the
> platform, and in that case it should be enabled by a "selects" under
> the platform Kconfig.
>
> I agree we want to have smaller defconfigs rather than bigger, but
> there are lots of features and many boards will not agree, so the
> defconfigs of many boards will have to contain something.

 The first thing that pops to mind is that if it used to be in
 config_cmd_default.h it should be on by default and disabled when needed
 (and this means we can be smart about CMD_FLASH / CMD_IMLS).  Otherwise
 we need to think hard on if something new should be on by default or
 not.
>>>
>>> I have the gut feeling that things that depend on hardware existing
>>> (such as CMD_NET) should not be default.  However, I guess if it's
>>> totally ubiquitous (such as CMD_MEMORY - though it's already in
>>> config_cmd_default.h) then it should be default just to shrink the
>>> defconfigs.
>>
>>
>> Even if your board has a network device,
>> you may not want to enable it by default in some cases.
>
> This is the reason for not making it a platform "selects X_FEATURE",
> but defaults are just that.
>
>> Network functions are often useful during development and debugging,
>> but might not for mass-production, for example.
>
> Do you think many (or any) boards are mass-produced based on the
> main-line defconfigs?

No, I think they are mostly for development boards.

Anyway, U-boot without network makes sense.


>>> Ian, you indicated that you thought CMD_NET should be a default since
>>> it is usually wanted. It seems that is generally the case. It looks
>>> like 94% of boards enable CMD_NET, which makes it pretty much
>>> ubiquitous.
>>>
>>> Perhaps that should be the metric for deciding (probably with
>>> flexibility for making an argument to the contrary)... if more that
>>> 80% (good enough water-mark?) of the boards enable a feature, then it
>>> should be the default?  50% would optimize for overall defconfig
>>> size... maybe that's better?
>>
>> The "Ubiquitous" thing is one criteria, but I prefer the best judge
>> for each CONFIG.
>
> It would help to have an idea of the criteria you would use to judge
> it. What do you do you consider important criteria?

I cannot describe it well, but I 

Re: [U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Bin Meng]

Hi Simon,

On Fri, Jun 5, 2015 at 2:31 AM, Simon Glass  wrote:
> Hi,
>
> On 4 June 2015 at 10:27, Andrew Bradford  wrote:
>>
>> Hi Bin,
>>
>> On 06/04 22:21, Bin Meng wrote:
>> > Hi Simon,
>> >
>> > On Thu, Jun 4, 2015 at 8:12 PM, Bin Meng  wrote:
>> > > This is a temparory hacking for testing U-Boot on a newer version
>> > > MinnowMax board.
>> > >
>> > > Signed-off-by: Bin Meng 
>> > > ---
>> > >
>> > >  arch/x86/dts/minnowmax.dts | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
>> > > index 7103bc5..9e1fcfc 100644
>> > > --- a/arch/x86/dts/minnowmax.dts
>> > > +++ b/arch/x86/dts/minnowmax.dts
>> > > @@ -101,7 +101,7 @@
>> > >
>> > > microcode {
>> > > update@0 {
>> > > -#include "microcode/m0130673322.dtsi"
>> > > +#include "microcode/m0130679901.dtsi"
>> > > };
>> > > };
>> > >
>> > > --
>> >
>> > Saket confirmed these two patches resolved the boot problem he saw. So
>> > we will need think about how to better support such scenario that
>> > different revision board with different stepping CPUs. Could be
>> > multiple microcodes in one U-Boot image, or still one microcode with
>> > some #ifdef #endif. Note FSP has the capability to accept multiple
>> > microcodes as parameters in the FspTempRamInit(), but right now U-Boot
>> > only specifies one. How do you think?
>>
>> Why not just have a minnowmax common dtsi and then top level dts files
>> for each revision of the board containing the ways they are different
>> (such as microcode)?
>
> My preference would be to include all the microcode needed by the
> board and then pass the correct one to the FSP. Now that we can access
> the device tree that should be possible. There is logic in
> ./arch/x86/cpu/ivybridge/microcode_intel.c to do this but it may need
> a bit of refactorng.
>

The device tree still cannot be accessed in that early phase before
CAR is initialized. The issue is that FSP is designed to have
FspTempRamInit() to do both microcode loading and CAR initialization.

> The existing microcode approach (with ifdtool adding a pointer to the
> microcode) is a work-around for the FSP problem. Now that Bin has
> solved this I'd be keen to remove it an just use device tree.
>

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

Re: [U-Boot] [PATCH] x86: baytrail: Add BayTrail-I D0 stepping microcode

[Bin Meng]

+Wolfgang, +Tom,

On Thu, Jun 4, 2015 at 8:09 PM, Bin Meng  wrote:
> New microcode for BayTrail-I D0 stepping.
>
> Signed-off-by: Bin Meng 
> ---
>

Looks that this patch is still pending on mailing list admin's
approval as its size exceeds the 100KB limit thus not showing on
patchwork. Wolfgang/Tom, would you take a look at this? Thanks,

>  arch/x86/dts/microcode/m0130679901.dtsi | 3284 
> +++
>  1 file changed, 3284 insertions(+)
>  create mode 100644 arch/x86/dts/microcode/m0130679901.dtsi
>
> diff --git a/arch/x86/dts/microcode/m0130679901.dtsi 
> b/arch/x86/dts/microcode/m0130679901.dtsi
> new file mode 100644
> index 000..110
> --- /dev/null
> +++ b/arch/x86/dts/microcode/m0130679901.dtsi
> @@ -0,0 +1,3284 @@
> +/*
> + * ---
> + * This is a device tree fragment. Use #include to add these properties to a
> + * node.
> + *
> + * Date:
> + */
> +
> +compatible = "intel,microcode";
> +intel,header-version = <1>;
> +intel,update-revision = <0x901>;
> +intel,date-code = <0x4212014>;
> +intel,processor-signature = <0x30679>;
> +intel,checksum = <0x69c4e6f1>;
> +intel,loader-revision = <1>;
> +intel,processor-flags = <0x1>;
> +
> +/* The first 48-bytes are the public header which repeats the above data */
> +data = <

[snip]

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

[U-Boot] [PATCH 6/8] ARM: bootm: allow skipping fdt memory node fixup

[Andre Przywara]

From: Rob Herring 

Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
has correct memory information, then we don't want or need u-boot to touch
the memory node. Allow platforms to skip this by not filling in dram bank
information.

Signed-off-by: Rob Herring 
Signed-off-by: Andre Przywara 
---
 arch/arm/lib/board.c | 2 ++
 arch/arm/lib/bootm-fdt.c | 5 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 37ea6e9..a3c7315 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -191,8 +191,10 @@ typedef int (init_fnc_t) (void);
 
 __weak void dram_init_banksize(void)
 {
+#if CONFIG_NR_DRAM_BANKS
gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
gd->bd->bi_dram[0].size =  gd->ram_size;
+#endif
 }
 
 __weak int arch_cpu_init(void)
diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c
index 7677358..dbf3d56 100644
--- a/arch/arm/lib/bootm-fdt.c
+++ b/arch/arm/lib/bootm-fdt.c
@@ -26,8 +26,10 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int arch_fixup_fdt(void *blob)
 {
+   int ret = 0;
+#if CONFIG_NR_DRAM_BANKS
bd_t *bd = gd->bd;
-   int bank, ret;
+   int bank;
u64 start[CONFIG_NR_DRAM_BANKS];
u64 size[CONFIG_NR_DRAM_BANKS];
 
@@ -42,6 +44,7 @@ int arch_fixup_fdt(void *blob)
}
 
ret = fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
+#endif
 #ifdef CONFIG_ARMV7_NONSEC
if (ret)
return ret;
-- 
1.8.4

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

[U-Boot] [PATCH 7/8] ARM: highbank: remove DRAM bank setup

[Andre Przywara]

From: Rob Herring 

On the highbank platform the SoC's management controller firmware
will probe the DRAM modules and populates the initial device tree with
the correct values. Therefore the memory sizes in are already correct,
so remove U-Boot's DRAM bank setup so the memory node is not "fixed
up" by u-boot.

Signed-off-by: Rob Herring 
Signed-off-by: Andre Przywara 
---
 board/highbank/highbank.c  | 6 --
 include/configs/highbank.h | 2 +-
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index e8132b8..9ebd895 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -93,12 +93,6 @@ int dram_init(void)
return 0;
 }
 
-void dram_init_banksize(void)
-{
-   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-   gd->bd->bi_dram[0].size =  PHYS_SDRAM_1_SIZE;
-}
-
 #if defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *fdt, bd_t *bd)
 {
diff --git a/include/configs/highbank.h b/include/configs/highbank.h
index da1c837..b1d618b 100644
--- a/include/configs/highbank.h
+++ b/include/configs/highbank.h
@@ -83,7 +83,7 @@
 /*---
  * Physical Memory Map
  */
-#define CONFIG_NR_DRAM_BANKS   1
+#define CONFIG_NR_DRAM_BANKS   0
 #define PHYS_SDRAM_1_SIZE  (4089 << 20)
 #define CONFIG_SYS_MEMTEST_START   0x10
 #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1_SIZE - 0x10)
-- 
1.8.4

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

[U-Boot] [PATCH 1/8] ARM: highbank: add missing SCU register setup for reset

[Andre Przywara]

From: Rob Herring 

Andre: assign names to the magic values

Signed-off-by: Rob Herring 
Signed-off-by: Andre Przywara 
---
 board/highbank/highbank.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index ba1beb5..ba254b6 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -14,6 +14,7 @@
 
 #define HB_AHCI_BASE   0xffe08000
 
+#define HB_SCU_A9_PWR_STATUS   0xfff10008
 #define HB_SREG_A9_PWR_REQ 0xfff3cf00
 #define HB_SREG_A9_BOOT_SRC_STAT   0xfff3cf04
 #define HB_SREG_A9_PWRDOM_STAT 0xfff3cf20
@@ -27,6 +28,10 @@
 #define PWRDOM_STAT_PCI0x4000
 #define PWRDOM_STAT_EMMC   0x2000
 
+#define HB_SCU_A9_PWR_NORMAL   0
+#define HB_SCU_A9_PWR_DORMANT  2
+#define HB_SCU_A9_PWR_OFF  3
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /*
@@ -114,6 +119,7 @@ int ft_board_setup(void *fdt, bd_t *bd)
 void reset_cpu(ulong addr)
 {
writel(HB_PWR_HARD_RESET, HB_SREG_A9_PWR_REQ);
+   writeb(HB_SCU_A9_PWR_OFF, HB_SCU_A9_PWR_STATUS);
 
wfi();
 }
-- 
1.8.4

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

[U-Boot] [PATCH 0/8] ARM: highbank: fix Calxeda machines

[Andre Przywara]

This series aims to upstream fixes that have been in the Calxeda
firmware version of U-Boot for ages.
The first two patches fix reset, both for Highbank and Midway.
Patches 3-5 add support for larger hard disks, so U-Boot can now
access sectors from beyond 2 TB on larger disks.
Patch 6 and 7 teach U-Boot not to touch the FDT memory node. The
primary Calxeda firmware detects the amount of memory (it has a DIMM
socket!) at boot time and populates the memory node accordingly.
U-Boot would overwrite the node with a fixed value, most commonly
getting lost of any memory beyond 4 GB on Midway systems. I have been
told that this fix has been disliked before, so I am open to a
discussion on how to address this problem.
The final patch fixes Highbank's SATA setup, which requires some
special care (cf. the sata_highbank.c driver in Linux).

There are actually more patches [1] in the last official firmware, but
most of the others only make sense with some special management
firmware versions that never made it to the light.
I extracted the most useful and important patches from there and
rebased them on top of the current master. With them I can happily
use upstream U-Boot on a Midway system - I haven't had time to test
it on Highbank, though.

Please review, comment and hopefully apply them!

Cheers,
Andre.

[1] 
https://git.linaro.org/people/rob.herring/u-boot.git/shortlog/refs/heads/highbank

Mark Langsdorf (5):
  ARM: highbank: add reset support for Calxeda Midway machine
  cmd_scsi: use lbaint_t for LBA values instead of u32
  ahci: support LBA48 data reads for 2+TB drives
  ahci: extend data io wait to 10s
  highbank: add custom ahci_link_up function

Rob Herring (3):
  ARM: highbank: add missing SCU register setup for reset
  ARM: bootm: allow skipping fdt memory node fixup
  ARM: highbank: remove DRAM bank setup

 arch/arm/lib/board.c   |   2 +
 arch/arm/lib/bootm-fdt.c   |   5 +-
 board/highbank/Makefile|   2 +-
 board/highbank/ahci.c  | 218 +
 board/highbank/highbank.c  |  37 ++--
 common/cmd_scsi.c  |  58 ++--
 drivers/block/ahci.c   |  32 +--
 include/configs/highbank.h |   2 +-
 include/scsi.h |   1 +
 9 files changed, 331 insertions(+), 26 deletions(-)
 create mode 100644 board/highbank/ahci.c

-- 
1.8.4

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

[U-Boot] [PATCH 4/8] ahci: support LBA48 data reads for 2+TB drives

[Andre Przywara]

From: Mark Langsdorf 

Enable full 48-bit LBA48 data reads by passing the upper word of the
LBA block pointer in bytes 9 and 10 of the FIS.

This allows uboot to load data from any arbitrary sector on a drive
with 2 or more TB of available data connected to an AHCI controller.

Signed-off-by: Mark Langsdorf 
Signed-off-by: Andre Przywara 
---
 common/cmd_scsi.c| 44 ++--
 drivers/block/ahci.c | 30 +++---
 include/scsi.h   |  1 +
 3 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index fe705b6..57d6a3f 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -56,6 +56,8 @@ static block_dev_desc_t 
scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
 void scsi_setup_test_unit_ready(ccb * pccb);
 void scsi_setup_read6(ccb * pccb, lbaint_t start, unsigned short blocks);
 void scsi_setup_read_ext(ccb * pccb, lbaint_t start, unsigned short blocks);
+void scsi_setup_read16(ccb * pccb, lbaint_t start, unsigned long blocks);
+
 static void scsi_setup_write_ext(ccb *pccb, lbaint_t start,
unsigned short blocks);
 void scsi_setup_inquiry(ccb * pccb);
@@ -357,7 +359,9 @@ int do_scsi (cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
  * scsi_read
  */
 
-#define SCSI_MAX_READ_BLK 0x /* almost the maximum amount of the scsi_ext 
command.. */
+/* almost the maximum amount of the scsi_ext command.. */
+#define SCSI_MAX_READ_BLK 0x
+#define SCSI_LBA48_READ0xFFF
 
 static ulong scsi_read(int device, lbaint_t blknr, lbaint_t blkcnt,
   void *buffer)
@@ -379,7 +383,14 @@ static ulong scsi_read(int device, lbaint_t blknr, 
lbaint_t blkcnt,
  device, start, blks, (unsigned long)buffer);
do {
pccb->pdata=(unsigned char *)buf_addr;
-   if(blks>SCSI_MAX_READ_BLK) {
+   if (start > SCSI_LBA48_READ) {
+   unsigned long blocks;
+   blocks = min_t(lbaint_t, blks, SCSI_MAX_READ_BLK);
+   pccb->datalen = scsi_dev_desc[device].blksz * blocks;
+   scsi_setup_read16(pccb, start, blocks);
+   start += blocks;
+   blks -= blocks;
+   } else if (blks > SCSI_MAX_READ_BLK) {
pccb->datalen=scsi_dev_desc[device].blksz * 
SCSI_MAX_READ_BLK;
smallblks=SCSI_MAX_READ_BLK;
scsi_setup_read_ext(pccb,start,smallblks);
@@ -579,6 +590,35 @@ void scsi_setup_test_unit_ready(ccb * pccb)
pccb->msgout[0]=SCSI_IDENTIFY; /* NOT USED */
 }
 
+void scsi_setup_read16(ccb * pccb, lbaint_t start, unsigned long blocks)
+{
+   pccb->cmd[0] = SCSI_READ16;
+   pccb->cmd[1] = pccb->lun<<5;
+   pccb->cmd[2] = ((unsigned char) (start >> 56)) & 0xff;
+   pccb->cmd[3] = ((unsigned char) (start >> 48)) & 0xff;
+   pccb->cmd[4] = ((unsigned char) (start >> 40)) & 0xff;
+   pccb->cmd[5] = ((unsigned char) (start >> 32)) & 0xff;
+   pccb->cmd[6] = ((unsigned char) (start >> 24)) & 0xff;
+   pccb->cmd[7] = ((unsigned char) (start >> 16)) & 0xff;
+   pccb->cmd[8] = ((unsigned char) (start >> 8)) & 0xff;
+   pccb->cmd[9] = ((unsigned char) (start)) & 0xff;
+   pccb->cmd[10] = 0;
+   pccb->cmd[11] = ((unsigned char) (blocks >> 24)) & 0xff;
+   pccb->cmd[12] = ((unsigned char) (blocks >> 16)) & 0xff;
+   pccb->cmd[13] = ((unsigned char) (blocks >> 8)) & 0xff;
+   pccb->cmd[14] = (unsigned char) blocks & 0xff;
+   pccb->cmd[15] = 0;
+   pccb->cmdlen = 16;
+   pccb->msgout[0] = SCSI_IDENTIFY; /* NOT USED */
+   debug ("scsi_setup_read16: cmd: %02X %02X "
+  "startblk %02X%02X%02X%02X%02X%02X%02X%02X "
+  "blccnt %02X%02X%02X%02X\n",
+   pccb->cmd[0], pccb->cmd[1],
+   pccb->cmd[2], pccb->cmd[3], pccb->cmd[4], pccb->cmd[5],
+   pccb->cmd[6], pccb->cmd[7], pccb->cmd[8], pccb->cmd[9],
+   pccb->cmd[11], pccb->cmd[12], pccb->cmd[13], pccb->cmd[14]);
+}
+
 void scsi_setup_read_ext(ccb * pccb, lbaint_t start, unsigned short blocks)
 {
pccb->cmd[0]=SCSI_READ10;
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 6508648..28d0b08 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -726,18 +726,25 @@ static int ata_scsiop_inquiry(ccb *pccb)
  */
 static int ata_scsiop_read_write(ccb *pccb, u8 is_write)
 {
-   u32 lba = 0;
+   lbaint_t lba = 0;
u16 blocks = 0;
u8 fis[20];
u8 *user_buffer = pccb->pdata;
u32 user_buffer_size = pccb->datalen;
 
/* Retrieve the base LBA number from the ccb structure. */
-   memcpy(&lba, pccb->cmd + 2, sizeof(lba));
-   lba = be32_to_cpu(lba);
+   if (pccb->cmd[0] == SCSI_READ16) {
+   memcpy(&lba, pccb->cmd + 2, 8);
+   lba = be64_to_cpu(lba);
+ 

[U-Boot] [PATCH 2/8] ARM: highbank: add reset support for Calxeda Midway machine

[Andre Przywara]

From: Mark Langsdorf 

The Calxeda Midway part has A15 cores, which do not have the Highbank
A9's SCU used there for resetting the chip.
Add code to distinguish between the A9 and the A15 and invoke the
appropriate register writes to support the newer part.

Andre: rework detection of Highbank vs. Midway
Rob: fix Andre's reworked detection

Signed-off-by: Mark Langsdorf 
Signed-off-by: Andre Przywara 
Signed-off-by: Rob Herring 
---
 board/highbank/highbank.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index ba254b6..e8132b8 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -18,6 +18,7 @@
 #define HB_SREG_A9_PWR_REQ 0xfff3cf00
 #define HB_SREG_A9_BOOT_SRC_STAT   0xfff3cf04
 #define HB_SREG_A9_PWRDOM_STAT 0xfff3cf20
+#define HB_SREG_A15_PWR_CTRL   0xfff3c200
 
 #define HB_PWR_SUSPEND 0
 #define HB_PWR_SOFT_RESET  1
@@ -116,10 +117,22 @@ int ft_board_setup(void *fdt, bd_t *bd)
 }
 #endif
 
+static int is_highbank(void)
+{
+   uint32_t midr;
+
+   asm volatile ("mrc p15, 0, %0, c0, c0, 0\n" : "=r"(midr));
+
+   return (midr & 0xfff0) == 0xc090;
+}
+
 void reset_cpu(ulong addr)
 {
writel(HB_PWR_HARD_RESET, HB_SREG_A9_PWR_REQ);
-   writeb(HB_SCU_A9_PWR_OFF, HB_SCU_A9_PWR_STATUS);
+   if (is_highbank())
+   writeb(HB_SCU_A9_PWR_OFF, HB_SCU_A9_PWR_STATUS);
+   else
+   writel(0x1, HB_SREG_A15_PWR_CTRL);
 
wfi();
 }
-- 
1.8.4

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

[U-Boot] [PATCH 8/8] highbank: add custom ahci_link_up function

[Andre Przywara]

From: Mark Langsdorf 

The Calxeda highbank SOC needs a custom sequence to bring up SATA links,
so override ahci_link_up with custom function to handle combophy setup.

Signed-off-by: Mark Langsdorf 
Signed-off-by: Richard Gibbs
Signed-off-by: Rob Herring 
Signed-off-by: Andre Przywara 
---
 board/highbank/Makefile   |   2 +-
 board/highbank/ahci.c | 218 ++
 board/highbank/highbank.c |  12 +++
 3 files changed, 231 insertions(+), 1 deletion(-)
 create mode 100644 board/highbank/ahci.c

diff --git a/board/highbank/Makefile b/board/highbank/Makefile
index d3eb232..ce7ee68 100644
--- a/board/highbank/Makefile
+++ b/board/highbank/Makefile
@@ -5,4 +5,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y  := highbank.o
+obj-y  := highbank.o ahci.o
diff --git a/board/highbank/ahci.c b/board/highbank/ahci.c
new file mode 100644
index 000..0015323
--- /dev/null
+++ b/board/highbank/ahci.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright 2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#define CPHY_MAP(dev, addr) dev) & 0x1f) << 7) | (((addr) >> 9) & 0x7f))
+#define CPHY_ADDR(base, dev, addr) ((base) | (((addr) & 0x1ff) << 2))
+#define CPHY_BASE  0xfff58000
+#define CPHY_WIDTH 0x1000
+#define CPHY_DTE_XS5
+#define CPHY_MII   31
+#define SERDES_CR_CTL  0x80a0
+#define SERDES_CR_ADDR 0x80a1
+#define SERDES_CR_DATA 0x80a2
+#define CR_BUSY0x0001
+#define CR_START   0x0001
+#define CR_WR_RDN  0x0002
+#define CPHY_TX_INPUT_STS  0x2001
+#define CPHY_RX_INPUT_STS  0x2002
+#define CPHY_SATA_TX_OVERRIDE_BIT  0x8000
+#define CPHY_SATA_RX_OVERRIDE_BIT  0x4000
+#define CPHY_TX_INPUT_OVERRIDE 0x2004
+#define CPHY_RX_INPUT_OVERRIDE 0x2005
+#define SPHY_LANE  0x100
+#define SPHY_HALF_RATE 0x0001
+#define CPHY_SATA_DPLL_MODE0x0700
+#define CPHY_SATA_DPLL_SHIFT   8
+#define CPHY_SATA_TX_ATTEN 0x1c00
+#define CPHY_SATA_TX_ATTEN_SHIFT   10
+
+#define HB_SREG_SATA_ATTEN 0xfff3cf24
+
+#define SATA_PORT_BASE 0xffe08000
+#define SATA_VERSIONR  0xf8
+#define SATA_HB_VERSION0x3332302a
+
+static u32 __combo_phy_reg_read(u8 phy, u8 dev, u32 addr)
+{
+   u32 data;
+   writel(CPHY_MAP(dev, addr), CPHY_BASE + 0x800 + CPHY_WIDTH * phy);
+   data = readl(CPHY_ADDR(CPHY_BASE + CPHY_WIDTH * phy, dev, addr));
+   return data;
+}
+
+static void __combo_phy_reg_write(u8 phy, u8 dev, u32 addr, u32 data)
+{
+   writel(CPHY_MAP(dev, addr), CPHY_BASE + 0x800 + CPHY_WIDTH * phy);
+   writel(data, CPHY_ADDR(CPHY_BASE + CPHY_WIDTH * phy, dev, addr));
+}
+
+static u32 combo_phy_read(u8 phy, u32 addr)
+{
+   u8 dev = CPHY_DTE_XS;
+   if (phy == 5)
+   dev = CPHY_MII;
+   while (__combo_phy_reg_read(phy, dev, SERDES_CR_CTL) & CR_BUSY)
+   udelay(5);
+   __combo_phy_reg_write(phy, dev, SERDES_CR_ADDR, addr);
+   __combo_phy_reg_write(phy, dev, SERDES_CR_CTL, CR_START);
+   while (__combo_phy_reg_read(phy, dev, SERDES_CR_CTL) & CR_BUSY)
+   udelay(5);
+   return __combo_phy_reg_read(phy, dev, SERDES_CR_DATA);
+}
+
+static void combo_phy_write(u8 phy, u32 addr, u32 data)
+{
+   u8 dev = CPHY_DTE_XS;
+   if (phy == 5)
+   dev = CPHY_MII;
+   while (__combo_phy_reg_read(phy, dev, SERDES_CR_CTL) & CR_BUSY)
+   udelay(5);
+   __combo_phy_reg_write(phy, dev, SERDES_CR_ADDR, addr);
+   __combo_phy_reg_write(phy, dev, SERDES_CR_DATA, data);
+   __combo_phy_reg_write(phy, dev, SERDES_CR_CTL, CR_WR_RDN | CR_START);
+}
+
+static void cphy_spread_spectrum_override(u8 phy, u8 lane, u32 val)
+{
+   u32 tmp;
+   tmp = combo_phy_read(phy, CPHY_RX_INPUT_STS + lane * SPHY_LANE);
+   tmp &= ~CPHY_SATA_RX_OVERRIDE_BIT;
+   combo_phy_write(phy, CPHY_RX_INPUT_OVERRIDE + lane * SPHY_LANE, tmp);
+
+   tmp |= CPHY_SATA_RX_OVERRIDE_BIT;
+   combo_phy_write(phy, CPHY_RX_INPUT_OVERRIDE + lane * SPHY_LANE, tmp);
+
+   tmp &= ~CPHY_SATA_DPLL_MODE;
+

[U-Boot] [PATCH 5/8] ahci: extend data io wait to 10s

[Andre Przywara]

From: Mark Langsdorf 

The AHCI driver currently waits 5s before timing out when sending a
data command to a drive. Some drives take upwards of 8s to respond to
the initial data command while they're spinning up. Increase the
data io timeout to 10s so that those drives can be found on initial
scsi scan.

Signed-off-by: Mark Langsdorf 
Signed-off-by: Andre Przywara 
---
 drivers/block/ahci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 28d0b08..eb22586 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -39,7 +39,7 @@ u16 *ataid[AHCI_MAX_PORTS];
 
 /* Maximum timeouts for each event */
 #define WAIT_MS_SPINUP 2
-#define WAIT_MS_DATAIO 5000
+#define WAIT_MS_DATAIO 1
 #define WAIT_MS_FLUSH  5000
 #define WAIT_MS_LINKUP 200
 
-- 
1.8.4

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

[U-Boot] [PATCH 3/8] cmd_scsi: use lbaint_t for LBA values instead of u32

[Andre Przywara]

From: Mark Langsdorf 

Signed-off-by: Mark Langsdorf 
Signed-off-by: Andre Przywara 
---
 common/cmd_scsi.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index f80f549..fe705b6 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -54,10 +54,10 @@ static block_dev_desc_t 
scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
  *  forward declerations of some Setup Routines
  */
 void scsi_setup_test_unit_ready(ccb * pccb);
-void scsi_setup_read6(ccb * pccb, unsigned long start, unsigned short blocks);
-void scsi_setup_read_ext(ccb * pccb, unsigned long start, unsigned short 
blocks);
-static void scsi_setup_write_ext(ccb *pccb, unsigned long start,
- unsigned short blocks);
+void scsi_setup_read6(ccb * pccb, lbaint_t start, unsigned short blocks);
+void scsi_setup_read_ext(ccb * pccb, lbaint_t start, unsigned short blocks);
+static void scsi_setup_write_ext(ccb *pccb, lbaint_t start,
+   unsigned short blocks);
 void scsi_setup_inquiry(ccb * pccb);
 void scsi_ident_cpy (unsigned char *dest, unsigned char *src, unsigned int 
len);
 
@@ -579,7 +579,7 @@ void scsi_setup_test_unit_ready(ccb * pccb)
pccb->msgout[0]=SCSI_IDENTIFY; /* NOT USED */
 }
 
-void scsi_setup_read_ext(ccb * pccb, unsigned long start, unsigned short 
blocks)
+void scsi_setup_read_ext(ccb * pccb, lbaint_t start, unsigned short blocks)
 {
pccb->cmd[0]=SCSI_READ10;
pccb->cmd[1]=pccb->lun<<5;
@@ -599,7 +599,7 @@ void scsi_setup_read_ext(ccb * pccb, unsigned long start, 
unsigned short blocks)
pccb->cmd[7],pccb->cmd[8]);
 }
 
-void scsi_setup_write_ext(ccb *pccb, unsigned long start, unsigned short 
blocks)
+void scsi_setup_write_ext(ccb *pccb, lbaint_t start, unsigned short blocks)
 {
pccb->cmd[0] = SCSI_WRITE10;
pccb->cmd[1] = pccb->lun << 5;
@@ -620,7 +620,7 @@ void scsi_setup_write_ext(ccb *pccb, unsigned long start, 
unsigned short blocks)
  pccb->cmd[7], pccb->cmd[8]);
 }
 
-void scsi_setup_read6(ccb * pccb, unsigned long start, unsigned short blocks)
+void scsi_setup_read6(ccb * pccb, lbaint_t start, unsigned short blocks)
 {
pccb->cmd[0]=SCSI_READ6;
pccb->cmd[1]=pccb->lun<<5 | (((unsigned char)(start>>16))&0x1f);
-- 
1.8.4

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

Re: [U-Boot] [PATCH v2 00/18] dm: Introduce device tree support in SPL (for Rockchip)

[Simon Glass]

Hi Tom,

On 12 May 2015 at 14:55, Simon Glass  wrote:
> With driver model SPL support in place the remaining driver difference
> between U-Boot proper and SPL is that SPL does not support device tree.
> This series adds this support, using a Rockchip board as an example.

I'd like to apply some of these - they are assigned to you in
patchwork. I need to be a little careful with the device tree SPL
change to make sure it does not affect any existing boards (and do a
final test with the boards I have). Is this OK with you or would you
prefer to apply some yourself?

For now I don't want to apply all the Rockchip patches, as I have a
much more functional port now and want to avoid churn. I'll tidy those
patches up and see how we get them applied later.

[snip]

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

[U-Boot] [PATCH] spi: cf_qspi: fix clamp macro type check compilation warnings

[Angelo Dureghello]

Fix clamp macro redefined warning, and clamp type check warnings.

Signed-off-by: Angelo Dureghello 
---
 drivers/spi/cf_qspi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/cf_qspi.c b/drivers/spi/cf_qspi.c
index 834c5bd..c4bafe0 100644
--- a/drivers/spi/cf_qspi.c
+++ b/drivers/spi/cf_qspi.c
@@ -19,7 +19,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define clamp(x, low, high) (min(max(low, x), high))
 #define to_cf_qspi_slave(s) container_of(s, struct cf_qspi_slave, slave)
 
 struct cf_qspi_slave {
@@ -119,7 +118,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
if (max_hz == 0) /* Go as fast as possible */
dev->qmr = 2u;
else /* Get the closest baud rate */
-   dev->qmr = clamp(((gd->bus_clk >> 2) + max_hz - 1)/max_hz,
+   dev->qmr = clamp_val(((gd->bus_clk >> 2) + max_hz - 1)/max_hz,
2u, 255u);
 
/* Map mode to QMR[CPOL] and QMR[CPHA] */
-- 
2.1.4


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

Re: [U-Boot] [PATCH v2 3/3] x86: fsp: Move FspInitEntry call to board_init_f()

[Andrew Bradford]

On 06/04 18:28, Bin Meng wrote:
> The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
> It worked pretty well but looks not that good. Apart from doing too
> much work than just enabling CAR, it cannot read the configuration
> data from device tree at that time. Now we want to move it a little
> bit later as part of init_sequence_f[] being called by board_init_f().
> This way it looks and works better in the U-Boot initialization path.
> 
> Due to FSP's design, after calling FspInitEntry it will not return to
> its caller, instead it jumps to a continuation function which is given
> by bootloader with a new stack in system memory. The original stack in
> the CAR is gone, but its content is perserved by FSP and described by
> a bootloader temporary memory HOB. Technically we can recover anything
> we had before in the previous stack, but that is way too complicated.
> To make life much easier, in the FSP continuation routine we just
> simply call fsp_init_done() and jump back to car_init_ret() to redo
> the whole board_init_f() initialization, but this time with a non-zero
> HOB list pointer saved in U-Boot's global data so that we can bypass
> the FspInitEntry for the second time.
> 
> Signed-off-by: Bin Meng 
> Acked-by: Simon Glass 
> Tested-by: Andrew Bradford 
> 
> ---
> 
> Changes in v2: None
> 
>  arch/x86/cpu/start.S  |  6 +-
>  arch/x86/include/asm/u-boot-x86.h |  4 
>  arch/x86/lib/fsp/fsp_car.S| 26 +-
>  arch/x86/lib/fsp/fsp_common.c |  8 
>  common/board_f.c  |  3 +++
>  5 files changed, 25 insertions(+), 22 deletions(-)

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

Re: [U-Boot] [PATCH v2 2/3] x86: fsp: Load GDT before calling FspInitEntry

[Andrew Bradford]

On 06/04 18:28, Bin Meng wrote:
> Currently the FSP execution environment GDT is setup by U-Boot in
> arch/x86/cpu/start16.S, which works pretty well. But if we try to
> move the FspInitEntry call a little bit later to better fit into
> U-Boot's initialization sequence, FSP will fail to bring up the AP
> due to #GP fault as AP's GDT is duplicated from BSP whose GDT is
> now moved into CAR, and unfortunately FSP calls AP initialization
> after it disables the CAR. So basically the BSP's GDT still refers
> to the one in the CAR, whose content is no longer available, so
> when AP starts up and loads its segment register, it blows up.
> 
> To resolve this, we load GDT before calling into FspInitEntry.
> The GDT is the same one used in arch/x86/cpu/start16.S, which is
> in the ROM and exists forever.
> 
> Signed-off-by: Bin Meng 
> 
> ---
> 
> Changes in v2:
> - Use CONFIG_RESET_SEG_START to avoid duplication
> 
>  arch/x86/cpu/cpu.c| 20 
>  arch/x86/cpu/start16.S|  1 +
>  arch/x86/include/asm/u-boot-x86.h |  3 +++
>  arch/x86/lib/fsp/fsp_support.c|  3 +++
>  4 files changed, 27 insertions(+)

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

Re: [U-Boot] [PATCH v2 1/3] x86: Add Kconfig options to be used by arch/x86/cpu/config.mk

[Andrew Bradford]

On 06/04 18:28, Bin Meng wrote:
> Add RESET_SEG_START, RESET_SEG_SIZE and RESET_VEC_LOC Kconfig options
> and make arch/x86/cpu/config.mk use these options.
> 
> Signed-off-by: Bin Meng 
> 
> ---
> 
> Changes in v2:
> - New patch to add Kconfig options to be used by arch/x86/cpu/config.mk
> 
>  arch/x86/Kconfig   | 15 +++
>  arch/x86/cpu/config.mk |  6 +++---
>  2 files changed, 18 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Simon Glass]

Hi,

On 4 June 2015 at 10:27, Andrew Bradford  wrote:
>
> Hi Bin,
>
> On 06/04 22:21, Bin Meng wrote:
> > Hi Simon,
> >
> > On Thu, Jun 4, 2015 at 8:12 PM, Bin Meng  wrote:
> > > This is a temparory hacking for testing U-Boot on a newer version
> > > MinnowMax board.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  arch/x86/dts/minnowmax.dts | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
> > > index 7103bc5..9e1fcfc 100644
> > > --- a/arch/x86/dts/minnowmax.dts
> > > +++ b/arch/x86/dts/minnowmax.dts
> > > @@ -101,7 +101,7 @@
> > >
> > > microcode {
> > > update@0 {
> > > -#include "microcode/m0130673322.dtsi"
> > > +#include "microcode/m0130679901.dtsi"
> > > };
> > > };
> > >
> > > --
> >
> > Saket confirmed these two patches resolved the boot problem he saw. So
> > we will need think about how to better support such scenario that
> > different revision board with different stepping CPUs. Could be
> > multiple microcodes in one U-Boot image, or still one microcode with
> > some #ifdef #endif. Note FSP has the capability to accept multiple
> > microcodes as parameters in the FspTempRamInit(), but right now U-Boot
> > only specifies one. How do you think?
>
> Why not just have a minnowmax common dtsi and then top level dts files
> for each revision of the board containing the ways they are different
> (such as microcode)?

My preference would be to include all the microcode needed by the
board and then pass the correct one to the FSP. Now that we can access
the device tree that should be possible. There is logic in
./arch/x86/cpu/ivybridge/microcode_intel.c to do this but it may need
a bit of refactorng.

The existing microcode approach (with ifdtool adding a pointer to the
microcode) is a work-around for the FSP problem. Now that Bin has
solved this I'd be keen to remove it an just use device tree.

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

Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default

[Joe Hershberger]

Hi Masahiro-san,

On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada
 wrote:
> Hi.
>
>
> 2015-06-04 7:55 GMT+09:00 Joe Hershberger :
>> On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini  wrote:
>>> On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote:
 Hi Tom,

 On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini  wrote:
 > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote:
 >
 >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then
 >> needing to have this in every sunxi defconfig file.
 >>
 >> This also fixes the Merrii_A80_Optimus defconfig no longer building.
 >>
 >> Cc: Maxin B. John 
 >> Reported-by: Maxin B. John 
 >> Signed-off-by: Hans de Goede 
 >
 > Joe? Masahiro?  It feels like something has gone wrong with the
 > conversion here.  Or do people need to get used to the defconfig files
 > being a non-trivial size?  Or do we need some more default y if ...
 > lines around things?  Or a few of the above?  Thanks!
>
>
> I think too much (ab)use of "default y if ..." in board Kconfigs is wrong.

I completely agree. I'd like to see them all go away, but maybe that's
just me. Doing this even causes the help for the option to incorrectly
indicate where that token is defined - it indicates the first default
setting inside some arch that's not even yours and not the real
definition location.

 It seems we should select good defaults. Maybe we should try to agree
 which way we should err. Make u-boot bigger by default, and boards
 that are limited can disable features? Or should we enable commands on
 boards that "need" a feature and keep u-boot slim by default?

 I don't like the half measure of defining a different default for one
 platform than another unless it is actually something inherent in the
 platform, and in that case it should be enabled by a "selects" under
 the platform Kconfig.

 I agree we want to have smaller defconfigs rather than bigger, but
 there are lots of features and many boards will not agree, so the
 defconfigs of many boards will have to contain something.
>>>
>>> The first thing that pops to mind is that if it used to be in
>>> config_cmd_default.h it should be on by default and disabled when needed
>>> (and this means we can be smart about CMD_FLASH / CMD_IMLS).  Otherwise
>>> we need to think hard on if something new should be on by default or
>>> not.
>>
>> I have the gut feeling that things that depend on hardware existing
>> (such as CMD_NET) should not be default.  However, I guess if it's
>> totally ubiquitous (such as CMD_MEMORY - though it's already in
>> config_cmd_default.h) then it should be default just to shrink the
>> defconfigs.
>
>
> Even if your board has a network device,
> you may not want to enable it by default in some cases.

This is the reason for not making it a platform "selects X_FEATURE",
but defaults are just that.

> Network functions are often useful during development and debugging,
> but might not for mass-production, for example.

Do you think many (or any) boards are mass-produced based on the
main-line defconfigs?

>> Ian, you indicated that you thought CMD_NET should be a default since
>> it is usually wanted. It seems that is generally the case. It looks
>> like 94% of boards enable CMD_NET, which makes it pretty much
>> ubiquitous.
>>
>> Perhaps that should be the metric for deciding (probably with
>> flexibility for making an argument to the contrary)... if more that
>> 80% (good enough water-mark?) of the boards enable a feature, then it
>> should be the default?  50% would optimize for overall defconfig
>> size... maybe that's better?
>
> The "Ubiquitous" thing is one criteria, but I prefer the best judge
> for each CONFIG.

It would help to have an idea of the criteria you would use to judge
it. What do you do you consider important criteria?

> I think the default value should be well-reviewed, because once we
> decide the default y (or n)
> it is hard to invert it later.

It is actually easy now with my new patch to moveconfig:
https://patchwork.ozlabs.org/patch/478053/

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

Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default

[Masahiro Yamada]

Hi.


2015-06-04 7:55 GMT+09:00 Joe Hershberger :
> On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini  wrote:
>> On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote:
>>> Hi Tom,
>>>
>>> On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini  wrote:
>>> > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote:
>>> >
>>> >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then
>>> >> needing to have this in every sunxi defconfig file.
>>> >>
>>> >> This also fixes the Merrii_A80_Optimus defconfig no longer building.
>>> >>
>>> >> Cc: Maxin B. John 
>>> >> Reported-by: Maxin B. John 
>>> >> Signed-off-by: Hans de Goede 
>>> >
>>> > Joe? Masahiro?  It feels like something has gone wrong with the
>>> > conversion here.  Or do people need to get used to the defconfig files
>>> > being a non-trivial size?  Or do we need some more default y if ...
>>> > lines around things?  Or a few of the above?  Thanks!


I think too much (ab)use of "default y if ..." in board Kconfigs is wrong.



>>> It seems we should select good defaults. Maybe we should try to agree
>>> which way we should err. Make u-boot bigger by default, and boards
>>> that are limited can disable features? Or should we enable commands on
>>> boards that "need" a feature and keep u-boot slim by default?
>>>
>>> I don't like the half measure of defining a different default for one
>>> platform than another unless it is actually something inherent in the
>>> platform, and in that case it should be enabled by a "selects" under
>>> the platform Kconfig.
>>>
>>> I agree we want to have smaller defconfigs rather than bigger, but
>>> there are lots of features and many boards will not agree, so the
>>> defconfigs of many boards will have to contain something.
>>
>> The first thing that pops to mind is that if it used to be in
>> config_cmd_default.h it should be on by default and disabled when needed
>> (and this means we can be smart about CMD_FLASH / CMD_IMLS).  Otherwise
>> we need to think hard on if something new should be on by default or
>> not.
>
> I have the gut feeling that things that depend on hardware existing
> (such as CMD_NET) should not be default.  However, I guess if it's
> totally ubiquitous (such as CMD_MEMORY - though it's already in
> config_cmd_default.h) then it should be default just to shrink the
> defconfigs.


Even if your board has a network device,
you may not want to enable it by default in some cases.

Network functions are often useful during development and debugging,
but might not for mass-production, for example.


> Ian, you indicated that you thought CMD_NET should be a default since
> it is usually wanted. It seems that is generally the case. It looks
> like 94% of boards enable CMD_NET, which makes it pretty much
> ubiquitous.
>
> Perhaps that should be the metric for deciding (probably with
> flexibility for making an argument to the contrary)... if more that
> 80% (good enough water-mark?) of the boards enable a feature, then it
> should be the default?  50% would optimize for overall defconfig
> size... maybe that's better?

The "Ubiquitous" thing is one criteria, but I prefer the best judge
for each CONFIG.
I think the default value should be well-reviewed, because once we
decide the default y (or n)
it is hard to invert it later.



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

Re: [U-Boot] [PATCH] ARM: phytec: pcm051: select board revision by Kconfig

[Masahiro Yamada]

Hi.

Sorry for my late reply.

2015-06-04 17:07 GMT+09:00 Lars Poeschel :
> On Wed, Jun 03, 2015 at 11:20:25AM -0400, Tom Rini wrote:
>> On Wed, Jun 03, 2015 at 04:36:06PM +0200, Lars Poeschel wrote:
>> > On Tue, Jun 02, 2015 at 10:34:34AM -0400, Tom Rini wrote:
>> > > On Mon, Jun 01, 2015 at 05:09:11PM +0200, poesc...@lemonage.de wrote:
>> > >
>> > > > From: Lars Poeschel 
>> > > >
>> > > > This add a Kconfig entry that allows to set the board revision in
>> > > > menuconfig. So the deprecated CONFIG_SYS_EXTRA_OPTIONS is no longer
>> > > > needed for this boad.
>> > > >
>> > > > Signed-off-by: Lars Poeschel 
>> > >
>> > > I like the concept but CONFIG_REVx is way too generic.  Can we maybe
>> > > re-work things as CONFIG_TARGET_PCM051_REV1 / CONFIG_TARGET_PCM051_REV3
>> > > (and those select CONFIG_TARGET_PCM051) ?  Masahiro?  Thanks!
>> >
>> > Agree: CONFIG_REVx is too generic. I will send a version 2 of the patch,
>> > but I don't understand why you want CONFIG_TARGET_PCM051_REV1 /
>> > CONFIG_TARGET_PCM051_REV3 to select CONFIG_TARGET_PCM051. The
>> > CONFIG_TARGET_PCM051_REVx's are inside an
>> >
>> > if TARGET_PCM051
>> > ...
>> > endif
>> >
>> > That means, that CONFIG_TARGET_PCM051 must already be selected to make
>> > the *_REVx's visible and selectable.
>>
>> Right.  I mean since we must select one of these boards at build-time,
>> why not just ask about them up-front in arch/arm/Kconfig as rev1/rev3,
>
> I wanted the initial list you choose your board from not to grow too
> big. The (unsorted) list you scroll in menuconfig is already huge! I
> like the aproach "Atmel AT91" takes more, and I'd propably even go
> one step further an select a manufacturer as a first step and then
> in a second step select a specific board from this manufacturer.

Right.
Refactoring arch/arm/Kconfig is still under way.

I think the biggest part of the remainder is Freescale boards.


> But if you prefer the other way - no problem. I tried that:
>
>> and then have the main symbol be a hidden one, ie roughly:
>>
>> config TARGET_PCM051
>>   bool
>>
>> config TARGET_PCM051_REV1
>>   bool "Enable pcm051 rev1"
>>   select TARGET_PCM051
>>   help
>> ...
>>
>> config TARGET_PCM051_REV3
>>   bool "Enable pcm051 rev3"
>>   select TARGET_PCM051
>>   help
>> ...
>
> I could not get this approach to work. It seems Kconfig does not support
> hidden config options. I took a slightly different approach. I'll send a
> PATCH V2 in a second. Please have a look, if that is what what you mean.


Why do we need to "select" the board?

The problem here is that CONFIG_REV1/_REV3 are too generic,
so I think just renaming them into CONFIG_PCM051_REV1/_REV3 is enough
and better.



choice
prompt "pcm051 revision select"
default REV3

config PCM051_REV1
   bool "pcm051 revision 1 or 2"
   help
 If you have 1358.1 written on the pcb of your pcm051, you
 have a revision 1 board. Likewise if you have 1358.2 on your
 board, it is a revision 2 board and this entry is for you.

config PCM051_REV3
   bool "pcm051 revision 3"
   help
 If you have 1358.3 written on the pcb of your pcm051, you
 have a revision 3 board and you have to select this entry.

endchoice




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

[U-Boot] BTRFS support in u-boot?

[Joakim Tjernlund]

I have seen btrfs patches for u-boot flying around a year ago or so then
it went silent. Is there any efforts ongoing to add btrfs support to u-boot?

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

Re: [U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Andrew Bradford]

Hi Bin,

On 06/04 22:21, Bin Meng wrote:
> Hi Simon,
> 
> On Thu, Jun 4, 2015 at 8:12 PM, Bin Meng  wrote:
> > This is a temparory hacking for testing U-Boot on a newer version
> > MinnowMax board.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  arch/x86/dts/minnowmax.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
> > index 7103bc5..9e1fcfc 100644
> > --- a/arch/x86/dts/minnowmax.dts
> > +++ b/arch/x86/dts/minnowmax.dts
> > @@ -101,7 +101,7 @@
> >
> > microcode {
> > update@0 {
> > -#include "microcode/m0130673322.dtsi"
> > +#include "microcode/m0130679901.dtsi"
> > };
> > };
> >
> > --
> 
> Saket confirmed these two patches resolved the boot problem he saw. So
> we will need think about how to better support such scenario that
> different revision board with different stepping CPUs. Could be
> multiple microcodes in one U-Boot image, or still one microcode with
> some #ifdef #endif. Note FSP has the capability to accept multiple
> microcodes as parameters in the FspTempRamInit(), but right now U-Boot
> only specifies one. How do you think?

Why not just have a minnowmax common dtsi and then top level dts files
for each revision of the board containing the ways they are different
(such as microcode)?

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

Re: [U-Boot] [PATCH v2 00/16] tegra: Expand Nyan-big support

[Tom Warren]

Simon,

Tried applying your patchset. Two or three had minor 'git am' conflicts that 
were easy to resolve with 'patch', but #11 (tegra: Allow board-specific init) 
conflicts with Mashiro's move of board.c to board2.c in mach-tegra:

Author: Masahiro Yamada 
Date:   Mon Apr 13 10:51:14 2015 +0900

ARM: tegra: move NVIDIA common files to arch/arm/mach-tegra

Please rebase your patches against current TOT u-boot-tegra/master and let me 
know when they're up on patchwork and I'll retry.

Thanks,

Tom

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Thursday, June 04, 2015 8:46 AM
> To: Tom Warren
> Cc: U-Boot Mailing List; Jagannadha Sutradharudu Teki; Stephen Warren;
> Marek Vasut; Pavel Herrmann; Stephen Warren
> Subject: Re: [PATCH v2 00/16] tegra: Expand Nyan-big support
> 
> Hi Tom,
> 
> On 4 June 2015 at 09:42, Tom Warren  wrote:
> >
> > Sorry, I've been busy with T210 stuff. I'll try to take a look at it before 
> > the
> EOW.
> >
> 
> Great to see progress on T210.
> 
> > IIRC, there was some push-back from Stephen on boot scripts, etc. Have
> these concerns all been addressed? Have you gotten Acks?
> >
> 
> No the boot script patch is the one that should be left out. I talked to 
> Stephen
> about it - there are some things we could do, but not in the timeframe of this
> release.
> 
> Regards,
> Simon
> 
> > Tom
> >
> > > -Original Message-
> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
> > > Glass
> > > Sent: Thursday, June 04, 2015 8:16 AM
> > > To: U-Boot Mailing List
> > > Cc: Simon Glass; Tom Warren; Jagannadha Sutradharudu Teki; Stephen
> > > Warren; Marek Vasut; Pavel Herrmann; Stephen Warren
> > > Subject: Re: [PATCH v2 00/16] tegra: Expand Nyan-big support
> > >
> > > Hi Tom,
> > >
> > > On 13 May 2015 at 07:45, Simon Glass  wrote:
> > > > This series expands Nyan-big support:
> > > >
> > > > - Enable Chrome OS EC, so that the keyboard works
> > > > - Add some extra clock and pre-kernel init required for reliable
> > > > operation
> > > > - Add Chrome OS environment variables, including 'run nvboot' to
> > > > allow booting Chrome OS more easily
> > > >
> > > > Still missing are audio and USB.
> > > >
> > > > Changes in v2:
> > > > - Use spi-max-frequency in both the bus and slave nodes
> > > > - Remove unnecessary ODMDATA mangling
> > > > - Use existing __stringify() macro
> > > > - Drop tegra timer patch as it is not needed
> > > > - Drop a few patches that have already been applied
> > > >
> > > > Doug Anderson (1):
> > > >   Add Chrome OS config header
> > >
> > > Apart from the above patch, can this series be applied please?
> > >
> > > >
> > > > Simon Glass (15):
> > > >   tegra: cros_ec: Add tegra support for Chrome OS EC
> > > >   tegra: spi: Drop the claim_bus() method to correct delays
> > > >   dm: tegra: cros_ec: Enable Chrome OS EC on Nyan-big
> > > >   tegra: spi: Support slow SPI rates
> > > >   tegra: clock: Support enabling external clocks
> > > >   tegra: clock: Adjust PLL access to avoid a warning
> > > >   tegra: Introduce SRAM repair on tegra124
> > > >   tegra: Add missing tegra124 peripherals
> > > >   tegra: Increase maximum arguments to 32
> > > >   tegra: lcd: Tidy up clock init
> > > >   tegra: Allow board-specific init
> > > >   tegra: nyan-big: Add additional clock and kernel init
> > > >   tegra: config: Allow Chrome OS environment settings to be included
> > > >   tegra: Replace 'Norrin' with 'Nyan-big' and fix typo
> > > >   tegra: config: nyan-big: Add options required by Chrome OS boot
> > > >
> > > >  arch/arm/dts/tegra124-nyan-big.dts|   3 +
> > > >  arch/arm/include/asm/arch-tegra/clock.h   |   8 +
> > > >  arch/arm/include/asm/arch-tegra/sys_proto.h   |   7 +
> > > >  arch/arm/include/asm/arch-tegra124/clock-tables.h |  12 +-
> > > >  arch/arm/include/asm/arch-tegra124/flow.h |  12 +
> > > >  arch/arm/mach-tegra/clock.c   |  24 +-
> > > >  arch/arm/mach-tegra/powergate.c   |  20 +-
> > > >  arch/arm/mach-tegra/tegra124/Kconfig  |   2 +-
> > > >  arch/arm/mach-tegra/tegra124/clock.c  |   2 +-
> > > >  board/nvidia/common/board.c   |   8 +-
> > > >  board/nvidia/nyan-big/MAINTAINERS |   2 +-
> > > >  board/nvidia/nyan-big/nyan-big.c  |  69 
> > > >  configs/nyan-big_defconfig|   5 +
> > > >  drivers/spi/tegra114_spi.c|  40 +-
> > > >  drivers/video/tegra124/tegra124-lcd.c |   4 +-
> > > >  include/configs/chromeos.h| 457
> ++
> > > >  include/configs/nyan-big.h|   9 +
> > > >  include/configs/tegra-common-post.h   |  15 +-
> > > >  include/configs/tegra-common.h|   2 +-
> > > >  19 files changed, 663 insertions(+), 38 deletions(-)  create mode
> > 

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Saket Sinha]

Hi Bin,

>> After applying both the patches, I am able to get the u-boot prompt
>> with u-boot.rom .
>> Thanks for these wonderful patches.
>
> This is good news! I believe you can continue your work for the ACPI
> support now :)

Sure. Thanks a lot for making this possible.

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

Re: [U-Boot] [PATCH v2 00/16] tegra: Expand Nyan-big support

[Simon Glass]

Hi Tom,

On 4 June 2015 at 09:42, Tom Warren  wrote:
>
> Sorry, I've been busy with T210 stuff. I'll try to take a look at it before 
> the EOW.
>

Great to see progress on T210.

> IIRC, there was some push-back from Stephen on boot scripts, etc. Have these 
> concerns all been addressed? Have you gotten Acks?
>

No the boot script patch is the one that should be left out. I talked
to Stephen about it - there are some things we could do, but not in
the timeframe of this release.

Regards,
Simon

> Tom
>
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: Thursday, June 04, 2015 8:16 AM
> > To: U-Boot Mailing List
> > Cc: Simon Glass; Tom Warren; Jagannadha Sutradharudu Teki; Stephen Warren;
> > Marek Vasut; Pavel Herrmann; Stephen Warren
> > Subject: Re: [PATCH v2 00/16] tegra: Expand Nyan-big support
> >
> > Hi Tom,
> >
> > On 13 May 2015 at 07:45, Simon Glass  wrote:
> > > This series expands Nyan-big support:
> > >
> > > - Enable Chrome OS EC, so that the keyboard works
> > > - Add some extra clock and pre-kernel init required for reliable
> > > operation
> > > - Add Chrome OS environment variables, including 'run nvboot' to allow
> > > booting Chrome OS more easily
> > >
> > > Still missing are audio and USB.
> > >
> > > Changes in v2:
> > > - Use spi-max-frequency in both the bus and slave nodes
> > > - Remove unnecessary ODMDATA mangling
> > > - Use existing __stringify() macro
> > > - Drop tegra timer patch as it is not needed
> > > - Drop a few patches that have already been applied
> > >
> > > Doug Anderson (1):
> > >   Add Chrome OS config header
> >
> > Apart from the above patch, can this series be applied please?
> >
> > >
> > > Simon Glass (15):
> > >   tegra: cros_ec: Add tegra support for Chrome OS EC
> > >   tegra: spi: Drop the claim_bus() method to correct delays
> > >   dm: tegra: cros_ec: Enable Chrome OS EC on Nyan-big
> > >   tegra: spi: Support slow SPI rates
> > >   tegra: clock: Support enabling external clocks
> > >   tegra: clock: Adjust PLL access to avoid a warning
> > >   tegra: Introduce SRAM repair on tegra124
> > >   tegra: Add missing tegra124 peripherals
> > >   tegra: Increase maximum arguments to 32
> > >   tegra: lcd: Tidy up clock init
> > >   tegra: Allow board-specific init
> > >   tegra: nyan-big: Add additional clock and kernel init
> > >   tegra: config: Allow Chrome OS environment settings to be included
> > >   tegra: Replace 'Norrin' with 'Nyan-big' and fix typo
> > >   tegra: config: nyan-big: Add options required by Chrome OS boot
> > >
> > >  arch/arm/dts/tegra124-nyan-big.dts|   3 +
> > >  arch/arm/include/asm/arch-tegra/clock.h   |   8 +
> > >  arch/arm/include/asm/arch-tegra/sys_proto.h   |   7 +
> > >  arch/arm/include/asm/arch-tegra124/clock-tables.h |  12 +-
> > >  arch/arm/include/asm/arch-tegra124/flow.h |  12 +
> > >  arch/arm/mach-tegra/clock.c   |  24 +-
> > >  arch/arm/mach-tegra/powergate.c   |  20 +-
> > >  arch/arm/mach-tegra/tegra124/Kconfig  |   2 +-
> > >  arch/arm/mach-tegra/tegra124/clock.c  |   2 +-
> > >  board/nvidia/common/board.c   |   8 +-
> > >  board/nvidia/nyan-big/MAINTAINERS |   2 +-
> > >  board/nvidia/nyan-big/nyan-big.c  |  69 
> > >  configs/nyan-big_defconfig|   5 +
> > >  drivers/spi/tegra114_spi.c|  40 +-
> > >  drivers/video/tegra124/tegra124-lcd.c |   4 +-
> > >  include/configs/chromeos.h| 457 
> > > ++
> > >  include/configs/nyan-big.h|   9 +
> > >  include/configs/tegra-common-post.h   |  15 +-
> > >  include/configs/tegra-common.h|   2 +-
> > >  19 files changed, 663 insertions(+), 38 deletions(-)  create mode
> > > 100644 include/configs/chromeos.h
> > >
> > > --
> > > 2.2.0.rc0.207.ga3a616c
> > >
> >
> > Regards,
> > Simon
> --
> nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 00/16] tegra: Expand Nyan-big support

[Tom Warren]

Sorry, I've been busy with T210 stuff. I'll try to take a look at it before the 
EOW.

IIRC, there was some push-back from Stephen on boot scripts, etc. Have these 
concerns all been addressed? Have you gotten Acks?

Tom

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Thursday, June 04, 2015 8:16 AM
> To: U-Boot Mailing List
> Cc: Simon Glass; Tom Warren; Jagannadha Sutradharudu Teki; Stephen Warren;
> Marek Vasut; Pavel Herrmann; Stephen Warren
> Subject: Re: [PATCH v2 00/16] tegra: Expand Nyan-big support
> 
> Hi Tom,
> 
> On 13 May 2015 at 07:45, Simon Glass  wrote:
> > This series expands Nyan-big support:
> >
> > - Enable Chrome OS EC, so that the keyboard works
> > - Add some extra clock and pre-kernel init required for reliable
> > operation
> > - Add Chrome OS environment variables, including 'run nvboot' to allow
> > booting Chrome OS more easily
> >
> > Still missing are audio and USB.
> >
> > Changes in v2:
> > - Use spi-max-frequency in both the bus and slave nodes
> > - Remove unnecessary ODMDATA mangling
> > - Use existing __stringify() macro
> > - Drop tegra timer patch as it is not needed
> > - Drop a few patches that have already been applied
> >
> > Doug Anderson (1):
> >   Add Chrome OS config header
> 
> Apart from the above patch, can this series be applied please?
> 
> >
> > Simon Glass (15):
> >   tegra: cros_ec: Add tegra support for Chrome OS EC
> >   tegra: spi: Drop the claim_bus() method to correct delays
> >   dm: tegra: cros_ec: Enable Chrome OS EC on Nyan-big
> >   tegra: spi: Support slow SPI rates
> >   tegra: clock: Support enabling external clocks
> >   tegra: clock: Adjust PLL access to avoid a warning
> >   tegra: Introduce SRAM repair on tegra124
> >   tegra: Add missing tegra124 peripherals
> >   tegra: Increase maximum arguments to 32
> >   tegra: lcd: Tidy up clock init
> >   tegra: Allow board-specific init
> >   tegra: nyan-big: Add additional clock and kernel init
> >   tegra: config: Allow Chrome OS environment settings to be included
> >   tegra: Replace 'Norrin' with 'Nyan-big' and fix typo
> >   tegra: config: nyan-big: Add options required by Chrome OS boot
> >
> >  arch/arm/dts/tegra124-nyan-big.dts|   3 +
> >  arch/arm/include/asm/arch-tegra/clock.h   |   8 +
> >  arch/arm/include/asm/arch-tegra/sys_proto.h   |   7 +
> >  arch/arm/include/asm/arch-tegra124/clock-tables.h |  12 +-
> >  arch/arm/include/asm/arch-tegra124/flow.h |  12 +
> >  arch/arm/mach-tegra/clock.c   |  24 +-
> >  arch/arm/mach-tegra/powergate.c   |  20 +-
> >  arch/arm/mach-tegra/tegra124/Kconfig  |   2 +-
> >  arch/arm/mach-tegra/tegra124/clock.c  |   2 +-
> >  board/nvidia/common/board.c   |   8 +-
> >  board/nvidia/nyan-big/MAINTAINERS |   2 +-
> >  board/nvidia/nyan-big/nyan-big.c  |  69 
> >  configs/nyan-big_defconfig|   5 +
> >  drivers/spi/tegra114_spi.c|  40 +-
> >  drivers/video/tegra124/tegra124-lcd.c |   4 +-
> >  include/configs/chromeos.h| 457 
> > ++
> >  include/configs/nyan-big.h|   9 +
> >  include/configs/tegra-common-post.h   |  15 +-
> >  include/configs/tegra-common.h|   2 +-
> >  19 files changed, 663 insertions(+), 38 deletions(-)  create mode
> > 100644 include/configs/chromeos.h
> >
> > --
> > 2.2.0.rc0.207.ga3a616c
> >
> 
> Regards,
> Simon
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/5] arm: imx6: tqma6: boot device selection via Kconfig

[Markus Niebel]

From: Markus Niebel 

Signed-off-by: Markus Niebel 
---
Changes for v2:
- regenerate defconfigs

 board/tqc/tqma6/Kconfig   | 19 +++
 configs/tqma6q_mba6_mmc_defconfig |  2 +-
 configs/tqma6q_mba6_spi_defconfig |  3 ++-
 configs/tqma6s_mba6_mmc_defconfig |  2 +-
 configs/tqma6s_mba6_spi_defconfig |  3 ++-
 5 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/board/tqc/tqma6/Kconfig b/board/tqc/tqma6/Kconfig
index ce47ba4..132e82f 100644
--- a/board/tqc/tqma6/Kconfig
+++ b/board/tqc/tqma6/Kconfig
@@ -33,6 +33,25 @@ config TQMA6S
 
 endchoice
 
+choice
+   prompt "TQMa6 boot configuration"
+   default TQMA6X_MMC_BOOT
+   help
+ Configure boot device. This is also used to implement environment
+ location.
+
+config TQMA6X_MMC_BOOT
+   bool "MMC / SD Boot"
+   help
+ Boot from eMMC / SD Card
+
+config TQMA6X_SPI_BOOT
+   bool "SPI NOR Boot"
+   help
+ Boot from on board SPI NOR flash
+
+endchoice
+
 config IMX_CONFIG
default "board/tqc/tqma6/tqma6q.cfg" if TQMA6Q
default "board/tqc/tqma6/tqma6s.cfg" if TQMA6S
diff --git a/configs/tqma6q_mba6_mmc_defconfig 
b/configs/tqma6q_mba6_mmc_defconfig
index ffdceb3..82a19b9 100644
--- a/configs/tqma6q_mba6_mmc_defconfig
+++ b/configs/tqma6q_mba6_mmc_defconfig
@@ -1,4 +1,4 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_MMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6q_mba6_spi_defconfig 
b/configs/tqma6q_mba6_spi_defconfig
index dc88151..102291d 100644
--- a/configs/tqma6q_mba6_spi_defconfig
+++ b/configs/tqma6q_mba6_spi_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_SPI_BOOT"
+CONFIG_TQMA6X_SPI_BOOT=y
+CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6s_mba6_mmc_defconfig 
b/configs/tqma6s_mba6_mmc_defconfig
index 6c0763d..09a820e 100644
--- a/configs/tqma6s_mba6_mmc_defconfig
+++ b/configs/tqma6s_mba6_mmc_defconfig
@@ -2,4 +2,4 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_MMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6s_mba6_spi_defconfig 
b/configs/tqma6s_mba6_spi_defconfig
index 4873ffb..d874dc2 100644
--- a/configs/tqma6s_mba6_spi_defconfig
+++ b/configs/tqma6s_mba6_spi_defconfig
@@ -2,4 +2,5 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_SPI_BOOT"
+CONFIG_TQMA6X_SPI_BOOT=y
+CONFIG_SYS_EXTRA_OPTIONS="MBA6"
-- 
2.3.0

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

[U-Boot] [PATCH v2 2/5] arm: mx6: tqma6: CPU type selection via Kconfig

[Markus Niebel]

From: Markus Niebel 

This is the first patch to remove the
CONFIG_SYS_EXTRA_OPTIONS.

This patch implements CPU type selection from Kconfig.
Further Kconfig stuff is added later.

Signed-off-by: Markus Niebel 
---
Changes in v2:
- regenerate defconfigs

 arch/arm/Kconfig  |  5 -
 arch/arm/cpu/armv7/mx6/Kconfig|  5 +
 board/tqc/tqma6/Kconfig   | 21 +
 configs/tqma6q_mba6_mmc_defconfig |  3 ++-
 configs/tqma6q_mba6_spi_defconfig |  3 ++-
 configs/tqma6s_mba6_mmc_defconfig |  4 +++-
 configs/tqma6s_mba6_spi_defconfig |  4 +++-
 7 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b62842f..2ea6643 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -576,10 +576,6 @@ config TARGET_TBS2910
bool "Support tbs2910"
select CPU_V7
 
-config TARGET_TQMA6
-   bool "TQ Systems TQMa6 board"
-   select CPU_V7
-
 config TARGET_OT1200
bool "Bachmann OT1200"
select CPU_V7
@@ -954,7 +950,6 @@ source "board/ti/ti816x/Kconfig"
 source "board/timll/devkit3250/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
 source "board/toradex/colibri_vf/Kconfig"
-source "board/tqc/tqma6/Kconfig"
 source "board/trizepsiv/Kconfig"
 source "board/ttcontrol/vision2/Kconfig"
 source "board/udoo/Kconfig"
diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 1282be3..10908c4 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -33,11 +33,16 @@ config TARGET_SECOMX6
bool "Support secomx6 boards"
select CPU_V7
 
+config TARGET_TQMA6
+   bool "TQ Systems TQMa6 board"
+   select CPU_V7
+
 endchoice
 
 config SYS_SOC
default "mx6"
 
 source "board/seco/Kconfig"
+source "board/tqc/tqma6/Kconfig"
 
 endif
diff --git a/board/tqc/tqma6/Kconfig b/board/tqc/tqma6/Kconfig
index f8b3d1f..3e4d9f5 100644
--- a/board/tqc/tqma6/Kconfig
+++ b/board/tqc/tqma6/Kconfig
@@ -12,4 +12,25 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "tqma6"
 
+choice
+   prompt "TQMa6 SoC variant"
+   default TQMA6Q
+   help
+ select the TQMa6 module variant. The variants differing in the used
+ i.MX6 CPU type and DRAM
+
+config TQMA6Q
+   bool "TQMa6Q / TQMa6D"
+   select MX6Q
+   help
+ select TQMa6Q / TQMa6D with i.MX6Q/D and 1GiB DRAM
+
+config TQMA6S
+   bool "TQMa6S"
+   select MX6S
+   help
+ select TQMa6S with i.MX6S and 512 MiB DRAM
+
+endchoice
+
 endif
diff --git a/configs/tqma6q_mba6_mmc_defconfig 
b/configs/tqma6q_mba6_mmc_defconfig
index 627883a..e6dcc99 100644
--- a/configs/tqma6q_mba6_mmc_defconfig
+++ b/configs/tqma6q_mba6_mmc_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MX6Q,MBA6,TQMA6X_MMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MBA6,TQMA6X_MMC_BOOT"
diff --git a/configs/tqma6q_mba6_spi_defconfig 
b/configs/tqma6q_mba6_spi_defconfig
index a56a802..ab811a9 100644
--- a/configs/tqma6q_mba6_spi_defconfig
+++ b/configs/tqma6q_mba6_spi_defconfig
@@ -1,3 +1,4 @@
 CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MX6Q,MBA6,TQMA6X_SPI_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MBA6,TQMA6X_SPI_BOOT"
diff --git a/configs/tqma6s_mba6_mmc_defconfig 
b/configs/tqma6s_mba6_mmc_defconfig
index 51958e2..b7feb18 100644
--- a/configs/tqma6s_mba6_mmc_defconfig
+++ b/configs/tqma6s_mba6_mmc_defconfig
@@ -1,3 +1,5 @@
 CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MX6S,MBA6,TQMA6X_MMC_BOOT"
+CONFIG_TQMA6S=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MBA6,TQMA6X_MMC_BOOT"
diff --git a/configs/tqma6s_mba6_spi_defconfig 
b/configs/tqma6s_mba6_spi_defconfig
index f94f704..24d07cd 100644
--- a/configs/tqma6s_mba6_spi_defconfig
+++ b/configs/tqma6s_mba6_spi_defconfig
@@ -1,3 +1,5 @@
 CONFIG_ARM=y
+CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MX6S,MBA6,TQMA6X_SPI_BOOT"
+CONFIG_TQMA6S=y
+CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MBA6,TQMA6X_SPI_BOOT"
-- 
2.3.0

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

[U-Boot] [PATCH v2 5/5] arm: imx6: tqma6: implement KConfig baseboard selection

[Markus Niebel]

From: Markus Niebel 

this finally removes the need for extra settings in
defconfig

Signed-off-by: Markus Niebel 
---
Changes for v2:
- add default for new choice
- regenerate defconfigs

 board/tqc/tqma6/Kconfig   | 14 ++
 configs/tqma6q_mba6_mmc_defconfig |  1 -
 configs/tqma6q_mba6_spi_defconfig |  1 -
 configs/tqma6s_mba6_mmc_defconfig |  1 -
 configs/tqma6s_mba6_spi_defconfig |  1 -
 5 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/board/tqc/tqma6/Kconfig b/board/tqc/tqma6/Kconfig
index 132e82f..b56237d 100644
--- a/board/tqc/tqma6/Kconfig
+++ b/board/tqc/tqma6/Kconfig
@@ -52,6 +52,20 @@ config TQMA6X_SPI_BOOT
 
 endchoice
 
+choice
+   prompt "TQMa6 base board variant"
+   default MBA6
+   help
+ Select base board for TQMa6
+
+config MBA6
+   bool "TQMa6 on MBa6 Starterkit"
+   help
+ Select the MBa6 starterkit. This features a GigE Phy, USB, SD-Card
+ etc.
+
+endchoice
+
 config IMX_CONFIG
default "board/tqc/tqma6/tqma6q.cfg" if TQMA6Q
default "board/tqc/tqma6/tqma6s.cfg" if TQMA6S
diff --git a/configs/tqma6q_mba6_mmc_defconfig 
b/configs/tqma6q_mba6_mmc_defconfig
index 82a19b9..7e67132 100644
--- a/configs/tqma6q_mba6_mmc_defconfig
+++ b/configs/tqma6q_mba6_mmc_defconfig
@@ -1,4 +1,3 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6q_mba6_spi_defconfig 
b/configs/tqma6q_mba6_spi_defconfig
index 102291d..1f91f6d 100644
--- a/configs/tqma6q_mba6_spi_defconfig
+++ b/configs/tqma6q_mba6_spi_defconfig
@@ -2,4 +2,3 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6X_SPI_BOOT=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6s_mba6_mmc_defconfig 
b/configs/tqma6s_mba6_mmc_defconfig
index 09a820e..2eb891b 100644
--- a/configs/tqma6s_mba6_mmc_defconfig
+++ b/configs/tqma6s_mba6_mmc_defconfig
@@ -2,4 +2,3 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6"
diff --git a/configs/tqma6s_mba6_spi_defconfig 
b/configs/tqma6s_mba6_spi_defconfig
index d874dc2..92b9711 100644
--- a/configs/tqma6s_mba6_spi_defconfig
+++ b/configs/tqma6s_mba6_spi_defconfig
@@ -3,4 +3,3 @@ CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
 CONFIG_TQMA6X_SPI_BOOT=y
-CONFIG_SYS_EXTRA_OPTIONS="MBA6"
-- 
2.3.0

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

[U-Boot] [PATCH v2 3/5] arm: imx6: tqma6: implement IMX_CONFIG with Kconfig

[Markus Niebel]

From: Markus Niebel 

Now that we have the Kconfig based CPU type selection,
use this to fill the IMX_CONFIG automatically

Signed-off-by: Markus Niebel 
---
Changes for v2:
- regenerate defconfigs

 board/tqc/tqma6/Kconfig   | 4 
 configs/tqma6q_mba6_mmc_defconfig | 2 +-
 configs/tqma6q_mba6_spi_defconfig | 2 +-
 configs/tqma6s_mba6_mmc_defconfig | 2 +-
 configs/tqma6s_mba6_spi_defconfig | 2 +-
 5 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/board/tqc/tqma6/Kconfig b/board/tqc/tqma6/Kconfig
index 3e4d9f5..ce47ba4 100644
--- a/board/tqc/tqma6/Kconfig
+++ b/board/tqc/tqma6/Kconfig
@@ -33,4 +33,8 @@ config TQMA6S
 
 endchoice
 
+config IMX_CONFIG
+   default "board/tqc/tqma6/tqma6q.cfg" if TQMA6Q
+   default "board/tqc/tqma6/tqma6s.cfg" if TQMA6S
+
 endif
diff --git a/configs/tqma6q_mba6_mmc_defconfig 
b/configs/tqma6q_mba6_mmc_defconfig
index e6dcc99..ffdceb3 100644
--- a/configs/tqma6q_mba6_mmc_defconfig
+++ b/configs/tqma6q_mba6_mmc_defconfig
@@ -1,4 +1,4 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MBA6,TQMA6X_MMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_MMC_BOOT"
diff --git a/configs/tqma6q_mba6_spi_defconfig 
b/configs/tqma6q_mba6_spi_defconfig
index ab811a9..dc88151 100644
--- a/configs/tqma6q_mba6_spi_defconfig
+++ b/configs/tqma6q_mba6_spi_defconfig
@@ -1,4 +1,4 @@
 CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6q.cfg,MBA6,TQMA6X_SPI_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_SPI_BOOT"
diff --git a/configs/tqma6s_mba6_mmc_defconfig 
b/configs/tqma6s_mba6_mmc_defconfig
index b7feb18..6c0763d 100644
--- a/configs/tqma6s_mba6_mmc_defconfig
+++ b/configs/tqma6s_mba6_mmc_defconfig
@@ -2,4 +2,4 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MBA6,TQMA6X_MMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_MMC_BOOT"
diff --git a/configs/tqma6s_mba6_spi_defconfig 
b/configs/tqma6s_mba6_spi_defconfig
index 24d07cd..4873ffb 100644
--- a/configs/tqma6s_mba6_spi_defconfig
+++ b/configs/tqma6s_mba6_spi_defconfig
@@ -2,4 +2,4 @@ CONFIG_ARM=y
 CONFIG_ARCH_MX6=y
 CONFIG_TARGET_TQMA6=y
 CONFIG_TQMA6S=y
-CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/tqc/tqma6/tqma6s.cfg,MBA6,TQMA6X_SPI_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="MBA6,TQMA6X_SPI_BOOT"
-- 
2.3.0

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

[U-Boot] [PATCH v2 1/5] arm: imx6: tqma6: add kconfig to board header

[Markus Niebel]

From: Markus Niebel 

this is needed later to have Kconfig generated
stuff as define.

Signed-off-by: Markus Niebel 
---
 include/configs/tqma6.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
index 4c93c9b..f9de0c6 100644
--- a/include/configs/tqma6.h
+++ b/include/configs/tqma6.h
@@ -9,6 +9,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include 
 /* SPL */
 /* #if defined(CONFIG_SPL_BUILD) */
 
-- 
2.3.0

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

[U-Boot] [PATCH v2 0/5] arm: imx6: tqma6: Kconfig rework

[Markus Niebel]

From: Markus Niebel 

This series extends the Kconfig options for TQMa6 to
enable removal of CONFIG_SYS_EXTRA_OPTIONS for this boards.

To enable env device / boot device configuration the first patch
includes the Kconfig generated header in the board configuration
header.

To enable CPU selection the second patch moves the board selection
to the i.MX6 CPU menu as implemented by the Seco mx6 boards

Changed for v2:
- rebase to current u-boot-imx
- add new patch to fix envcrc build for non default boot / env 
  devices
- regenerate defconfigs to exclude defaults

Markus Niebel (5):
  arm: imx6: tqma6: add kconfig to board header
  arm: mx6: tqma6: CPU type selection via Kconfig
  arm: imx6: tqma6: implement IMX_CONFIG with Kconfig
  arm: imx6: tqma6: boot device selection via Kconfig
  arm: imx6: tqma6: implement KConfig baseboard selection

 arch/arm/Kconfig  |  5 
 arch/arm/cpu/armv7/mx6/Kconfig|  5 
 board/tqc/tqma6/Kconfig   | 58 +++
 configs/tqma6q_mba6_mmc_defconfig |  2 +-
 configs/tqma6q_mba6_spi_defconfig |  3 +-
 configs/tqma6s_mba6_mmc_defconfig |  3 +-
 configs/tqma6s_mba6_spi_defconfig |  4 ++-
 include/configs/tqma6.h   |  1 +
 8 files changed, 72 insertions(+), 9 deletions(-)

-- 
2.3.0

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

[U-Boot] No maintainer info

[Simon Glass]

Hi,

The genboardsconfig.py script reports a growing list of warnings:

WARNING: no status info for 'axs103'
WARNING: no maintainers for 'axs103'
WARNING: no status info for 'at91sam9g20ek_2mmc'
WARNING: no maintainers for 'at91sam9g20ek_2mmc'
WARNING: no status info for 'at91sam9rlek_mmc'
WARNING: no maintainers for 'at91sam9rlek_mmc'
WARNING: no status info for 'socfpga_arria5'
WARNING: no maintainers for 'socfpga_arria5'
WARNING: no status info for 'cairo'
WARNING: no maintainers for 'cairo'
WARNING: no status info for 'odroid-xu3'
WARNING: no maintainers for 'odroid-xu3'
WARNING: no status info for 'db-88f6820-gp'
WARNING: no maintainers for 'db-88f6820-gp'

Does anyone have ideas on how to avoid this growing further?

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

Re: [U-Boot] [PATCH v4 3/4] x86: gpio: add pinctrl support from the device tree

[Simon Glass]

On 25 May 2015 at 23:27, Gabriel Huau  wrote:
> Every pin can be configured now from the device tree. A dt-bindings
> has been added to describe the different property available.
>
> Signed-off-by: Gabriel Huau 
> ---
>
> Changes in v4:
> - Rebase modification on latest update
> - Fix typo to read the io-base
> - Fix direction_output function to set the value
>
> Changes in v3:
> - Fix the dt-binding copyright header
> - Remove define for IOBASE and use a property
> - Fix issues with signed/unsigned variable type
> - Fix coding style
> - Add a compatible string for the driver
>
> Changes in v2:
> - Clean commit message
> - Rename compatible string 'ich6' to 'x86'
> - Fix coding style
> - Create a dt-bindinds documentation
> - Move x86-gpio defines to a specific header
> - Reorder the functions to avoid the need for forward declarations
> - Rename double underscore functions to only one
> - Create a specific function to configure one pin
> - Use a define to prevent build/support issues with other x86 CPU that
> doesn't have a IOBASE.
>
>  arch/x86/dts/minnowmax.dts |  23 ++
>  arch/x86/include/asm/gpio.h|   1 +
>  .../gpio/intel,x86-pinctrl.txt |  31 +++
>  drivers/gpio/intel_ich6_gpio.c | 257 
> ++---
>  include/dt-bindings/gpio/x86-gpio.h|  31 +++
>  include/fdtdec.h   |   1 +
>  lib/fdtdec.c   |   1 +
>  7 files changed, 317 insertions(+), 28 deletions(-)
>  create mode 100644 doc/device-tree-bindings/gpio/intel,x86-pinctrl.txt
>  create mode 100644 include/dt-bindings/gpio/x86-gpio.h

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

Re: [U-Boot] [PATCH v2 5/5] x86: qemu: Implement PIRQ routing

[Simon Glass]

On 2 June 2015 at 19:20, Bin Meng  wrote:
> Support QEMU PIRQ routing via device tree on both i440fx and q35
> platforms. With this commit, Linux booting on QEMU from U-Boot
> has working ATA/SATA, USB and ethernet.
>
> Signed-off-by: Bin Meng 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/coreboot/coreboot.c |  5 +
>  arch/x86/cpu/qemu/qemu.c |  8 
>  arch/x86/dts/qemu-x86_i440fx.dts | 16 
>  arch/x86/dts/qemu-x86_q35.dts| 32 
>  configs/qemu-x86_defconfig   |  1 +
>  include/configs/qemu-x86.h   |  1 +
>  6 files changed, 63 insertions(+)

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

Re: [U-Boot] [PATCH v3 4/4] x86: minnowmax: initialize the pin-muxing from device tree

[Simon Glass]

On 12 May 2015 at 00:18, Gabriel Huau  wrote:
> Signed-off-by: Gabriel Huau 
> Acked-by: Simon Glass 
>
> ---
>
> Changes in v3:
> - Rebase to the origin/master
>
> Changes in v2:
> - Fix ordering of include header
>
>  board/intel/minnowmax/minnowmax.c | 9 +
>  include/configs/minnowmax.h   | 1 +
>  2 files changed, 10 insertions(+)

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

Re: [U-Boot] [PATCH v2 4/5] x86: coreboot: Control I/O port 0xb2 writing via device tree

[Simon Glass]

On 4 June 2015 at 02:47, Simon Glass  wrote:
> On 2 June 2015 at 19:20, Bin Meng  wrote:
>> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
>> U-Boot to hang on QEMU q35 target. We introduce a config option in the
>> device tree "u-boot,no-apm-finalize" under /config node if we don't want
>> to do that.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - Use a config option in the device tree instead of deleting the codes
>>
>>  arch/x86/cpu/coreboot/coreboot.c | 12 +---
>>  arch/x86/dts/qemu-x86_q35.dts|  1 +
>>  2 files changed, 10 insertions(+), 3 deletions(-)
>>
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] gpio: fix typos in GPIO header

[Simon Glass]

On 4 June 2015 at 03:38, Simon Glass  wrote:
> Hi Masahiro,
>
> On 29 May 2015 at 06:57, Masahiro Yamada  
> wrote:
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> I also noticed British English spelling "standardise" and "behaviour",
>> but I kept them.
>> I am not sure if it is justified to fix them...
>
> No, the queen would not be amused. We can accept both spellings.
>
>>
>>
>>  include/asm-generic/gpio.h | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3] x86: baytrail: pci region 3 is not always mapped to end of ram

[Simon Glass]

On 4 June 2015 at 02:47, Simon Glass  wrote:
> On 3 June 2015 at 18:15, Bin Meng  wrote:
>> On Thu, Jun 4, 2015 at 12:37 AM,   wrote:
>>> From: Andrew Bradford 
>>>
>>> Baytrail physically maps the first 2 GB of SDRAM from 0x0 to 0x7FFF
>>> and additional SDRAM is mapped from 0x1 and up.  There is a
>>> physical memory hole from 0x8000 to 0x for other uses.
>>> Because of this, PCI region 3 should only try to use up to the amount of
>>> SDRAM or 0x8000, which ever is less.
>>>
>>> Signed-off-by: Andrew Bradford 
>>> ---
>>> v3: Fix build breakage due to semicolon
>>> v2: limit maximum size to lesser of SDRAM or 0x8000
>>> ---
>>>  arch/x86/cpu/baytrail/pci.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/cpu/baytrail/pci.c b/arch/x86/cpu/baytrail/pci.c
>>> index 6c291f9..48409de 100644
>>> --- a/arch/x86/cpu/baytrail/pci.c
>>> +++ b/arch/x86/cpu/baytrail/pci.c
>>> @@ -39,7 +39,7 @@ void board_pci_setup_hose(struct pci_controller *hose)
>>> pci_set_region(hose->regions + 3,
>>>0,
>>>0,
>>> -  gd->ram_size,
>>> +  gd->ram_size < 0x8000 ? gd->ram_size : 
>>> 0x8000,
>>>PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>>>
>>> hose->region_count = 4;
>>> --
>>
>> Reviewed-by: Bin Meng 
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2 00/16] tegra: Expand Nyan-big support

[Simon Glass]

Hi Tom,

On 13 May 2015 at 07:45, Simon Glass  wrote:
> This series expands Nyan-big support:
>
> - Enable Chrome OS EC, so that the keyboard works
> - Add some extra clock and pre-kernel init required for reliable operation
> - Add Chrome OS environment variables, including 'run nvboot' to allow
> booting Chrome OS more easily
>
> Still missing are audio and USB.
>
> Changes in v2:
> - Use spi-max-frequency in both the bus and slave nodes
> - Remove unnecessary ODMDATA mangling
> - Use existing __stringify() macro
> - Drop tegra timer patch as it is not needed
> - Drop a few patches that have already been applied
>
> Doug Anderson (1):
>   Add Chrome OS config header

Apart from the above patch, can this series be applied please?

>
> Simon Glass (15):
>   tegra: cros_ec: Add tegra support for Chrome OS EC
>   tegra: spi: Drop the claim_bus() method to correct delays
>   dm: tegra: cros_ec: Enable Chrome OS EC on Nyan-big
>   tegra: spi: Support slow SPI rates
>   tegra: clock: Support enabling external clocks
>   tegra: clock: Adjust PLL access to avoid a warning
>   tegra: Introduce SRAM repair on tegra124
>   tegra: Add missing tegra124 peripherals
>   tegra: Increase maximum arguments to 32
>   tegra: lcd: Tidy up clock init
>   tegra: Allow board-specific init
>   tegra: nyan-big: Add additional clock and kernel init
>   tegra: config: Allow Chrome OS environment settings to be included
>   tegra: Replace 'Norrin' with 'Nyan-big' and fix typo
>   tegra: config: nyan-big: Add options required by Chrome OS boot
>
>  arch/arm/dts/tegra124-nyan-big.dts|   3 +
>  arch/arm/include/asm/arch-tegra/clock.h   |   8 +
>  arch/arm/include/asm/arch-tegra/sys_proto.h   |   7 +
>  arch/arm/include/asm/arch-tegra124/clock-tables.h |  12 +-
>  arch/arm/include/asm/arch-tegra124/flow.h |  12 +
>  arch/arm/mach-tegra/clock.c   |  24 +-
>  arch/arm/mach-tegra/powergate.c   |  20 +-
>  arch/arm/mach-tegra/tegra124/Kconfig  |   2 +-
>  arch/arm/mach-tegra/tegra124/clock.c  |   2 +-
>  board/nvidia/common/board.c   |   8 +-
>  board/nvidia/nyan-big/MAINTAINERS |   2 +-
>  board/nvidia/nyan-big/nyan-big.c  |  69 
>  configs/nyan-big_defconfig|   5 +
>  drivers/spi/tegra114_spi.c|  40 +-
>  drivers/video/tegra124/tegra124-lcd.c |   4 +-
>  include/configs/chromeos.h| 457 
> ++
>  include/configs/nyan-big.h|   9 +
>  include/configs/tegra-common-post.h   |  15 +-
>  include/configs/tegra-common.h|   2 +-
>  19 files changed, 663 insertions(+), 38 deletions(-)
>  create mode 100644 include/configs/chromeos.h
>
> --
> 2.2.0.rc0.207.ga3a616c
>

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

Re: [U-Boot] [PATCH v2 1/5] x86: coreboot: Fix cosmetic issues

[Simon Glass]

On 2 June 2015 at 19:20, Bin Meng  wrote:
> Clean up arch/x86/cpu/coreboot.c to fix several cosmetic issues.
>
> Signed-off-by: Bin Meng 
> Acked-by: Simon Glass 
>
> ---
>
> Changes in v2:
> - Drop v1 patches already applied
> - Add  inclusion back
>
>  arch/x86/cpu/coreboot/coreboot.c  | 27 +++
>  arch/x86/include/asm/u-boot-x86.h |  1 -
>  2 files changed, 3 insertions(+), 25 deletions(-)

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

Re: [U-Boot] [PATCH v2 3/5] x86: qemu: Create separate i440fx and q35 device trees

[Simon Glass]

On 4 June 2015 at 02:47, Simon Glass  wrote:
> On 2 June 2015 at 19:20, Bin Meng  wrote:
>> Although the two qemu-x86 targets (i440fx and q35) share a lot in
>> common, they still have something that cannot easily handled in one
>> single device tree). Split to create two dedicated device tree files
>> and make the i440fx be the default build target.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v2:
>> - Still use one board configuration file qemu-x86.h
>>
>>  arch/x86/dts/Makefile   |  3 ++-
>>  arch/x86/dts/qemu-x86_i440fx.dts| 34 
>> +
>>  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} |  2 +-
>>  board/coreboot/coreboot/Kconfig |  2 +-
>>  configs/qemu-x86_defconfig  |  3 +--
>>  doc/README.x86  | 10 +++-
>>  6 files changed, 48 insertions(+), 6 deletions(-)
>>  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>>  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] tools: ifdtool: Do not write region while its size is negative

[Simon Glass]

On 4 June 2015 at 03:03, Simon Glass  wrote:
> On 31 May 2015 at 00:57, Bin Meng  wrote:
>>
>> We should ignore those regions whose size is negative. These are
>> typically optional and unused regions (like GbE and platform data).
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  tools/ifdtool.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] x86: kconfig: Make FSP_TEMP_RAM_ADDR depend on HAVE_FSP

[Simon Glass]

On 4 June 2015 at 02:47, Simon Glass  wrote:
> On 1 June 2015 at 07:07, Bin Meng  wrote:
>> FSP_TEMP_RAM_ADDR should only be visible when HAVE_FSP is on.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Bin Meng]

Hi Simon,

On Thu, Jun 4, 2015 at 8:12 PM, Bin Meng  wrote:
> This is a temparory hacking for testing U-Boot on a newer version
> MinnowMax board.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/dts/minnowmax.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
> index 7103bc5..9e1fcfc 100644
> --- a/arch/x86/dts/minnowmax.dts
> +++ b/arch/x86/dts/minnowmax.dts
> @@ -101,7 +101,7 @@
>
> microcode {
> update@0 {
> -#include "microcode/m0130673322.dtsi"
> +#include "microcode/m0130679901.dtsi"
> };
> };
>
> --

Saket confirmed these two patches resolved the boot problem he saw. So
we will need think about how to better support such scenario that
different revision board with different stepping CPUs. Could be
multiple microcodes in one U-Boot image, or still one microcode with
some #ifdef #endif. Note FSP has the capability to accept multiple
microcodes as parameters in the FspTempRamInit(), but right now U-Boot
only specifies one. How do you think?

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Bin Meng]

Hi Saket,

On Thu, Jun 4, 2015 at 10:05 PM, Saket Sinha  wrote:
> Hi Bin,
>
>>
>> I've created two patches to include a D0 stepping microcode for
>> BayTrail-I. The microcode was generated from the microcode header in
>> the coreboot source tree.
>>
>> The first patch is waiting for the list moderator's approval as it
>> exceeds the mailing list size. The second patch is at
>> http://patchwork.ozlabs.org/patch/480673/
>> I will send the first patch to you offline. Please have a try.
>
> After applying both the patches, I am able to get the u-boot prompt
> with u-boot.rom .
>
> Please find the logs below -
>
> U-Boot 2015.07-rc1-20956-g5d3c2c5-dirty (Jun 04 2015 - 19:27:32 +0530)
>
> CPU: x86_64, vendor Intel, device 30679h
> DRAM:  2 GiB
> MMC:   ValleyView SDHCI: 0, ValleyView SDHCI: 1
> Using default environment
>
> Video: 1280x1024x16
> Model: Intel Minnowboard Max
> SCSI:  SATA link 0 timeout.
> SATA link 1 timeout.
> AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
> flags: 64bit ncq stag pm led clo pio slum part sxs
> scanning bus for devices...
> Found 0 device(s).
> Net:   RTL8169#0
> Warning: RTL8169#0 using MAC address from net device
>
> =>
>
>
> Thanks for these wonderful patches.
>

This is good news! I believe you can continue your work for the ACPI
support now :)

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Saket Sinha]

Hi Bin,

>
> I've created two patches to include a D0 stepping microcode for
> BayTrail-I. The microcode was generated from the microcode header in
> the coreboot source tree.
>
> The first patch is waiting for the list moderator's approval as it
> exceeds the mailing list size. The second patch is at
> http://patchwork.ozlabs.org/patch/480673/
> I will send the first patch to you offline. Please have a try.

After applying both the patches, I am able to get the u-boot prompt
with u-boot.rom .

Please find the logs below -

U-Boot 2015.07-rc1-20956-g5d3c2c5-dirty (Jun 04 2015 - 19:27:32 +0530)

CPU: x86_64, vendor Intel, device 30679h
DRAM:  2 GiB
MMC:   ValleyView SDHCI: 0, ValleyView SDHCI: 1
Using default environment

Video: 1280x1024x16
Model: Intel Minnowboard Max
SCSI:  SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001.0300 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: 64bit ncq stag pm led clo pio slum part sxs
scanning bus for devices...
Found 0 device(s).
Net:   RTL8169#0
Warning: RTL8169#0 using MAC address from net device

=>


Thanks for these wonderful patches.

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

[Bin Meng]

Hi Saket,

On Thu, Jun 4, 2015 at 11:23 AM, Simon Glass  wrote:
> Hi John,
>
> On 3 June 2015 at 18:13, Bin Meng  wrote:
>> Hi,
>>
>> On Thu, Jun 4, 2015 at 5:44 AM, John Hawley  wrote:
>>> Ok some more data points.  I tested with the FSP3 Gold that Saket built,
>>> and it continues to work on the A0, but it continues to not work on the
>>> A2 D0 board I have.  I'm guessing this is something between the
>>> steppings in the CPU and the FSP, but I'm not sure.
>>>
>>> Adding Vincent to this, as I'm guessing there is something going on here
>>> with the interaction with the FSP (since it works on an A0 B3, but not
>>> an A2 D0)
>>>
>>> - John
>>>
>>> On 06/03/2015 01:24 PM, Saket Sinha wrote:
 Hi,

> I'm 99% sure that's the issue. try with FSP 3 gold."
>
> I am now trying to build the u-boot.rom from FSP 3 gold and would let
> you know about the results ASAP.

 u-boot.rom prepared from FSP3-Gold dowmloaded from
 https://downloadcenter.intel.com/download/24496 doesn't work with the
 minnowmax I have.

 Regards,
 Saket Sinha

>>
>> Given even with Simon's debug UART WIP patch, the A2 D0 board still
>> has nothing output, I suspect that the FspTempRamInit() call failed
>> due to the microcode loading. Could it be the problem that the
>> microcode passed to the FSP is a little bit old that it does not
>> support the D0 stepping. Can you try some newer version microcode to
>> see if there is any luck?
>
> I was using the Gold3 version. Is there a new microcode we could try?
>

I've created two patches to include a D0 stepping microcode for
BayTrail-I. The microcode was generated from the microcode header in
the coreboot source tree.

The first patch is waiting for the list moderator's approval as it
exceeds the mailing list size. The second patch is at
http://patchwork.ozlabs.org/patch/480673/
I will send the first patch to you offline. Please have a try.

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

[U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Bin Meng]

This is a temparory hacking for testing U-Boot on a newer version
MinnowMax board.

Signed-off-by: Bin Meng 
---

 arch/x86/dts/minnowmax.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index 7103bc5..9e1fcfc 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -101,7 +101,7 @@
 
microcode {
update@0 {
-#include "microcode/m0130673322.dtsi"
+#include "microcode/m0130679901.dtsi"
};
};
 
-- 
1.8.2.1

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

[U-Boot] mmc erase command fails with DAT0 timeout on eMMC on iMX6 board

[Palacios, Hector]

Hello,

I can see the command 'mmc erase blk# cnt' fails with a DAT0 timeout on iMX6 
boards when run over the eMMC.

=> mmc dev 2 
=> mmc erase 4000 1000 
MMC erase: dev # 2, block # 16384, count 4096 ... Timeout waiting for
DAT0 to go high! 
mmc erase failed 
0 blocks erase: ERROR

I reproduced it with the SabreSD board running upstream U-Boot v2015.04.
The error does not happen using microSD card, though.

Does anybody else have the same problem on other iMX6 based boards?
Thank you.

PS. Increasing the timeout value ad infinitum does not help.
--
Héctor Palacios


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

[U-Boot] [PATCH 07/10] ARM: DRA7-evm: Add mux data

[Lokesh Vutla]

From: Nishanth Menon 

Adding the mux data, manual and virtual mode
settings for DRA7-evm.

Signed-off-by: Nishanth Menon 
Signed-off-by: Lokesh Vutla 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Vishal Mahaveer 
---
 board/ti/dra7xx/evm.c  |  14 +-
 board/ti/dra7xx/mux_data.h | 339 +
 2 files changed, 326 insertions(+), 27 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 06adaac..9941afa 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -117,9 +117,17 @@ void set_muxconf_regs_essential(void)
 #ifdef CONFIG_IODELAY_RECALIBRATION
 void recalibrate_iodelay(void)
 {
-   __recalibrate_iodelay(core_padconf_array_essential,
- ARRAY_SIZE(core_padconf_array_essential),
- iodelay_cfg_array, ARRAY_SIZE(iodelay_cfg_array));
+   if (is_dra72x()) {
+   __recalibrate_iodelay(core_padconf_array_essential,
+ ARRAY_SIZE(core_padconf_array_essential),
+ iodelay_cfg_array,
+ ARRAY_SIZE(iodelay_cfg_array));
+   } else {
+   __recalibrate_iodelay(dra74x_core_padconf_array,
+ ARRAY_SIZE(dra74x_core_padconf_array),
+ dra742_iodelay_cfg_array,
+ ARRAY_SIZE(dra742_iodelay_cfg_array));
+   }
 }
 #endif
 
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 4824077..c9301a5 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -76,30 +76,30 @@ const struct pad_conf_entry core_padconf_array_essential[] 
= {
{I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
{MDIO_MCLK, (PTU | PEN | M0)},  /* MDIO_MCLK  */
{MDIO_D, (IEN | PTU | PEN | M0)},   /* MDIO_D  */
-   {RGMII0_TXC, (M0) },
-   {RGMII0_TXCTL, (M0) },
-   {RGMII0_TXD3, (M0) },
-   {RGMII0_TXD2, (M0) },
-   {RGMII0_TXD1, (M0) },
-   {RGMII0_TXD0, (M0) },
-   {RGMII0_RXC, (IEN | M0) },
-   {RGMII0_RXCTL, (IEN | M0) },
-   {RGMII0_RXD3, (IEN | M0) },
-   {RGMII0_RXD2, (IEN | M0) },
-   {RGMII0_RXD1, (IEN | M0) },
-   {RGMII0_RXD0, (IEN | M0) },
-   {VIN2A_D12, (M3) },
-   {VIN2A_D13, (M3) },
-   {VIN2A_D14, (M3) },
-   {VIN2A_D15, (M3) },
-   {VIN2A_D16, (M3) },
-   {VIN2A_D17, (M3) },
-   {VIN2A_D18, (IEN | M3)},
-   {VIN2A_D19, (IEN | M3)},
-   {VIN2A_D20, (IEN | M3)},
-   {VIN2A_D21, (IEN | M3)},
-   {VIN2A_D22, (IEN | M3)},
-   {VIN2A_D23, (IEN | M3)},
+   {RGMII0_TXC, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_TXCTL, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_TXD3, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_TXD2, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_TXD1, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_TXD0, (PIN_OUTPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXC, (PIN_INPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXCTL, (PIN_INPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXD3, (PIN_INPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXD2, (PIN_INPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXD1, (PIN_INPUT | MANUAL_MODE | M0) },
+   {RGMII0_RXD0, (PIN_INPUT | MANUAL_MODE | M0) },
+   {VIN2A_D12, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D13, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D14, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D15, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D16, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D17, (PIN_OUTPUT | MANUAL_MODE | M3) },
+   {VIN2A_D18, (PIN_INPUT | MANUAL_MODE | M3)},
+   {VIN2A_D19, (PIN_INPUT | MANUAL_MODE | M3)},
+   {VIN2A_D20, (PIN_INPUT | MANUAL_MODE | M3)},
+   {VIN2A_D21, (PIN_INPUT | MANUAL_MODE | M3)},
+   {VIN2A_D22, (PIN_INPUT | MANUAL_MODE | M3)},
+   {VIN2A_D23, (PIN_INPUT | MANUAL_MODE | M3)},
 #if defined(CONFIG_NAND) || defined(CONFIG_NOR)
/* NAND / NOR pin-mux */
{GPMC_AD0 , M0 | IEN | PDIS}, /* GPMC_AD0  */
@@ -141,4 +141,295 @@ const struct pad_conf_entry 
core_padconf_array_essential[] = {
{USB2_DRVVBUS, (M0 | IEN | FSC) },
{SPI1_CS1, (PEN | IDIS | M14) },
 };
+
+const struct pad_conf_entry early_padconf[] = {
+#if (CONFIG_CONS_INDEX == 1)
+   {UART1_RXD, (PIN_INPUT_SLEW | M0)}, /* UART1_RXD */
+   {UART1_TXD, (PIN_INPUT_SLEW | M0)}, /* UART1_TXD */
+#elif (CONFIG_CONS_INDEX == 3)
+   {UART3_RXD, (PIN_INPUT_SLEW | M0)}, /* UART3_RXD */
+   {UART3_TXD, (PIN_INPUT_SLEW | M0)}, /* UART3_TXD */
+#endif
+   {I2C1_SDA, (PIN_INPUT | M0)},   /* I2C1_SDA */
+   {I2C1_SCL, (PIN_INPUT | M0)},   /* I2C1_SCL */
+};
+
+#ifdef CONFIG_IODELAY_RECALIBRATION
+const struct iodelay_cfg_entry iodelay_cfg_array[] = {
+   {0x6F0, 480, 0}, /* RGMMI0_RXC_IN */
+   {0x6

[U-Boot] [PATCH 03/10] ARM: DRA7: Add support for virtual mode configuration

[Lokesh Vutla]

In addition to the regular mux configuration, certain pins of DRA7
require to have "virtual mode" also programmed.
This allows for predefined delay characteristics to be used by the SoC
to meet timing characterstics needed for the interface.

Provide easy to use macro to do the same.

For configuring virtual mode, along with normal pad configuration add
the following two steps:
- Select MODESELECT field of each assocaited PAD.
  CTRL_CORE_PAD_XXX[8]:MODESELECT = 1
- DELAYMODE filed should be configured with value given in DATA Manual.
  CTRL_CORE_PAD_XXX[7:4]:DELAYMODE =[0-15] (as given in DATA manual).

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h 
b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
index 13a8099..13c288b 100644
--- a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
+++ b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
@@ -58,6 +58,26 @@
 #define M1414
 #define M1515
 
+#define MODE_SELECT(1 << 8)
+#define DELAYMODE_SHIFT4
+
+#define VIRTUAL_MODE0  (MODE_SELECT | (0x0 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE1  (MODE_SELECT | (0x1 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE2  (MODE_SELECT | (0x2 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE3  (MODE_SELECT | (0x3 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE4  (MODE_SELECT | (0x4 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE5  (MODE_SELECT | (0x5 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE6  (MODE_SELECT | (0x6 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE7  (MODE_SELECT | (0x7 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE8  (MODE_SELECT | (0x8 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE9  (MODE_SELECT | (0x9 << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE10 (MODE_SELECT | (0xa << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE11 (MODE_SELECT | (0xb << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE12 (MODE_SELECT | (0xc << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE13 (MODE_SELECT | (0xd << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE14 (MODE_SELECT | (0xe << DELAYMODE_SHIFT))
+#define VIRTUAL_MODE15 (MODE_SELECT | (0xf << DELAYMODE_SHIFT))
+
 #define SAFE_MODE  M15
 
 #define GPMC_AD0   0x000
-- 
1.9.1

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

[U-Boot] [PATCH 09/10] ARM: BeagleBoard-x15: Enable IO delay recalibration sequence

[Lokesh Vutla]

Enable IO delay recalibration sequence.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 board/ti/beagle_x15/board.c  | 14 +++---
 include/configs/beagle_x15.h |  4 
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
index 39e1527..6a6499c 100644
--- a/board/ti/beagle_x15/board.c
+++ b/board/ti/beagle_x15/board.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -243,11 +244,18 @@ int board_late_init(void)
 void set_muxconf_regs_essential(void)
 {
do_set_mux32((*ctrl)->control_padconf_core_base,
-core_padconf_array_essential,
-sizeof(core_padconf_array_essential) /
-sizeof(struct pad_conf_entry));
+early_padconf, ARRAY_SIZE(early_padconf));
 }
 
+#ifdef CONFIG_IODELAY_RECALIBRATION
+void recalibrate_iodelay(void)
+{
+   __recalibrate_iodelay(core_padconf_array_essential,
+ ARRAY_SIZE(core_padconf_array_essential),
+ iodelay_cfg_array, ARRAY_SIZE(iodelay_cfg_array));
+}
+#endif
+
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
diff --git a/include/configs/beagle_x15.h b/include/configs/beagle_x15.h
index 369f7b8..8d072c6 100644
--- a/include/configs/beagle_x15.h
+++ b/include/configs/beagle_x15.h
@@ -14,6 +14,10 @@
 
 #define CONFIG_AM57XX
 
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_IODELAY_RECALIBRATION
+#endif
+
 #define CONFIG_NR_DRAM_BANKS   2
 
 #define CONFIG_ENV_SIZE(64 << 10)
-- 
1.9.1

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

[U-Boot] [PATCH 10/10] ARM: BeagleBoard-x15: Add mux data

[Lokesh Vutla]

Adding the mux data, manual and virtual mode
settings for BeagleBoard-X15.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Nishanth Menon 
Signed-off-by: Roger Quadros 
---
 board/ti/beagle_x15/mux_data.h | 351 -
 1 file changed, 313 insertions(+), 38 deletions(-)

diff --git a/board/ti/beagle_x15/mux_data.h b/board/ti/beagle_x15/mux_data.h
index df658c5..09d3650 100644
--- a/board/ti/beagle_x15/mux_data.h
+++ b/board/ti/beagle_x15/mux_data.h
@@ -13,43 +13,318 @@
 #include 
 
 const struct pad_conf_entry core_padconf_array_essential[] = {
-   {MMC1_CLK, (IEN | PTU | PDIS | M0)},/* MMC1_CLK */
-   {MMC1_CMD, (IEN | PTU | PDIS | M0)},/* MMC1_CMD */
-   {MMC1_DAT0, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT0 */
-   {MMC1_DAT1, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT1 */
-   {MMC1_DAT2, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT2 */
-   {MMC1_DAT3, (IEN | PTU | PDIS | M0)},   /* MMC1_DAT3 */
-   {MMC1_SDCD, (FSC | IEN | PTU | PDIS | M0)}, /* MMC1_SDCD */
-   {MMC1_SDWP, (FSC | IEN | PTD | PEN | M14)}, /* MMC1_SDWP */
-   {GPMC_A19, (IEN | PTU | PDIS | M1)},/* mmc2_dat4 */
-   {GPMC_A20, (IEN | PTU | PDIS | M1)},/* mmc2_dat5 */
-   {GPMC_A21, (IEN | PTU | PDIS | M1)},/* mmc2_dat6 */
-   {GPMC_A22, (IEN | PTU | PDIS | M1)},/* mmc2_dat7 */
-   {GPMC_A23, (IEN | PTU | PDIS | M1)},/* mmc2_clk */
-   {GPMC_A24, (IEN | PTU | PDIS | M1)},/* mmc2_dat0 */
-   {GPMC_A25, (IEN | PTU | PDIS | M1)},/* mmc2_dat1 */
-   {GPMC_A26, (IEN | PTU | PDIS | M1)},/* mmc2_dat2 */
-   {GPMC_A27, (IEN | PTU | PDIS | M1)},/* mmc2_dat3 */
-   {GPMC_CS1, (IEN | PTU | PDIS | M1)},/* mmm2_cmd */
-   {UART2_CTSN, (FSC | IEN | PTU | PDIS | M2)}, /* uart2_ctsn.uart3_rxd */
-   {UART2_RTSN, (FSC | IEN | PTU | PDIS | M1)}, /* uart2_rtsn.uart3_txd */
-   {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
-   {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
-   {MDIO_MCLK, (PTU | PEN | M0)},  /* MDIO_MCLK  */
-   {MDIO_D, (IEN | PTU | PEN | M0)},   /* MDIO_D  */
-   {RGMII0_TXC, (M0) },
-   {RGMII0_TXCTL, (M0) },
-   {RGMII0_TXD3, (M0) },
-   {RGMII0_TXD2, (M0) },
-   {RGMII0_TXD1, (M0) },
-   {RGMII0_TXD0, (M0) },
-   {RGMII0_RXC, (IEN | M0) },
-   {RGMII0_RXCTL, (IEN | M0) },
-   {RGMII0_RXD3, (IEN | M0) },
-   {RGMII0_RXD2, (IEN | M0) },
-   {RGMII0_RXD1, (IEN | M0) },
-   {RGMII0_RXD0, (IEN | M0) },
-   {USB1_DRVVBUS, (M0 | FSC) },
-   {SPI1_CS1, (PEN | IDIS | M14) }, /* GPIO7_11 */
+   {GPMC_AD0, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad0.vin3a_d0 */
+   {GPMC_AD1, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_ad1.vin3a_d1 */
+   {GPMC_AD2, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad2.vin3a_d2 */
+   {GPMC_AD3, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad3.vin3a_d3 */
+   {GPMC_AD4, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad4.vin3a_d4 */
+   {GPMC_AD5, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_ad5.vin3a_d5 */
+   {GPMC_AD6, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad6.vin3a_d6 */
+   {GPMC_AD7, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad7.vin3a_d7 */
+   {GPMC_AD8, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_ad8.vin3a_d8 */
+   {GPMC_AD9, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_ad9.vin3a_d9 */
+   {GPMC_AD10, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
gpmc_ad10.vin3a_d10 */
+   {GPMC_AD11, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
gpmc_ad11.vin3a_d11 */
+   {GPMC_AD12, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
gpmc_ad12.vin3a_d12 */
+   {GPMC_AD13, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
gpmc_ad13.vin3a_d13 */
+   {GPMC_AD14, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
gpmc_ad14.vin3a_d14 */
+   {GPMC_AD15, (M2 | PIN_INPUT_PULLUP | MANUAL_MODE)}, /* 
gpmc_ad15.vin3a_d15 */
+   {GPMC_A0, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a0.vin3a_d16 */
+   {GPMC_A1, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a1.vin3a_d17 */
+   {GPMC_A2, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a2.vin3a_d18 */
+   {GPMC_A3, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a3.vin3a_d19 */
+   {GPMC_A4, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a4.vin3a_d20 */
+   {GPMC_A5, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a5.vin3a_d21 */
+   {GPMC_A6, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a6.vin3a_d22 */
+   {GPMC_A7, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a7.vin3a_d23 */
+   {GPMC_A8, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a8.vin3a_hsync0 */
+   {GPMC_A9, (M2 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
gpmc_a9.vin3a_vsync0

[U-Boot] [PATCH 08/10] ARM: DRA7: CPSW: Remove IO delay hack

[Lokesh Vutla]

Now all manual mode configurations are done as part of
IO delay recalibration sequence, remove the hack done for
CPSW.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/omap.h | 25 -
 board/ti/dra7xx/evm.c  | 66 --
 2 files changed, 91 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index e844bfb..68c6d6d 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -216,27 +216,6 @@ struct s32ktimer {
 #define OMAP5_ABB_LDOVBBMPU_MUX_CTRL_MASK  (0x1 << 10)
 #define OMAP5_ABB_LDOVBBMPU_VSET_OUT_MASK  (0x1f << 0)
 
-/* IO Delay module defines */
-#define CFG_IO_DELAY_BASE  0x4844A000
-#define CFG_IO_DELAY_LOCK  (CFG_IO_DELAY_BASE + 0x02C)
-
-/* CPSW IO Delay registers*/
-#define CFG_RGMII0_TXCTL   (CFG_IO_DELAY_BASE + 0x74C)
-#define CFG_RGMII0_TXD0(CFG_IO_DELAY_BASE + 0x758)
-#define CFG_RGMII0_TXD1(CFG_IO_DELAY_BASE + 0x764)
-#define CFG_RGMII0_TXD2(CFG_IO_DELAY_BASE + 0x770)
-#define CFG_RGMII0_TXD3(CFG_IO_DELAY_BASE + 0x77C)
-#define CFG_VIN2A_D13  (CFG_IO_DELAY_BASE + 0xA7C)
-#define CFG_VIN2A_D17  (CFG_IO_DELAY_BASE + 0xAAC)
-#define CFG_VIN2A_D16  (CFG_IO_DELAY_BASE + 0xAA0)
-#define CFG_VIN2A_D15  (CFG_IO_DELAY_BASE + 0xA94)
-#define CFG_VIN2A_D14  (CFG_IO_DELAY_BASE + 0xA88)
-
-#define CFG_IO_DELAY_UNLOCK_KEY0x
-#define CFG_IO_DELAY_LOCK_KEY  0xAAAB
-#define CFG_IO_DELAY_ACCESS_PATTERN0x00029000
-#define CFG_IO_DELAY_LOCK_MASK 0x400
-
 #ifndef __ASSEMBLY__
 struct srcomp_params {
s8 divide_factor;
@@ -255,9 +234,5 @@ struct ctrl_ioregs {
u32 ctrl_ddr_ctrl_ext_0;
 };
 
-struct io_delay {
-   u32 addr;
-   u32 dly;
-};
 #endif /* __ASSEMBLY__ */
 #endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9941afa..94a1a8c 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -41,43 +41,6 @@ const struct omap_sysinfo sysinfo = {
"Board: DRA7xx\n"
 };
 
-/*
- * Adjust I/O delays on the Tx control and data lines of each MAC port. This
- * is a workaround in order to work properly with the DP83865 PHYs on the EVM.
- * In 3COM RGMII mode this PHY applies it's own internal clock delay, so we
- * essentially need to counteract the DRA7xx internal delay, and we do this
- * by delaying the control and data lines. If not using this PHY, you probably
- * don't need to do this stuff!
- */
-static void dra7xx_adj_io_delay(const struct io_delay *io_dly)
-{
-   int i = 0;
-   u32 reg_val;
-   u32 delta;
-   u32 coarse;
-   u32 fine;
-
-   writel(CFG_IO_DELAY_UNLOCK_KEY, CFG_IO_DELAY_LOCK);
-
-   while(io_dly[i].addr) {
-   writel(CFG_IO_DELAY_ACCESS_PATTERN & ~CFG_IO_DELAY_LOCK_MASK,
-  io_dly[i].addr);
-   delta = io_dly[i].dly;
-   reg_val = readl(io_dly[i].addr) & 0x3ff;
-   coarse = ((reg_val >> 5) & 0x1F) + ((delta >> 5) & 0x1F);
-   coarse = (coarse > 0x1F) ? (0x1F) : (coarse);
-   fine = (reg_val & 0x1F) + (delta & 0x1F);
-   fine = (fine > 0x1F) ? (0x1F) : (fine);
-   reg_val = CFG_IO_DELAY_ACCESS_PATTERN |
-   CFG_IO_DELAY_LOCK_MASK |
-   ((coarse << 5) | (fine));
-   writel(reg_val, io_dly[i].addr);
-   i++;
-   }
-
-   writel(CFG_IO_DELAY_LOCK_KEY, CFG_IO_DELAY_LOCK);
-}
-
 /**
  * @brief board_init
  *
@@ -263,19 +226,6 @@ int spl_start_uboot(void)
 #endif
 
 #ifdef CONFIG_DRIVER_TI_CPSW
-
-/* Delay value to add to calibrated value */
-#define RGMII0_TXCTL_DLY_VAL   ((0x3 << 5) + 0x8)
-#define RGMII0_TXD0_DLY_VAL((0x3 << 5) + 0x8)
-#define RGMII0_TXD1_DLY_VAL((0x3 << 5) + 0x2)
-#define RGMII0_TXD2_DLY_VAL((0x4 << 5) + 0x0)
-#define RGMII0_TXD3_DLY_VAL((0x4 << 5) + 0x0)
-#define VIN2A_D13_DLY_VAL  ((0x3 << 5) + 0x8)
-#define VIN2A_D17_DLY_VAL  ((0x3 << 5) + 0x8)
-#define VIN2A_D16_DLY_VAL  ((0x3 << 5) + 0x2)
-#define VIN2A_D15_DLY_VAL  ((0x4 << 5) + 0x0)
-#define VIN2A_D14_DLY_VAL  ((0x4 << 5) + 0x0)
-
 extern u32 *const omap_si_rev;
 
 static void cpsw_control(int enabled)
@@ -323,22 +273,6 @@ int board_eth_init(bd_t *bis)
uint8_t mac_addr[6];
uint32_t mac_hi, mac_lo;
uint32_t ctrl_val;
-   const struct io_delay io_dly[] = {
-   {CFG_RGMII0_TXCTL, RGMII0_TXCTL_DLY_VAL},
-   {CFG_RGMII0_TXD0, RGMII0_TXD0_DLY_VAL},
-   {CFG_RGMII0_TXD1, RGMII0_TXD1_DLY_VAL},
-   {CFG_RGMII0_TXD2, RGMII0_TXD2_DLY_VAL}

[U-Boot] [PATCH 06/10] ARM: DRA7-evm: Enable IO delay recalibration sequence

[Lokesh Vutla]

Enabling IO delay recalibration sequence for DRA7 EVM.
UART and I2C are configured before IO delay recalibration sequence
as these are used earlier and safe to use.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 board/ti/dra7xx/evm.c| 14 +++---
 include/configs/dra7xx_evm.h |  4 
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 1b05150..06adaac 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -110,11 +111,18 @@ int board_late_init(void)
 void set_muxconf_regs_essential(void)
 {
do_set_mux32((*ctrl)->control_padconf_core_base,
-core_padconf_array_essential,
-sizeof(core_padconf_array_essential) /
-sizeof(struct pad_conf_entry));
+early_padconf, ARRAY_SIZE(early_padconf));
 }
 
+#ifdef CONFIG_IODELAY_RECALIBRATION
+void recalibrate_iodelay(void)
+{
+   __recalibrate_iodelay(core_padconf_array_essential,
+ ARRAY_SIZE(core_padconf_array_essential),
+ iodelay_cfg_array, ARRAY_SIZE(iodelay_cfg_array));
+}
+#endif
+
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)
 int board_mmc_init(bd_t *bis)
 {
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 77edc21..afcc36b 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -15,6 +15,10 @@
 #define CONFIG_DRA7XX
 #define CONFIG_BOARD_EARLY_INIT_F
 
+#ifdef CONFIG_SPL_BUILD
+#define CONFIG_IODELAY_RECALIBRATION
+#endif
+
 #ifndef CONFIG_QSPI_BOOT
 /* MMC ENV related defines */
 #define CONFIG_ENV_IS_IN_MMC
-- 
1.9.1

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

[U-Boot] [PATCH 00/10] ARM: DRA7: Add support for IOdelay module

[Lokesh Vutla]

SoCs such as DRA7 family from Texas Instruments include a highly
configurable hardware block called the IOdelay block. This block
allows very specific custom fine tuning for electrical characteristics
of IO pins that are necessary for functionality and device lifetime
requirements.

IODelay module exists on it's own register space with registers
allocated for various pins. A set of values (derived from either
automated tools OR from device datasheet) is then computed on a
per-chip basis(to account for die specific variations) to generate a
set of delay parameters that are programmed to one or more registers
for the delay path of the io line.

This series basically adds support for this IOdelay recalibration and
enables the same on DRA7-evm, BeagleBoard-x15 boards.

Tested on:
DRA7-evm: http://pastebin.ubuntu.com/11562641/
BeagleBoard-x15: http://pastebin.ubuntu.com/11563215/

Lokesh Vutla (9):
  ARM: DRA7: Make do_set_mux32() generic
  ARM: DRA7: Add pinctrl register definitions
  ARM: DRA7: Add support for virtual mode configuration
  ARM: DRA7: Add support for IO delay configuration
  ARM: DRA7: Add support for manual mode configuration
  ARM: DRA7-evm: Enable IO delay recalibration sequence
  ARM: DRA7: CPSW: Remove IO delay hack
  ARM: BeagleBoard-x15: Enable IO delay recalibration sequence
  ARM: BeagleBoard-x15: Add mux data

Nishanth Menon (1):
  ARM: DRA7-evm: Add mux data

 arch/arm/cpu/armv7/omap-common/clocks-common.c   |  26 ++
 arch/arm/cpu/armv7/omap5/Makefile|   1 +
 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c| 238 +++
 arch/arm/cpu/armv7/omap5/hwinit.c|   9 +
 arch/arm/cpu/armv7/omap5/prcm-regs.c |   3 +
 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |  83 ++
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h |  37 +++
 arch/arm/include/asm/arch-omap5/omap.h   |  25 --
 arch/arm/include/asm/arch-omap5/sys_proto.h  |  13 +
 arch/arm/include/asm/omap_common.h   |   4 +
 board/ti/beagle_x15/board.c  |  22 +-
 board/ti/beagle_x15/mux_data.h   | 351 ---
 board/ti/dra7xx/evm.c|  96 ++-
 board/ti/dra7xx/mux_data.h   | 339 --
 include/configs/beagle_x15.h |   4 +
 include/configs/dra7xx_evm.h |   4 +
 16 files changed, 1078 insertions(+), 177 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
 create mode 100644 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h

-- 
1.9.1

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

[U-Boot] [PATCH 05/10] ARM: DRA7: Add support for manual mode configuration

[Lokesh Vutla]

In addition to the regular mux configuration, certain pins of DRA7
require to have "manual mode" also programmed, when predefined
delay characteristics cannot be used for the interface.

struct iodelay_cfg_entry is introduced for populating
manual mode IO timings.
For configuring manual mode, along with the normal pad
configuration do the following steps:
- Select MODESELECT field of each assocaited PAD.
  CTRL_CORE_PAD_XXX[8]:MODESELECT = 1(Enable MANUAL_MODE macro along with mux)
- Populate A_DELAY, G_DELAY values that are specified in DATA MANUAL.
  And pass the offset of the CFG_XXX register in iodelay_cfg_entry.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c| 101 ++-
 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |  27 +-
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h |   2 +
 arch/arm/include/asm/arch-omap5/sys_proto.h  |  12 +++
 4 files changed, 140 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c 
b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
index 4b8ba26..9fa6e69 100644
--- a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
+++ b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static int isolate_io(u32 isolate)
@@ -80,7 +81,94 @@ static int update_delay_mechanism(u32 base)
return 0;
 }
 
-void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads)
+static u32 calculate_delay(u32 base, u16 offset, u16 den)
+{
+   u16 refclk_period, dly_cnt, ref_cnt;
+   u32 reg, q, r;
+
+   refclk_period = readl(base + CFG_REG_2_OFFSET) &
+ CFG_REG_REFCLK_PERIOD_MASK;
+
+   reg = readl(base + offset);
+   dly_cnt = (reg & CFG_REG_DLY_CNT_MASK) >> CFG_REG_DLY_CNT_SHIFT;
+   ref_cnt = (reg & CFG_REG_REF_CNT_MASK) >> CFG_REG_REF_CNT_SHIFT;
+
+   if (!dly_cnt || !den)
+   return 0;
+
+   /*
+* To avoid overflow and integer truncation, delay value
+* is calculated as quotient + remainder.
+*/
+   q = 5 * ((ref_cnt * refclk_period) / (dly_cnt * den));
+   r = (10 * ((ref_cnt * refclk_period) % (dly_cnt * den))) /
+   (2 * dly_cnt * den);
+
+   return q + r;
+}
+
+static u32 get_cfg_reg(u16 a_delay, u16 g_delay, u32 cpde, u32 fpde)
+{
+   u32 g_delay_coarse, g_delay_fine;
+   u32 a_delay_coarse, a_delay_fine;
+   u32 c_elements, f_elements;
+   u32 total_delay, reg = 0;
+
+   g_delay_coarse = g_delay / 920;
+   g_delay_fine = ((g_delay % 920) * 10) / 60;
+
+   a_delay_coarse = a_delay / cpde;
+   a_delay_fine = ((a_delay % cpde) * 10) / fpde;
+
+   c_elements = g_delay_coarse + a_delay_coarse;
+   f_elements = (g_delay_fine + a_delay_fine) / 10;
+
+   if (f_elements > 22) {
+   total_delay = c_elements * cpde + f_elements * fpde;
+
+   c_elements = total_delay / cpde;
+   f_elements = (total_delay % cpde) / fpde;
+   }
+
+   reg = (c_elements << CFG_X_COARSE_DLY_SHIFT) & CFG_X_COARSE_DLY_MASK;
+   reg |= (f_elements << CFG_X_FINE_DLY_SHIFT) & CFG_X_FINE_DLY_MASK;
+   reg |= CFG_X_SIGNATURE << CFG_X_SIGNATURE_SHIFT;
+   reg |= CFG_X_LOCK << CFG_X_LOCK_SHIFT;
+
+   return reg;
+}
+
+static int do_set_iodelay(u32 base, struct iodelay_cfg_entry const *array,
+  int niodelays)
+{
+   struct iodelay_cfg_entry *iodelay = (struct iodelay_cfg_entry *)array;
+   u32 reg, cpde, fpde, i;
+
+   if (!niodelays)
+   return 0;
+
+   cpde = calculate_delay((*ctrl)->iodelay_config_base, CFG_REG_3_OFFSET,
+  88);
+   if (!cpde)
+   return ERR_CPDE;
+
+   fpde = calculate_delay((*ctrl)->iodelay_config_base, CFG_REG_4_OFFSET,
+  264);
+   if (!fpde)
+   return ERR_FPDE;
+
+   for (i = 0; i < niodelays; i++, iodelay++) {
+   reg = get_cfg_reg(iodelay->a_delay, iodelay->g_delay, cpde,
+ fpde);
+   writel(reg, base + iodelay->offset);
+   }
+
+   return 0;
+}
+
+void __recalibrate_iodelay(struct pad_conf_entry const *pad, int npads,
+  struct iodelay_cfg_entry const *iodelay,
+  int niodelays)
 {
int ret = 0;
 
@@ -109,6 +197,11 @@ void __recalibrate_iodelay(struct pad_conf_entry const 
*pad, int npads)
/* Configure Mux settings */
do_set_mux32((*ctrl)->control_padconf_core_base, pad, npads);
 
+   /* Configure Manual IO timing modes */
+   ret = do_set_iodelay((*ctrl)->iodelay_config_base, iodelay, niodelays);
+   if (ret)
+   goto err;
+
ret = isolate_io(DEISOLATE_IO);
 
 err:
@@ -133,6 +226,12 @@ err:
case ERR_DEISOLATE_IO:
puts("IODELAY: De-isolation of Device IOs faile

[U-Boot] [PATCH 01/10] ARM: DRA7: Make do_set_mux32() generic

[Lokesh Vutla]

do_set_mux32() is redefined in dra7xx and beagle_x15 boards.
IO delay recalibration sequence also needs this.
Making it generic to avoid duplication.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap5/hwinit.c   |  9 +
 arch/arm/include/asm/arch-omap5/sys_proto.h |  1 +
 board/ti/beagle_x15/board.c | 10 --
 board/ti/dra7xx/evm.c   | 10 --
 4 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 8d6b59e..786d6d0 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -40,6 +40,15 @@ static struct gpio_bank gpio_bank_54xx[8] = {
 
 const struct gpio_bank *const omap_gpio_bank = gpio_bank_54xx;
 
+void do_set_mux32(u32 base, struct pad_conf_entry const *array, int size)
+{
+   int i;
+   struct pad_conf_entry *pad = (struct pad_conf_entry *)array;
+
+   for (i = 0; i < size; i++, pad++)
+   writel(pad->val, base + pad->offset);
+}
+
 #ifdef CONFIG_SPL_BUILD
 /* LPDDR2 specific IO settings */
 static void io_settings_lpddr2(void)
diff --git a/arch/arm/include/asm/arch-omap5/sys_proto.h 
b/arch/arm/include/asm/arch-omap5/sys_proto.h
index ea84665..b41bf15 100644
--- a/arch/arm/include/asm/arch-omap5/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap5/sys_proto.h
@@ -32,6 +32,7 @@ void gpmc_init(void);
 void watchdog_init(void);
 u32 get_device_type(void);
 void do_set_mux(u32 base, struct pad_conf_entry const *array, int size);
+void do_set_mux32(u32 base, struct pad_conf_entry const *array, int size);
 void set_muxconf_regs_essential(void);
 u32 wait_on_value(u32, u32, void *, u32);
 void sdelay(unsigned long);
diff --git a/board/ti/beagle_x15/board.c b/board/ti/beagle_x15/board.c
index ffcd531..39e1527 100644
--- a/board/ti/beagle_x15/board.c
+++ b/board/ti/beagle_x15/board.c
@@ -240,16 +240,6 @@ int board_late_init(void)
return 0;
 }
 
-static void do_set_mux32(u32 base,
-struct pad_conf_entry const *array, int size)
-{
-   int i;
-   struct pad_conf_entry *pad = (struct pad_conf_entry *)array;
-
-   for (i = 0; i < size; i++, pad++)
-   writel(pad->val, base + pad->offset);
-}
-
 void set_muxconf_regs_essential(void)
 {
do_set_mux32((*ctrl)->control_padconf_core_base,
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index d464855..1b05150 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -107,16 +107,6 @@ int board_late_init(void)
return 0;
 }
 
-static void do_set_mux32(u32 base,
-struct pad_conf_entry const *array, int size)
-{
-   int i;
-   struct pad_conf_entry *pad = (struct pad_conf_entry *)array;
-
-   for (i = 0; i < size; i++, pad++)
-   writel(pad->val, base + pad->offset);
-}
-
 void set_muxconf_regs_essential(void)
 {
do_set_mux32((*ctrl)->control_padconf_core_base,
-- 
1.9.1

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

[U-Boot] [PATCH 04/10] ARM: DRA7: Add support for IO delay configuration

[Lokesh Vutla]

On DRA7, in addition to the regular muxing of pins, an additional
hardware module called IODelay which is also expected to be
configured. This "IODelay" module has it's own register space that is
independent of the control module.

It is advocated strongly in TI's official documentation considering
the existing design of the DRA7 family of processors during mux or
IODelay recalibration, there is a potential for a significant glitch
which may cause functional impairment to certain hardware. It is
hence recommended to do muxing as part of IOdelay recalibration.

IODELAY recalibration sequence:
- Complete AVS voltage change on VDD_CORE_L
- Unlock IODLAY config registers.
- Perform IO delay calibration with predefined values.
- Isolate all the IOs
- Update the delay mechanism for each IO with new calibrated values.
- Configure PAD configuration registers
- De-isolate all the IOs.
- Relock IODELAY config registers.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/cpu/armv7/omap-common/clocks-common.c   |  26 +
 arch/arm/cpu/armv7/omap5/Makefile|   1 +
 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c| 139 +++
 arch/arm/cpu/armv7/omap5/prcm-regs.c |   3 +
 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h |  58 ++
 arch/arm/include/asm/omap_common.h   |   4 +
 6 files changed, 231 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
 create mode 100644 arch/arm/include/asm/arch-omap5/dra7xx_iodelay.h

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 03674e6..fa04bbe 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -508,6 +508,12 @@ static u32 optimize_vcore_voltage(struct volts const *v)
return val;
 }
 
+#ifdef CONFIG_IODELAY_RECALIBRATION
+void __weak recalibrate_iodelay(void)
+{
+}
+#endif
+
 /*
  * Setup the voltages for the main SoC core power domains.
  * We start with the maximum voltages allowed here, as set in the corresponding
@@ -561,6 +567,16 @@ void scale_vcores(struct vcores_data const *vcores)
 
debug("cor: %d\n", vcores->core.value);
do_scale_vcore(vcores->core.addr, vcores->core.value, 
vcores->core.pmic);
+   /*
+* IO delay recalibration should be done immediately after
+* adjusting AVS voltages for VDD_CORE_L.
+* Respective boards should call __recalibrate_iodelay()
+* with proper mux, virtual and manual mode configurations.
+*/
+#ifdef CONFIG_IODELAY_RECALIBRATION
+   recalibrate_iodelay();
+#endif
+
debug("mpu: %d\n", vcores->mpu.value);
do_scale_vcore(vcores->mpu.addr, vcores->mpu.value, vcores->mpu.pmic);
/* Configure MPU ABB LDO after scale */
@@ -587,6 +603,16 @@ void scale_vcores(struct vcores_data const *vcores)
val = optimize_vcore_voltage(&vcores->core);
do_scale_vcore(vcores->core.addr, val, vcores->core.pmic);
 
+   /*
+* IO delay recalibration should be done immediately after
+* adjusting AVS voltages for VDD_CORE_L.
+* Respective boards should call __recalibrate_iodelay()
+* with proper mux, virtual and manual mode configurations.
+*/
+#ifdef CONFIG_IODELAY_RECALIBRATION
+   recalibrate_iodelay();
+#endif
+
val = optimize_vcore_voltage(&vcores->mpu);
do_scale_vcore(vcores->mpu.addr, val, vcores->mpu.pmic);
 
diff --git a/arch/arm/cpu/armv7/omap5/Makefile 
b/arch/arm/cpu/armv7/omap5/Makefile
index 64c6879..e709f14 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -11,3 +11,4 @@ obj-y += sdram.o
 obj-y  += prcm-regs.o
 obj-y  += hw_data.o
 obj-y  += abb.o
+obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
diff --git a/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c 
b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
new file mode 100644
index 000..4b8ba26
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
@@ -0,0 +1,139 @@
+/*
+ * (C) Copyright 2015
+ * Texas Instruments Incorporated, 
+ *
+ * Lokesh Vutla 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int isolate_io(u32 isolate)
+{
+   if (isolate) {
+   clrsetbits_le32((*ctrl)->control_pbias, SDCARD_PWRDNZ,
+   SDCARD_PWRDNZ);
+   clrsetbits_le32((*ctrl)->control_pbias, SDCARD_BIAS_PWRDNZ,
+   SDCARD_BIAS_PWRDNZ);
+   }
+
+   /* Override control on ISOCLKIN signal to IO pad ring. */
+   clrsetbits_le32((*prcm)->prm_io_pmctrl, PMCTRL_ISOCLK_OVERRIDE_MASK,
+   PMCTRL_ISOCLK_OVERRIDE_CTRL);
+   if (!wait_on_value(PMCTRL_ISOCLK_STATUS_MASK, PMCTRL_ISOCLK_STATUS_MASK,
+  (u32 *)(*prcm)->prm_io_pmctrl, LDELAY))
+   return

[U-Boot] [PATCH 02/10] ARM: DRA7: Add pinctrl register definitions

[Lokesh Vutla]

Adopting the pinctrl register definitions from Linux kernel
to be consistent.
Old definitions will be removed once all the pinctrl data
is adapted to new definitions.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 arch/arm/include/asm/arch-omap5/mux_dra7xx.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h 
b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
index e155387..13a8099 100644
--- a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
+++ b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
@@ -26,6 +26,21 @@
 #define WKEN   (1 << 24)
 #define WKDIS  (0 << 24)
 
+#define PULL_ENA   (0 << 16)
+#define PULL_DIS   (1 << 16)
+#define PULL_UP(1 << 17)
+#define INPUT_EN   (1 << 18)
+#define SLEWCONTROL(1 << 19)
+
+/* Active pin states */
+#define PIN_OUTPUT (0 | PULL_DIS)
+#define PIN_OUTPUT_PULLUP  (PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(0)
+#define PIN_INPUT  (INPUT_EN | PULL_DIS)
+#define PIN_INPUT_SLEW (INPUT_EN | SLEWCONTROL)
+#define PIN_INPUT_PULLUP   (PULL_ENA | INPUT_EN | PULL_UP)
+#define PIN_INPUT_PULLDOWN (PULL_ENA | INPUT_EN)
+
 #define M0 0
 #define M1 1
 #define M2 2
-- 
1.9.1

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

[U-Boot] [PATCH v2 3/3] x86: fsp: Move FspInitEntry call to board_init_f()

[Bin Meng]

The call to FspInitEntry is done in arch/x86/lib/fsp/fsp_car.S so far.
It worked pretty well but looks not that good. Apart from doing too
much work than just enabling CAR, it cannot read the configuration
data from device tree at that time. Now we want to move it a little
bit later as part of init_sequence_f[] being called by board_init_f().
This way it looks and works better in the U-Boot initialization path.

Due to FSP's design, after calling FspInitEntry it will not return to
its caller, instead it jumps to a continuation function which is given
by bootloader with a new stack in system memory. The original stack in
the CAR is gone, but its content is perserved by FSP and described by
a bootloader temporary memory HOB. Technically we can recover anything
we had before in the previous stack, but that is way too complicated.
To make life much easier, in the FSP continuation routine we just
simply call fsp_init_done() and jump back to car_init_ret() to redo
the whole board_init_f() initialization, but this time with a non-zero
HOB list pointer saved in U-Boot's global data so that we can bypass
the FspInitEntry for the second time.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 
Tested-by: Andrew Bradford 

---

Changes in v2: None

 arch/x86/cpu/start.S  |  6 +-
 arch/x86/include/asm/u-boot-x86.h |  4 
 arch/x86/lib/fsp/fsp_car.S| 26 +-
 arch/x86/lib/fsp/fsp_common.c |  8 
 common/board_f.c  |  3 +++
 5 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 2e5f9da..00e585e 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -116,12 +116,16 @@ car_init_ret:
rep stosb
 
 #ifdef CONFIG_HAVE_FSP
+   test%esi, %esi
+   jz  skip_hob
+
/* Store HOB list */
movl%esp, %edx
addl$GD_HOB_LIST, %edx
movl%esi, (%edx)
-#endif
 
+skip_hob:
+#endif
/* Setup first parameter to setup_gdt, pointer to global_data */
movl%esp, %eax
 
diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index 67c0098..5d8a96d 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -52,6 +52,10 @@ u32 isa_map_rom(u32 bus_addr, int size);
 /* arch/x86/lib/... */
 int video_bios_init(void);
 
+#ifdef CONFIG_HAVE_FSP
+int x86_fsp_init(void);
+#endif
+
 void   board_init_f_r_trampoline(ulong) __attribute__ ((noreturn));
 void   board_init_f_r(void) __attribute__ ((noreturn));
 
diff --git a/arch/x86/lib/fsp/fsp_car.S b/arch/x86/lib/fsp/fsp_car.S
index 5e09568..afbf3f9 100644
--- a/arch/x86/lib/fsp/fsp_car.S
+++ b/arch/x86/lib/fsp/fsp_car.S
@@ -56,28 +56,10 @@ temp_ram_init_ret:
 
/* stack grows down from top of CAR */
movl%edx, %esp
+   subl$4, %esp
 
-   /*
-* TODO:
-*
-* According to FSP architecture spec, the fsp_init() will not return
-* to its caller, instead it requires the bootloader to provide a
-* so-called continuation function to pass into the FSP as a parameter
-* of fsp_init, and fsp_init() will call that continuation function
-* directly.
-*
-* The call to fsp_init() may need to be moved out of the car_init()
-* to cpu_init_f() with the help of some inline assembly codes.
-* Note there is another issue that fsp_init() will setup another stack
-* using the fsp_init parameter stack_top after DRAM is initialized,
-* which means any data on the previous stack (on the CAR) gets lost
-* (ie: U-Boot global_data). FSP is supposed to support such scenario,
-* however it does not work. This should be revisited in the future.
-*/
-   movl$CONFIG_FSP_TEMP_RAM_ADDR, %eax
-   xorl%edx, %edx
-   xorl%ecx, %ecx
-   callfsp_init
+   xor %esi, %esi
+   jmp car_init_done
 
 .global fsp_init_done
 fsp_init_done:
@@ -86,6 +68,8 @@ fsp_init_done:
 * Save eax to esi temporarily.
 */
movl%eax, %esi
+
+car_init_done:
/*
 * Re-initialize the ebp (BIST) to zero, as we already reach here
 * which means we passed BIST testing before.
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index 001494d..5b25632 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -46,3 +46,11 @@ void board_final_cleanup(void)
 
return;
 }
+
+int x86_fsp_init(void)
+{
+   if (!gd->arch.hob_list)
+   fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, NULL);
+
+   return 0;
+}
diff --git a/common/board_f.c b/common/board_f.c
index fbbad1b..21be26f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -753,6 +753,9 @@ static init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_OF_CONTROL
fdtdec_setup,
 #endif
+#if defined(CONFIG_X86) && defined

[U-Boot] [PATCH v2 2/3] x86: fsp: Load GDT before calling FspInitEntry

[Bin Meng]

Currently the FSP execution environment GDT is setup by U-Boot in
arch/x86/cpu/start16.S, which works pretty well. But if we try to
move the FspInitEntry call a little bit later to better fit into
U-Boot's initialization sequence, FSP will fail to bring up the AP
due to #GP fault as AP's GDT is duplicated from BSP whose GDT is
now moved into CAR, and unfortunately FSP calls AP initialization
after it disables the CAR. So basically the BSP's GDT still refers
to the one in the CAR, whose content is no longer available, so
when AP starts up and loads its segment register, it blows up.

To resolve this, we load GDT before calling into FspInitEntry.
The GDT is the same one used in arch/x86/cpu/start16.S, which is
in the ROM and exists forever.

Signed-off-by: Bin Meng 

---

Changes in v2:
- Use CONFIG_RESET_SEG_START to avoid duplication

 arch/x86/cpu/cpu.c| 20 
 arch/x86/cpu/start16.S|  1 +
 arch/x86/include/asm/u-boot-x86.h |  3 +++
 arch/x86/lib/fsp/fsp_support.c|  3 +++
 4 files changed, 27 insertions(+)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index bb4a110..f4ebc97 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -164,6 +164,26 @@ void setup_gdt(gd_t *id, u64 *gdt_addr)
load_fs(X86_GDT_ENTRY_32BIT_FS);
 }
 
+#ifdef CONFIG_HAVE_FSP
+/*
+ * Setup FSP execution environment GDT
+ *
+ * Per Intel FSP external architecture specification, before calling any FSP
+ * APIs, we need make sure the system is in flat 32-bit mode and both the code
+ * and data selectors should have full 4GB access range. Here we reuse the one
+ * we used in arch/x86/cpu/start16.S, and reload the segement registers.
+ */
+void setup_fsp_gdt(void)
+{
+   load_gdt((const u64 *)((u32)&gdt + CONFIG_RESET_SEG_START), 4);
+   load_ds(X86_GDT_ENTRY_32BIT_DS);
+   load_ss(X86_GDT_ENTRY_32BIT_DS);
+   load_es(X86_GDT_ENTRY_32BIT_DS);
+   load_fs(X86_GDT_ENTRY_32BIT_DS);
+   load_gs(X86_GDT_ENTRY_32BIT_DS);
+}
+#endif
+
 int __weak x86_cleanup_before_linux(void)
 {
 #ifdef CONFIG_BOOTSTAGE_STASH
diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
index 826e2b4..a3e7ab4 100644
--- a/arch/x86/cpu/start16.S
+++ b/arch/x86/cpu/start16.S
@@ -75,6 +75,7 @@ gdt_ptr:
 
/* Some CPUs are picky about GDT alignment... */
.align  16
+.globl gdt
 gdt:
/*
 * The GDT table ...
diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index d1d21ed..67c0098 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -8,12 +8,15 @@
 #ifndef _U_BOOT_I386_H_
 #define _U_BOOT_I386_H_1
 
+extern u32 gdt;
+
 /* cpu/.../cpu.c */
 int arch_cpu_init(void);
 int x86_cpu_init_f(void);
 int cpu_init_f(void);
 void init_gd(gd_t *id, u64 *gdt_addr);
 void setup_gdt(gd_t *id, u64 *gdt_addr);
+void setup_fsp_gdt(void);
 int init_cache(void);
 int cleanup_before_linux(void);
 
diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index 5809235..4585166 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -173,6 +173,9 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
 
post_code(POST_PRE_MRC);
 
+   /* Load GDT for FSP */
+   setup_fsp_gdt();
+
/*
 * Use ASM code to ensure the register value in EAX & ECX
 * will be passed into BlContinuationFunc
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 1/3] x86: Add Kconfig options to be used by arch/x86/cpu/config.mk

[Bin Meng]

Add RESET_SEG_START, RESET_SEG_SIZE and RESET_VEC_LOC Kconfig options
and make arch/x86/cpu/config.mk use these options.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to add Kconfig options to be used by arch/x86/cpu/config.mk

 arch/x86/Kconfig   | 15 +++
 arch/x86/cpu/config.mk |  6 +++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3506ba2..78996d0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -75,6 +75,21 @@ config X86_RESET_VECTOR
bool
default n
 
+config RESET_SEG_START
+   hex
+   depends on X86_RESET_VECTOR
+   default 0x
+
+config RESET_SEG_SIZE
+   hex
+   depends on X86_RESET_VECTOR
+   default 0x1
+
+config RESET_VEC_LOC
+   hex
+   depends on X86_RESET_VECTOR
+   default 0xfff0
+
 config SYS_X86_START16
hex
depends on X86_RESET_VECTOR
diff --git a/arch/x86/cpu/config.mk b/arch/x86/cpu/config.mk
index 4c4d0c7..1263221 100644
--- a/arch/x86/cpu/config.mk
+++ b/arch/x86/cpu/config.mk
@@ -10,8 +10,8 @@ CROSS_COMPILE ?= i386-linux-
 PLATFORM_CPPFLAGS += -D__I386__
 
 # DO NOT MODIFY THE FOLLOWING UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!
-LDPPFLAGS += -DRESET_SEG_START=0x
-LDPPFLAGS += -DRESET_SEG_SIZE=0x1
-LDPPFLAGS += -DRESET_VEC_LOC=0xfff0
+LDPPFLAGS += -DRESET_SEG_START=$(CONFIG_RESET_SEG_START)
+LDPPFLAGS += -DRESET_SEG_SIZE=$(CONFIG_RESET_SEG_SIZE)
+LDPPFLAGS += -DRESET_VEC_LOC=$(CONFIG_RESET_VEC_LOC)
 LDPPFLAGS += -DSTART_16=$(CONFIG_SYS_X86_START16)
 LDPPFLAGS += -DRESET_BASE="CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN - 
RESET_SEG_SIZE)"
-- 
1.8.2.1

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

Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default

[Hans de Goede]

Hi,

On 04-06-15 00:55, Joe Hershberger wrote:

On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini  wrote:

On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote:

Hi Tom,

On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini  wrote:

On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote:


Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then
needing to have this in every sunxi defconfig file.

This also fixes the Merrii_A80_Optimus defconfig no longer building.

Cc: Maxin B. John 
Reported-by: Maxin B. John 
Signed-off-by: Hans de Goede 


Joe? Masahiro?  It feels like something has gone wrong with the
conversion here.  Or do people need to get used to the defconfig files
being a non-trivial size?  Or do we need some more default y if ...
lines around things?  Or a few of the above?  Thanks!


It seems we should select good defaults. Maybe we should try to agree
which way we should err. Make u-boot bigger by default, and boards
that are limited can disable features? Or should we enable commands on
boards that "need" a feature and keep u-boot slim by default?

I don't like the half measure of defining a different default for one
platform than another unless it is actually something inherent in the
platform, and in that case it should be enabled by a "selects" under
the platform Kconfig.

I agree we want to have smaller defconfigs rather than bigger, but
there are lots of features and many boards will not agree, so the
defconfigs of many boards will have to contain something.


The first thing that pops to mind is that if it used to be in
config_cmd_default.h it should be on by default and disabled when needed
(and this means we can be smart about CMD_FLASH / CMD_IMLS).  Otherwise
we need to think hard on if something new should be on by default or
not.


I have the gut feeling that things that depend on hardware existing
(such as CMD_NET) should not be default.


Well taking CMD_NET as example, most boards may not have (wired) ethernet
but they often to have USB and u-boot supports several popular
USB <-> ethernet adapters...

TBH given modern system memory sizes I think it makes sense for a lot
of stuff to just default to y, and then one really space / mem
constrained systems they can be disabled via a select from the
ARCH setting.


 However, I guess if it's
totally ubiquitous (such as CMD_MEMORY - though it's already in
config_cmd_default.h) then it should be default just to shrink the
defconfigs.

Ian, you indicated that you thought CMD_NET should be a default since
it is usually wanted. It seems that is generally the case. It looks
like 94% of boards enable CMD_NET, which makes it pretty much
ubiquitous.

Perhaps that should be the metric for deciding (probably with
flexibility for making an argument to the contrary)... if more that
80% (good enough water-mark?) of the boards enable a feature, then it
should be the default?  50% would optimize for overall defconfig
size... maybe that's better?


Regards,

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

Re: [U-Boot] [PATCH 1/2] ARMv7: Factor out reusable timer_wait from sunxi/psci_sun7i.S

[Hans de Goede]

Hi,

On 04-06-15 06:01, Dongsheng Wang wrote:

From: Wang Dongsheng 

timer_wait is moved from sunxi/psci_sun7i.S, and it can be converted
completely into a reusable armv7 generic timer. LS1021A will use it
as well.

Signed-off-by: Wang Dongsheng 


Thanks for rebasing this, looks good:

Reviewed-by: Hans de Goede 

As for upstreaming this, it is probably best for the entire set
to go upstream through the same tree, although if people want I
can upstream this one through the sunxi tree.

In the mean time I'll add this to the sunxi-wip branch of my
personal repo so that it sees some testing (not that I'm expecting
any issues).

Regards,

Hans





diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
index d4cb51e..4ff46e4 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
@@ -18,6 +18,8 @@
   */

  #include 
+
+#include 
  #include 
  #include 
  #include 
@@ -43,26 +45,6 @@
  #define   GICD_BASE   0x1c81000
  #define   GICC_BASE   0x1c82000

-.macro timer_wait  reg, ticks
-   @ Program CNTP_TVAL
-   movw\reg, #(\ticks & 0x)
-   movt\reg, #(\ticks >> 16)
-   mcr p15, 0, \reg, c14, c2, 0
-   isb
-   @ Enable physical timer, mask interrupt
-   mov \reg, #3
-   mcr p15, 0, \reg, c14, c2, 1
-   @ Poll physical timer until ISTATUS is on
-1: isb
-   mrc p15, 0, \reg, c14, c2, 1
-   ands\reg, \reg, #4
-   bne 1b
-   @ Disable timer
-   mov \reg, #0
-   mcr p15, 0, \reg, c14, c2, 1
-   isb
-.endm
-
  .globlpsci_fiq_enter
  psci_fiq_enter:
push{r0-r12}
diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S 
b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
index bbfeec8..e15d587 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
@@ -18,6 +18,8 @@
   */

  #include 
+
+#include 
  #include 
  #include 
  #include 
@@ -43,26 +45,6 @@
  #define   GICD_BASE   0x1c81000
  #define   GICC_BASE   0x1c82000

-.macro timer_wait  reg, ticks
-   @ Program CNTP_TVAL
-   movw\reg, #(\ticks & 0x)
-   movt\reg, #(\ticks >> 16)
-   mcr p15, 0, \reg, c14, c2, 0
-   isb
-   @ Enable physical timer, mask interrupt
-   mov \reg, #3
-   mcr p15, 0, \reg, c14, c2, 1
-   @ Poll physical timer until ISTATUS is on
-1: isb
-   mrc p15, 0, \reg, c14, c2, 1
-   ands\reg, \reg, #4
-   bne 1b
-   @ Disable timer
-   mov \reg, #0
-   mcr p15, 0, \reg, c14, c2, 1
-   isb
-.endm
-
  .globlpsci_fiq_enter
  psci_fiq_enter:
push{r0-r12}
diff --git a/arch/arm/include/asm/arch-armv7/generictimer.h 
b/arch/arm/include/asm/arch-armv7/generictimer.h
new file mode 100644
index 000..0956d7c
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/generictimer.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2013 - ARM Ltd
+ * Author: Marc Zyngier 
+ *
+ * Based on code by Carl van Schaik .
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#ifndef _GENERICTIMER_H_
+#define _GENERICTIMER_H_
+
+#ifdef __ASSEMBLY__
+
+/*
+ * This macro provide a physical timer that can be used for delay in the code.
+ * The macro is moved from sunxi/psci_sun7i.S
+ *
+ * reg: is used in this macro.
+ * ticks: The freq is based on generic timer.
+ */
+.macro timer_wait  reg, ticks
+   movw\reg, #(\ticks & 0x)
+   movt\reg, #(\ticks >> 16)
+   mcr p15, 0, \reg, c14, c2, 0
+   isb
+   mov \reg, #3
+   mcr p15, 0, \reg, c14, c2, 1
+1 :isb
+   mrc p15, 0, \reg, c14, c2, 1
+   ands\reg, \reg, #4
+   bne 1b
+   mov \reg, #0
+   mcr p15, 0, \reg, c14, c2, 1
+   isb
+.endm
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _GENERICTIMER_H_ */


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

Re: [U-Boot] [PATCH] gpio: fix typos in GPIO header

[Simon Glass]

Hi Masahiro,

On 29 May 2015 at 06:57, Masahiro Yamada  wrote:
> Signed-off-by: Masahiro Yamada 
> ---
>
> I also noticed British English spelling "standardise" and "behaviour",
> but I kept them.
> I am not sure if it is justified to fix them...

No, the queen would not be amused. We can accept both spellings.

>
>
>  include/asm-generic/gpio.h | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 4/4] x86: minnowmax: initialize the pin-muxing from device tree

[Simon Glass]

Hi Gabriel,

On 26 May 2015 at 08:41, Gabriel Huau  wrote:
> Hi Andy,
>
> On 05/26/2015 01:01 AM, Andy Pont wrote:
>>
>> Hi Gabriel,
>>
>>
>>>   soc_gpio_s5_0@0 {
>>>   gpio-offset = <0x80 0>;
>>>   pad-offset = <0x1d0>;
>>>   mode-gpio;
>>>   output-value = <0>;
>>>   direction = ;
>>>   };
>>>
>>>   soc_gpio_s5_1@0 {
>>>   gpio-offset = <0x80 1>;
>>>   pad-offset = <0x210>;
>>>   mode-gpio;
>>>   output-value = <0>;
>>>   direction = ;
>>>   };
>>>
>>>   soc_gpio_s5_2@0 {
>>>   gpio-offset = <0x80 2>;
>>>   pad-offset = <0x1e0>;
>>>   mode-gpio;
>>>   output-value = <0>;
>>>   direction = ;
>>>   };
>>>
>>> And after, you can use the GPIO commands:
>>>
>>> => gpio set E0
>>> gpio: pin E0 (gpio 128) value is 1
>>> => gpio clear E0
>>> gpio: pin E0 (gpio 128) value is 0
>>> => gpio set E2
>>> gpio: pin E2 (gpio 130) value is 1
>>> => gpio clear E2
>>> gpio: pin E2 (gpio 130) value is 0
>>>
>>> E0 E1 and E2 correspond to the GPIO0 1 and 2.
>>
>> Is there, or can someone add, some documentation somewhere as to how to
>> convert between the device tree definition and the value used for "pin" in
>> the gpio commands as it doesn't seem intuitive or obvious to me that what
>> you have defined translates to E0, E1 and E2.
>
> I agree, but I think the documentation should be part of another patch,
> especially as this is the case for all the x86 platform.
> The naming is not specific to the minnowboard max (baytrail).

Sounds good, please go ahead.

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

Re: [U-Boot] [PATCH v3 4/4] x86: minnowmax: initialize the pin-muxing from device tree

[Simon Glass]

Hi Gabriel,

On 25 May 2015 at 23:30, gabriel huau  wrote:
> Hi Simon,
>
> I just submitted a new version of the patch, actually, when I tried to use
> the GPIO on the header I saw a typo in the code.
>
> To test it, you have to define these nodes in the device tree (should be
> there by default or not?):

Yes I think so. Can you please send a patch?

>
> soc_gpio_s5_0@0 {
> gpio-offset = <0x80 0>;
> pad-offset = <0x1d0>;
> mode-gpio;
> output-value = <0>;
> direction = ;
> };
>
> soc_gpio_s5_1@0 {
> gpio-offset = <0x80 1>;
> pad-offset = <0x210>;
> mode-gpio;
> output-value = <0>;
> direction = ;
> };
>
> soc_gpio_s5_2@0 {
> gpio-offset = <0x80 2>;
> pad-offset = <0x1e0>;
> mode-gpio;
> output-value = <0>;
> direction = ;
> };
>
> And after, you can use the GPIO commands:
>
> => gpio set E0
> gpio: pin E0 (gpio 128) value is 1
> => gpio clear E0
> gpio: pin E0 (gpio 128) value is 0
> => gpio set E2
> gpio: pin E2 (gpio 130) value is 1
> => gpio clear E2
> gpio: pin E2 (gpio 130) value is 0
>
> E0 E1 and E2 correspond to the GPIO0 1 and 2.

OK thanks, that seems to work for me. I tested these with a multimeter
and can adjust the output.

Acked-by: Simon Glass 
Tested-by: Simon Glass 

Regards,
Simon

>
> Regards,
> Gabriel
>
>
> On 05/20/2015 07:21 AM, Simon Glass wrote:
>>
>> Hi Gabriel,
>>
>> I have two patches in patchwork:
>>
>> http://patchwork.ozlabs.org/patch/471146/
>> http://patchwork.ozlabs.org/patch/471147/
>>
>> Are they the correct ones? Also do you know how to use the gpio
>> command to toggle a bin on the Minnowboard MAX header? I'd like to try
>> that.
>>
>> Regards,
>> Simon
>>
>>
>> On 12 May 2015 at 00:20, gabriel huau  wrote:
>>>
>>> Please ignore this email/patch, I put the wrong message id ...
>>>
>>>
>>> On 05/11/2015 11:12 PM, Gabriel Huau wrote:

 Signed-off-by: Gabriel Huau 
 Acked-by: Simon Glass 

 ---

 Changes in v3:
   - Rebase to the origin/master

 Changes in v2:
   - Fix ordering of include header

board/intel/minnowmax/minnowmax.c | 9 +
include/configs/minnowmax.h   | 1 +
2 files changed, 10 insertions(+)

 diff --git a/board/intel/minnowmax/minnowmax.c
 b/board/intel/minnowmax/minnowmax.c
 index 1f5549a..383cae0 100644
 --- a/board/intel/minnowmax/minnowmax.c
 +++ b/board/intel/minnowmax/minnowmax.c
 @@ -5,6 +5,7 @@
 */
  #include 
 +#include 
#include 
#include 
#include 
 @@ -12,6 +13,14 @@
  #define SERIAL_DEV PNP_DEV(0x2e, 4)
+int arch_early_init_r(void)
 +{
 +   /* do the pin-muxing */
 +   gpio_ich6_pinctrl_init();
 +
 +   return 0;
 +}
 +
int board_early_init_f(void)
{
  lpc47m_enable_serial(SERIAL_DEV, UART0_BASE, UART0_IRQ);
 diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
 index eb35a50..547765d 100644
 --- a/include/configs/minnowmax.h
 +++ b/include/configs/minnowmax.h
 @@ -15,6 +15,7 @@
  #define CONFIG_SYS_MONITOR_LEN  (1 << 20)
#define CONFIG_BOARD_EARLY_INIT_F
 +#define CONFIG_ARCH_EARLY_INIT_R
  #define CONFIG_X86_SERIAL
#define CONFIG_SMSC_LPC47M
>>>
>>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: ifdtool: Do not write region while its size is negative

[Simon Glass]

On 31 May 2015 at 00:57, Bin Meng  wrote:
>
> We should ignore those regions whose size is negative. These are
> typically optional and unused regions (like GbE and platform data).
>
> Signed-off-by: Bin Meng 
> ---
>
>  tools/ifdtool.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [RFC PATCH 1/2] x86: fsp: Load GDT before calling FspInitEntry

[Bin Meng]

Hi Simon,

On Thu, Jun 4, 2015 at 4:59 PM, Simon Glass  wrote:
> Hi Bin,
>
> On 1 June 2015 at 06:31, Bin Meng  wrote:
>> Currently the FSP execution environment GDT is setup by U-Boot in
>> arch/x86/cpu/start16.S, which works pretty well. But if we try to
>> move the FspInitEntry call a little bit later to better fit into
>> U-Boot's initialization sequence, FSP will fail to bring up the AP
>> due to #GP fault as AP's GDT is duplicated from BSP whose GDT is
>> now moved into CAR, and unfortunately FSP calls AP initialization
>> after it disables the CAR. So basically the BSP's GDT still refers
>> to the one in the CAR, whose content is no longer available, so
>> when AP starts up and loads its segment register, it blows up.
>>
>> To resolve this, we load GDT before calling into FspInitEntry.
>> The GDT is the same one used in arch/x86/cpu/start16.S, which is
>> in the ROM and exists forever.
>>
>> Signed-off-by: Bin Meng 
>> ---
>>
>>  arch/x86/cpu/cpu.c| 18 ++
>>  arch/x86/cpu/start16.S|  1 +
>>  arch/x86/include/asm/u-boot-x86.h |  4 
>>  arch/x86/lib/fsp/fsp_support.c|  3 +++
>>  4 files changed, 26 insertions(+)
>>
>> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
>> index bb4a110..a0b101c 100644
>> --- a/arch/x86/cpu/cpu.c
>> +++ b/arch/x86/cpu/cpu.c
>> @@ -164,6 +164,24 @@ void setup_gdt(gd_t *id, u64 *gdt_addr)
>> load_fs(X86_GDT_ENTRY_32BIT_FS);
>>  }
>>
>> +/*
>> + * Setup FSP execution environment GDT
>> + *
>> + * Per Intel FSP external architecture specification, before calling any FSP
>> + * APIs, we need make sure the system is in flat 32-bit mode and both the 
>> code
>> + * and data selectors should have full 4GB access range. Here we reuse the 
>> one
>> + * we used in arch/x86/cpu/start16.S, and reload the segement registers.
>> + */
>> +void setup_fsp_gdt(void)
>> +{
>> +   load_gdt((const u64 *)((u32)&gdt + BOOT_SEG), 4);
>> +   load_ds(X86_GDT_ENTRY_32BIT_DS);
>> +   load_ss(X86_GDT_ENTRY_32BIT_DS);
>> +   load_es(X86_GDT_ENTRY_32BIT_DS);
>> +   load_fs(X86_GDT_ENTRY_32BIT_DS);
>> +   load_gs(X86_GDT_ENTRY_32BIT_DS);
>> +}
>> +
>>  int __weak x86_cleanup_before_linux(void)
>>  {
>>  #ifdef CONFIG_BOOTSTAGE_STASH
>> diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
>> index 826e2b4..a3e7ab4 100644
>> --- a/arch/x86/cpu/start16.S
>> +++ b/arch/x86/cpu/start16.S
>> @@ -75,6 +75,7 @@ gdt_ptr:
>>
>> /* Some CPUs are picky about GDT alignment... */
>> .align  16
>> +.globl gdt
>>  gdt:
>> /*
>>  * The GDT table ...
>> diff --git a/arch/x86/include/asm/u-boot-x86.h 
>> b/arch/x86/include/asm/u-boot-x86.h
>> index be103c0..faa5182 100644
>> --- a/arch/x86/include/asm/u-boot-x86.h
>> +++ b/arch/x86/include/asm/u-boot-x86.h
>> @@ -8,12 +8,16 @@
>>  #ifndef _U_BOOT_I386_H_
>>  #define _U_BOOT_I386_H_1
>>
>> +#define BOOT_SEG   0x
>
> We have RESET_SEG_START in arch/x86/cpu/config.mk. We could move this
> to Kconfig if you like? But it would be good to avoid the duplication.

Yes, we could. Will do in v2.

>> +extern u32 gdt;
>> +
>>  /* cpu/.../cpu.c */
>>  int arch_cpu_init(void);
>>  int x86_cpu_init_f(void);
>>  int cpu_init_f(void);
>>  void init_gd(gd_t *id, u64 *gdt_addr);
>>  void setup_gdt(gd_t *id, u64 *gdt_addr);
>> +void setup_fsp_gdt(void);
>>  int init_cache(void);
>>  int cleanup_before_linux(void);
>>  void panic_puts(const char *str);
>> diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
>> index 5f96da1..cf6ed04 100644
>> --- a/arch/x86/lib/fsp/fsp_support.c
>> +++ b/arch/x86/lib/fsp/fsp_support.c
>> @@ -173,6 +173,9 @@ void fsp_init(u32 stack_top, u32 boot_mode, void 
>> *nvs_buf)
>>
>> post_code(POST_PRE_MRC);
>>
>> +   /* Load GDT for FSP */
>> +   setup_fsp_gdt();
>> +
>
> Where does the GDT get set back to the normal U-Boot one?

In arch/x86/cpu/start.S where U-Boot setup its new GDT with a new FS
segment descriptor.

>
>> /*
>>  * Use ASM code to ensure the register value in EAX & ECX
>>  * will be passed into BlContinuationFunc
>> --

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

Re: [U-Boot] [RFC PATCH 1/2] x86: fsp: Load GDT before calling FspInitEntry

[Simon Glass]

Hi Bin,

On 1 June 2015 at 06:31, Bin Meng  wrote:
> Currently the FSP execution environment GDT is setup by U-Boot in
> arch/x86/cpu/start16.S, which works pretty well. But if we try to
> move the FspInitEntry call a little bit later to better fit into
> U-Boot's initialization sequence, FSP will fail to bring up the AP
> due to #GP fault as AP's GDT is duplicated from BSP whose GDT is
> now moved into CAR, and unfortunately FSP calls AP initialization
> after it disables the CAR. So basically the BSP's GDT still refers
> to the one in the CAR, whose content is no longer available, so
> when AP starts up and loads its segment register, it blows up.
>
> To resolve this, we load GDT before calling into FspInitEntry.
> The GDT is the same one used in arch/x86/cpu/start16.S, which is
> in the ROM and exists forever.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/cpu/cpu.c| 18 ++
>  arch/x86/cpu/start16.S|  1 +
>  arch/x86/include/asm/u-boot-x86.h |  4 
>  arch/x86/lib/fsp/fsp_support.c|  3 +++
>  4 files changed, 26 insertions(+)
>
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index bb4a110..a0b101c 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -164,6 +164,24 @@ void setup_gdt(gd_t *id, u64 *gdt_addr)
> load_fs(X86_GDT_ENTRY_32BIT_FS);
>  }
>
> +/*
> + * Setup FSP execution environment GDT
> + *
> + * Per Intel FSP external architecture specification, before calling any FSP
> + * APIs, we need make sure the system is in flat 32-bit mode and both the 
> code
> + * and data selectors should have full 4GB access range. Here we reuse the 
> one
> + * we used in arch/x86/cpu/start16.S, and reload the segement registers.
> + */
> +void setup_fsp_gdt(void)
> +{
> +   load_gdt((const u64 *)((u32)&gdt + BOOT_SEG), 4);
> +   load_ds(X86_GDT_ENTRY_32BIT_DS);
> +   load_ss(X86_GDT_ENTRY_32BIT_DS);
> +   load_es(X86_GDT_ENTRY_32BIT_DS);
> +   load_fs(X86_GDT_ENTRY_32BIT_DS);
> +   load_gs(X86_GDT_ENTRY_32BIT_DS);
> +}
> +
>  int __weak x86_cleanup_before_linux(void)
>  {
>  #ifdef CONFIG_BOOTSTAGE_STASH
> diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
> index 826e2b4..a3e7ab4 100644
> --- a/arch/x86/cpu/start16.S
> +++ b/arch/x86/cpu/start16.S
> @@ -75,6 +75,7 @@ gdt_ptr:
>
> /* Some CPUs are picky about GDT alignment... */
> .align  16
> +.globl gdt
>  gdt:
> /*
>  * The GDT table ...
> diff --git a/arch/x86/include/asm/u-boot-x86.h 
> b/arch/x86/include/asm/u-boot-x86.h
> index be103c0..faa5182 100644
> --- a/arch/x86/include/asm/u-boot-x86.h
> +++ b/arch/x86/include/asm/u-boot-x86.h
> @@ -8,12 +8,16 @@
>  #ifndef _U_BOOT_I386_H_
>  #define _U_BOOT_I386_H_1
>
> +#define BOOT_SEG   0x

We have RESET_SEG_START in arch/x86/cpu/config.mk. We could move this
to Kconfig if you like? But it would be good to avoid the duplication.

> +extern u32 gdt;
> +
>  /* cpu/.../cpu.c */
>  int arch_cpu_init(void);
>  int x86_cpu_init_f(void);
>  int cpu_init_f(void);
>  void init_gd(gd_t *id, u64 *gdt_addr);
>  void setup_gdt(gd_t *id, u64 *gdt_addr);
> +void setup_fsp_gdt(void);
>  int init_cache(void);
>  int cleanup_before_linux(void);
>  void panic_puts(const char *str);
> diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
> index 5f96da1..cf6ed04 100644
> --- a/arch/x86/lib/fsp/fsp_support.c
> +++ b/arch/x86/lib/fsp/fsp_support.c
> @@ -173,6 +173,9 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
>
> post_code(POST_PRE_MRC);
>
> +   /* Load GDT for FSP */
> +   setup_fsp_gdt();
> +

Where does the GDT get set back to the normal U-Boot one?

> /*
>  * Use ASM code to ensure the register value in EAX & ECX
>  * will be passed into BlContinuationFunc
> --
> 1.8.2.1
>

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

Re: [U-Boot] [PATCH v2 2/5] x86: qemu: Add CMD_NET to qemu-x86_defconfig

[Simon Glass]

Hi Bin,

On 2 June 2015 at 19:20, Bin Meng  wrote:
> The following error is observed on QEMU x86.
>
> => print ipaddr
> ipaddr=192.168.178.66
> => ping 192.168.178.1
> *** ERROR: `ipaddr' not set
> ping failed; host 192.168.178.1 is not alive
>
> The issue was introduced in commit fd30563. Adding CMD_NET to
> defconfig resolves this.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - New patch to fix the networking issue
>
>  configs/qemu-x86_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
> index 198ab97..4509d52 100644
> --- a/configs/qemu-x86_defconfig
> +++ b/configs/qemu-x86_defconfig
> @@ -1,6 +1,7 @@
>  CONFIG_X86=y
>  CONFIG_VENDOR_EMULATION=y
>  CONFIG_TARGET_QEMU_X86=y
> +CONFIG_CMD_NET=y
>  CONFIG_OF_CONTROL=y
>  CONFIG_OF_SEPARATE=y
>  CONFIG_DEFAULT_DEVICE_TREE="qemu-x86"
> --
> 1.8.2.1
>

I'll squash this into your commit that adds qemu support.

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

Re: [U-Boot] [PATCH v3] x86: baytrail: pci region 3 is not always mapped to end of ram

[Simon Glass]

On 3 June 2015 at 18:15, Bin Meng  wrote:
> On Thu, Jun 4, 2015 at 12:37 AM,   wrote:
>> From: Andrew Bradford 
>>
>> Baytrail physically maps the first 2 GB of SDRAM from 0x0 to 0x7FFF
>> and additional SDRAM is mapped from 0x1 and up.  There is a
>> physical memory hole from 0x8000 to 0x for other uses.
>> Because of this, PCI region 3 should only try to use up to the amount of
>> SDRAM or 0x8000, which ever is less.
>>
>> Signed-off-by: Andrew Bradford 
>> ---
>> v3: Fix build breakage due to semicolon
>> v2: limit maximum size to lesser of SDRAM or 0x8000
>> ---
>>  arch/x86/cpu/baytrail/pci.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/cpu/baytrail/pci.c b/arch/x86/cpu/baytrail/pci.c
>> index 6c291f9..48409de 100644
>> --- a/arch/x86/cpu/baytrail/pci.c
>> +++ b/arch/x86/cpu/baytrail/pci.c
>> @@ -39,7 +39,7 @@ void board_pci_setup_hose(struct pci_controller *hose)
>> pci_set_region(hose->regions + 3,
>>0,
>>0,
>> -  gd->ram_size,
>> +  gd->ram_size < 0x8000 ? gd->ram_size : 0x8000,
>>PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>>
>> hose->region_count = 4;
>> --
>
> Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH v2 4/5] x86: coreboot: Control I/O port 0xb2 writing via device tree

[Simon Glass]

On 2 June 2015 at 19:20, Bin Meng  wrote:
> Writing 0xcb to I/O port 0xb2 (Advanced Power Management Control) causes
> U-Boot to hang on QEMU q35 target. We introduce a config option in the
> device tree "u-boot,no-apm-finalize" under /config node if we don't want
> to do that.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - Use a config option in the device tree instead of deleting the codes
>
>  arch/x86/cpu/coreboot/coreboot.c | 12 +---
>  arch/x86/dts/qemu-x86_q35.dts|  1 +
>  2 files changed, 10 insertions(+), 3 deletions(-)
>

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

Re: [U-Boot] [PATCH] x86: kconfig: Make FSP_TEMP_RAM_ADDR depend on HAVE_FSP

[Simon Glass]

On 1 June 2015 at 07:07, Bin Meng  wrote:
> FSP_TEMP_RAM_ADDR should only be visible when HAVE_FSP is on.
>
> Signed-off-by: Bin Meng 
> ---
>
>  arch/x86/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [PATCH v2 3/5] x86: qemu: Create separate i440fx and q35 device trees

[Simon Glass]

On 2 June 2015 at 19:20, Bin Meng  wrote:
> Although the two qemu-x86 targets (i440fx and q35) share a lot in
> common, they still have something that cannot easily handled in one
> single device tree). Split to create two dedicated device tree files
> and make the i440fx be the default build target.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - Still use one board configuration file qemu-x86.h
>
>  arch/x86/dts/Makefile   |  3 ++-
>  arch/x86/dts/qemu-x86_i440fx.dts| 34 
> +
>  arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} |  2 +-
>  board/coreboot/coreboot/Kconfig |  2 +-
>  configs/qemu-x86_defconfig  |  3 +--
>  doc/README.x86  | 10 +++-
>  6 files changed, 48 insertions(+), 6 deletions(-)
>  create mode 100644 arch/x86/dts/qemu-x86_i440fx.dts
>  rename arch/x86/dts/{qemu-x86.dts => qemu-x86_q35.dts} (95%)

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

[U-Boot] [PATCHv3 0/1] Add Toby-Churchill SL50 board support

[Enric Balletbo i Serra]

This patch series adds support for SL50 board based on TI AM335x SoC.

Changes since v2:
 - Rebased with current mainline.
 - Keep the TI copyright header on some files.
 - Add SPDX tags instead the full verbage.
 - Set default fdtfile to am335x-sl50.dtb (instead uses am33xx-sl50.dtb)

Changes since v1:
 - Rebased with current mainline.
 - Fix implicit declaration of function 'is_valid_ether_addr'
   (and the resulting link failure).

Best regards,

Enric Balletbo i Serra (1):
  board: Add Toby-Churchill SL50 board support.

 arch/arm/Kconfig  |   6 +
 board/tcl/sl50/Kconfig|  34 
 board/tcl/sl50/MAINTAINERS|   6 +
 board/tcl/sl50/Makefile   |  13 ++
 board/tcl/sl50/board.c| 386 ++
 board/tcl/sl50/board.h|  22 +++
 board/tcl/sl50/mux.c  | 154 +
 configs/am335x_sl50_defconfig |   7 +
 include/configs/am335x_sl50.h | 138 +++
 9 files changed, 766 insertions(+)
 create mode 100644 board/tcl/sl50/Kconfig
 create mode 100644 board/tcl/sl50/MAINTAINERS
 create mode 100644 board/tcl/sl50/Makefile
 create mode 100644 board/tcl/sl50/board.c
 create mode 100644 board/tcl/sl50/board.h
 create mode 100644 board/tcl/sl50/mux.c
 create mode 100644 configs/am335x_sl50_defconfig
 create mode 100644 include/configs/am335x_sl50.h

-- 
2.1.0

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

[U-Boot] [PATCHv3 1/1] board: Add Toby-Churchill SL50 board support.

[Enric Balletbo i Serra]

Add support for Lightwriter SL50 series board, a small, robust and portable
Voice Output Communication Aids (VOCA) designed to meet the particular and
changing needs of people with speech loss resulting from a wide range of
acquired, progressive and congenital conditions.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/Kconfig  |   6 +
 board/tcl/sl50/Kconfig|  34 
 board/tcl/sl50/MAINTAINERS|   6 +
 board/tcl/sl50/Makefile   |  13 ++
 board/tcl/sl50/board.c| 386 ++
 board/tcl/sl50/board.h|  22 +++
 board/tcl/sl50/mux.c  | 154 +
 configs/am335x_sl50_defconfig |   7 +
 include/configs/am335x_sl50.h | 138 +++
 9 files changed, 766 insertions(+)
 create mode 100644 board/tcl/sl50/Kconfig
 create mode 100644 board/tcl/sl50/MAINTAINERS
 create mode 100644 board/tcl/sl50/Makefile
 create mode 100644 board/tcl/sl50/board.c
 create mode 100644 board/tcl/sl50/board.h
 create mode 100644 board/tcl/sl50/mux.c
 create mode 100644 configs/am335x_sl50_defconfig
 create mode 100644 include/configs/am335x_sl50.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2985e6e..095c009 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -377,6 +377,11 @@ config TARGET_AM335X_EVM
select DM_SERIAL
select DM_GPIO
 
+config TARGET_AM335X_SL50
+   bool "Support am335x_sl50"
+   select CPU_V7
+   select SUPPORT_SPL
+
 config TARGET_AM43XX_EVM
bool "Support am43xx_evm"
select CPU_V7
@@ -949,6 +954,7 @@ source "board/st/stv0991/Kconfig"
 source "board/sunxi/Kconfig"
 source "board/syteco/zmx25/Kconfig"
 source "board/tbs/tbs2910/Kconfig"
+source "board/tcl/sl50/Kconfig"
 source "board/ti/am335x/Kconfig"
 source "board/ti/am43xx/Kconfig"
 source "board/birdland/bav335x/Kconfig"
diff --git a/board/tcl/sl50/Kconfig b/board/tcl/sl50/Kconfig
new file mode 100644
index 000..2b93aa2
--- /dev/null
+++ b/board/tcl/sl50/Kconfig
@@ -0,0 +1,34 @@
+if TARGET_AM335X_SL50
+
+config SYS_BOARD
+   default "sl50"
+
+config SYS_VENDOR
+   default "tcl"
+
+config SYS_SOC
+   default "am33xx"
+
+config SYS_CONFIG_NAME
+   default "am335x_sl50"
+
+config CONS_INDEX
+   int "UART used for console"
+   range 1 6
+   default 1
+   help
+ The AM335x SoC has a total of 6 UARTs (UART0 to UART5 as referenced
+ in documentation, etc) available to it.  Depending on your specific
+ board you may want something other than UART0 as for example the IDK
+ uses UART3 so enter 4 here.
+
+config DM
+   default y
+
+config DM_GPIO
+   default y if DM
+
+config DM_SERIAL
+   default y if DM
+
+endif
diff --git a/board/tcl/sl50/MAINTAINERS b/board/tcl/sl50/MAINTAINERS
new file mode 100644
index 000..29f1e3d
--- /dev/null
+++ b/board/tcl/sl50/MAINTAINERS
@@ -0,0 +1,6 @@
+SL50 BOARD
+M: Enric Balletbo i Serra 
+S: Maintained
+F: board/tcl/sl50/
+F: include/configs/am335x_sl50.h
+F: configs/am335x_sl50_defconfig
diff --git a/board/tcl/sl50/Makefile b/board/tcl/sl50/Makefile
new file mode 100644
index 000..d4a548c
--- /dev/null
+++ b/board/tcl/sl50/Makefile
@@ -0,0 +1,13 @@
+#
+# Makefile
+#
+# Copyright (C) 2015 Toby Churchill Ltd - http://www.toby-churchill.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifeq ($(CONFIG_SKIP_LOWLEVEL_INIT),)
+obj-y  := mux.o
+endif
+
+obj-y  += board.o
diff --git a/board/tcl/sl50/board.c b/board/tcl/sl50/board.c
new file mode 100644
index 000..e89ee35
--- /dev/null
+++ b/board/tcl/sl50/board.c
@@ -0,0 +1,386 @@
+/*
+ * board.c
+ *
+ * Board functions for TCL SL50 board
+ *
+ * Copyright (C) 2011, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "board.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
+
+#ifndef CONFIG_SKIP_LOWLEVEL_INIT
+
+static const struct ddr_data ddr3_sl50_data = {
+   .datardsratio0 = MT41K256M16HA125E_RD_DQS,
+   .datawdsratio0 = MT41K256M16HA125E_WR_DQS,
+   .datafwsratio0 = MT41K256M16HA125E_PHY_FIFO_WE,
+   .datawrsratio0 = MT41K256M16HA125E_PHY_WR_DATA,
+};
+
+static const struct cmd_control ddr3_sl50_cmd_ctrl_data = {
+   .cmd0csratio = MT41K256M16HA125E_RATIO,
+   .cmd0iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+
+   .cmd1csratio = MT41K256M16HA125E_RATIO,
+   .cmd1iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+
+   .cmd2csratio = MT41K256M16HA125E_RATIO,
+   .cmd2iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+};
+
+static struct emif_regs ddr3_sl50_emif_reg_data = {
+   .sdram_config = MT41K256M16HA125E_EMIF_SDCFG,
+   

[U-Boot] [PATCH v2] ARM: phytec: pcm051: select board revision by Kconfig

[poeschel]

From: Lars Poeschel 

This add a Kconfig entry that allows to set the board revision in
menuconfig. So the deprecated CONFIG_SYS_EXTRA_OPTIONS is no longer
needed for this boad.

Signed-off-by: Lars Poeschel 
---
 arch/arm/Kconfig  | 19 +--
 board/phytec/pcm051/Kconfig   | 11 +--
 board/phytec/pcm051/board.c   |  2 +-
 configs/pcm051_rev1_defconfig |  3 +--
 configs/pcm051_rev3_defconfig |  3 +--
 5 files changed, 29 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2985e6e..193a111 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -333,13 +333,28 @@ config TARGET_AM335X_IGEP0033
select DM_SERIAL
select DM_GPIO
 
-config TARGET_PCM051
-   bool "Support pcm051"
+config TARGET_PCM051_REV1
+   bool "Support pcm051 board revision 1 or 2"
select CPU_V7
select SUPPORT_SPL
select DM
select DM_SERIAL
select DM_GPIO
+   help
+ If you have 1358.1 written on the pcb of your pcm051, you
+ have a revision 1 board. Likewise if you have 1358.2 on your
+ board, it is a revision 2 board and this entry is for you.
+
+config TARGET_PCM051_REV3
+   bool "Support pcm051 board revision 3"
+   select CPU_V7
+   select SUPPORT_SPL
+   select DM
+   select DM_SERIAL
+   select DM_GPIO
+   help
+ If you have 1358.3 written on the pcb of your pcm051, you
+ have a revision 3 board and you have to select this entry.
 
 config TARGET_DRACO
bool "Support draco"
diff --git a/board/phytec/pcm051/Kconfig b/board/phytec/pcm051/Kconfig
index 2cc0d88..5981c72 100644
--- a/board/phytec/pcm051/Kconfig
+++ b/board/phytec/pcm051/Kconfig
@@ -1,7 +1,14 @@
-if TARGET_PCM051
+if TARGET_PCM051_REV1 || TARGET_PCM051_REV3
 
+if TARGET_PCM051_REV1
 config SYS_BOARD
-   default "pcm051"
+   default "pcm051rev1"
+endif
+
+if TARGET_PCM051_REV3
+config SYS_BOARD
+   default "pcm051rev3"
+endif
 
 config SYS_VENDOR
default "phytec"
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index 1bf9d73..3e01c01 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -49,7 +49,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
return &dpll_ddr;
 }
 
-#ifdef CONFIG_REV1
+#ifdef CONFIG_TARGET_PCM051_REV1
 const struct ctrl_ioregs ioregs = {
.cm0ioctl   = MT41J256M8HX15E_IOCTRL_VALUE,
.cm1ioctl   = MT41J256M8HX15E_IOCTRL_VALUE,
diff --git a/configs/pcm051_rev1_defconfig b/configs/pcm051_rev1_defconfig
index 1ea9333..239ed70 100644
--- a/configs/pcm051_rev1_defconfig
+++ b/configs/pcm051_rev1_defconfig
@@ -1,5 +1,4 @@
 CONFIG_ARM=y
-CONFIG_TARGET_PCM051=y
+CONFIG_TARGET_PCM051_REV1=y
 CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS="REV1"
 CONFIG_CMD_NET=y
diff --git a/configs/pcm051_rev3_defconfig b/configs/pcm051_rev3_defconfig
index a0a32f6..7992dc3 100644
--- a/configs/pcm051_rev3_defconfig
+++ b/configs/pcm051_rev3_defconfig
@@ -1,5 +1,4 @@
 CONFIG_ARM=y
-CONFIG_TARGET_PCM051=y
+CONFIG_TARGET_PCM051_REV3=y
 CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS="REV3"
 CONFIG_CMD_NET=y
-- 
2.1.4

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

Re: [U-Boot] [PATCH] ARM: phytec: pcm051: select board revision by Kconfig

[Lars Poeschel]

On Wed, Jun 03, 2015 at 11:20:25AM -0400, Tom Rini wrote:
> On Wed, Jun 03, 2015 at 04:36:06PM +0200, Lars Poeschel wrote:
> > On Tue, Jun 02, 2015 at 10:34:34AM -0400, Tom Rini wrote:
> > > On Mon, Jun 01, 2015 at 05:09:11PM +0200, poesc...@lemonage.de wrote:
> > > 
> > > > From: Lars Poeschel 
> > > > 
> > > > This add a Kconfig entry that allows to set the board revision in
> > > > menuconfig. So the deprecated CONFIG_SYS_EXTRA_OPTIONS is no longer
> > > > needed for this boad.
> > > > 
> > > > Signed-off-by: Lars Poeschel 
> > > 
> > > I like the concept but CONFIG_REVx is way too generic.  Can we maybe
> > > re-work things as CONFIG_TARGET_PCM051_REV1 / CONFIG_TARGET_PCM051_REV3
> > > (and those select CONFIG_TARGET_PCM051) ?  Masahiro?  Thanks!
> > 
> > Agree: CONFIG_REVx is too generic. I will send a version 2 of the patch,
> > but I don't understand why you want CONFIG_TARGET_PCM051_REV1 /
> > CONFIG_TARGET_PCM051_REV3 to select CONFIG_TARGET_PCM051. The
> > CONFIG_TARGET_PCM051_REVx's are inside an
> > 
> > if TARGET_PCM051
> > ...
> > endif
> > 
> > That means, that CONFIG_TARGET_PCM051 must already be selected to make
> > the *_REVx's visible and selectable.
> 
> Right.  I mean since we must select one of these boards at build-time,
> why not just ask about them up-front in arch/arm/Kconfig as rev1/rev3,

I wanted the initial list you choose your board from not to grow too
big. The (unsorted) list you scroll in menuconfig is already huge! I
like the aproach "Atmel AT91" takes more, and I'd propably even go
one step further an select a manufacturer as a first step and then
in a second step select a specific board from this manufacturer.
But if you prefer the other way - no problem. I tried that:

> and then have the main symbol be a hidden one, ie roughly:
> 
> config TARGET_PCM051
>   bool
> 
> config TARGET_PCM051_REV1
>   bool "Enable pcm051 rev1"
>   select TARGET_PCM051
>   help
> ...
> 
> config TARGET_PCM051_REV3
>   bool "Enable pcm051 rev3"
>   select TARGET_PCM051
>   help
> ...

I could not get this approach to work. It seems Kconfig does not support
hidden config options. I took a slightly different approach. I'll send a
PATCH V2 in a second. Please have a look, if that is what what you mean.

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