Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Jonathan Gray]

On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam  wrote:
> > Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> > SPL boot on i.MX6 starts to fail:
> >
> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> > Trying to boot from MMC1
> > (keep in loop)
> >
> > Use the original allocation scheme for the SPL case, so that MX6 boards
> > can boot again.
> >
> > This is a temporary solution to avoid the boot regression.
> >
> > Signed-off-by: Fabio Estevam 
> > ---
> > Hi Tom,
> >
> > I do not have time this week to further investigate and narrow down
> > this problem.
> >
> > Using the old allocation scheme fixes the mx6 SPL boot problem.
> >
> 
> Hi Tom, if you are ok with this as a temporary fix, then this is:
> 
> Acked-by: Rob Clark 
> 
> I'm getting some help from some of the fedora-arm folks so hopefully I
> can get some idea what is going wrong, but I'd like to unblock folks
> w/ mx6 boards..
> 
> BR,
> -R

This does not seem to be a complete fix, cubox is still broken when
U-Boot proper loads, unless the efi loader commits are to blame
for introducing unaligned accesses.

Works with 2017.09.

U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
Trying to boot from MMC1


U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)

CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 34C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM:  2 GiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to HDMI
Display: HDMI (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range - 

Re: [U-Boot] [PATCH v2 0/8] Sync and consolidate Linux-derived printk, BUILD_BUG, BUG, WARN, etc.

[Masahiro Yamada]

Hi Tom,


2017-10-05 12:06 GMT+09:00 Tom Rini :
> On Wed, Oct 04, 2017 at 02:15:19PM +0900, Masahiro Yamada wrote:
>> 2017-09-16 14:10 GMT+09:00 Masahiro Yamada :
>> >
>> > I tested this series with buildman.
>> >
>> >
>> >
>> > Masahiro Yamada (8):
>> >   stdio.h: move printf() stuff from  to 
>> >   printk: collect printk stuff into  with loglevel
>> > support
>> >   treewide: replace with error() with pr_err()
>> >   common.h: remove error()
>> >   vsprintf.h: include 
>> >   bug.h: sync BUILD_BUG stuff with Linux 4.13
>> >   bug.h: move runtime BUG/WARN macros into 
>> >   dm: define dev_*() log functions in DM header
>>
>> I am still worried if this series is dismissed.
>>
>> I am being blocked from importing NAND code from Linux
>> due to missing/incompatible Linux-derived macros.
>
> I am looking at this, but a default LOGLEVEL of 5 is just too high and
> I'm seeing what's reasonable now.
>

No.  I set the default to 6, not 5.

The reason why I chose 6 was to suppress a bunch of pr_info()
from drivers/mtd/nand/, which is a copy of Linux.


If you change it to a bigger number,
some annoying logs would be displayed after NAND:  tag.

If you change it to a smaller number,
pr_notice() would be suppressed.


The Linux doc says:

 5 (KERN_NOTICE) normal but significant condition


So, I think this is worth printing by default.


If you do not like it, you can change it,
but please make sure to adjust git-log.


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

Re: [U-Boot] [PATCH v2 0/8] Sync and consolidate Linux-derived printk, BUILD_BUG, BUG, WARN, etc.

[Tom Rini]

On Wed, Oct 04, 2017 at 02:15:19PM +0900, Masahiro Yamada wrote:
> 2017-09-16 14:10 GMT+09:00 Masahiro Yamada :
> >
> > I tested this series with buildman.
> >
> >
> >
> > Masahiro Yamada (8):
> >   stdio.h: move printf() stuff from  to 
> >   printk: collect printk stuff into  with loglevel
> > support
> >   treewide: replace with error() with pr_err()
> >   common.h: remove error()
> >   vsprintf.h: include 
> >   bug.h: sync BUILD_BUG stuff with Linux 4.13
> >   bug.h: move runtime BUG/WARN macros into 
> >   dm: define dev_*() log functions in DM header
> 
> I am still worried if this series is dismissed.
> 
> I am being blocked from importing NAND code from Linux
> due to missing/incompatible Linux-derived macros.

I am looking at this, but a default LOGLEVEL of 5 is just too high and
I'm seeing what's reasonable now.

-- 
Tom


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

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Heinrich Schuchardt]

On 10/05/2017 02:12 AM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 8:00 PM, Rob Clark  wrote:
>> On Wed, Oct 4, 2017 at 7:53 PM, Heinrich Schuchardt  
>> wrote:
>>> On 10/05/2017 01:19 AM, Rob Clark wrote:
 On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt  
 wrote:
> On 10/04/2017 10:54 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
>> wrote:
>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
 Shell.efi uses this, and supporting color attributes makes things look
 nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
 Not all colors have a perfect match, but spec just says "Devices
 supporting a different number of text colors are required to emulate 
 the
 above colors to the best of the device’s capabilities".

 Signed-off-by: Rob Clark 
 ---
  include/efi_api.h| 29 +
  lib/efi_loader/efi_console.c | 30 ++
  2 files changed, 59 insertions(+)

 diff --git a/include/efi_api.h b/include/efi_api.h
 index 87c8ffe68e..3cc1dbac2e 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -426,6 +426,35 @@ struct simple_text_output_mode {
   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)

 +#define EFI_BLACK0x00
 +#define EFI_BLUE 0x01
 +#define EFI_GREEN0x02
 +#define EFI_CYAN 0x03
 +#define EFI_RED  0x04
 +#define EFI_MAGENTA  0x05
 +#define EFI_BROWN0x06
 +#define EFI_LIGHTGRAY0x07
 +#define EFI_BRIGHT   0x08
 +#define EFI_DARKGRAY 0x08
 +#define EFI_LIGHTBLUE0x09
 +#define EFI_LIGHTGREEN   0x0a
 +#define EFI_LIGHTCYAN0x0b
 +#define EFI_LIGHTRED 0x0c
 +#define EFI_LIGHTMAGENTA 0x0d
 +#define EFI_YELLOW   0x0e
 +#define EFI_WHITE0x0f
 +#define EFI_BACKGROUND_BLACK 0x00
 +#define EFI_BACKGROUND_BLUE  0x10
 +#define EFI_BACKGROUND_GREEN 0x20
 +#define EFI_BACKGROUND_CYAN  0x30
 +#define EFI_BACKGROUND_RED   0x40
 +#define EFI_BACKGROUND_MAGENTA   0x50
 +#define EFI_BACKGROUND_BROWN 0x60
 +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>
>>> Will we ever use these constants?
>>>
>>
>> possibly not, but it is useful to understand what is going on with
>> efi->ansi mapping, so I would prefer to keep them.
>>
>>>
>>> Where are the comments explaining the defines below?
>>>
 +
 +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>>
>>> This saves 8 entries in the table below.
>>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>>
 +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>>
>>> Add
>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>
 +
  struct efi_simple_text_output_protocol {
   void *reset;
   efi_status_t (EFIAPI *output_string)(
 diff --git a/lib/efi_loader/efi_console.c 
 b/lib/efi_loader/efi_console.c
 index 2e13fdc096..fcd65ca488 100644
 --- a/lib/efi_loader/efi_console.c
 +++ b/lib/efi_loader/efi_console.c
 @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
   return EFI_EXIT(EFI_SUCCESS);
  }

 +static const struct {
 + unsigned fg;
 + unsigned bg;
 +} color[] = {
 + { 30, 40 }, /* 0: black */
 + { 34, 44 }, /* 1: blue */
 + { 32, 42 }, /* 2: green */
 + { 36, 46 }, /* 3: cyan */
 + { 31, 41 }, /* 4: red */
 + { 35, 45 }, /* 5: magenta */
 + { 30, 40 }, /* 6: brown, map to black */
>>>
>>> This should be { 33, 43 }
>>>
 + { 37, 47 }, /* 7: light grey, map to white */
>>>
>>> The entries below are redundant.
>>>
 + { 37, 47 }, /* 8: bright, map to white */
 + { 34, 44 }, /* 9: light blue, map to blue */
 + { 32, 42 }, /* A: light green, map to green */
 + { 36, 46 }, /* B: light cyan, map to cyan */
 + { 31, 41 }, /* C: light red, map to red */
 + { 35, 45 }, /* D: light magenta, map to magenta */
 + { 33, 43 }, /* E: yellow */
 + { 37, 47 }, /* F: white 

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Rob Clark]

On Wed, Oct 4, 2017 at 8:00 PM, Rob Clark  wrote:
> On Wed, Oct 4, 2017 at 7:53 PM, Heinrich Schuchardt  
> wrote:
>> On 10/05/2017 01:19 AM, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt  
>>> wrote:
 On 10/04/2017 10:54 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
> wrote:
>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>> Shell.efi uses this, and supporting color attributes makes things look
>>> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
>>> Not all colors have a perfect match, but spec just says "Devices
>>> supporting a different number of text colors are required to emulate the
>>> above colors to the best of the device’s capabilities".
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  include/efi_api.h| 29 +
>>>  lib/efi_loader/efi_console.c | 30 ++
>>>  2 files changed, 59 insertions(+)
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 87c8ffe68e..3cc1dbac2e 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>
>>> +#define EFI_BLACK0x00
>>> +#define EFI_BLUE 0x01
>>> +#define EFI_GREEN0x02
>>> +#define EFI_CYAN 0x03
>>> +#define EFI_RED  0x04
>>> +#define EFI_MAGENTA  0x05
>>> +#define EFI_BROWN0x06
>>> +#define EFI_LIGHTGRAY0x07
>>> +#define EFI_BRIGHT   0x08
>>> +#define EFI_DARKGRAY 0x08
>>> +#define EFI_LIGHTBLUE0x09
>>> +#define EFI_LIGHTGREEN   0x0a
>>> +#define EFI_LIGHTCYAN0x0b
>>> +#define EFI_LIGHTRED 0x0c
>>> +#define EFI_LIGHTMAGENTA 0x0d
>>> +#define EFI_YELLOW   0x0e
>>> +#define EFI_WHITE0x0f
>>> +#define EFI_BACKGROUND_BLACK 0x00
>>> +#define EFI_BACKGROUND_BLUE  0x10
>>> +#define EFI_BACKGROUND_GREEN 0x20
>>> +#define EFI_BACKGROUND_CYAN  0x30
>>> +#define EFI_BACKGROUND_RED   0x40
>>> +#define EFI_BACKGROUND_MAGENTA   0x50
>>> +#define EFI_BACKGROUND_BROWN 0x60
>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>
>> Will we ever use these constants?
>>
>
> possibly not, but it is useful to understand what is going on with
> efi->ansi mapping, so I would prefer to keep them.
>
>>
>> Where are the comments explaining the defines below?
>>
>>> +
>>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>
>> This saves 8 entries in the table below.
>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>
>>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>
>> Add
>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>
>>> +
>>>  struct efi_simple_text_output_protocol {
>>>   void *reset;
>>>   efi_status_t (EFIAPI *output_string)(
>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>> index 2e13fdc096..fcd65ca488 100644
>>> --- a/lib/efi_loader/efi_console.c
>>> +++ b/lib/efi_loader/efi_console.c
>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>   return EFI_EXIT(EFI_SUCCESS);
>>>  }
>>>
>>> +static const struct {
>>> + unsigned fg;
>>> + unsigned bg;
>>> +} color[] = {
>>> + { 30, 40 }, /* 0: black */
>>> + { 34, 44 }, /* 1: blue */
>>> + { 32, 42 }, /* 2: green */
>>> + { 36, 46 }, /* 3: cyan */
>>> + { 31, 41 }, /* 4: red */
>>> + { 35, 45 }, /* 5: magenta */
>>> + { 30, 40 }, /* 6: brown, map to black */
>>
>> This should be { 33, 43 }
>>
>>> + { 37, 47 }, /* 7: light grey, map to white */
>>
>> The entries below are redundant.
>>
>>> + { 37, 47 }, /* 8: bright, map to white */
>>> + { 34, 44 }, /* 9: light blue, map to blue */
>>> + { 32, 42 }, /* A: light green, map to green */
>>> + { 36, 46 }, /* B: light cyan, map to cyan */
>>> + { 31, 41 }, /* C: light red, map to red */
>>> + { 35, 45 }, /* D: light magenta, map to magenta */
>>> + { 33, 43 }, /* E: yellow */
>>> + { 37, 47 }, /* F: white */
>>> +};
>>> +
>
> I'm not totally convinced about mapping extra colors that UEFI defines
> to bold.. unless you have some example of prior-art for this on 

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Rob Clark]

On Wed, Oct 4, 2017 at 7:53 PM, Heinrich Schuchardt  wrote:
> On 10/05/2017 01:19 AM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt  
>> wrote:
>>> On 10/04/2017 10:54 PM, Rob Clark wrote:
 On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
 wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> Shell.efi uses this, and supporting color attributes makes things look
>> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
>> Not all colors have a perfect match, but spec just says "Devices
>> supporting a different number of text colors are required to emulate the
>> above colors to the best of the device’s capabilities".
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  include/efi_api.h| 29 +
>>  lib/efi_loader/efi_console.c | 30 ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 87c8ffe68e..3cc1dbac2e 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>
>> +#define EFI_BLACK0x00
>> +#define EFI_BLUE 0x01
>> +#define EFI_GREEN0x02
>> +#define EFI_CYAN 0x03
>> +#define EFI_RED  0x04
>> +#define EFI_MAGENTA  0x05
>> +#define EFI_BROWN0x06
>> +#define EFI_LIGHTGRAY0x07
>> +#define EFI_BRIGHT   0x08
>> +#define EFI_DARKGRAY 0x08
>> +#define EFI_LIGHTBLUE0x09
>> +#define EFI_LIGHTGREEN   0x0a
>> +#define EFI_LIGHTCYAN0x0b
>> +#define EFI_LIGHTRED 0x0c
>> +#define EFI_LIGHTMAGENTA 0x0d
>> +#define EFI_YELLOW   0x0e
>> +#define EFI_WHITE0x0f
>> +#define EFI_BACKGROUND_BLACK 0x00
>> +#define EFI_BACKGROUND_BLUE  0x10
>> +#define EFI_BACKGROUND_GREEN 0x20
>> +#define EFI_BACKGROUND_CYAN  0x30
>> +#define EFI_BACKGROUND_RED   0x40
>> +#define EFI_BACKGROUND_MAGENTA   0x50
>> +#define EFI_BACKGROUND_BROWN 0x60
>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>
> Will we ever use these constants?
>

 possibly not, but it is useful to understand what is going on with
 efi->ansi mapping, so I would prefer to keep them.

>
> Where are the comments explaining the defines below?
>
>> +
>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>
> This saves 8 entries in the table below.
> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>
>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>
> Add
> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>
>> +
>>  struct efi_simple_text_output_protocol {
>>   void *reset;
>>   efi_status_t (EFIAPI *output_string)(
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 2e13fdc096..fcd65ca488 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>   return EFI_EXIT(EFI_SUCCESS);
>>  }
>>
>> +static const struct {
>> + unsigned fg;
>> + unsigned bg;
>> +} color[] = {
>> + { 30, 40 }, /* 0: black */
>> + { 34, 44 }, /* 1: blue */
>> + { 32, 42 }, /* 2: green */
>> + { 36, 46 }, /* 3: cyan */
>> + { 31, 41 }, /* 4: red */
>> + { 35, 45 }, /* 5: magenta */
>> + { 30, 40 }, /* 6: brown, map to black */
>
> This should be { 33, 43 }
>
>> + { 37, 47 }, /* 7: light grey, map to white */
>
> The entries below are redundant.
>
>> + { 37, 47 }, /* 8: bright, map to white */
>> + { 34, 44 }, /* 9: light blue, map to blue */
>> + { 32, 42 }, /* A: light green, map to green */
>> + { 36, 46 }, /* B: light cyan, map to cyan */
>> + { 31, 41 }, /* C: light red, map to red */
>> + { 35, 45 }, /* D: light magenta, map to magenta */
>> + { 33, 43 }, /* E: yellow */
>> + { 37, 47 }, /* F: white */
>> +};
>> +

 I'm not totally convinced about mapping extra colors that UEFI defines
 to bold.. unless you have some example of prior-art for this on other
 platforms.
>>>
>>> See
>>> Standard ECMA-48 - Control Functions for Coded Character Sets
>>> chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
>>>
>>> 1 - bold or increased intensity

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Heinrich Schuchardt]

On 10/05/2017 01:19 AM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt  
> wrote:
>> On 10/04/2017 10:54 PM, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
>>> wrote:
 On 09/10/2017 03:22 PM, Rob Clark wrote:
> Shell.efi uses this, and supporting color attributes makes things look
> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
> Not all colors have a perfect match, but spec just says "Devices
> supporting a different number of text colors are required to emulate the
> above colors to the best of the device’s capabilities".
>
> Signed-off-by: Rob Clark 
> ---
>  include/efi_api.h| 29 +
>  lib/efi_loader/efi_console.c | 30 ++
>  2 files changed, 59 insertions(+)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 87c8ffe68e..3cc1dbac2e 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>
> +#define EFI_BLACK0x00
> +#define EFI_BLUE 0x01
> +#define EFI_GREEN0x02
> +#define EFI_CYAN 0x03
> +#define EFI_RED  0x04
> +#define EFI_MAGENTA  0x05
> +#define EFI_BROWN0x06
> +#define EFI_LIGHTGRAY0x07
> +#define EFI_BRIGHT   0x08
> +#define EFI_DARKGRAY 0x08
> +#define EFI_LIGHTBLUE0x09
> +#define EFI_LIGHTGREEN   0x0a
> +#define EFI_LIGHTCYAN0x0b
> +#define EFI_LIGHTRED 0x0c
> +#define EFI_LIGHTMAGENTA 0x0d
> +#define EFI_YELLOW   0x0e
> +#define EFI_WHITE0x0f
> +#define EFI_BACKGROUND_BLACK 0x00
> +#define EFI_BACKGROUND_BLUE  0x10
> +#define EFI_BACKGROUND_GREEN 0x20
> +#define EFI_BACKGROUND_CYAN  0x30
> +#define EFI_BACKGROUND_RED   0x40
> +#define EFI_BACKGROUND_MAGENTA   0x50
> +#define EFI_BACKGROUND_BROWN 0x60
> +#define EFI_BACKGROUND_LIGHTGRAY 0x70

 Will we ever use these constants?

>>>
>>> possibly not, but it is useful to understand what is going on with
>>> efi->ansi mapping, so I would prefer to keep them.
>>>

 Where are the comments explaining the defines below?

> +
> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)

 This saves 8 entries in the table below.
 +#define EFI_ATTR_FG(attr)((attr) & 0x07)

> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)

 Add
 #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)

> +
>  struct efi_simple_text_output_protocol {
>   void *reset;
>   efi_status_t (EFIAPI *output_string)(
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 2e13fdc096..fcd65ca488 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>   return EFI_EXIT(EFI_SUCCESS);
>  }
>
> +static const struct {
> + unsigned fg;
> + unsigned bg;
> +} color[] = {
> + { 30, 40 }, /* 0: black */
> + { 34, 44 }, /* 1: blue */
> + { 32, 42 }, /* 2: green */
> + { 36, 46 }, /* 3: cyan */
> + { 31, 41 }, /* 4: red */
> + { 35, 45 }, /* 5: magenta */
> + { 30, 40 }, /* 6: brown, map to black */

 This should be { 33, 43 }

> + { 37, 47 }, /* 7: light grey, map to white */

 The entries below are redundant.

> + { 37, 47 }, /* 8: bright, map to white */
> + { 34, 44 }, /* 9: light blue, map to blue */
> + { 32, 42 }, /* A: light green, map to green */
> + { 36, 46 }, /* B: light cyan, map to cyan */
> + { 31, 41 }, /* C: light red, map to red */
> + { 35, 45 }, /* D: light magenta, map to magenta */
> + { 33, 43 }, /* E: yellow */
> + { 37, 47 }, /* F: white */
> +};
> +
>>>
>>> I'm not totally convinced about mapping extra colors that UEFI defines
>>> to bold.. unless you have some example of prior-art for this on other
>>> platforms.
>>
>> See
>> Standard ECMA-48 - Control Functions for Coded Character Sets
>> chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
>>
>> 1 - bold or increased intensity
>> 22 - normal colour or normal intensity (neither bold nor faint)
>>
>> You can easily experiment in your bash shell like this:
>>
>> printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";
>>

[U-Boot] [PATCH] tools/mkimage: Fix DTC run command to handle file names with space

[Mirza, Taimoor]

From: "Mirza, Taimoor" 

fit_handle_file function does not quote input and output files while preparing
command to run DTC to convert .its to .itb. This results in a failure if input
or output files contain spaces in their names. Quote input and output files in
DTC command to avoid this failure.

Signed-off-by: Mirza, Taimoor 
---

 tools/fit_image.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/fit_image.c b/tools/fit_image.c
index 4dc8bd8..0f88c21 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -648,11 +648,11 @@ static int fit_handle_file(struct image_tool_params 
*params)
*cmd = '\0';
} else if (params->datafile) {
/* dtc -I dts -O dtb -p 500 datafile > tmpfile */
-   snprintf(cmd, sizeof(cmd), "%s %s %s > %s",
+   snprintf(cmd, sizeof(cmd), "%s %s \"%s\" > \"%s\"",
 MKIMAGE_DTC, params->dtc, params->datafile, tmpfile);
debug("Trying to execute \"%s\"\n", cmd);
} else {
-   snprintf(cmd, sizeof(cmd), "cp %s %s",
+   snprintf(cmd, sizeof(cmd), "cp \"%s\" \"%s\"",
 params->imagefile, tmpfile);
}
if (*cmd && system(cmd) == -1) {
-- 
1.9.1

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

[U-Boot] [PATCH] tools/mkimage: Fix DTC run command to handle file names with space

[Mirza, Taimoor]

From: "Mirza, Taimoor" 

fit_handle_file function does not quote input and output files while preparing
command to run DTC to convert .its to .itb. This results in a failure if input
or output files contain spaces in their names. Quote input and output files in
DTC command to avoid this failure.

Signed-off-by: Mirza, Taimoor 
---

 tools/fit_image.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/fit_image.c b/tools/fit_image.c
index 4dc8bd8..0f88c21 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -648,11 +648,11 @@ static int fit_handle_file(struct image_tool_params 
*params)
*cmd = '\0';
} else if (params->datafile) {
/* dtc -I dts -O dtb -p 500 datafile > tmpfile */
-   snprintf(cmd, sizeof(cmd), "%s %s %s > %s",
+   snprintf(cmd, sizeof(cmd), "%s %s \"%s\" > \"%s\"",
 MKIMAGE_DTC, params->dtc, params->datafile, tmpfile);
debug("Trying to execute \"%s\"\n", cmd);
} else {
-   snprintf(cmd, sizeof(cmd), "cp %s %s",
+   snprintf(cmd, sizeof(cmd), "cp \"%s\" \"%s\"",
 params->imagefile, tmpfile);
}
if (*cmd && system(cmd) == -1) {
-- 
1.9.1

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

[U-Boot] [PATCH] SPL: SPI: select SPL_SPI_FLASH_SUPPORT on SPL_SPI_SUNXI

[Andre Przywara]

The Allwinner SPI flash SPL boot support is guarded by the SPL_SPI_SUNXI
symbol. But despite its generic name, the actual only use case for this
is to provide SPI flash support to the SPL, which requires
CONFIG_SPL_SPI_FLASH_SUPPORT to be defined.
Select this symbol from the SPL_SPI_SUNXI Kconfig definition. This
avoids doing this explicitly in the defconfig, and fixes SPI booting on
the Pine64 SoPine (and -LTS version) and the OrangePi Win board (both with
SPI flash).

Signed-off-by: Andre Przywara 
---
 configs/orangepi_pc2_defconfig  | 1 -
 configs/orangepi_zero_defconfig | 1 -
 drivers/mtd/spi/Kconfig | 1 +
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 61b2d98705..ae732a8ee3 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=672
 CONFIG_DRAM_ZQ=3881977
diff --git a/configs/orangepi_zero_defconfig b/configs/orangepi_zero_defconfig
index 4d8d9262cb..64290ddd8f 100644
--- a/configs/orangepi_zero_defconfig
+++ b/configs/orangepi_zero_defconfig
@@ -1,6 +1,5 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=624
 CONFIG_DRAM_ZQ=3881979
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 5700859ff2..6ba255d676 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -140,6 +140,7 @@ if SPL
 config SPL_SPI_SUNXI
bool "Support for SPI Flash on Allwinner SoCs in SPL"
depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUNXI_H3_H5 
|| MACH_SUN50I
+   select SPL_SPI_FLASH_SUPPORT
---help---
Enable support for SPI Flash. This option allows SPL to read from
sunxi SPI Flash. It uses the same method as the boot ROM, so does
-- 
2.14.1

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

[U-Boot] [PATCH] ARM: SPL: FIT: fix DTC warnings on FIT generation

[Andre Przywara]

Newer versions of the device tree compiler (rightfully) complain about
mismatches between attributed node names (name@) and a missing
reg property in that node.
Adjust the FIT build script for 64-bit Allwinner boards to remove the
bogus addresses from the node names and avoid the warnings.

Signed-off-by: Andre Przywara 
---
 board/sunxi/mksunxi_fit_atf.sh | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/sunxi/mksunxi_fit_atf.sh b/board/sunxi/mksunxi_fit_atf.sh
index b1d6e0e16a..36abe9efed 100755
--- a/board/sunxi/mksunxi_fit_atf.sh
+++ b/board/sunxi/mksunxi_fit_atf.sh
@@ -21,7 +21,7 @@ cat << __HEADER_EOF
#address-cells = <1>;
 
images {
-   uboot@1 {
+   uboot {
description = "U-Boot (64-bit)";
data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
@@ -29,7 +29,7 @@ cat << __HEADER_EOF
compression = "none";
load = <0x4a00>;
};
-   atf@1 {
+   atf {
description = "ARM Trusted Firmware";
data = /incbin/("$BL31");
type = "firmware";
@@ -44,7 +44,7 @@ cnt=1
 for dtname in $*
 do
cat << __FDT_IMAGE_EOF
-   fdt@$cnt {
+   fdt_$cnt {
description = "$(basename $dtname .dtb)";
data = /incbin/("$dtname");
type = "flat_dt";
@@ -57,7 +57,7 @@ done
 cat << __CONF_HEADER_EOF
};
configurations {
-   default = "config@1";
+   default = "config_1";
 
 __CONF_HEADER_EOF
 
@@ -65,11 +65,11 @@ cnt=1
 for dtname in $*
 do
cat << __CONF_SECTION_EOF
-   config@$cnt {
+   config_$cnt {
description = "$(basename $dtname .dtb)";
-   firmware = "uboot@1";
-   loadables = "atf@1";
-   fdt = "fdt@$cnt";
+   firmware = "uboot";
+   loadables = "atf";
+   fdt = "fdt_$cnt";
};
 __CONF_SECTION_EOF
cnt=$((cnt+1))
-- 
2.14.1

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

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Rob Clark]

On Wed, Oct 4, 2017 at 6:01 PM, Heinrich Schuchardt  wrote:
> On 10/04/2017 10:54 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
>> wrote:
>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
 Shell.efi uses this, and supporting color attributes makes things look
 nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
 Not all colors have a perfect match, but spec just says "Devices
 supporting a different number of text colors are required to emulate the
 above colors to the best of the device’s capabilities".

 Signed-off-by: Rob Clark 
 ---
  include/efi_api.h| 29 +
  lib/efi_loader/efi_console.c | 30 ++
  2 files changed, 59 insertions(+)

 diff --git a/include/efi_api.h b/include/efi_api.h
 index 87c8ffe68e..3cc1dbac2e 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -426,6 +426,35 @@ struct simple_text_output_mode {
   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)

 +#define EFI_BLACK0x00
 +#define EFI_BLUE 0x01
 +#define EFI_GREEN0x02
 +#define EFI_CYAN 0x03
 +#define EFI_RED  0x04
 +#define EFI_MAGENTA  0x05
 +#define EFI_BROWN0x06
 +#define EFI_LIGHTGRAY0x07
 +#define EFI_BRIGHT   0x08
 +#define EFI_DARKGRAY 0x08
 +#define EFI_LIGHTBLUE0x09
 +#define EFI_LIGHTGREEN   0x0a
 +#define EFI_LIGHTCYAN0x0b
 +#define EFI_LIGHTRED 0x0c
 +#define EFI_LIGHTMAGENTA 0x0d
 +#define EFI_YELLOW   0x0e
 +#define EFI_WHITE0x0f
 +#define EFI_BACKGROUND_BLACK 0x00
 +#define EFI_BACKGROUND_BLUE  0x10
 +#define EFI_BACKGROUND_GREEN 0x20
 +#define EFI_BACKGROUND_CYAN  0x30
 +#define EFI_BACKGROUND_RED   0x40
 +#define EFI_BACKGROUND_MAGENTA   0x50
 +#define EFI_BACKGROUND_BROWN 0x60
 +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>>
>>> Will we ever use these constants?
>>>
>>
>> possibly not, but it is useful to understand what is going on with
>> efi->ansi mapping, so I would prefer to keep them.
>>
>>>
>>> Where are the comments explaining the defines below?
>>>
 +
 +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>>
>>> This saves 8 entries in the table below.
>>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>>
 +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>>
>>> Add
>>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>>
 +
  struct efi_simple_text_output_protocol {
   void *reset;
   efi_status_t (EFIAPI *output_string)(
 diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
 index 2e13fdc096..fcd65ca488 100644
 --- a/lib/efi_loader/efi_console.c
 +++ b/lib/efi_loader/efi_console.c
 @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
   return EFI_EXIT(EFI_SUCCESS);
  }

 +static const struct {
 + unsigned fg;
 + unsigned bg;
 +} color[] = {
 + { 30, 40 }, /* 0: black */
 + { 34, 44 }, /* 1: blue */
 + { 32, 42 }, /* 2: green */
 + { 36, 46 }, /* 3: cyan */
 + { 31, 41 }, /* 4: red */
 + { 35, 45 }, /* 5: magenta */
 + { 30, 40 }, /* 6: brown, map to black */
>>>
>>> This should be { 33, 43 }
>>>
 + { 37, 47 }, /* 7: light grey, map to white */
>>>
>>> The entries below are redundant.
>>>
 + { 37, 47 }, /* 8: bright, map to white */
 + { 34, 44 }, /* 9: light blue, map to blue */
 + { 32, 42 }, /* A: light green, map to green */
 + { 36, 46 }, /* B: light cyan, map to cyan */
 + { 31, 41 }, /* C: light red, map to red */
 + { 35, 45 }, /* D: light magenta, map to magenta */
 + { 33, 43 }, /* E: yellow */
 + { 37, 47 }, /* F: white */
 +};
 +
>>
>> I'm not totally convinced about mapping extra colors that UEFI defines
>> to bold.. unless you have some example of prior-art for this on other
>> platforms.
>
> See
> Standard ECMA-48 - Control Functions for Coded Character Sets
> chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION
>
> 1 - bold or increased intensity
> 22 - normal colour or normal intensity (neither bold nor faint)
>
> You can easily experiment in your bash shell like this:
>
> printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";
>
> You will find that "bold" prints bold and bright in the KDE konsole and
> xterm.

but I think we don't want (potential) font changes, just color changes..

if you can 

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Heinrich Schuchardt]

On 10/04/2017 10:54 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  
> wrote:
>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>> Shell.efi uses this, and supporting color attributes makes things look
>>> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
>>> Not all colors have a perfect match, but spec just says "Devices
>>> supporting a different number of text colors are required to emulate the
>>> above colors to the best of the device’s capabilities".
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  include/efi_api.h| 29 +
>>>  lib/efi_loader/efi_console.c | 30 ++
>>>  2 files changed, 59 insertions(+)
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 87c8ffe68e..3cc1dbac2e 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>>
>>> +#define EFI_BLACK0x00
>>> +#define EFI_BLUE 0x01
>>> +#define EFI_GREEN0x02
>>> +#define EFI_CYAN 0x03
>>> +#define EFI_RED  0x04
>>> +#define EFI_MAGENTA  0x05
>>> +#define EFI_BROWN0x06
>>> +#define EFI_LIGHTGRAY0x07
>>> +#define EFI_BRIGHT   0x08
>>> +#define EFI_DARKGRAY 0x08
>>> +#define EFI_LIGHTBLUE0x09
>>> +#define EFI_LIGHTGREEN   0x0a
>>> +#define EFI_LIGHTCYAN0x0b
>>> +#define EFI_LIGHTRED 0x0c
>>> +#define EFI_LIGHTMAGENTA 0x0d
>>> +#define EFI_YELLOW   0x0e
>>> +#define EFI_WHITE0x0f
>>> +#define EFI_BACKGROUND_BLACK 0x00
>>> +#define EFI_BACKGROUND_BLUE  0x10
>>> +#define EFI_BACKGROUND_GREEN 0x20
>>> +#define EFI_BACKGROUND_CYAN  0x30
>>> +#define EFI_BACKGROUND_RED   0x40
>>> +#define EFI_BACKGROUND_MAGENTA   0x50
>>> +#define EFI_BACKGROUND_BROWN 0x60
>>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>>
>> Will we ever use these constants?
>>
> 
> possibly not, but it is useful to understand what is going on with
> efi->ansi mapping, so I would prefer to keep them.
> 
>>
>> Where are the comments explaining the defines below?
>>
>>> +
>>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>>
>> This saves 8 entries in the table below.
>> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>>
>>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>>
>> Add
>> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>>
>>> +
>>>  struct efi_simple_text_output_protocol {
>>>   void *reset;
>>>   efi_status_t (EFIAPI *output_string)(
>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>> index 2e13fdc096..fcd65ca488 100644
>>> --- a/lib/efi_loader/efi_console.c
>>> +++ b/lib/efi_loader/efi_console.c
>>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>>   return EFI_EXIT(EFI_SUCCESS);
>>>  }
>>>
>>> +static const struct {
>>> + unsigned fg;
>>> + unsigned bg;
>>> +} color[] = {
>>> + { 30, 40 }, /* 0: black */
>>> + { 34, 44 }, /* 1: blue */
>>> + { 32, 42 }, /* 2: green */
>>> + { 36, 46 }, /* 3: cyan */
>>> + { 31, 41 }, /* 4: red */
>>> + { 35, 45 }, /* 5: magenta */
>>> + { 30, 40 }, /* 6: brown, map to black */
>>
>> This should be { 33, 43 }
>>
>>> + { 37, 47 }, /* 7: light grey, map to white */
>>
>> The entries below are redundant.
>>
>>> + { 37, 47 }, /* 8: bright, map to white */
>>> + { 34, 44 }, /* 9: light blue, map to blue */
>>> + { 32, 42 }, /* A: light green, map to green */
>>> + { 36, 46 }, /* B: light cyan, map to cyan */
>>> + { 31, 41 }, /* C: light red, map to red */
>>> + { 35, 45 }, /* D: light magenta, map to magenta */
>>> + { 33, 43 }, /* E: yellow */
>>> + { 37, 47 }, /* F: white */
>>> +};
>>> +
> 
> I'm not totally convinced about mapping extra colors that UEFI defines
> to bold.. unless you have some example of prior-art for this on other
> platforms.

See
Standard ECMA-48 - Control Functions for Coded Character Sets
chapter 8.3.117 SGR - SELECT GRAPHIC RENDITION

1 - bold or increased intensity
22 - normal colour or normal intensity (neither bold nor faint)

You can easily experiment in your bash shell like this:

printf "\x1b[1;32;40m bold \x1b[22;32;40m normal\x1b[22;39;49m\n";

You will find that "bold" prints bold and bright in the KDE konsole and
xterm.

Using colors 90-97 as foreground colors produces only bright but not
bold in the KDE konsole and xterm:

printf "\x1b[92;40m bold \x1b[32;40m normal\x1b[22;39;49m\n";

But these codes are not defined in ECMA-48.

Best regards

Heinrich

___
U-Boot mailing 

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Rob Clark]

On Wed, Oct 4, 2017 at 2:53 PM, Heinrich Schuchardt  wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> Shell.efi uses this, and supporting color attributes makes things look
>> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
>> Not all colors have a perfect match, but spec just says "Devices
>> supporting a different number of text colors are required to emulate the
>> above colors to the best of the device’s capabilities".
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  include/efi_api.h| 29 +
>>  lib/efi_loader/efi_console.c | 30 ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 87c8ffe68e..3cc1dbac2e 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>>
>> +#define EFI_BLACK0x00
>> +#define EFI_BLUE 0x01
>> +#define EFI_GREEN0x02
>> +#define EFI_CYAN 0x03
>> +#define EFI_RED  0x04
>> +#define EFI_MAGENTA  0x05
>> +#define EFI_BROWN0x06
>> +#define EFI_LIGHTGRAY0x07
>> +#define EFI_BRIGHT   0x08
>> +#define EFI_DARKGRAY 0x08
>> +#define EFI_LIGHTBLUE0x09
>> +#define EFI_LIGHTGREEN   0x0a
>> +#define EFI_LIGHTCYAN0x0b
>> +#define EFI_LIGHTRED 0x0c
>> +#define EFI_LIGHTMAGENTA 0x0d
>> +#define EFI_YELLOW   0x0e
>> +#define EFI_WHITE0x0f
>> +#define EFI_BACKGROUND_BLACK 0x00
>> +#define EFI_BACKGROUND_BLUE  0x10
>> +#define EFI_BACKGROUND_GREEN 0x20
>> +#define EFI_BACKGROUND_CYAN  0x30
>> +#define EFI_BACKGROUND_RED   0x40
>> +#define EFI_BACKGROUND_MAGENTA   0x50
>> +#define EFI_BACKGROUND_BROWN 0x60
>> +#define EFI_BACKGROUND_LIGHTGRAY 0x70
>
> Will we ever use these constants?
>

possibly not, but it is useful to understand what is going on with
efi->ansi mapping, so I would prefer to keep them.

>
> Where are the comments explaining the defines below?
>
>> +
>> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)
>
> This saves 8 entries in the table below.
> +#define EFI_ATTR_FG(attr)((attr) & 0x07)
>
>> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)
>
> Add
> #define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)
>
>> +
>>  struct efi_simple_text_output_protocol {
>>   void *reset;
>>   efi_status_t (EFIAPI *output_string)(
>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>> index 2e13fdc096..fcd65ca488 100644
>> --- a/lib/efi_loader/efi_console.c
>> +++ b/lib/efi_loader/efi_console.c
>> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>>   return EFI_EXIT(EFI_SUCCESS);
>>  }
>>
>> +static const struct {
>> + unsigned fg;
>> + unsigned bg;
>> +} color[] = {
>> + { 30, 40 }, /* 0: black */
>> + { 34, 44 }, /* 1: blue */
>> + { 32, 42 }, /* 2: green */
>> + { 36, 46 }, /* 3: cyan */
>> + { 31, 41 }, /* 4: red */
>> + { 35, 45 }, /* 5: magenta */
>> + { 30, 40 }, /* 6: brown, map to black */
>
> This should be { 33, 43 }
>
>> + { 37, 47 }, /* 7: light grey, map to white */
>
> The entries below are redundant.
>
>> + { 37, 47 }, /* 8: bright, map to white */
>> + { 34, 44 }, /* 9: light blue, map to blue */
>> + { 32, 42 }, /* A: light green, map to green */
>> + { 36, 46 }, /* B: light cyan, map to cyan */
>> + { 31, 41 }, /* C: light red, map to red */
>> + { 35, 45 }, /* D: light magenta, map to magenta */
>> + { 33, 43 }, /* E: yellow */
>> + { 37, 47 }, /* F: white */
>> +};
>> +

I'm not totally convinced about mapping extra colors that UEFI defines
to bold.. unless you have some example of prior-art for this on other
platforms.

There are ansi extensions that allow for more colors, we could perhaps
map the extra EFI colors to the base sequence (presumably more widely
supported) followed by the extended sequence (which presumably not all
terminal emulators support)..  I'm not sure if it is worth the effort.
The current patch implements something that is at least fairly
reasonable and within the bounds of what the spec says (ie. "Devices
supporting a different number of text colors are required to emulate
the above colors to the best of the device’s capabilities.")

BR,
-R

>
> No function without a comment explaining the parameters.
>
>>  static efi_status_t EFIAPI efi_cout_set_attribute(
>>   struct efi_simple_text_output_protocol *this,
>>   unsigned long attribute)
>>  {
>> + unsigned fg = EFI_ATTR_FG(attribute);
>> + unsigned bg = 

[U-Boot] [PATCH] distro: load FDT from any partition on boot device

[Rob Clark]

In the EFI_LOADER boot path, we were only checking the FAT partition
containing the EFI payload for dtb files.  But this is somewhat of a
fiction.  In reality there will be one small (V)FAT partition containing
grub (or whatever the payload may be), and a second boot partition
containing kernel/initrd/fdt (typically ext4).  It is this second
partition where we should be looking for a FDT to load.

So instead scan all the partitions of the disk containing the EFI
payload.  This matches where grub looks for kernel/initrd (barring
custom grub.cfg, in which case the user can use grub's 'devicetree'
command to load the correct FDT).

The other option is somehow passing the ${fdtfile} to grub so that it
can load the FDT based on selected kernel version location (which grub
knows) and SoC/board specific ${fdtfile} (which grub does not know).

Signed-off-by: Rob Clark 
---
 include/config_distro_bootcmd.h | 34 +++---
 1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index e232a62996..58b2fe3371 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -126,25 +126,37 @@
"fi\0"\
\
"load_efi_dtb="   \
-   "load ${devtype} ${devnum}:${distro_bootpart} "   \
-   "${fdt_addr_r} ${prefix}${efi_fdtfile}\0" \
+   "load ${devtype} ${devnum}:${dtb_devp} "  \
+   "${fdt_addr_r} ${prefix}${efi_fdtfile} && "   \
+   "run boot_efi_binary\0"   \
\
"efi_dtb_prefixes=/ /dtb/ /dtb/current/\0"\
-   "scan_dev_for_efi="   \
+   "scan_dev_for_dtb="   \
"setenv efi_fdtfile ${fdtfile}; " \
BOOTENV_EFI_SET_FDTFILE_FALLBACK  \
-   "for prefix in ${efi_dtb_prefixes}; do "  \
-   "if test -e ${devtype} "  \
-   "${devnum}:${distro_bootpart} "   \
-   "${prefix}${efi_fdtfile}; then "  \
-   "run load_efi_dtb; "  \
-   "fi;" \
-   "done;"   \
+   "part list ${devtype} ${devnum} dtb_devplist; "   \
+   "env exists dtb_devplist || setenv dtb_devplist " \
+   "${distro_bootpart}; "\
+   "for dtb_devp in ${dtb_devplist}; do "\
+   "for prefix in ${efi_dtb_prefixes}; do "  \
+   "if test -e ${devtype} "  \
+   "${devnum}:${dtb_devp} "  \
+   "${prefix}${efi_fdtfile};"\
+   " then "  \
+   "echo Found DTB ${devtype} "  \
+   "${devnum}:${dtb_devp} "  \
+   "${prefix}${efi_fdtfile};"\
+   "run load_efi_dtb; "  \
+   "fi;" \
+   "done; "  \
+   "done; "  \
+   "run boot_efi_binary\0"   \
+   "scan_dev_for_efi="   \
"if test -e ${devtype} ${devnum}:${distro_bootpart} " \
"efi/boot/"BOOTEFI_NAME"; then "  \
"echo Found EFI removable media binary "  \
"efi/boot/"BOOTEFI_NAME"; "   \
-   "run boot_efi_binary; "   \
+   "run scan_dev_for_dtb; "  \
"echo EFI LOAD FAILED: continuing...; "   \
"fi; "\
"setenv efi_fdtfile\0"
-- 
2.13.5

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

Re: [U-Boot] [PATCH v1 09/12] dm: video: Fix cache flushes

[Heinrich Schuchardt]

On 09/10/2017 03:22 PM, Rob Clark wrote:
> Content can come to screen via putc() and we cannot always rely on
> updates ending with a puts().

The commit message does not explain why you are modifying videconsole_puts.

Probably you wanted to refer to a newline character '\n' which leads to
calling video_sync without your patch. Please, update the commit message.

The code change looks correct to me.

Acked-by: Heinrich Schuchardt 

> This is the case with efi_console output
> to vidconsole.  Fixes corruption with Shell.efi.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/video/vidconsole-uclass.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/video/vidconsole-uclass.c 
> b/drivers/video/vidconsole-uclass.c
> index b5afd72227..e081d5a0ee 100644
> --- a/drivers/video/vidconsole-uclass.c
> +++ b/drivers/video/vidconsole-uclass.c
> @@ -163,6 +163,7 @@ static void vidconsole_putc(struct stdio_dev *sdev, const 
> char ch)
>   struct udevice *dev = sdev->priv;
>  
>   vidconsole_put_char(dev, ch);
> + video_sync(dev->parent);
>  }
>  
>  static void vidconsole_puts(struct stdio_dev *sdev, const char *s)
> @@ -260,6 +261,8 @@ static int do_video_puts(cmd_tbl_t *cmdtp, int flag, int 
> argc,
>   for (s = argv[1]; *s; s++)
>   vidconsole_put_char(dev, *s);
>  
> + video_sync(dev->parent);
> +
>   return 0;
>  }
>  
> 

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

Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub

[Heinrich Schuchardt]

On 10/04/2017 08:57 PM, Heinrich Schuchardt wrote:
> On 10/04/2017 08:35 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 1:57 PM, Heinrich Schuchardt  
>> wrote:
>>> On 09/10/2017 03:22 PM, Rob Clark wrote:
 From: Leif Lindholm 
>>>
>>> The commit message is missing.
>>>
>>> Fix all issues reported by checkpatch.
>>>

 Signed-off-by: Leif Lindholm 
 ---
  include/efi_api.h | 33 +++
  include/efi_loader.h  |  2 ++
  lib/efi_loader/Makefile   |  2 +-
  lib/efi_loader/efi_boottime.c |  3 ++
  lib/efi_loader/efi_unicode.c  | 73 
 +++
  5 files changed, 112 insertions(+), 1 deletion(-)
  create mode 100644 lib/efi_loader/efi_unicode.c

 diff --git a/include/efi_api.h b/include/efi_api.h
 index 932a3429a8..25f774f253 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -740,6 +740,39 @@ struct efi_hii_string_protocol
   UINTN *secondary_languages_size);
  };

 +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
 + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
 +  0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
 +
 +struct efi_unicode_collation_protocol
 +{
>>>
>>> ERROR: open brace '{' following struct go on the same line
>>> #30: FILE: include/efi_api.h:748:
>>> +struct efi_unicode_collation_protocol
>>> +{
>>>
 + INTN(EFIAPI *stri_coll)(
 + struct efi_unicode_collation_protocol *this,
 + efi_string_t s1,
 + efi_string_t s2);
 + bool(EFIAPI *metai_match)(
 + struct efi_unicode_collation_protocol *this,
 + efi_string_t string,
 + efi_string_t pattern);
 + void(EFIAPI *str_lwr)(
 + struct efi_unicode_collation_protocol *this,
 + efi_string_t string);
 + void(EFIAPI *str_upr)(
 + struct efi_unicode_collation_protocol *this,
 + efi_string_t string);
 + void(EFIAPI *fat_to_str)(
 + struct efi_unicode_collation_protocol *this,
 + UINTN fat_size,
 + uint8_t *fat,
 + efi_string_t string);
 + bool(EFIAPI *str_to_fat)(
 + struct efi_unicode_collation_protocol *this,
 + efi_string_t string,
 + UINTN fat_size,
 + uint8_t *fat);
 + uint8_t *supported_languages;
 +};
 +
  #define EFI_GOP_GUID \
   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
 diff --git a/include/efi_loader.h b/include/efi_loader.h
 index a89bb2fcd9..6668338d0b 100644
 --- a/include/efi_loader.h
 +++ b/include/efi_loader.h
 @@ -62,6 +62,7 @@ extern const struct efi_device_path_utilities_protocol 
 efi_device_path_utilities
  extern const struct efi_hii_config_routing_protocol 
 efi_hii_config_routing;
  extern const struct efi_hii_database_protocol efi_hii_database;
  extern const struct efi_hii_string_protocol efi_hii_string;
 +extern const struct efi_unicode_collation_protocol efi_unicode_collation;

  uint16_t *efi_dp_str(struct efi_device_path *dp);

 @@ -76,6 +77,7 @@ extern const efi_guid_t 
 efi_guid_device_path_utilities_protocol;
  extern const efi_guid_t efi_guid_hii_config_routing_protocol;
  extern const efi_guid_t efi_guid_hii_database_protocol;
  extern const efi_guid_t efi_guid_hii_string_protocol;
 +extern const efi_guid_t efi_guid_unicode_collation_protocol2;

  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
 diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
 index e8fd6823a3..82b703bb39 100644
 --- a/lib/efi_loader/Makefile
 +++ b/lib/efi_loader/Makefile
 @@ -16,7 +16,7 @@ always := $(efiprogs-y)
  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
 -obj-y += efi_device_path_utilities.o efi_hii.o
 +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
  obj-$(CONFIG_LCD) += efi_gop.o
  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
 diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
 index 4d1a16051b..04358e8aca 100644
 --- a/lib/efi_loader/efi_boottime.c
 +++ b/lib/efi_loader/efi_boottime.c
 @@ -788,6 +788,9 @@ void efi_setup_loaded_image(struct efi_loaded_image 
 *info, struct efi_object *ob
   obj->protocols[7].guid = _guid_hii_config_routing_protocol;
   

Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub

[Peter Jones]

On Wed, Oct 04, 2017 at 06:35:46PM +, Rob Clark wrote:
> > Add the missing EFIAPI.
> 
> I was talking to Peter Jones about this, and he suggested something
> that makes *way* more sense.. just build u-boot with '-mabi=ms_abi' on
> x86_64 (at least conditionally if EFI_LOADER is enabled).  That would
> take a bit of work to annotate the os layer in sandbox to use sysv
> abi, but that is a lot smaller of an interface than EFI_LOADER (which
> is only going to continue to grow).

Worth noting that if we went this route, we'd also need to do
-mregparm=0 on 32-bit x86.

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

Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub

[Heinrich Schuchardt]

On 10/04/2017 08:35 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 1:57 PM, Heinrich Schuchardt  
> wrote:
>> On 09/10/2017 03:22 PM, Rob Clark wrote:
>>> From: Leif Lindholm 
>>
>> The commit message is missing.
>>
>> Fix all issues reported by checkpatch.
>>
>>>
>>> Signed-off-by: Leif Lindholm 
>>> ---
>>>  include/efi_api.h | 33 +++
>>>  include/efi_loader.h  |  2 ++
>>>  lib/efi_loader/Makefile   |  2 +-
>>>  lib/efi_loader/efi_boottime.c |  3 ++
>>>  lib/efi_loader/efi_unicode.c  | 73 
>>> +++
>>>  5 files changed, 112 insertions(+), 1 deletion(-)
>>>  create mode 100644 lib/efi_loader/efi_unicode.c
>>>
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 932a3429a8..25f774f253 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -740,6 +740,39 @@ struct efi_hii_string_protocol
>>>   UINTN *secondary_languages_size);
>>>  };
>>>
>>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>>> +  0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>>> +
>>> +struct efi_unicode_collation_protocol
>>> +{
>>
>> ERROR: open brace '{' following struct go on the same line
>> #30: FILE: include/efi_api.h:748:
>> +struct efi_unicode_collation_protocol
>> +{
>>
>>> + INTN(EFIAPI *stri_coll)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t s1,
>>> + efi_string_t s2);
>>> + bool(EFIAPI *metai_match)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string,
>>> + efi_string_t pattern);
>>> + void(EFIAPI *str_lwr)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string);
>>> + void(EFIAPI *str_upr)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string);
>>> + void(EFIAPI *fat_to_str)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + UINTN fat_size,
>>> + uint8_t *fat,
>>> + efi_string_t string);
>>> + bool(EFIAPI *str_to_fat)(
>>> + struct efi_unicode_collation_protocol *this,
>>> + efi_string_t string,
>>> + UINTN fat_size,
>>> + uint8_t *fat);
>>> + uint8_t *supported_languages;
>>> +};
>>> +
>>>  #define EFI_GOP_GUID \
>>>   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>>> index a89bb2fcd9..6668338d0b 100644
>>> --- a/include/efi_loader.h
>>> +++ b/include/efi_loader.h
>>> @@ -62,6 +62,7 @@ extern const struct efi_device_path_utilities_protocol 
>>> efi_device_path_utilities
>>>  extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>>>  extern const struct efi_hii_database_protocol efi_hii_database;
>>>  extern const struct efi_hii_string_protocol efi_hii_string;
>>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>>
>>>  uint16_t *efi_dp_str(struct efi_device_path *dp);
>>>
>>> @@ -76,6 +77,7 @@ extern const efi_guid_t 
>>> efi_guid_device_path_utilities_protocol;
>>>  extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>>>  extern const efi_guid_t efi_guid_hii_database_protocol;
>>>  extern const efi_guid_t efi_guid_hii_string_protocol;
>>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>>
>>>  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>>>  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>>> index e8fd6823a3..82b703bb39 100644
>>> --- a/lib/efi_loader/Makefile
>>> +++ b/lib/efi_loader/Makefile
>>> @@ -16,7 +16,7 @@ always := $(efiprogs-y)
>>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>>> -obj-y += efi_device_path_utilities.o efi_hii.o
>>> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>>>  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>>>  obj-$(CONFIG_LCD) += efi_gop.o
>>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index 4d1a16051b..04358e8aca 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -788,6 +788,9 @@ void efi_setup_loaded_image(struct efi_loaded_image 
>>> *info, struct efi_object *ob
>>>   obj->protocols[7].guid = _guid_hii_config_routing_protocol;
>>>   obj->protocols[7].protocol_interface = (void 
>>> *)_hii_config_routing;
>>>
>>
>> Do not add a protocol that is not properly implemented yet.
> 
> There is *no possible 

Re: [U-Boot] [PATCH v1 08/12] efi_loader: console support for color attributes

[Heinrich Schuchardt]

On 09/10/2017 03:22 PM, Rob Clark wrote:
> Shell.efi uses this, and supporting color attributes makes things look
> nicer.  Map the EFI fg/bg color attributes to ANSI escape sequences.
> Not all colors have a perfect match, but spec just says "Devices
> supporting a different number of text colors are required to emulate the
> above colors to the best of the device’s capabilities".
> 
> Signed-off-by: Rob Clark 
> ---
>  include/efi_api.h| 29 +
>  lib/efi_loader/efi_console.c | 30 ++
>  2 files changed, 59 insertions(+)
> 
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 87c8ffe68e..3cc1dbac2e 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -426,6 +426,35 @@ struct simple_text_output_mode {
>   EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
>0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>  
> +#define EFI_BLACK0x00
> +#define EFI_BLUE 0x01
> +#define EFI_GREEN0x02
> +#define EFI_CYAN 0x03
> +#define EFI_RED  0x04
> +#define EFI_MAGENTA  0x05
> +#define EFI_BROWN0x06
> +#define EFI_LIGHTGRAY0x07
> +#define EFI_BRIGHT   0x08
> +#define EFI_DARKGRAY 0x08
> +#define EFI_LIGHTBLUE0x09
> +#define EFI_LIGHTGREEN   0x0a
> +#define EFI_LIGHTCYAN0x0b
> +#define EFI_LIGHTRED 0x0c
> +#define EFI_LIGHTMAGENTA 0x0d
> +#define EFI_YELLOW   0x0e
> +#define EFI_WHITE0x0f
> +#define EFI_BACKGROUND_BLACK 0x00
> +#define EFI_BACKGROUND_BLUE  0x10
> +#define EFI_BACKGROUND_GREEN 0x20
> +#define EFI_BACKGROUND_CYAN  0x30
> +#define EFI_BACKGROUND_RED   0x40
> +#define EFI_BACKGROUND_MAGENTA   0x50
> +#define EFI_BACKGROUND_BROWN 0x60
> +#define EFI_BACKGROUND_LIGHTGRAY 0x70

Will we ever use these constants?


Where are the comments explaining the defines below?

> +
> +#define EFI_ATTR_FG(attr)((attr) & 0x0f)

This saves 8 entries in the table below.
+#define EFI_ATTR_FG(attr)((attr) & 0x07)

> +#define EFI_ATTR_BG(attr)(((attr) >> 4) & 0x7)

Add
#define EFI_ATTR_BOLD(attr) (((attr) >> 3) & 0x01)

> +
>  struct efi_simple_text_output_protocol {
>   void *reset;
>   efi_status_t (EFIAPI *output_string)(
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 2e13fdc096..fcd65ca488 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -316,12 +316,42 @@ static efi_status_t EFIAPI efi_cout_set_mode(
>   return EFI_EXIT(EFI_SUCCESS);
>  }
>  
> +static const struct {
> + unsigned fg;
> + unsigned bg;
> +} color[] = {
> + { 30, 40 }, /* 0: black */
> + { 34, 44 }, /* 1: blue */
> + { 32, 42 }, /* 2: green */
> + { 36, 46 }, /* 3: cyan */
> + { 31, 41 }, /* 4: red */
> + { 35, 45 }, /* 5: magenta */
> + { 30, 40 }, /* 6: brown, map to black */

This should be { 33, 43 }

> + { 37, 47 }, /* 7: light grey, map to white */

The entries below are redundant.

> + { 37, 47 }, /* 8: bright, map to white */
> + { 34, 44 }, /* 9: light blue, map to blue */
> + { 32, 42 }, /* A: light green, map to green */
> + { 36, 46 }, /* B: light cyan, map to cyan */
> + { 31, 41 }, /* C: light red, map to red */
> + { 35, 45 }, /* D: light magenta, map to magenta */
> + { 33, 43 }, /* E: yellow */
> + { 37, 47 }, /* F: white */
> +};
> +

No function without a comment explaining the parameters.

>  static efi_status_t EFIAPI efi_cout_set_attribute(
>   struct efi_simple_text_output_protocol *this,
>   unsigned long attribute)
>  {
> + unsigned fg = EFI_ATTR_FG(attribute);
> + unsigned bg = EFI_ATTR_BG(attribute);

Use unsigned int.

> +
>   EFI_ENTRY("%p, %lx", this, attribute);
>  
> + if (attribute)

Attribute 0 should be black on black. No need for any if here.

> + printf(ESC"[%u;%um", color[fg].fg, color[bg].bg);

Use bold for light colors.

unsigned int bold;
if (EFI_ATTRIB_BOLD(attr))
bold = 1;
else
bold = 22;


printf(ESC"[%u;%u;%um", bold, color[fg].fg, color[bg].bg)

Best regards

Heinrich

> + else
> + printf(ESC"[37;40m");


> +
>   /* Just ignore attributes (colors) for now */
>   return EFI_EXIT(EFI_UNSUPPORTED);
>  }
> 

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

[U-Boot] Fwd: INTEL E3900 Apollo Lake I (APL-I) with U-Boot?

[Zoran Stojsavljevic]

Repeating, since I am not sure that this email reached the community!

Zoran

-- Forwarded message --
From: Zoran Stojsavljevic 
Date: Wed, Oct 4, 2017 at 7:52 AM
Subject: INTEL E3900 Apollo Lake I (APL-I) with U-Boot?
To: u-boot@lists.denx.de


Hello to the U-Boot Community,

I am curious about the following HW/FW configuration with regards to the
U-Boot?

Did anybody managed to run the following: INTEL Atom E3900 APL-I with
U-Boot?

E3900 -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?!

Here are some explanations regarding the terms/context:

*IFWI is the Intel FirmWare Interface, a binary blob loaded from the eMMC
boot partition that executes a secondary loader (in this case U-Boot) from
the main eMMC. IFWI blobs for the APL-I are provided by Intel and are
specific for different flavors of the MID silicon.*
*Normal IFWI eMMC boot process*

   1. *On-chip boot rom inits eMMC and loads IFWI from the MMC boot
   partitions*
   2. *IFWI looks for OSIP header at top of eMMC (MBR boot block)*
   3. *The header directs IFWI to the start, size, load address, and entry
   of U-Boot in eMMC*
   4. *(need clarification) If u-boot is not found, try the alt u-boot
   image at 5MB into the eMMC*
   5. *U-Boot is loaded into RAM and executed*

*OSIP stands for OS Image Profile, and it is nothing more and less than
INTEL name for very known old fashion MBR, considering DATA structure.*

Thank you in advance,
Zoran
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] armv8: fsl-layerscape: SPL size reduction

[York Sun]

On 10/03/2017 03:51 AM, Sumit Garg wrote:
>> -Original Message-
>> From: York Sun
>> Sent: Friday, September 15, 2017 2:08 AM
>> To: Sumit Garg ; u-boot@lists.denx.de
>> Cc: Ruchika Gupta ; Prabhakar Kushwaha
>> 
>> Subject: Re: [PATCH 1/3] armv8: fsl-layerscape: SPL size reduction
>>
>> On 08/29/2017 12:01 AM, Sumit Garg wrote:
>>> Using changes in this patch we were able to reduce approx 4k size of
>>> u-boot-spl.bin image. Following is breif description of changes to
>>> reduce SPL size:
>>> 1. Compile-off mp.c and libfdt.c in case of SPL build.
>>> 2. Keep MMU and DCACHE specific variable and functions under
>>> CONFIG_SYS_DCACHE_OFF macro.
>>> 3. Compile-off IFC specific funtion call "init_early_memctl_regs"
>>> in case of SPL build.
>>>
>>> Signed-off-by: Sumit Garg 
>>> ---
>>>
>>> Dependent on ls1088 base SD boot target. Also dependent on ls1088 QPSI
>>> secure boot target.
>>
>> I don't agree D-cache should be off for SPL boot. Please find other way to
>> reduce SPL image size.
>>
>> York
>  
> Sure, let me use GCC 6.2 to reduce SPL image size in upstream rather than 
> compiling-off
> D-cache code.
> 
> But I still don't see ls1088ardb sd boot support in upstream.
> 
> Ashish,
> 
> By when can I expect ls1088ardb sd boot support in upstream?
> 

Sumit,

SD boot is not completed. I don't see RCW in the final image. Pending
Ashish's investigation.

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

Re: [U-Boot] [PATCH v3 1/2] armv8: fsl-lsch3: Add SD boot support for LS1088ARDB

[York Sun]

On 08/31/2017 04:14 AM, Ashish Kumar wrote:
> Add SD boot support for LS1088ARDB
> 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> ---
> v3:
> Depends upon
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F794217%2F=01%7C01%7Cyork.sun%40nxp.com%7Cd0d5453b5bf74aff8d3108d4f061763a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=WaEywrTx85RuymmrU06%2FPXlNOPiIHBFcyNiUhOz9c5g%3D=0
> 
> Rebase to top commit "8b3cec7 mtdparts: Fix uninitialized scalar usage"
> Enable PPA
> New memory map
> 

Ashish,

I don't see correct image is generated with SD boot. RCW is missing. How
do you boot it?

York

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

Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub

[Rob Clark]

On Wed, Oct 4, 2017 at 1:57 PM, Heinrich Schuchardt  wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> From: Leif Lindholm 
>
> The commit message is missing.
>
> Fix all issues reported by checkpatch.
>
>>
>> Signed-off-by: Leif Lindholm 
>> ---
>>  include/efi_api.h | 33 +++
>>  include/efi_loader.h  |  2 ++
>>  lib/efi_loader/Makefile   |  2 +-
>>  lib/efi_loader/efi_boottime.c |  3 ++
>>  lib/efi_loader/efi_unicode.c  | 73 
>> +++
>>  5 files changed, 112 insertions(+), 1 deletion(-)
>>  create mode 100644 lib/efi_loader/efi_unicode.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index 932a3429a8..25f774f253 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -740,6 +740,39 @@ struct efi_hii_string_protocol
>>   UINTN *secondary_languages_size);
>>  };
>>
>> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
>> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
>> +  0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
>> +
>> +struct efi_unicode_collation_protocol
>> +{
>
> ERROR: open brace '{' following struct go on the same line
> #30: FILE: include/efi_api.h:748:
> +struct efi_unicode_collation_protocol
> +{
>
>> + INTN(EFIAPI *stri_coll)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t s1,
>> + efi_string_t s2);
>> + bool(EFIAPI *metai_match)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + efi_string_t pattern);
>> + void(EFIAPI *str_lwr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void(EFIAPI *str_upr)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string);
>> + void(EFIAPI *fat_to_str)(
>> + struct efi_unicode_collation_protocol *this,
>> + UINTN fat_size,
>> + uint8_t *fat,
>> + efi_string_t string);
>> + bool(EFIAPI *str_to_fat)(
>> + struct efi_unicode_collation_protocol *this,
>> + efi_string_t string,
>> + UINTN fat_size,
>> + uint8_t *fat);
>> + uint8_t *supported_languages;
>> +};
>> +
>>  #define EFI_GOP_GUID \
>>   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index a89bb2fcd9..6668338d0b 100644
>> --- a/include/efi_loader.h
>> +++ b/include/efi_loader.h
>> @@ -62,6 +62,7 @@ extern const struct efi_device_path_utilities_protocol 
>> efi_device_path_utilities
>>  extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>>  extern const struct efi_hii_database_protocol efi_hii_database;
>>  extern const struct efi_hii_string_protocol efi_hii_string;
>> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>>
>>  uint16_t *efi_dp_str(struct efi_device_path *dp);
>>
>> @@ -76,6 +77,7 @@ extern const efi_guid_t 
>> efi_guid_device_path_utilities_protocol;
>>  extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>>  extern const efi_guid_t efi_guid_hii_database_protocol;
>>  extern const efi_guid_t efi_guid_hii_string_protocol;
>> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>>
>>  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>>  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
>> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>> index e8fd6823a3..82b703bb39 100644
>> --- a/lib/efi_loader/Makefile
>> +++ b/lib/efi_loader/Makefile
>> @@ -16,7 +16,7 @@ always := $(efiprogs-y)
>>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
>> -obj-y += efi_device_path_utilities.o efi_hii.o
>> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>>  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>>  obj-$(CONFIG_LCD) += efi_gop.o
>>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 4d1a16051b..04358e8aca 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -788,6 +788,9 @@ void efi_setup_loaded_image(struct efi_loaded_image 
>> *info, struct efi_object *ob
>>   obj->protocols[7].guid = _guid_hii_config_routing_protocol;
>>   obj->protocols[7].protocol_interface = (void *)_hii_config_routing;
>>
>
> Do not add a protocol that is not properly implemented yet.

There is *no possible way* that I am going to completely implement
HII, so big nak on this comment!

In general, my plan was to implement the minimal parts of these
protocols to get to the point 

Re: [U-Boot] [PATCH v1 01/12] efi_loader: add stub EFI_DEVICE_PATH_UTILITIES_PROTOCOL

[Heinrich Schuchardt]

On 10/04/2017 07:13 PM, Heinrich Schuchardt wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> From: Leif Lindholm 
>>
>> Signed-off-by: Leif Lindholm 
>> ---
>>  include/efi_api.h  | 30 +++
>>  include/efi_loader.h   |  2 +
>>  lib/efi_loader/Makefile|  1 +
>>  lib/efi_loader/efi_boottime.c  |  4 ++
>>  lib/efi_loader/efi_device_path_utilities.c | 83 
>> ++
>>  5 files changed, 120 insertions(+)
>>  create mode 100644 lib/efi_loader/efi_device_path_utilities.c
>>



>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 3860feb79b..8bb243d673 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -775,6 +775,10 @@ void efi_setup_loaded_image(struct efi_loaded_image 
>> *info, struct efi_object *ob
>>  obj->protocols[3].protocol_interface =
>>  (void *)_device_path_to_text;
>>  
>> +obj->protocols[4].guid = _guid_device_path_utilities_protocol;
>> +obj->protocols[4].protocol_interface =
>> +(void *)_device_path_utilities;
>> +

Do not add a protocol that is not properly implemented yet.

Regards

Heinrich

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

Re: [U-Boot] [PATCH v1 02/12] efi_loader: add stub HII protocols

[Heinrich Schuchardt]

On 10/04/2017 07:45 PM, Heinrich Schuchardt wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> From: Leif Lindholm 
>>
>> EfiHiiConfigRoutingProtocolGuid
>> EfiHiiDatabaseProtocol
>> EfiHiiStringProtocol
> 
> Please, provide a proper commit message.
> 
> Resolve all issues reported by checkpatch.
> 
>>
>> Signed-off-by: Leif Lindholm 
>> ---
>>  include/efi_api.h | 204 
>>  include/efi_loader.h  |   6 +
>>  lib/efi_loader/Makefile   |   2 +-



>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 8bb243d673..4d1a16051b 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -779,6 +779,15 @@ void efi_setup_loaded_image(struct efi_loaded_image 
>> *info, struct efi_object *ob
>>  obj->protocols[4].protocol_interface =
>>  (void *)_device_path_utilities;
>>  
>> +obj->protocols[5].guid = _guid_hii_string_protocol;
>> +obj->protocols[5].protocol_interface = (void *)_hii_string;
>> +
>> +obj->protocols[6].guid = _guid_hii_database_protocol;
>> +obj->protocols[6].protocol_interface = (void *)_hii_database;
>> +
>> +obj->protocols[7].guid = _guid_hii_config_routing_protocol;
>> +obj->protocols[7].protocol_interface = (void *)_hii_config_routing;
>> +

Do not add a protocol that is not properly implemented yet.

Regards

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

Re: [U-Boot] [PATCH v1 03/12] efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub

[Heinrich Schuchardt]

On 09/10/2017 03:22 PM, Rob Clark wrote:
> From: Leif Lindholm 

The commit message is missing.

Fix all issues reported by checkpatch.

> 
> Signed-off-by: Leif Lindholm 
> ---
>  include/efi_api.h | 33 +++
>  include/efi_loader.h  |  2 ++
>  lib/efi_loader/Makefile   |  2 +-
>  lib/efi_loader/efi_boottime.c |  3 ++
>  lib/efi_loader/efi_unicode.c  | 73 
> +++
>  5 files changed, 112 insertions(+), 1 deletion(-)
>  create mode 100644 lib/efi_loader/efi_unicode.c
> 
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 932a3429a8..25f774f253 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -740,6 +740,39 @@ struct efi_hii_string_protocol
>   UINTN *secondary_languages_size);
>  };
>  
> +#define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
> + EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
> +  0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
> +
> +struct efi_unicode_collation_protocol
> +{

ERROR: open brace '{' following struct go on the same line
#30: FILE: include/efi_api.h:748:
+struct efi_unicode_collation_protocol
+{

> + INTN(EFIAPI *stri_coll)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t s1,
> + efi_string_t s2);
> + bool(EFIAPI *metai_match)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string,
> + efi_string_t pattern);
> + void(EFIAPI *str_lwr)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string);
> + void(EFIAPI *str_upr)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string);
> + void(EFIAPI *fat_to_str)(
> + struct efi_unicode_collation_protocol *this,
> + UINTN fat_size,
> + uint8_t *fat,
> + efi_string_t string);
> + bool(EFIAPI *str_to_fat)(
> + struct efi_unicode_collation_protocol *this,
> + efi_string_t string,
> + UINTN fat_size,
> + uint8_t *fat);
> + uint8_t *supported_languages;
> +};
> +
>  #define EFI_GOP_GUID \
>   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index a89bb2fcd9..6668338d0b 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -62,6 +62,7 @@ extern const struct efi_device_path_utilities_protocol 
> efi_device_path_utilities
>  extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
>  extern const struct efi_hii_database_protocol efi_hii_database;
>  extern const struct efi_hii_string_protocol efi_hii_string;
> +extern const struct efi_unicode_collation_protocol efi_unicode_collation;
>  
>  uint16_t *efi_dp_str(struct efi_device_path *dp);
>  
> @@ -76,6 +77,7 @@ extern const efi_guid_t 
> efi_guid_device_path_utilities_protocol;
>  extern const efi_guid_t efi_guid_hii_config_routing_protocol;
>  extern const efi_guid_t efi_guid_hii_database_protocol;
>  extern const efi_guid_t efi_guid_hii_string_protocol;
> +extern const efi_guid_t efi_guid_unicode_collation_protocol2;
>  
>  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index e8fd6823a3..82b703bb39 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -16,7 +16,7 @@ always := $(efiprogs-y)
>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
> -obj-y += efi_device_path_utilities.o efi_hii.o
> +obj-y += efi_device_path_utilities.o efi_hii.o efi_unicode.o
>  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>  obj-$(CONFIG_LCD) += efi_gop.o
>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 4d1a16051b..04358e8aca 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -788,6 +788,9 @@ void efi_setup_loaded_image(struct efi_loaded_image 
> *info, struct efi_object *ob
>   obj->protocols[7].guid = _guid_hii_config_routing_protocol;
>   obj->protocols[7].protocol_interface = (void *)_hii_config_routing;
>  

Do not add a protocol that is not properly implemented yet.

> + obj->protocols[8].guid = _guid_unicode_collation_protocol2;
> + obj->protocols[8].protocol_interface = (void *)_unicode_collation;
> +
>   info->file_path = file_path;
>   info->device_handle = efi_dp_find_obj(device_path, NULL);
>  
> diff --git a/lib/efi_loader/efi_unicode.c b/lib/efi_loader/efi_unicode.c
> new file mode 100644
> index 00..fdf1a99812
> 

Re: [U-Boot] [PATCH v1 02/12] efi_loader: add stub HII protocols

[Heinrich Schuchardt]

On 09/10/2017 03:22 PM, Rob Clark wrote:
> From: Leif Lindholm 
> 
> EfiHiiConfigRoutingProtocolGuid
> EfiHiiDatabaseProtocol
> EfiHiiStringProtocol

Please, provide a proper commit message.

Resolve all issues reported by checkpatch.

> 
> Signed-off-by: Leif Lindholm 
> ---
>  include/efi_api.h | 204 
>  include/efi_loader.h  |   6 +
>  lib/efi_loader/Makefile   |   2 +-
>  lib/efi_loader/efi_boottime.c |   9 ++
>  lib/efi_loader/efi_hii.c  | 303 
> ++
>  5 files changed, 523 insertions(+), 1 deletion(-)
>  create mode 100644 lib/efi_loader/efi_hii.c
> 
> diff --git a/include/efi_api.h b/include/efi_api.h
> index 57468dd972..932a3429a8 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -536,6 +536,210 @@ struct efi_device_path_utilities_protocol
>   const struct efi_device_path *device_path);
>  };
>  
> +#define EFI_HII_CONFIG_ROUTING_PROTOCOL_GUID \
> + EFI_GUID(0x587e72d7, 0xcc50, 0x4f79, \
> +  0x82, 0x09, 0xca, 0x29, 0x1f, 0xc1, 0xa1, 0x0f)
> +
> +struct efi_hii_config_routing_protocol
> +{

ERROR: open brace '{' following struct go on the same line
#34: FILE: include/efi_api.h:544:
+struct efi_hii_config_routing_protocol
+{


> + efi_status_t(EFIAPI *extract_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t request,
> + efi_string_t *progress,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *export_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + efi_string_t *results);
> + efi_status_t(EFIAPI *route_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t configuration,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *block_to_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_request,
> + const uint8_t *block,
> + const UINTN block_size,
> + efi_string_t *config,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *config_to_block)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const uint8_t *block,
> + const UINTN *block_size,
> + efi_string_t *progress);
> + efi_status_t(EFIAPI *get_alt_config)(
> + const struct efi_hii_config_routing_protocol *this,
> + const efi_string_t config_resp,
> + const efi_guid_t *guid,
> + const efi_string_t name,
> + const struct efi_device_path *device_path,
> + const efi_string_t alt_cfg_id,
> + efi_string_t *alt_cfg_resp);
> +};
> +
> +#define EFI_HII_DATABASE_PROTOCOL_GUID\
> + EFI_GUID(0xef9fc172, 0xa1b2, 0x4693, \
> +  0xb3, 0x27, 0x6d, 0x32, 0xfc, 0x41, 0x60, 0x42)
> +
> +typedef enum {

We do not use CamelCase.

> + EfiKeyLCtrl, EfiKeyA0, EfiKeyLAlt, EfiKeySpaceBar,
> + EfiKeyA2, EfiKeyA3, EfiKeyA4, EfiKeyRCtrl, EfiKeyLeftArrow,
> + EfiKeyDownArrow, EfiKeyRightArrow, EfiKeyZero,
> + EfiKeyPeriod, EfiKeyEnter, EfiKeyLShift, EfiKeyB0,
> + EfiKeyB1, EfiKeyB2, EfiKeyB3, EfiKeyB4, EfiKeyB5, EfiKeyB6,
> + EfiKeyB7, EfiKeyB8, EfiKeyB9, EfiKeyB10, EfiKeyRShift,
> + EfiKeyUpArrow, EfiKeyOne, EfiKeyTwo, EfiKeyThree,
> + EfiKeyCapsLock, EfiKeyC1, EfiKeyC2, EfiKeyC3, EfiKeyC4,
> + EfiKeyC5, EfiKeyC6, EfiKeyC7, EfiKeyC8, EfiKeyC9,
> + EfiKeyC10, EfiKeyC11, EfiKeyC12, EfiKeyFour, EfiKeyFive,
> + EfiKeySix, EfiKeyPlus, EfiKeyTab, EfiKeyD1, EfiKeyD2,
> + EfiKeyD3, EfiKeyD4, EfiKeyD5, EfiKeyD6, EfiKeyD7, EfiKeyD8,
> + EfiKeyD9, EfiKeyD10, EfiKeyD11, EfiKeyD12, EfiKeyD13,
> + EfiKeyDel, EfiKeyEnd, EfiKeyPgDn, EfiKeySeven, EfiKeyEight,
> + EfiKeyNine, EfiKeyE0, EfiKeyE1, EfiKeyE2, EfiKeyE3,
> + EfiKeyE4, EfiKeyE5, EfiKeyE6, EfiKeyE7, EfiKeyE8, EfiKeyE9,
> + EfiKeyE10, EfiKeyE11, EfiKeyE12, EfiKeyBackSpace,
> + EfiKeyIns, EfiKeyHome, EfiKeyPgUp, EfiKeyNLck, EfiKeySlash,
> + EfiKeyAsterisk, EfiKeyMinus, EfiKeyEsc, EfiKeyF1, EfiKeyF2,
> + EfiKeyF3, EfiKeyF4, EfiKeyF5, EfiKeyF6, EfiKeyF7, EfiKeyF8,
> + EfiKeyF9, EfiKeyF10, EfiKeyF11, EfiKeyF12, EfiKeyPrint,
> + EfiKeySLck, EfiKeyPause
> +} efi_key;
> +
> +struct efi_key_descriptor
> +{
> + efi_key key;
> + uint16_t unicode;
> + uint16_t shifted_unicode;
> + uint16_t alt_gr_unicode;
> + uint16_t shifted_alt_gr_unicode;
> + uint16_t modifier;
> + uint16_t affected_attribute;
> +};
> +
> +struct efi_hii_keyboard_layout
> +{
> + uint16_t layout_length;
> + efi_guid_t guid;
> + uint32_t layout_descriptor_string_offset;
> + uint8_t descriptor_count;
> + 

Re: [U-Boot] [PATCH v1 01/12] efi_loader: add stub EFI_DEVICE_PATH_UTILITIES_PROTOCOL

[Heinrich Schuchardt]

On 10/04/2017 07:13 PM, Heinrich Schuchardt wrote:
> On 09/10/2017 03:22 PM, Rob Clark wrote:
>> From: Leif Lindholm 
>>
>> Signed-off-by: Leif Lindholm 
>> ---
>>  include/efi_api.h  | 30 +++
>>  include/efi_loader.h   |  2 +
>>  lib/efi_loader/Makefile|  1 +
>>  lib/efi_loader/efi_boottime.c  |  4 ++
>>  lib/efi_loader/efi_device_path_utilities.c | 83 
>> ++
>>  5 files changed, 120 insertions(+)
>>  create mode 100644 lib/efi_loader/efi_device_path_utilities.c
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index c3b9032a48..57468dd972 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -506,6 +506,36 @@ struct efi_device_path_to_text_protocol
>>  bool allow_shortcuts);
>>  };
>>  
>> +#define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
>> +EFI_GUID(0x0379be4e, 0xd706, 0x437d, \
>> + 0xb0, 0x37, 0xed, 0xb8, 0x2f, 0xb7, 0x72, 0xa4)
>> +
>> +struct efi_device_path_utilities_protocol
>> +{

checkpatch returns an error:

ERROR: open brace '{' following struct go on the same line
#30: FILE: include/efi_api.h:514:
+struct efi_device_path_utilities_protocol
+{

Regards

Heinrich

>> +UINTN(EFIAPI *get_device_path_size)(
>> +const struct efi_device_path *device_path);
>> +struct efi_device_path *(EFIAPI *duplicate_device_path)(
>> +const struct efi_device_path *device_path);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: ls1088a: Update MC boot sequence

[York Sun]

On 10/04/2017 02:10 AM, Bogdan Purcareata wrote:
> This patch follows the work of previous commits:
> 5707dfb02e drivers: net: fsl-mc: Fixup MAC addresses in DPC
> 33a8991a87 drivers: net: fsl-mc: Link MC boot to PHY_RESET_R
> 1161dbcc0a drivers: net: fsl-mc: Include MAC addr fixup to DPL

These are not commit message. They belong to under the --- line under
your signature.

> 
> Add support for LS1088 platforms, to make sure u-boot env MAC addresses
> are properly set in DPC / DPL.

This message doesn't match the change. You are removing mc_boot_env_var
from qds and rdb files and replace it with a common function call to
reset phy. You are not actually adding support for LS1088 platforms.
Please revise your commit message.

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

Re: [U-Boot] [PATCH v1 01/12] efi_loader: add stub EFI_DEVICE_PATH_UTILITIES_PROTOCOL

[Heinrich Schuchardt]

On 09/10/2017 03:22 PM, Rob Clark wrote:
> From: Leif Lindholm 
> 
> Signed-off-by: Leif Lindholm 
> ---
>  include/efi_api.h  | 30 +++
>  include/efi_loader.h   |  2 +
>  lib/efi_loader/Makefile|  1 +
>  lib/efi_loader/efi_boottime.c  |  4 ++
>  lib/efi_loader/efi_device_path_utilities.c | 83 
> ++
>  5 files changed, 120 insertions(+)
>  create mode 100644 lib/efi_loader/efi_device_path_utilities.c
> 
> diff --git a/include/efi_api.h b/include/efi_api.h
> index c3b9032a48..57468dd972 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -506,6 +506,36 @@ struct efi_device_path_to_text_protocol
>   bool allow_shortcuts);
>  };
>  
> +#define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \
> + EFI_GUID(0x0379be4e, 0xd706, 0x437d, \
> +  0xb0, 0x37, 0xed, 0xb8, 0x2f, 0xb7, 0x72, 0xa4)
> +
> +struct efi_device_path_utilities_protocol
> +{
> + UINTN(EFIAPI *get_device_path_size)(
> + const struct efi_device_path *device_path);
> + struct efi_device_path *(EFIAPI *duplicate_device_path)(
> + const struct efi_device_path *device_path);
> + struct efi_device_path *(EFIAPI *append_device_path)(
> + const struct efi_device_path *src1,
> + const struct efi_device_path *src2);
> + struct efi_device_path *(EFIAPI *append_device_node)(
> + const struct efi_device_path *device_path,
> + const struct efi_device_path *device_node);
> + struct efi_device_path *(EFIAPI *append_device_path_instance)(
> + const struct efi_device_path *device_path,
> + const struct efi_device_path *device_path_instance);
> + struct efi_device_path *(EFIAPI *get_next_device_path_instance)(
> + struct efi_device_path **device_path_instance,
> + UINTN *device_path_instance_size);

The sequence is wrong. It does not match
UEFI Spec 2.7 Errata A, August 2017.

EDK2 uses the same sequence as the spec see

EdkCompatibilityPkg/Foundation/Efi/Protocol/DevicePathUtilities/DevicePathUtilities.h

Put is_device_path_multi_instance before create_device_node.

> + struct efi_device_path *(EFIAPI *create_device_node)(
> + uint8_t node_type,
> + uint8_t node_sub_type,
> + uint16_t node_length);
> + bool(EFIAPI *is_device_path_multi_instance)(
> + const struct efi_device_path *device_path);
> +};
> +
>  #define EFI_GOP_GUID \
>   EFI_GUID(0x9042a9de, 0x23dc, 0x4a38, \
>0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, 0x51, 0x6a)
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 43b12b94fa..c009828db9 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -58,6 +58,7 @@ extern const struct efi_simple_text_output_protocol 
> efi_con_out;
>  extern struct efi_simple_input_interface efi_con_in;
>  extern const struct efi_console_control_protocol efi_console_control;
>  extern const struct efi_device_path_to_text_protocol efi_device_path_to_text;
> +extern const struct efi_device_path_utilities_protocol 
> efi_device_path_utilities;
>  
>  uint16_t *efi_dp_str(struct efi_device_path *dp);
>  
> @@ -68,6 +69,7 @@ extern const efi_guid_t efi_guid_loaded_image;
>  extern const efi_guid_t efi_guid_device_path_to_text_protocol;
>  extern const efi_guid_t efi_simple_file_system_protocol_guid;
>  extern const efi_guid_t efi_file_info_guid;
> +extern const efi_guid_t efi_guid_device_path_utilities_protocol;
>  
>  extern unsigned int __efi_runtime_start, __efi_runtime_stop;
>  extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> index 930c0e218e..f5e69dd078 100644
> --- a/lib/efi_loader/Makefile
> +++ b/lib/efi_loader/Makefile
> @@ -16,6 +16,7 @@ always := $(efiprogs-y)
>  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
>  obj-y += efi_image_loader.o efi_boottime.o efi_runtime.o efi_console.o
>  obj-y += efi_memory.o efi_device_path_to_text.o efi_device_path.o
> +obj-y += efi_device_path_utilities.o
>  obj-y += efi_file.o efi_variable.o efi_bootmgr.o
>  obj-$(CONFIG_LCD) += efi_gop.o
>  obj-$(CONFIG_DM_VIDEO) += efi_gop.o
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 3860feb79b..8bb243d673 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -775,6 +775,10 @@ void efi_setup_loaded_image(struct efi_loaded_image 
> *info, struct efi_object *ob
>   obj->protocols[3].protocol_interface =
>   (void *)_device_path_to_text;
>  
> + obj->protocols[4].guid = _guid_device_path_utilities_protocol;
> + obj->protocols[4].protocol_interface =
> + (void *)_device_path_utilities;
> +
>   info->file_path = file_path;
>   info->device_handle = 

Re: [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Rob Clark]

On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam  wrote:
> Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> SPL boot on i.MX6 starts to fail:
>
> U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> Trying to boot from MMC1
> (keep in loop)
>
> Use the original allocation scheme for the SPL case, so that MX6 boards
> can boot again.
>
> This is a temporary solution to avoid the boot regression.
>
> Signed-off-by: Fabio Estevam 
> ---
> Hi Tom,
>
> I do not have time this week to further investigate and narrow down
> this problem.
>
> Using the old allocation scheme fixes the mx6 SPL boot problem.
>

Hi Tom, if you are ok with this as a temporary fix, then this is:

Acked-by: Rob Clark 

I'm getting some help from some of the fedora-arm folks so hopefully I
can get some idea what is going wrong, but I'd like to unblock folks
w/ mx6 boards..

BR,
-R

>
>  disk/part_dos.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 1a36be0..6dd2c2d 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
>
>  static int part_test_dos(struct blk_desc *dev_desc)
>  {
> +#ifndef CONFIG_SPL_BUILD
> ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
>
> if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
> @@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc)
> dev_desc->sig_type = SIG_TYPE_MBR;
> dev_desc->mbr_sig = mbr->unique_mbr_signature;
> }
> +#else
> +   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
> +
> +   if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)
> +   return -1;
> +
> +   if (test_block_type(buffer) != DOS_MBR)
> +   return -1;
> +#endif
>
> return 0;
>  }
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Rob Clark]

On Wed, Oct 4, 2017 at 12:29 PM, Heinrich Schuchardt  wrote:
> On 10/04/2017 05:25 PM, Alexander Graf wrote:
>>
>>
>> On 04.10.17 16:57, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt
>>>  wrote:
 On 10/04/2017 04:14 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt
>  wrote:
>> Queued and signaled describe boolean states of events.
>> So let's use type bool and rename the structure members to is_queued
>> and is_signaled.
>>
>> Update the comments for is_queued and is_signaled.
>
> Reviewed-by: Rob Clark 
>
> It would be kinda nice to merge my efi_event fixes and rework to use
> an arbitrary sized list of events before making too many more
> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>
> BR,
> -R

 I would not mind if you patch went first.

 But your patch
 https://patchwork.ozlabs.org/patch/812967/
 is not applicable to U-Boot master and needs rebasing anyway.
>>>
>>> jfyi, I have it (and other pending patches) rebased on latest master
>>> (as of ~yesterday) here:
>>>
>>>https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>>>
>>> I wasn't planning on resending until I get further with FAT write
>>> stuff (currently on a local branch, although I might not get much time
>>> to work on in the next week or two).. although I can re-send it or any
>>> of the other patches to get Shell.efi working if wanted.  (Note that
>>> I'm also using your patch for efi watchdog support, that was one of
>>> the other required bits.)
>>>
>>> Not sure what agraf's plan is but I think the needed bits for
>>> Shell.efi are mergable already.
>>
>> I don't have a concrete plan - in general I consider patches that have
>> unaddressed review comments as "not to be applied atm" though and I'm
>> not sure I have anything pending from you that would not fall into that
>> category :).
>>
>> Can you split off a series that has Heinrich's blessing to get us as far
>> as we can, so we can keep your queue short?
>>
>
> These are the two first patches in Rob's queue:
>
> efi_loader: support 16 protocols per efi_object
> https://patchwork.ozlabs.org/patch/806167/
>
> efi_loader: allow creating new handles
> https://patchwork.ozlabs.org/patch/806173/

btw, you can add for these two:

Reviewed-by: Rob Clark 

> Please, merge these.
>
> I am aware that we need to convert the protocols list to a linked list
> and will do so in a later patch.
>
> Please, also merge this patch that definitively does not interfere with
> Rob's work:
>
> efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
> https://patchwork.ozlabs.org/patch/816412/
>
> Best regards
>
> Heinrich
>
>>>
 Please, add the missing check that the event pointer is valid.
 The EFI code checks other arguments rigorously so we should do the same
 for pointers. It would be very hard to debug a problem in an EFI
 application otherwise.
>>>
>>> I'm a bit undecided on this, since we have other places where there is
>>> no good way to check the validity of a pointer.  (For example file or
>>> disk objects.)  I was thinking about perhaps implementing a
>>> compile-time optional feature using a hashtable to map objects to type
>>> so we can add in some type checking, at the expense of extra runtime
>>> overhead.  Probably not something you'd want to ship enabled, but it
>>> would be useful for debugging.
>>
>> Feel free to implement just the boilerplate for it with a function that
>> always returns true:
>>
>> static int efi_ptr_valid(void *foo)
>> {
>> return 1;
>> }
>>
>> which we can then later on improve to do actual checking if we care. The
>> least we can do is probably to check for alignment problems.
>>
>>
>> Alex
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Rob Clark]

On Wed, Oct 4, 2017 at 12:02 PM, Heinrich Schuchardt  wrote:
> On 10/04/2017 04:57 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt  
>> wrote:
>>> On 10/04/2017 04:14 PM, Rob Clark wrote:
 On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  
 wrote:
> Queued and signaled describe boolean states of events.
> So let's use type bool and rename the structure members to is_queued
> and is_signaled.
>
> Update the comments for is_queued and is_signaled.

 Reviewed-by: Rob Clark 

 It would be kinda nice to merge my efi_event fixes and rework to use
 an arbitrary sized list of events before making too many more
 efi_event changes, since that is kind of annoying to keep rebasing ;-)

 BR,
 -R
>>>
>>> I would not mind if you patch went first.
>>>
>>> But your patch
>>> https://patchwork.ozlabs.org/patch/812967/
>>> is not applicable to U-Boot master and needs rebasing anyway.
>>
>> jfyi, I have it (and other pending patches) rebased on latest master
>> (as of ~yesterday) here:
>>
>>   https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>
> You have a Travis CI build error. Could you, please, fix that.
>
> efi_loader: implement SetWatchdogTimer
> is the last patch in your branch that is not called "HACK ...".
>
> So could you, please, prepare a branch that ends here and let Travis
> test it.
>
>>
>> I wasn't planning on resending until I get further with FAT write
>> stuff (currently on a local branch, although I might not get much time
>> to work on in the next week or two).. although I can re-send it or any
>> of the other patches to get Shell.efi working if wanted.  (Note that
>> I'm also using your patch for efi watchdog support, that was one of
>> the other required bits.)
>
> I have also a lot of patches in the pipeline. We should not block each
> other. So, please, either resend the patch series (but please nothing
> called HACK) for review now or let my patches below enter efi-next.

sorry, I didn't have time to push the non "wip-" version of the branch
(which does not have other patches+hacks to make things work on
db410c), but ofc I wouldn't send those as part of a patchset

btw, did you plan any further changes for your watchdog patch?  I've
rebased it already, but let me know if I should pull in something
newer.

> Some review comments for your branch:
>
> Patch efi_loader: add stub HII protocols uses UINTN heavily. In a recent
> comment Simon remarked that types should not be uppercase. So I was
> planning to replace all occurences of UINTN by size_t in an upcoming patch.

ok, I also wanted to clean up efi strings and introduce a typedef for
efi 16b chars too.. and this might be easier just to do on top of the
other patches.

If you were planning on doing this before the weekend, I'll rebase on
top.. if you weren't going to have time for it in the next week or so
I can take a stab at it.  I guess both the cleanups are just a big
chunk of mechanical churn, but otherwise not so difficult.

> Patch efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub
> has EFI_EXIT(0). We should yuse a constant like EFI_SUCCESS here.
>
> In patch efi_loader: Decouple EFI input/output from stdin/stdout
> the commit message is insufficient. Please, explain how the output
> device will be controlled. I am managing my machines remotely via
> serial. Some of my machines have video but not monitor attached. I would
> not be able to accept no longer seeing EFI output on my serial.

ok.. fwiw, this introduces two new env vars, efiin and efiout, so you
can still configure output/input as you prefer.  I was planning to add
efiout=vidconsole\0efiin=usbkbd to include/configs/dragonboard410c
(although maybe there is a better place.. either way setting the vars
isn't part of this patch)

> Patch efi_loader: fix events
> still has the TODO text that you wanted to remove. And of cause the
> missing pointer validity check.

I did update the TODO text to clarify better, but I could remove it.
It was mostly an idea for a future optimization which might (or might
not) be useful, not something I was planning to add as part of this
patch.

BR,
-R

> Best regards
>
> Heinrich
>
>>
>> Not sure what agraf's plan is but I think the needed bits for
>> Shell.efi are mergable already.
>>
>>> Please, add the missing check that the event pointer is valid.
>>> The EFI code checks other arguments rigorously so we should do the same
>>> for pointers. It would be very hard to debug a problem in an EFI
>>> application otherwise.
>>
>> I'm a bit undecided on this, since we have other places where there is
>> no good way to check the validity of a pointer.  (For example file or
>> disk objects.)  I was thinking about perhaps implementing a
>> compile-time optional feature using a hashtable to map objects to type
>> so we can add in some type checking, at the expense of 

[U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case

[Fabio Estevam]

Since commit ff98cb90514d ("part: extract MBR signature from partitions")
SPL boot on i.MX6 starts to fail:

U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
Trying to boot from MMC1
(keep in loop)

Use the original allocation scheme for the SPL case, so that MX6 boards
can boot again.

This is a temporary solution to avoid the boot regression.

Signed-off-by: Fabio Estevam 
---
Hi Tom,

I do not have time this week to further investigate and narrow down 
this problem.

Using the old allocation scheme fixes the mx6 SPL boot problem.


 disk/part_dos.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 1a36be0..6dd2c2d 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -89,6 +89,7 @@ static int test_block_type(unsigned char *buffer)
 
 static int part_test_dos(struct blk_desc *dev_desc)
 {
+#ifndef CONFIG_SPL_BUILD
ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
 
if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
@@ -102,6 +103,15 @@ static int part_test_dos(struct blk_desc *dev_desc)
dev_desc->sig_type = SIG_TYPE_MBR;
dev_desc->mbr_sig = mbr->unique_mbr_signature;
}
+#else
+   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
+
+   if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)
+   return -1;
+
+   if (test_block_type(buffer) != DOS_MBR)
+   return -1;
+#endif
 
return 0;
 }
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Heinrich Schuchardt]

On 10/04/2017 05:25 PM, Alexander Graf wrote:
> 
> 
> On 04.10.17 16:57, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt
>>  wrote:
>>> On 10/04/2017 04:14 PM, Rob Clark wrote:
 On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt
  wrote:
> Queued and signaled describe boolean states of events.
> So let's use type bool and rename the structure members to is_queued
> and is_signaled.
>
> Update the comments for is_queued and is_signaled.

 Reviewed-by: Rob Clark 

 It would be kinda nice to merge my efi_event fixes and rework to use
 an arbitrary sized list of events before making too many more
 efi_event changes, since that is kind of annoying to keep rebasing ;-)

 BR,
 -R
>>>
>>> I would not mind if you patch went first.
>>>
>>> But your patch
>>> https://patchwork.ozlabs.org/patch/812967/
>>> is not applicable to U-Boot master and needs rebasing anyway.
>>
>> jfyi, I have it (and other pending patches) rebased on latest master
>> (as of ~yesterday) here:
>>
>>    https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell
>>
>> I wasn't planning on resending until I get further with FAT write
>> stuff (currently on a local branch, although I might not get much time
>> to work on in the next week or two).. although I can re-send it or any
>> of the other patches to get Shell.efi working if wanted.  (Note that
>> I'm also using your patch for efi watchdog support, that was one of
>> the other required bits.)
>>
>> Not sure what agraf's plan is but I think the needed bits for
>> Shell.efi are mergable already.
> 
> I don't have a concrete plan - in general I consider patches that have
> unaddressed review comments as "not to be applied atm" though and I'm
> not sure I have anything pending from you that would not fall into that
> category :).
> 
> Can you split off a series that has Heinrich's blessing to get us as far
> as we can, so we can keep your queue short?
> 

These are the two first patches in Rob's queue:

efi_loader: support 16 protocols per efi_object
https://patchwork.ozlabs.org/patch/806167/

efi_loader: allow creating new handles
https://patchwork.ozlabs.org/patch/806173/

Please, merge these.

I am aware that we need to convert the protocols list to a linked list
and will do so in a later patch.

Please, also merge this patch that definitively does not interfere with
Rob's work:

efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
https://patchwork.ozlabs.org/patch/816412/

Best regards

Heinrich

>>
>>> Please, add the missing check that the event pointer is valid.
>>> The EFI code checks other arguments rigorously so we should do the same
>>> for pointers. It would be very hard to debug a problem in an EFI
>>> application otherwise.
>>
>> I'm a bit undecided on this, since we have other places where there is
>> no good way to check the validity of a pointer.  (For example file or
>> disk objects.)  I was thinking about perhaps implementing a
>> compile-time optional feature using a hashtable to map objects to type
>> so we can add in some type checking, at the expense of extra runtime
>> overhead.  Probably not something you'd want to ship enabled, but it
>> would be useful for debugging.
> 
> Feel free to implement just the boilerplate for it with a function that
> always returns true:
> 
> static int efi_ptr_valid(void *foo)
> {
>     return 1;
> }
> 
> which we can then later on improve to do actual checking if we care. The
> least we can do is probably to check for alignment problems.
> 
> 
> Alex
> 

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

Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr

[Fabio Estevam]

On Wed, Oct 4, 2017 at 11:51 AM, Rob Clark  wrote:

> Not sure Tom's opinion, but I'd be ok with applying this patch, even
> if just a temporary fix, to unblock folks trying to test latest u-boot
> on these devices

Yes, sounds like an option given we are at -rc1 now.

Will submit it and let's see what Tom says about it.

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

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Heinrich Schuchardt]

On 10/04/2017 04:57 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt  
> wrote:
>> On 10/04/2017 04:14 PM, Rob Clark wrote:
>>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  
>>> wrote:
 Queued and signaled describe boolean states of events.
 So let's use type bool and rename the structure members to is_queued
 and is_signaled.

 Update the comments for is_queued and is_signaled.
>>>
>>> Reviewed-by: Rob Clark 
>>>
>>> It would be kinda nice to merge my efi_event fixes and rework to use
>>> an arbitrary sized list of events before making too many more
>>> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>>>
>>> BR,
>>> -R
>>
>> I would not mind if you patch went first.
>>
>> But your patch
>> https://patchwork.ozlabs.org/patch/812967/
>> is not applicable to U-Boot master and needs rebasing anyway.
> 
> jfyi, I have it (and other pending patches) rebased on latest master
> (as of ~yesterday) here:
> 
>   https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell

You have a Travis CI build error. Could you, please, fix that.

efi_loader: implement SetWatchdogTimer
is the last patch in your branch that is not called "HACK ...".

So could you, please, prepare a branch that ends here and let Travis
test it.

> 
> I wasn't planning on resending until I get further with FAT write
> stuff (currently on a local branch, although I might not get much time
> to work on in the next week or two).. although I can re-send it or any
> of the other patches to get Shell.efi working if wanted.  (Note that
> I'm also using your patch for efi watchdog support, that was one of
> the other required bits.)

I have also a lot of patches in the pipeline. We should not block each
other. So, please, either resend the patch series (but please nothing
called HACK) for review now or let my patches below enter efi-next.

Some review comments for your branch:

Patch efi_loader: add stub HII protocols uses UINTN heavily. In a recent
comment Simon remarked that types should not be uppercase. So I was
planning to replace all occurences of UINTN by size_t in an upcoming patch.

Patch efi_loader: add EFI_UNICODE_COLLATION_PROTOCOL stub
has EFI_EXIT(0). We should yuse a constant like EFI_SUCCESS here.

In patch efi_loader: Decouple EFI input/output from stdin/stdout
the commit message is insufficient. Please, explain how the output
device will be controlled. I am managing my machines remotely via
serial. Some of my machines have video but not monitor attached. I would
not be able to accept no longer seeing EFI output on my serial.

Patch efi_loader: fix events
still has the TODO text that you wanted to remove. And of cause the
missing pointer validity check.

Best regards

Heinrich

> 
> Not sure what agraf's plan is but I think the needed bits for
> Shell.efi are mergable already.
> 
>> Please, add the missing check that the event pointer is valid.
>> The EFI code checks other arguments rigorously so we should do the same
>> for pointers. It would be very hard to debug a problem in an EFI
>> application otherwise.
> 
> I'm a bit undecided on this, since we have other places where there is
> no good way to check the validity of a pointer.  (For example file or
> disk objects.)  I was thinking about perhaps implementing a
> compile-time optional feature using a hashtable to map objects to type
> so we can add in some type checking, at the expense of extra runtime
> overhead.  Probably not something you'd want to ship enabled, but it
> would be useful for debugging.
> 
> BR,
> -R
> 
>> @Alexander
>> I guess with Suseconf you were quite busy in the last weeks. Did you
>> already make up your mind in which sequence we should prepare the EFI
>> patches?
>>
>> The following of my patches could be directly applied to efi-next:
>>
>> [U-Boot,1/1] efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
>> https://patchwork.ozlabs.org/patch/816412/
>> [U-Boot,1/1] efi_loader: replace efi_div10 by div64_u64
>> https://patchwork.ozlabs.org/patch/820731/
>> [U-Boot,1/1] efi_selftest: use efi_st_error for all error messages
>> https://patchwork.ozlabs.org/patch/821237/
>> [U-Boot,1/1] efi_loader: use type bool for event states
>> https://patchwork.ozlabs.org/patch/821302/
>> [U-Boot,v2,1/1] efi_selftest: make tests easier to read
>> https://patchwork.ozlabs.org/patch/821306/
>>
>> I guess Rob was refering to
>> [U-Boot,1/1] efi_loader: use type bool for event states
>>
>> Best regards
>>
>> Heinrich
> 

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

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Alexander Graf]

On 04.10.17 16:57, Rob Clark wrote:

On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt  wrote:

On 10/04/2017 04:14 PM, Rob Clark wrote:

On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  wrote:

Queued and signaled describe boolean states of events.
So let's use type bool and rename the structure members to is_queued
and is_signaled.

Update the comments for is_queued and is_signaled.


Reviewed-by: Rob Clark 

It would be kinda nice to merge my efi_event fixes and rework to use
an arbitrary sized list of events before making too many more
efi_event changes, since that is kind of annoying to keep rebasing ;-)

BR,
-R


I would not mind if you patch went first.

But your patch
https://patchwork.ozlabs.org/patch/812967/
is not applicable to U-Boot master and needs rebasing anyway.


jfyi, I have it (and other pending patches) rebased on latest master
(as of ~yesterday) here:

   https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell

I wasn't planning on resending until I get further with FAT write
stuff (currently on a local branch, although I might not get much time
to work on in the next week or two).. although I can re-send it or any
of the other patches to get Shell.efi working if wanted.  (Note that
I'm also using your patch for efi watchdog support, that was one of
the other required bits.)

Not sure what agraf's plan is but I think the needed bits for
Shell.efi are mergable already.


I don't have a concrete plan - in general I consider patches that have 
unaddressed review comments as "not to be applied atm" though and I'm 
not sure I have anything pending from you that would not fall into that 
category :).


Can you split off a series that has Heinrich's blessing to get us as far 
as we can, so we can keep your queue short?





Please, add the missing check that the event pointer is valid.
The EFI code checks other arguments rigorously so we should do the same
for pointers. It would be very hard to debug a problem in an EFI
application otherwise.


I'm a bit undecided on this, since we have other places where there is
no good way to check the validity of a pointer.  (For example file or
disk objects.)  I was thinking about perhaps implementing a
compile-time optional feature using a hashtable to map objects to type
so we can add in some type checking, at the expense of extra runtime
overhead.  Probably not something you'd want to ship enabled, but it
would be useful for debugging.


Feel free to implement just the boilerplate for it with a function that 
always returns true:


static int efi_ptr_valid(void *foo)
{
return 1;
}

which we can then later on improve to do actual checking if we care. The 
least we can do is probably to check for alignment problems.



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

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Rob Clark]

On Wed, Oct 4, 2017 at 10:46 AM, Heinrich Schuchardt  wrote:
> On 10/04/2017 04:14 PM, Rob Clark wrote:
>> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  
>> wrote:
>>> Queued and signaled describe boolean states of events.
>>> So let's use type bool and rename the structure members to is_queued
>>> and is_signaled.
>>>
>>> Update the comments for is_queued and is_signaled.
>>
>> Reviewed-by: Rob Clark 
>>
>> It would be kinda nice to merge my efi_event fixes and rework to use
>> an arbitrary sized list of events before making too many more
>> efi_event changes, since that is kind of annoying to keep rebasing ;-)
>>
>> BR,
>> -R
>
> I would not mind if you patch went first.
>
> But your patch
> https://patchwork.ozlabs.org/patch/812967/
> is not applicable to U-Boot master and needs rebasing anyway.

jfyi, I have it (and other pending patches) rebased on latest master
(as of ~yesterday) here:

  https://github.com/robclark/u-boot/commits/wip-enough-uefi-for-shell

I wasn't planning on resending until I get further with FAT write
stuff (currently on a local branch, although I might not get much time
to work on in the next week or two).. although I can re-send it or any
of the other patches to get Shell.efi working if wanted.  (Note that
I'm also using your patch for efi watchdog support, that was one of
the other required bits.)

Not sure what agraf's plan is but I think the needed bits for
Shell.efi are mergable already.

> Please, add the missing check that the event pointer is valid.
> The EFI code checks other arguments rigorously so we should do the same
> for pointers. It would be very hard to debug a problem in an EFI
> application otherwise.

I'm a bit undecided on this, since we have other places where there is
no good way to check the validity of a pointer.  (For example file or
disk objects.)  I was thinking about perhaps implementing a
compile-time optional feature using a hashtable to map objects to type
so we can add in some type checking, at the expense of extra runtime
overhead.  Probably not something you'd want to ship enabled, but it
would be useful for debugging.

BR,
-R

> @Alexander
> I guess with Suseconf you were quite busy in the last weeks. Did you
> already make up your mind in which sequence we should prepare the EFI
> patches?
>
> The following of my patches could be directly applied to efi-next:
>
> [U-Boot,1/1] efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
> https://patchwork.ozlabs.org/patch/816412/
> [U-Boot,1/1] efi_loader: replace efi_div10 by div64_u64
> https://patchwork.ozlabs.org/patch/820731/
> [U-Boot,1/1] efi_selftest: use efi_st_error for all error messages
> https://patchwork.ozlabs.org/patch/821237/
> [U-Boot,1/1] efi_loader: use type bool for event states
> https://patchwork.ozlabs.org/patch/821302/
> [U-Boot,v2,1/1] efi_selftest: make tests easier to read
> https://patchwork.ozlabs.org/patch/821306/
>
> I guess Rob was refering to
> [U-Boot,1/1] efi_loader: use type bool for event states
>
> Best regards
>
> Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr

[Rob Clark]

On Wed, Oct 4, 2017 at 10:27 AM, Fabio Estevam  wrote:
> Hi Rob,
>
> On Wed, Oct 4, 2017 at 11:11 AM, Rob Clark  wrote:
>
>> btw, I'm still hoping someone can get me some logs so I can see what
>> blksz is, etc, on these boards..
>
> Sorry, I haven't been able to get you the logs yet.
>
> I will probably be able to work on this next week only, unfortunately.
>
> I am adding some mx6 folks in case they could help collecting such
> logs in the meantime.
>
> Just to provide them some context: we are investigating the mx6 SPL
> regression in mainline.
>
>> in the worst case I guess we can change part_test_dos() to:
>>
>> #ifdef SPL
>>   .. old code ..
>> #else
>>   .. new code ..
>> #endif
>> a bit ugly, but at least that wouldn't break efi_bootmgr plus boards
>> with multiple "disks".. having the proper partition signatures I guess
>> doesn't matter in the SPL stage..
>
> Yes, this is what I have locally to workaround the issue:
> https://pastebin.com/XxBfpwh7
>

Not sure Tom's opinion, but I'd be ok with applying this patch, even
if just a temporary fix, to unblock folks trying to test latest u-boot
on these devices

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

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Heinrich Schuchardt]

On 10/04/2017 04:14 PM, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  
> wrote:
>> Queued and signaled describe boolean states of events.
>> So let's use type bool and rename the structure members to is_queued
>> and is_signaled.
>>
>> Update the comments for is_queued and is_signaled.
> 
> Reviewed-by: Rob Clark 
> 
> It would be kinda nice to merge my efi_event fixes and rework to use
> an arbitrary sized list of events before making too many more
> efi_event changes, since that is kind of annoying to keep rebasing ;-)
> 
> BR,
> -R

I would not mind if you patch went first.

But your patch
https://patchwork.ozlabs.org/patch/812967/
is not applicable to U-Boot master and needs rebasing anyway.

Please, add the missing check that the event pointer is valid.
The EFI code checks other arguments rigorously so we should do the same
for pointers. It would be very hard to debug a problem in an EFI
application otherwise.

@Alexander
I guess with Suseconf you were quite busy in the last weeks. Did you
already make up your mind in which sequence we should prepare the EFI
patches?

The following of my patches could be directly applied to efi-next:

[U-Boot,1/1] efi_selftest: enable CONFIG_CMD_BOOTEFI_SELFTEST
https://patchwork.ozlabs.org/patch/816412/
[U-Boot,1/1] efi_loader: replace efi_div10 by div64_u64
https://patchwork.ozlabs.org/patch/820731/
[U-Boot,1/1] efi_selftest: use efi_st_error for all error messages
https://patchwork.ozlabs.org/patch/821237/
[U-Boot,1/1] efi_loader: use type bool for event states
https://patchwork.ozlabs.org/patch/821302/
[U-Boot,v2,1/1] efi_selftest: make tests easier to read
https://patchwork.ozlabs.org/patch/821306/

I guess Rob was refering to
[U-Boot,1/1] efi_loader: use type bool for event states

Best regards

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

Re: [U-Boot] [GIT PULL v3] u-boot-sunxi/master

[Maxime Ripard]

On Wed, Oct 04, 2017 at 02:20:53PM +, Maxime Ripard wrote:
> Hi Tom,
> 
> Hopefully it's going to be the final version of that PR.
> 
> It passed on travis-ci, so we should be all set.
> 
> Thanks!
> Maxime
> 
> The following changes since commit 39dd65a059e503883dbf16d4c00ac083d15837da:
> 
>   sandbox: Enable btrfs support (2017-10-03 08:44:55 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-sunxi sunxi/master

The branch should be just master.

Actually, how does one generate a pull-request without the local
branch name in the output of git request-pull?

Using the remote branch name will error out here, and I haven't found
a good way to do that yet without editing it by hand.

Thanks!
Maxime


-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] Antwort: Re: QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

[Clément Péron]

Hi,

My issue is with the eMMC after the boot from linux 3.12 and a warm reboot.
The eMMC is stuck in an infinite loop after CMD8 small trace of the
eMMC cmds sent:

Sending CMD0
Sending CMD8
dwmci_send_cmd: Response Timeout.
Sending CMD55
dwmci_send_cmd: Response Timeout.
Sending CMD0
Sending CMD1
Sending CMD1
Sending CMD0
Sending CMD1
Sending CMD1
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD8

Not sure is someone got the same behavior but i rollback to the
Socfpga v2013.01.01 and everything is fine.

I would investigate more later.

Regards,
Clement


2017-09-29 11:23 GMT+02:00 Goldschmidt Simon
:
> Hi Clement,
>
>> Did you also test the saveenv and sf unlock ?
>
> Not yet.
>
>> Did you get some strange behaviors after a "warm reboot" from linux ?
>
> Unfortunately, I'm not that far, yet. My Linux image only uses the sd-card 
> for now.
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr

[Fabio Estevam]

Hi Rob,

On Wed, Oct 4, 2017 at 11:11 AM, Rob Clark  wrote:

> btw, I'm still hoping someone can get me some logs so I can see what
> blksz is, etc, on these boards..

Sorry, I haven't been able to get you the logs yet.

I will probably be able to work on this next week only, unfortunately.

I am adding some mx6 folks in case they could help collecting such
logs in the meantime.

Just to provide them some context: we are investigating the mx6 SPL
regression in mainline.

> in the worst case I guess we can change part_test_dos() to:
>
> #ifdef SPL
>   .. old code ..
> #else
>   .. new code ..
> #endif
> a bit ugly, but at least that wouldn't break efi_bootmgr plus boards
> with multiple "disks".. having the proper partition signatures I guess
> doesn't matter in the SPL stage..

Yes, this is what I have locally to workaround the issue:
https://pastebin.com/XxBfpwh7

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

[U-Boot] [GIT PULL v3] u-boot-sunxi/master

[Maxime Ripard]

Hi Tom,

Hopefully it's going to be the final version of that PR.

It passed on travis-ci, so we should be all set.

Thanks!
Maxime

The following changes since commit 39dd65a059e503883dbf16d4c00ac083d15837da:

  sandbox: Enable btrfs support (2017-10-03 08:44:55 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-sunxi sunxi/master

for you to fetch changes up to e6ee85a6891eca187c9a9364c51690d3f6a36932:

  sunxi: only init USB Ethernet gadget when it's enabled (2017-10-03 19:12:06 
+0200)


Chen-Yu Tsai (2):
  sunxi: rename Bananapi M3 dts file name
  sunxi: Enable eMMC on Cubietruck Plus

Icenowy Zheng (2):
  sunxi: defaultly enable SPL for Lichee Pi Zero
  sunxi: only init USB Ethernet gadget when it's enabled

Jagan Teki (1):
  sun7i: a20: Add Bananapi M1 Plus support

Maxime Ripard (22):
  sandbox: Expand list of IO accessors
  usb: gadget: Move USBNET_DEVADDR option out of g_dnl
  usb: gadget: Document USBNET_DEVADDR
  usb: gadget: Move USBNET_HOST_ADDR to Kconfig
  usb: gadget: Convert USB_ETHER to Kconfig
  usb: gadget: usb_ether: Move the interfaces to Kconfig
  usb: gadget: Make g_dnl USB settings common
  usb: gadget: usb_ether: Move settings to common
  sunxi: provide default USB gadget setup
  sunxi: imply USB_GADGET
  cmd: fastboot: Rework fastboot dependency
  musb: sunxi: switch to the device model
  sunxi: Register usb_ether
  sunxi: Imply USB_ETHER
  sunxi: sina33: Sync the device tree with the kernel
  cmd: Move CONFIG_RANDOM_UUID to Kconfig
  sunxi: Enable CMD_GPT by default
  arm: sunxi: Move spl_boot_device in a separate function
  sunxi: Use sunxi_get_boot_device
  sunxi: Remove the MMC index hack
  sunxi: Fix USB_GADGET implication
  sunxi: usb_phy: invert the USB phy_ctl condition

Stefan Mavrodiev (1):
  sunxi: Add support for A20-OLinuXino-MICRO-eMMC

 arch/arm/Kconfig   |   5 +-
 arch/arm/dts/Makefile  |   4 +-
 arch/arm/dts/axp223.dtsi   |  58 +++
 arch/arm/dts/axp22x.dtsi   |  10 +
 arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts|  91 +++-
 arch/arm/dts/sun7i-a20-olinuxino-micro-emmc.dts|  70 +++
 arch/arm/dts/sun8i-a23-a33.dtsi| 446 +--
 arch/arm/dts/sun8i-a23.dtsi|  88 ++--
 arch/arm/dts/sun8i-a33-sinlinx-sina33.dts  |  43 ++
 arch/arm/dts/sun8i-a33.dtsi| 477 +
 ...ovoip-bpi-m3.dts => sun8i-a83t-bananapi-m3.dts} |   0
 arch/arm/include/asm/arch-sunxi/spl.h  |   2 +
 arch/arm/include/asm/arch-sunxi/usb_phy.h  |   7 -
 arch/arm/mach-imx/spl.c|   2 +-
 arch/arm/mach-sunxi/board.c|  11 +-
 arch/arm/mach-sunxi/usb_phy.c  |  14 +-
 arch/sandbox/include/asm/io.h  |  47 ++
 board/samsung/common/gadget.c  |   4 +-
 board/siemens/common/factoryset.c  |   4 +-
 board/sunxi/MAINTAINERS|   5 +
 board/sunxi/board.c|  31 +-
 cmd/Kconfig|   7 +
 cmd/fastboot/Kconfig   |   7 +
 configs/A13-OLinuXino_defconfig|   5 -
 configs/A20-OLinuXino-Lime2-eMMC_defconfig |   6 -
 configs/A20-OLinuXino-Lime2_defconfig  |   5 -
 configs/A20-OLinuXino_MICRO-eMMC_defconfig |  27 ++
 configs/CHIP_defconfig |   5 -
 configs/CHIP_pro_defconfig |   5 -
 configs/Cubietruck_defconfig   |   5 -
 configs/Cubietruck_plus_defconfig  |   1 +
 configs/LicheePi_Zero_defconfig|   4 +
 configs/Nintendo_NES_Classic_Edition_defconfig |   5 -
 configs/Sinlinx_SinA33_defconfig   |   6 -
 configs/Sinovoip_BPI_M3_defconfig  |   2 +-
 configs/am335x_baltos_defconfig|   8 +-
 configs/am335x_boneblack_defconfig |  10 +-
 configs/am335x_boneblack_vboot_defconfig   |   9 +-
 configs/am335x_evm_defconfig   |   9 +-
 configs/am335x_evm_nor_defconfig   |   9 +-
 configs/am335x_evm_norboot_defconfig   |  10 +-
 configs/am335x_evm_spiboot_defconfig   |   9 +-
 configs/am335x_evm_usbspl_defconfig|   9 +-
 configs/am335x_hs_evm_defconfig|   7 +-
 configs/am43xx_evm_defconfig   |   6 +-
 configs/am43xx_evm_ethboot_defconfig   |   6 +-
 configs/am43xx_evm_qspiboot_defconfig  |   6 +-
 configs/am43xx_evm_usbhost_boot_defconfig  |   6 +-
 configs/am43xx_hs_evm_defconfig  

Re: [U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Rob Clark]

On Wed, Oct 4, 2017 at 9:03 AM, Heinrich Schuchardt  wrote:
> Queued and signaled describe boolean states of events.
> So let's use type bool and rename the structure members to is_queued
> and is_signaled.
>
> Update the comments for is_queued and is_signaled.

Reviewed-by: Rob Clark 

It would be kinda nice to merge my efi_event fixes and rework to use
an arbitrary sized list of events before making too many more
efi_event changes, since that is kind of annoying to keep rebasing ;-)

BR,
-R

> Reported-by: Simon Glass 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_loader.h  |  8 
>  lib/efi_loader/efi_boottime.c | 32 
>  lib/efi_loader/efi_console.c  |  2 +-
>  3 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 2f081f8996..1148db2b00 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -136,8 +136,8 @@ struct efi_object {
>   * @nofify_function:   Function to call when the event is triggered
>   * @notify_context:Data to be passed to the notify function
>   * @trigger_type:  Type of timer, see efi_set_timer
> - * @queued:The notification functionis queued
> - * @signaled:  The event occured
> + * @queued:The notification function is queued
> + * @signaled:  The event occurred. The event is in the signaled 
> state.
>   */
>  struct efi_event {
> uint32_t type;
> @@ -147,8 +147,8 @@ struct efi_event {
> u64 trigger_next;
> u64 trigger_time;
> enum efi_timer_delay trigger_type;
> -   int queued;
> -   int signaled;
> +   bool is_queued;
> +   bool is_signaled;
>  };
>
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index d63c66dd45..8975fc4ec1 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -132,14 +132,14 @@ const char *__efi_nesting_dec(void)
>  void efi_signal_event(struct efi_event *event)
>  {
> if (event->notify_function) {
> -   event->queued = 1;
> +   event->is_queued = true;
> /* Check TPL */
> if (efi_tpl >= event->notify_tpl)
> return;
> EFI_CALL_VOID(event->notify_function(event,
>  event->notify_context));
> }
> -   event->queued = 0;
> +   event->is_queued = false;
>  }
>
>  static efi_status_t efi_unsupported(const char *funcname)
> @@ -267,8 +267,8 @@ efi_status_t efi_create_event(uint32_t type, UINTN 
> notify_tpl,
> efi_events[i].notify_context = notify_context;
> /* Disable timers on bootup */
> efi_events[i].trigger_next = -1ULL;
> -   efi_events[i].queued = 0;
> -   efi_events[i].signaled = 0;
> +   efi_events[i].is_queued = false;
> +   efi_events[i].is_signaled = false;
> *event = _events[i];
> return EFI_SUCCESS;
> }
> @@ -301,7 +301,7 @@ void efi_timer_check(void)
> for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
> if (!efi_events[i].type)
> continue;
> -   if (efi_events[i].queued)
> +   if (efi_events[i].is_queued)
> efi_signal_event(_events[i]);
> if (!(efi_events[i].type & EVT_TIMER) ||
> now < efi_events[i].trigger_next)
> @@ -317,7 +317,7 @@ void efi_timer_check(void)
> default:
> continue;
> }
> -   efi_events[i].signaled = 1;
> +   efi_events[i].is_signaled = true;
> efi_signal_event(_events[i]);
> }
> WATCHDOG_RESET();
> @@ -354,7 +354,7 @@ efi_status_t efi_set_timer(struct efi_event *event, enum 
> efi_timer_delay type,
> }
> event->trigger_type = type;
> event->trigger_time = trigger_time;
> -   event->signaled = 0;
> +   event->is_signaled = false;
> return EFI_SUCCESS;
> }
> return EFI_INVALID_PARAMETER;
> @@ -391,14 +391,14 @@ static efi_status_t EFIAPI efi_wait_for_event(unsigned 
> long num_events,
>  known_event:
> if (!event[i]->type || event[i]->type & EVT_NOTIFY_SIGNAL)
> return EFI_EXIT(EFI_INVALID_PARAMETER);
> -   if (!event[i]->signaled)
> +   if (!event[i]->is_signaled)
> efi_signal_event(event[i]);
> }
>
> /* Wait for signal */
> for (;;) {
> for (i = 0; i < num_events; ++i) {
> -   if (event[i]->signaled)
> +   if (event[i]->is_signaled)
>

Re: [U-Boot] [PATCH] disk: Don't assume blksz > legacy_mbr

[Rob Clark]

On Tue, Oct 3, 2017 at 12:32 PM, Rob Clark  wrote:
> On Tue, Oct 3, 2017 at 12:04 PM, Fabio Estevam  wrote:
>> On Tue, Oct 3, 2017 at 12:30 PM, Rob Clark  wrote:
>>> On some devices, this does not appear to be a valid assumption.  So
>>> figure out the number of blocks we actually need to read.
>>>
>>> Signed-off-by: Rob Clark 
>>
>> This version does not solve the mx6 spl boot issue.
>
> Hmm, the change you had tested earlier is not correct, since it would
> allocate potentially less than blksz (and then read blksz bytes into
> it)..
>
> *maybe* the memory allocation is failing?  I'm not sure, I'm kind of
> just guessing here.  It would be nice to know what blksz is on your
> device.  (That said, before the original patch, the allocation was for
> blksz bytes too, so if this were the issue I think it would have been
> failing before.)
>

btw, I'm still hoping someone can get me some logs so I can see what
blksz is, etc, on these boards..

in the worst case I guess we can change part_test_dos() to:

#ifdef SPL
  .. old code ..
#else
  .. new code ..
#endif

a bit ugly, but at least that wouldn't break efi_bootmgr plus boards
with multiple "disks".. having the proper partition signatures I guess
doesn't matter in the SPL stage..

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

[U-Boot] [PATCH v2 1/1] efi_selftest: make tests easier to read

[Heinrich Schuchardt]

Rename counter to more illustrative names.
Update notification function description.
Simplify notification function.
Add comment for arbitrary non-zero value.
Document @return.
Use constants for return values of setup, execute, teardown.

Reported-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
v2:
Remove superfluous blank in a message text.
---
 include/efi_selftest.h   |  3 +
 lib/efi_selftest/efi_selftest.c  | 15 +++--
 lib/efi_selftest/efi_selftest_events.c   | 80 --
 lib/efi_selftest/efi_selftest_exitbootservices.c | 46 +++--
 lib/efi_selftest/efi_selftest_tpl.c  | 85 +---
 5 files changed, 129 insertions(+), 100 deletions(-)

diff --git a/include/efi_selftest.h b/include/efi_selftest.h
index 76304a2b2a..beb662d4e1 100644
--- a/include/efi_selftest.h
+++ b/include/efi_selftest.h
@@ -14,6 +14,9 @@
 #include 
 #include 
 
+#define EFI_ST_SUCCESS 0
+#define EFI_ST_FAILURE 1
+
 /*
  * Prints an error message.
  *
diff --git a/lib/efi_selftest/efi_selftest.c b/lib/efi_selftest/efi_selftest.c
index ff00254c21..45d8d3d384 100644
--- a/lib/efi_selftest/efi_selftest.c
+++ b/lib/efi_selftest/efi_selftest.c
@@ -66,16 +66,17 @@ void efi_st_exit_boot_services(void)
  *
  * @test   the test to be executed
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int setup(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->setup)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nSetting up '%s'\n", test->name);
ret = test->setup(handle, systable);
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Setting up '%s' failed\n", test->name);
++*failures;
} else {
@@ -89,16 +90,17 @@ static int setup(struct efi_unit_test *test, unsigned int 
*failures)
  *
  * @test   the test to be executed
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int execute(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->execute)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nExecuting '%s'\n", test->name);
ret = test->execute();
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Executing '%s' failed\n", test->name);
++*failures;
} else {
@@ -112,16 +114,17 @@ static int execute(struct efi_unit_test *test, unsigned 
int *failures)
  *
  * @test   the test to be torn down
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int teardown(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->teardown)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nTearing down '%s'\n", test->name);
ret = test->teardown();
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Tearing down '%s' failed\n", test->name);
++*failures;
} else {
diff --git a/lib/efi_selftest/efi_selftest_events.c 
b/lib/efi_selftest/efi_selftest_events.c
index c4f66952b9..7766eedc38 100644
--- a/lib/efi_selftest/efi_selftest_events.c
+++ b/lib/efi_selftest/efi_selftest_events.c
@@ -14,20 +14,22 @@
 
 static struct efi_event *event_notify;
 static struct efi_event *event_wait;
-static unsigned int counter;
+static unsigned int timer_ticks;
 static struct efi_boot_services *boottime;
 
 /*
- * Notification function, increments a counter.
+ * Notification function, increments the notfication count if parameter
+ * context is provided.
  *
  * @event  notified event
- * @contextpointer to the counter
+ * @contextpointer to the notification count
  */
 static void EFIAPI notify(struct efi_event *event, void *context)
 {
-   if (!context)
-   return;
-   ++*(unsigned int *)context;
+   unsigned int *count = context;
+
+   if (count)
+   ++*count;
 }
 
 /*
@@ -38,6 +40,7 @@ static void EFIAPI notify(struct efi_event *event, void 
*context)
  *
  * @handle:handle of the loaded image
  * @systable:  system table
+ * @return:EFI_ST_SUCCESS for success
  */
 static int setup(const efi_handle_t handle,
 const struct efi_system_table *systable)
@@ -47,25 +50,27 @@ static int setup(const efi_handle_t handle,
boottime = systable->boottime;
 
ret = boottime->create_event(EVT_TIMER | EVT_NOTIFY_SIGNAL,
-TPL_CALLBACK, notify, (void *),
+TPL_CALLBACK, notify, (void *)_ticks,
 

Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner

[Faiz Abbas]

Hi,

On Wednesday 04 October 2017 06:01 PM, Marek Vasut wrote:
> On 10/04/2017 12:51 PM, Faiz Abbas wrote:
>> Hi,
>> On Tuesday 03 October 2017 06:48 PM, Marek Vasut wrote:
>>> On 10/03/2017 03:17 PM, Faiz Abbas wrote:
 Hi,
 On Tuesday 03 October 2017 05:34 PM, Marek Vasut wrote:
> On 09/19/2017 01:15 PM, Faiz Abbas wrote:
>>  
>> -dwc3_flush_cache((uintptr_t)trb, sizeof(*trb));
>> +dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 
>> 2);
>
> Why *2 ?

 Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is not
 strictly required as dwc3_flush_cache() rounds up the size to
 CACHELINE_SIZE but from a caller POV, flush everything we allocated.
>>>
>>> Can the other TRB be in use ? Maybe aligning the TRBs to cacheline size
>>> would be better ?
>>>
>> A single trb is 16 bytes in size and two of them are allocated
>> contiguously.
> 
> Why are two allocated continuously ? (I am not dwc3 expert)

Neither am I. I did try to pad to the dwc_trb structure such that each
trb is 64 bytes in size but this leads to failures when testing. I
didn't get a chance to debug this though. I suspect its because the code
expects the trbs to be contiguous and/or 16 bytes in size.

It'll be great if someone can shed light on this.

> 
>> Originally, a flush on the first trb was flushing both of
>> them anyway as the minimum flush is CACHELINE_SIZE (64 bytes). This is
>> not changing any functionality as far as I have tested. Just making sure
>> cache misaligned warnings don't show up.
> 
> If you flush 64bytes, you flush more than 2 TRBs, you flush something
> around those TRBs too.

Yes and that is why I changed the allocation step to
ROUND(sizeof(trb) * 2, 64). We use only 32 bytes for two trbs but make
sure to allocate 64 bytes so that we can safely flush it.

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

[U-Boot] [PATCH 1/1] efi_selftest: make tests easier to read

[Heinrich Schuchardt]

Rename counter to more illustrative names.
Update notification function description.
Simplify notification function.
Add comment for arbitrary non-zero value.
Document @return.
Use constants for return values of setup, execute, teardown.

Reported-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
 include/efi_selftest.h   |  3 +
 lib/efi_selftest/efi_selftest.c  | 15 +++--
 lib/efi_selftest/efi_selftest_events.c   | 80 --
 lib/efi_selftest/efi_selftest_exitbootservices.c | 46 +++--
 lib/efi_selftest/efi_selftest_tpl.c  | 85 +---
 5 files changed, 129 insertions(+), 100 deletions(-)

diff --git a/include/efi_selftest.h b/include/efi_selftest.h
index 76304a2b2a..beb662d4e1 100644
--- a/include/efi_selftest.h
+++ b/include/efi_selftest.h
@@ -14,6 +14,9 @@
 #include 
 #include 
 
+#define EFI_ST_SUCCESS 0
+#define EFI_ST_FAILURE 1
+
 /*
  * Prints an error message.
  *
diff --git a/lib/efi_selftest/efi_selftest.c b/lib/efi_selftest/efi_selftest.c
index ff00254c21..45d8d3d384 100644
--- a/lib/efi_selftest/efi_selftest.c
+++ b/lib/efi_selftest/efi_selftest.c
@@ -66,16 +66,17 @@ void efi_st_exit_boot_services(void)
  *
  * @test   the test to be executed
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int setup(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->setup)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nSetting up '%s'\n", test->name);
ret = test->setup(handle, systable);
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Setting up '%s' failed\n", test->name);
++*failures;
} else {
@@ -89,16 +90,17 @@ static int setup(struct efi_unit_test *test, unsigned int 
*failures)
  *
  * @test   the test to be executed
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int execute(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->execute)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nExecuting '%s'\n", test->name);
ret = test->execute();
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Executing '%s' failed\n", test->name);
++*failures;
} else {
@@ -112,16 +114,17 @@ static int execute(struct efi_unit_test *test, unsigned 
int *failures)
  *
  * @test   the test to be torn down
  * @failures   counter that will be incremented if a failure occurs
+ * @return EFI_ST_SUCCESS for success
  */
 static int teardown(struct efi_unit_test *test, unsigned int *failures)
 {
int ret;
 
if (!test->teardown)
-   return 0;
+   return EFI_ST_SUCCESS;
efi_st_printf("\nTearing down '%s'\n", test->name);
ret = test->teardown();
-   if (ret) {
+   if (ret != EFI_ST_SUCCESS) {
efi_st_error("Tearing down '%s' failed\n", test->name);
++*failures;
} else {
diff --git a/lib/efi_selftest/efi_selftest_events.c 
b/lib/efi_selftest/efi_selftest_events.c
index c4f66952b9..7766eedc38 100644
--- a/lib/efi_selftest/efi_selftest_events.c
+++ b/lib/efi_selftest/efi_selftest_events.c
@@ -14,20 +14,22 @@
 
 static struct efi_event *event_notify;
 static struct efi_event *event_wait;
-static unsigned int counter;
+static unsigned int timer_ticks;
 static struct efi_boot_services *boottime;
 
 /*
- * Notification function, increments a counter.
+ * Notification function, increments the notfication count if parameter
+ * context is provided.
  *
  * @event  notified event
- * @contextpointer to the counter
+ * @contextpointer to the notification count
  */
 static void EFIAPI notify(struct efi_event *event, void *context)
 {
-   if (!context)
-   return;
-   ++*(unsigned int *)context;
+   unsigned int *count = context;
+
+   if (count)
+   ++*count;
 }
 
 /*
@@ -38,6 +40,7 @@ static void EFIAPI notify(struct efi_event *event, void 
*context)
  *
  * @handle:handle of the loaded image
  * @systable:  system table
+ * @return:EFI_ST_SUCCESS for success
  */
 static int setup(const efi_handle_t handle,
 const struct efi_system_table *systable)
@@ -47,25 +50,27 @@ static int setup(const efi_handle_t handle,
boottime = systable->boottime;
 
ret = boottime->create_event(EVT_TIMER | EVT_NOTIFY_SIGNAL,
-TPL_CALLBACK, notify, (void *),
+TPL_CALLBACK, notify, (void *)_ticks,
 _notify);
if (ret != EFI_SUCCESS) {

[U-Boot] [PATCH 1/1] efi_loader: use type bool for event states

[Heinrich Schuchardt]

Queued and signaled describe boolean states of events.
So let's use type bool and rename the structure members to is_queued
and is_signaled.

Update the comments for is_queued and is_signaled.

Reported-by: Simon Glass 
Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h  |  8 
 lib/efi_loader/efi_boottime.c | 32 
 lib/efi_loader/efi_console.c  |  2 +-
 3 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 2f081f8996..1148db2b00 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -136,8 +136,8 @@ struct efi_object {
  * @nofify_function:   Function to call when the event is triggered
  * @notify_context:Data to be passed to the notify function
  * @trigger_type:  Type of timer, see efi_set_timer
- * @queued:The notification functionis queued
- * @signaled:  The event occured
+ * @queued:The notification function is queued
+ * @signaled:  The event occurred. The event is in the signaled state.
  */
 struct efi_event {
uint32_t type;
@@ -147,8 +147,8 @@ struct efi_event {
u64 trigger_next;
u64 trigger_time;
enum efi_timer_delay trigger_type;
-   int queued;
-   int signaled;
+   bool is_queued;
+   bool is_signaled;
 };
 
 
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index d63c66dd45..8975fc4ec1 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -132,14 +132,14 @@ const char *__efi_nesting_dec(void)
 void efi_signal_event(struct efi_event *event)
 {
if (event->notify_function) {
-   event->queued = 1;
+   event->is_queued = true;
/* Check TPL */
if (efi_tpl >= event->notify_tpl)
return;
EFI_CALL_VOID(event->notify_function(event,
 event->notify_context));
}
-   event->queued = 0;
+   event->is_queued = false;
 }
 
 static efi_status_t efi_unsupported(const char *funcname)
@@ -267,8 +267,8 @@ efi_status_t efi_create_event(uint32_t type, UINTN 
notify_tpl,
efi_events[i].notify_context = notify_context;
/* Disable timers on bootup */
efi_events[i].trigger_next = -1ULL;
-   efi_events[i].queued = 0;
-   efi_events[i].signaled = 0;
+   efi_events[i].is_queued = false;
+   efi_events[i].is_signaled = false;
*event = _events[i];
return EFI_SUCCESS;
}
@@ -301,7 +301,7 @@ void efi_timer_check(void)
for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
if (!efi_events[i].type)
continue;
-   if (efi_events[i].queued)
+   if (efi_events[i].is_queued)
efi_signal_event(_events[i]);
if (!(efi_events[i].type & EVT_TIMER) ||
now < efi_events[i].trigger_next)
@@ -317,7 +317,7 @@ void efi_timer_check(void)
default:
continue;
}
-   efi_events[i].signaled = 1;
+   efi_events[i].is_signaled = true;
efi_signal_event(_events[i]);
}
WATCHDOG_RESET();
@@ -354,7 +354,7 @@ efi_status_t efi_set_timer(struct efi_event *event, enum 
efi_timer_delay type,
}
event->trigger_type = type;
event->trigger_time = trigger_time;
-   event->signaled = 0;
+   event->is_signaled = false;
return EFI_SUCCESS;
}
return EFI_INVALID_PARAMETER;
@@ -391,14 +391,14 @@ static efi_status_t EFIAPI efi_wait_for_event(unsigned 
long num_events,
 known_event:
if (!event[i]->type || event[i]->type & EVT_NOTIFY_SIGNAL)
return EFI_EXIT(EFI_INVALID_PARAMETER);
-   if (!event[i]->signaled)
+   if (!event[i]->is_signaled)
efi_signal_event(event[i]);
}
 
/* Wait for signal */
for (;;) {
for (i = 0; i < num_events; ++i) {
-   if (event[i]->signaled)
+   if (event[i]->is_signaled)
goto out;
}
/* Allow events to occur. */
@@ -410,7 +410,7 @@ out:
 * Reset the signal which is passed to the caller to allow periodic
 * events to occur.
 */
-   event[i]->signaled = 0;
+   event[i]->is_signaled = false;
if (index)
*index = i;
 
@@ -425,9 +425,9 @@ static efi_status_t EFIAPI efi_signal_event_ext(struct 
efi_event *event)
for (i = 0; i < ARRAY_SIZE(efi_events); ++i) {
if (event != _events[i])

[U-Boot] [PATCH v2] fdt: update bcm283x device tree sources to Linux 4.14 state

[Alexander Graf]

Upstream Linux has received a few device tree updates to the RPi
which we should propagate into the builtin U-Boot one as well to
gain hardware support.

This patch bumps the dts files to their 4.14 Linux counterparts
with the exception of sdhost on 32bit RPi versions. There we stay
with iproc as the sdhost driver is missing in U-Boot.

Signed-off-by: Alexander Graf 

---

v1 -> v2:

  - use sdhost on 32bit RPis
---
 arch/arm/dts/bcm2835-rpi-a-plus.dts|  74 +++-
 arch/arm/dts/bcm2835-rpi-a.dts |  76 +++-
 arch/arm/dts/bcm2835-rpi-b-plus.dts|  75 +++-
 arch/arm/dts/bcm2835-rpi-b-rev2.dts|  75 +++-
 arch/arm/dts/bcm2835-rpi-b.dts |  76 +++-
 arch/arm/dts/bcm2835-rpi.dtsi  |  34 +++-
 arch/arm/dts/bcm2835.dtsi  |  10 +
 arch/arm/dts/bcm2836-rpi-2-b.dts   |   9 +-
 arch/arm/dts/bcm2836.dtsi  |  11 ++
 arch/arm/dts/bcm2837-rpi-3-b.dts   |  35 +++-
 arch/arm/dts/bcm2837.dtsi  |  13 +-
 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi |   2 +-
 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi |   2 +-
 arch/arm/dts/bcm283x-rpi-usb-host.dtsi |   3 +
 arch/arm/dts/bcm283x.dtsi  | 325 -
 include/dt-bindings/clock/bcm2835.h|   2 +
 include/dt-bindings/pinctrl/bcm2835.h  |   5 +
 17 files changed, 801 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/dts/bcm283x-rpi-usb-host.dtsi

diff --git a/arch/arm/dts/bcm2835-rpi-a-plus.dts 
b/arch/arm/dts/bcm2835-rpi-a-plus.dts
index 35ff4e7a4a..9f866491ef 100644
--- a/arch/arm/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/dts/bcm2835-rpi-a-plus.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"
 
 / {
compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
@@ -21,7 +22,72 @@
 };
 
  {
-   pinctrl-0 = <  _alt0 >;
+   /*
+* This is based on the unreleased schematic for the Model A+.
+*
+* Legend:
+* "NC" = not connected (no rail from the SoC)
+* "FOO" = GPIO line named "FOO" on the schematic
+* "FOO_N" = GPIO line named "FOO" on schematic, active low
+*/
+   gpio-line-names = "SDA0",
+ "SCL0",
+ "SDA1",
+ "SCL1",
+ "GPIO_GCLK",
+ "GPIO5",
+ "GPIO6",
+ "SPI_CE1_N",
+ "SPI_CE0_N",
+ "SPI_MISO",
+ "SPI_MOSI",
+ "SPI_SCLK",
+ "GPIO12",
+ "GPIO13",
+ /* Serial port */
+ "TXD0",
+ "RXD0",
+ "GPIO16",
+ "GPIO17",
+ "GPIO18",
+ "GPIO19",
+ "GPIO20",
+ "GPIO21",
+ "GPIO22",
+ "GPIO23",
+ "GPIO24",
+ "GPIO25",
+ "GPIO26",
+ "GPIO27",
+ "SDA0",
+ "SCL0",
+ "NC", /* GPIO30 */
+ "NC", /* GPIO31 */
+ "CAM_GPIO1", /* GPIO32 */
+ "NC", /* GPIO33 */
+ "NC", /* GPIO34 */
+ "PWR_LOW_N", /* GPIO35 */
+ "NC", /* GPIO36 */
+ "NC", /* GPIO37 */
+ "USB_LIMIT", /* GPIO38 */
+ "NC", /* GPIO39 */
+ "PWM0_OUT", /* GPIO40 */
+ "CAM_GPIO0", /* GPIO41 */
+ "NC", /* GPIO42 */
+ "NC", /* GPIO43 */
+ "NC", /* GPIO44 */
+ "PWM1_OUT", /* GPIO45 */
+ "HDMI_HPD_N",
+ "STATUS_LED",
+ /* Used by SD Card */
+ "SD_CLK_R",
+ "SD_CMD_R",
+ "SD_DATA0_R",
+ "SD_DATA1_R",
+ "SD_DATA2_R",
+ "SD_DATA3_R";
+
+   pinctrl-0 = <  _alt0>;
 
/* I2S interface */
i2s_alt0: i2s_alt0 {
@@ -33,3 +99,9 @@
  {
hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio14>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/bcm2835-rpi-a.dts b/arch/arm/dts/bcm2835-rpi-a.dts
index 306a84ee98..4b1af06c8d 100644
--- a/arch/arm/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/dts/bcm2835-rpi-a.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include 

Re: [U-Boot] [PATCH v4 2/2] wandboard: Add support for the MX6QP variant

[Fabio Estevam]

Hi Stefano,

On Wed, Oct 4, 2017 at 6:34 AM, Stefano Babic  wrote:

> mmhhh...it looks to me we are diverging with this SOC. I understand that
> current funtions are not suitable for the new SOC. However, we were able
> to manage up now to write tables (mx6dq_iomux_ddr_regs) and use
> functions to setup the strength and the other parameters. As your tests
> has proofed that these functions do not work for MX6QP, the logical way
> to do is to modify these functions instead of putting back all this code
> in the board file. Do you agree ?

Sure, I will work on using the common code for imx6qp here too.

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

Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner

[Marek Vasut]

On 10/04/2017 12:51 PM, Faiz Abbas wrote:
> Hi,
> 
> On Tuesday 03 October 2017 06:48 PM, Marek Vasut wrote:
>> On 10/03/2017 03:17 PM, Faiz Abbas wrote:
>>> Hi,
>>>
>>> On Tuesday 03 October 2017 05:34 PM, Marek Vasut wrote:
 On 09/19/2017 01:15 PM, Faiz Abbas wrote:
> A flush of the cache is required before any DMA access can take place.

 You mean invalidation for inbound DMA, flush for outbound DMA, right ?
>>>
>>> yes thats what i meant.
>>>
>>>
>  
> - dwc3_flush_cache((uintptr_t)trb, sizeof(*trb));
> + dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2);

 Why *2 ?
>>>
>>> Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is not
>>> strictly required as dwc3_flush_cache() rounds up the size to
>>> CACHELINE_SIZE but from a caller POV, flush everything we allocated.
>>
>> Can the other TRB be in use ? Maybe aligning the TRBs to cacheline size
>> would be better ?
>>
> A single trb is 16 bytes in size and two of them are allocated
> contiguously.

Why are two allocated continuously ? (I am not dwc3 expert)

> Originally, a flush on the first trb was flushing both of
> them anyway as the minimum flush is CACHELINE_SIZE (64 bytes). This is
> not changing any functionality as far as I have tested. Just making sure
> cache misaligned warnings don't show up.

If you flush 64bytes, you flush more than 2 TRBs, you flush something
around those TRBs too.

> Thanks,
> Faiz
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] u-boot hangs after reboot

[Zoran Stojsavljevic]

Hello Mike,

It could be that newer versions of U-Boot include ECC testing/checking for
Olimex-olinuxino-micro-emmc. and this might influence your tests/reboots.

Please, check for ECC and try not to use/to exclude ECC checking
algorithm... Just to simplify use case?!

Hint out of desperation. ;-)

Zoran

On Wed, Oct 4, 2017 at 8:53 AM, Mike Mildner 
wrote:

> Hi all,
>
> i'm new to this list...
>
> I have a strange problem with my Olimex-olinuxino-micro-emmc (Allwinner
> A20):
>
> I've tested u-boot-v2016.07/09/11 2017.03/05/09 - all this version hangs
> after reboot.
> Only reseting or repowering helps.
> On Display i get this:
>
> U-Boot SPL 2016.09 (Oct 04 2017 - 08:12:07)
> DR
>
> The version u-boot-v2016.03 reboots fine and always.
>
> Any ideas or hints?
>
> Thx Mike
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

[Guillaume Gardet]

Le 04/10/2017 à 13:46, Tom Rini a écrit :

On Wed, Oct 04, 2017 at 09:39:52AM +0200, Guillaume Gardet wrote:


Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :


Le 02/10/2017 à 17:58, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:

Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis 
Date:   Fri Apr 21 10:01:28 2017 -0500

  Kconfig: Enable FIT support by default for TI platforms

  Almost all TI defconfigs enable this already, add this as a default
  and remove the explicit assignment.

  Signed-off-by: Andrew F. Davis 
  Reviewed-by: Tom Rini 

broke boot on Beagleboard xM. I mean the board hangs after:
  OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
  OMAP3 Beagle board + LPDDR/NAND
  I2C:   ready
  DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!

This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

OK.  Can you test FAT booting?  Both should work, but I have an idea at
least on RAW, but I'd like to rule out anything else other than size
changes.   Thanks!

Indeed, if u-boot.img is on FAT partition, it boots properly!

So, what is the problem?
Are we limited in size for u-boot.img when raw booting is used?

Actually, I'm not sure now.  I thought it was one thing, but no, it
can't be just a size thing.  And it's proper U-Boot that fails, not SPL.
Can you add a call to image_check_dcrc() to make sure that the
u-boot.img that's being loaded is not corrupted in some dway?  Thanks!



Ok, but where should I add such a call?

Guillaume

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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

[Tom Rini]

On Wed, Oct 04, 2017 at 09:39:52AM +0200, Guillaume Gardet wrote:
> 
> 
> Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :
> >
> >
> >Le 02/10/2017 à 17:58, Tom Rini a écrit :
> >>On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:
> >>>
> >>>Le 02/10/2017 à 15:53, Tom Rini a écrit :
> On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:
> >Hi,
> >
> >commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
> >Author: Andrew F. Davis 
> >Date:   Fri Apr 21 10:01:28 2017 -0500
> >
> > Kconfig: Enable FIT support by default for TI platforms
> >
> > Almost all TI defconfigs enable this already, add this as a default
> > and remove the explicit assignment.
> >
> > Signed-off-by: Andrew F. Davis 
> > Reviewed-by: Tom Rini 
> >
> >broke boot on Beagleboard xM. I mean the board hangs after:
> > OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
> > OMAP3 Beagle board + LPDDR/NAND
> > I2C:   ready
> > DRAM:  512 MiB
> >
> >
> >To get back the board booting, I need to manually disable FIT 
> >(CONFIG_FIT) _and_ disable SHA256 hash support (CONFIG_SHA256).
> >
> >If I enable FIT without sha256 : it breaks boot.
> >If I enable sha256 without FIT : it breaks boot.
> >
> >Any idea what could cause this?
> >
> >As a workaround we could disable it in the omap3_beagle_defconfig but I 
> >guess it would be better to fix it instead of workaround it, since other 
> >boards may also be affected.
> Which Beagleboard xM rev do you have?  And how are you booting (FAT or
> raw) ?  Mine, FAT booting, is working currently and is part of my
> automated test farm, thanks!
> >>>This is a Beagleboard xM rev. B.
> >>>We use raw booting (instead of default FAT booting).
> >>OK.  Can you test FAT booting?  Both should work, but I have an idea at
> >>least on RAW, but I'd like to rule out anything else other than size
> >>changes.   Thanks!
> >
> >Indeed, if u-boot.img is on FAT partition, it boots properly!
> 
> So, what is the problem?
> Are we limited in size for u-boot.img when raw booting is used?

Actually, I'm not sure now.  I thought it was one thing, but no, it
can't be just a size thing.  And it's proper U-Boot that fails, not SPL.
Can you add a call to image_check_dcrc() to make sure that the
u-boot.img that's being loaded is not corrupted in some dway?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] fdt: update bcm283x device tree sources to Linux 4.14 state

[Alexander Graf]

On 04.10.17 08:59, Fabian Vogt wrote:

On Monday, October 4 2017, 06:33:37 CEST Alexander Graf wrote:

Upstream Linux has received a few device tree updates to the RPi
which we should propagate into the builtin U-Boot one as well to
gain hardware support.

This patch bumps the dts files to their 4.14 Linux counterparts.


Looks good to me.


Signed-off-by: Alexander Graf 

Acked-by: Fabian Vogt 


My testing just revealed that this breaks on the RPi 1B. It doesn't find 
the SD card.


I'll dig a bit.


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

[U-Boot] INTEL E3900 Apollo Lake I (APL-I) with U-Boot?

[Zoran Stojsavljevic]

Hello to the U-Boot Community,

I am curious about the following HW/FW configuration with regards to the
U-Boot?

Did anybody managed to run the following: INTEL Atom E3900 APL-I with
U-Boot?

E3900 -> IFWI -> MBR -> U-Boot -> eLinux/YOCTO ?!

Here are some explanations regarding the terms/context:

*IFWI is the Intel FirmWare Interface, a binary blob loaded from the eMMC
boot partition that executes a secondary loader (in this case U-Boot) from
the main eMMC. IFWI blobs for the APL-I are provided by Intel and are
specific for different flavors of the MID silicon.*
*Normal IFWI eMMC boot process*

   1. *On-chip boot rom inits eMMC and loads IFWI from the MMC boot
   partitions*
   2. *IFWI looks for OSIP header at top of eMMC (MBR boot block)*
   3. *The header directs IFWI to the start, size, load address, and entry
   of U-Boot in eMMC*
   4. *(need clarification) If u-boot is not found, try the alt u-boot
   image at 5MB into the eMMC*
   5. *U-Boot is loaded into RAM and executed*

*OSIP stands for OS Image Profile, and it is nothing more and less than
INTEL name for very known old fashion MBR, considering DATA structure.*

Thank you in advance,
Zoran
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] u-boot hangs after reboot

[Mike Mildner]

Hi all,

i'm new to this list...

I have a strange problem with my Olimex-olinuxino-micro-emmc (Allwinner A20):

I've tested u-boot-v2016.07/09/11 2017.03/05/09 - all this version hangs after 
reboot.
Only reseting or repowering helps.
On Display i get this:

U-Boot SPL 2016.09 (Oct 04 2017 - 08:12:07)
DR

The version u-boot-v2016.03 reboots fine and always.

Any ideas or hints?

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

Re: [U-Boot] [PATCH] dwc: ep0: Allocate and flush dwc->ep0_trb in a cache aligned manner

[Faiz Abbas]

Hi,

On Tuesday 03 October 2017 06:48 PM, Marek Vasut wrote:
> On 10/03/2017 03:17 PM, Faiz Abbas wrote:
>> Hi,
>>
>> On Tuesday 03 October 2017 05:34 PM, Marek Vasut wrote:
>>> On 09/19/2017 01:15 PM, Faiz Abbas wrote:
 A flush of the cache is required before any DMA access can take place.
>>>
>>> You mean invalidation for inbound DMA, flush for outbound DMA, right ?
>>
>> yes thats what i meant.
>>
>>
  
 -  dwc3_flush_cache((uintptr_t)trb, sizeof(*trb));
 +  dwc3_flush_cache((uintptr_t)dwc->ep0_trb_addr, sizeof(*trb) * 2);
>>>
>>> Why *2 ?
>>
>> Because its allocated as sizeof(*dwc->ep0_trb) * 2 below. This is not
>> strictly required as dwc3_flush_cache() rounds up the size to
>> CACHELINE_SIZE but from a caller POV, flush everything we allocated.
> 
> Can the other TRB be in use ? Maybe aligning the TRBs to cacheline size
> would be better ?
> 
A single trb is 16 bytes in size and two of them are allocated
contiguously. Originally, a flush on the first trb was flushing both of
them anyway as the minimum flush is CACHELINE_SIZE (64 bytes). This is
not changing any functionality as far as I have tested. Just making sure
cache misaligned warnings don't show up.

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

[U-Boot] [PATCH 1/1] efi_selftest: use efi_st_error for all error messages

[Heinrich Schuchardt]

All error messages in the selftests should use efi_st_error.
efi_st_error will print the file name and line number of the error.

Splitting message texts due to lines being over 80
characters is avoided. This resolves the issue reported
by Simon Glass in
https://lists.denx.de/pipermail/u-boot/2017-September/307387.html

Reported-by: Simon Glass 
Fixes: 623b3a579765 efi_selftest: provide an EFI selftest application
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest.c b/lib/efi_selftest/efi_selftest.c
index efec832e98..ff00254c21 100644
--- a/lib/efi_selftest/efi_selftest.c
+++ b/lib/efi_selftest/efi_selftest.c
@@ -35,8 +35,8 @@ void efi_st_exit_boot_services(void)
ret = boottime->get_memory_map(_size, NULL, _key, _size,
   _version);
if (ret != EFI_BUFFER_TOO_SMALL) {
-   efi_st_printf("ERROR: GetMemoryMap did not return "
- "EFI_BUFFER_TOO_SMALL\n");
+   efi_st_error(
+   "GetMemoryMap did not return EFI_BUFFER_TOO_SMALL\n");
return;
}
/* Allocate extra space for newly allocated memory */
@@ -44,21 +44,18 @@ void efi_st_exit_boot_services(void)
ret = boottime->allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
  (void **)_map);
if (ret != EFI_SUCCESS) {
-   efi_st_printf("ERROR: AllocatePool did not return "
- "EFI_SUCCESS\n");
+   efi_st_error("AllocatePool did not return EFI_SUCCESS\n");
return;
}
ret = boottime->get_memory_map(_size, memory_map, _key,
   _size, _version);
if (ret != EFI_SUCCESS) {
-   efi_st_printf("ERROR: GetMemoryMap did not return "
- "EFI_SUCCESS\n");
+   efi_st_error("GetMemoryMap did not return EFI_SUCCESS\n");
return;
}
ret = boottime->exit_boot_services(handle, map_key);
if (ret != EFI_SUCCESS) {
-   efi_st_printf("ERROR: ExitBootServices did not return "
- "EFI_SUCCESS\n");
+   efi_st_error("ExitBootServices did not return EFI_SUCCESS\n");
return;
}
efi_st_printf("\nBoot services terminated\n");
@@ -79,7 +76,7 @@ static int setup(struct efi_unit_test *test, unsigned int 
*failures)
efi_st_printf("\nSetting up '%s'\n", test->name);
ret = test->setup(handle, systable);
if (ret) {
-   efi_st_printf("ERROR: Setting up '%s' failed\n", test->name);
+   efi_st_error("Setting up '%s' failed\n", test->name);
++*failures;
} else {
efi_st_printf("Setting up '%s' succeeded\n", test->name);
@@ -102,7 +99,7 @@ static int execute(struct efi_unit_test *test, unsigned int 
*failures)
efi_st_printf("\nExecuting '%s'\n", test->name);
ret = test->execute();
if (ret) {
-   efi_st_printf("ERROR: Executing '%s' failed\n", test->name);
+   efi_st_error("Executing '%s' failed\n", test->name);
++*failures;
} else {
efi_st_printf("Executing '%s' succeeded\n", test->name);
@@ -125,7 +122,7 @@ static int teardown(struct efi_unit_test *test, unsigned 
int *failures)
efi_st_printf("\nTearing down '%s'\n", test->name);
ret = test->teardown();
if (ret) {
-   efi_st_printf("ERROR: Tearing down '%s' failed\n", test->name);
+   efi_st_error("Tearing down '%s' failed\n", test->name);
++*failures;
} else {
efi_st_printf("Tearing down '%s' succeeded\n", test->name);
@@ -213,7 +210,8 @@ efi_status_t EFIAPI efi_selftest(efi_handle_t image_handle,
efi_st_get_key();
runtime->reset_system(EFI_RESET_WARM, EFI_NOT_READY,
  sizeof(reset_message), reset_message);
-   efi_st_printf("\nERROR: reset failed.\n");
+   efi_st_printf("\n");
+   efi_st_error("Reset failed.\n");
 
return EFI_UNSUPPORTED;
 }
-- 
2.14.1

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

Re: [U-Boot] [PATCH v4 2/2] wandboard: Add support for the MX6QP variant

[Stefano Babic]

Hi Fabio,

On 02/10/2017 20:47, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Add support for the latest MX6QP wandboard variant.
> 
> Based on Richard Hu's work from Technexion's U-Boot tree.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v3:
> - Rebased against latest u-boot-imx
> 
>  arch/arm/include/asm/arch-mx6/imx-regs.h |   3 +
>  board/wandboard/spl.c| 135 
> ++-
>  board/wandboard/wandboard.c  |   6 +-
>  include/configs/wandboard.h  |   2 +
>  4 files changed, 142 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h 
> b/arch/arm/include/asm/arch-mx6/imx-regs.h
> index 86e2670..624ccec 100644
> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
> @@ -346,6 +346,9 @@
>  #define IOMUXC_SNVS_BASE_ADDR   (AIPS3_ARB_BASE_ADDR + 0x9)
>  #define SNVS_GPR_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x94000)
>  #endif
> +
> +#define NOC_DDR_BASE_ADDR   (GPV0_BASE_ADDR + 0xB)
> +
>  /* Only for i.MX6SX */
>  #define LCDIF2_BASE_ADDR(AIPS3_ARB_BASE_ADDR + 0x24000)
>  #define MX6SX_LCDIF1_BASE_ADDR  (AIPS3_ARB_BASE_ADDR + 0x2)
> diff --git a/board/wandboard/spl.c b/board/wandboard/spl.c
> index 00c75d0..2446699 100644
> --- a/board/wandboard/spl.c
> +++ b/board/wandboard/spl.c
> @@ -32,6 +32,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #define IMX6DQ_DRIVE_STRENGTH0x30
>  #define IMX6SDL_DRIVE_STRENGTH   0x28
> +#define IMX6QP_DRIVE_STRENGTH0x28
>  
>  /* configure MX6Q/DUAL mmdc DDR io registers */
>  static struct mx6dq_iomux_ddr_regs mx6dq_ddr_ioregs = {
> @@ -260,15 +261,145 @@ static void ccgr_init(void)
>   writel(0x00C03F3F, >CCGR0);
>   writel(0x0030FC03, >CCGR1);
>   writel(0x0FFFC000, >CCGR2);
> - writel(0x3FF0, >CCGR3);
> + writel(0x3FF03000, >CCGR3);
>   writel(0x00FFF300, >CCGR4);
>   writel(0x0FC3, >CCGR5);
>   writel(0x03FF, >CCGR6);
>  }
>  
> +static void spl_dram_init_imx6qp_lpddr3(void)
> +{
> + /* DDR IO TYPE */
> + writel(0x000C, IOMUXC_BASE_ADDR + 0x798);
> + writel(0x, IOMUXC_BASE_ADDR + 0x758);
> + /* Clock */
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x588);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x594);
> + /* Address */
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x56c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x578);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x74c);
> + /* Control */
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x57c);
> + writel(0x, IOMUXC_BASE_ADDR + 0x58c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x59c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a0);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x78c);
> + /* Data Strobe */
> + writel(0x0002, IOMUXC_BASE_ADDR + 0x750);

mmhhh...it looks to me we are diverging with this SOC. I understand that
current funtions are not suitable for the new SOC. However, we were able
to manage up now to write tables (mx6dq_iomux_ddr_regs) and use
functions to setup the strength and the other parameters. As your tests
has proofed that these functions do not work for MX6QP, the logical way
to do is to modify these functions instead of putting back all this code
in the board file. Do you agree ?


> +
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5a8);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b0);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x524);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x51c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x518);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x50c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b8);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5c0);
> + /* Data */
> + writel(0x0002, IOMUXC_BASE_ADDR + 0x774);
> +
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x784);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x788);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x794);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x79c);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a0);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a4);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x7a8);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x748);
> +
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5ac);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x5b4);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x528);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 0x520);
> + writel(IMX6QP_DRIVE_STRENGTH, IOMUXC_BASE_ADDR + 

Re: [U-Boot] [PATCH v4 1/2] wandboard: Add support for the latest revd1 revision

[Stefano Babic]

On 02/10/2017 20:47, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Latest wandboard hardware revision is revd1, which brings the following
> new features:
> 
> - PFUZE100 PMIC
> - AR8035 Ethernet PHY
> - Upgrade Wifi/BT chip to BCM4339/BCM43430.
> 
> The detection mechanism is to probe the PMIC and when it is
> found, then the revision of the board is revd1.
> 
> As the detection is done via PMIC, we need to print the board version
> at a later stage via CONFIG_DISPLAY_BOARDINFO_LATE and also need
> to disable CONFIG_DISPLAY_BOARDINFO, which is done much earlier.
> 
> Make the necessary adjustments for the AR8035 PHY to work on revd1.
> 
> Based on Richard Hu's work from Technexion's U-Boot tree.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v3:
> - Rebased against latest u-boot-imx
> 
>  board/wandboard/wandboard.c | 108 
> ++--
>  configs/wandboard_defconfig |   1 +
>  include/configs/wandboard.h |  11 +
>  3 files changed, 115 insertions(+), 5 deletions(-)
> 
> diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c
> index dde4988..6d2609c 100644
> --- a/board/wandboard/wandboard.c
> +++ b/board/wandboard/wandboard.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -51,8 +53,11 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define USDHC1_CD_GPIO   IMX_GPIO_NR(1, 2)
>  #define USDHC3_CD_GPIO   IMX_GPIO_NR(3, 9)
>  #define ETH_PHY_RESETIMX_GPIO_NR(3, 29)
> +#define ETH_PHY_AR8035_POWER IMX_GPIO_NR(7, 13)
>  #define REV_DETECTIONIMX_GPIO_NR(2, 28)
>  
> +static bool with_pmic;
> +
>  int dram_init(void)
>  {
>   gd->ram_size = imx_ddr_size();
> @@ -107,6 +112,11 @@ static iomux_v3_cfg_t const enet_pads[] = {
>   IOMUX_PADS(PAD_EIM_D29__GPIO3_IO29| MUX_PAD_CTRL(NO_PAD_CTRL)),
>  };
>  
> +static iomux_v3_cfg_t const enet_ar8035_power_pads[] = {
> + /* AR8035 POWER */
> + IOMUX_PADS(PAD_GPIO_18__GPIO7_IO13| MUX_PAD_CTRL(NO_PAD_CTRL)),
> +};
> +
>  static iomux_v3_cfg_t const rev_detection_pad[] = {
>   IOMUX_PADS(PAD_EIM_EB0__GPIO2_IO28  | MUX_PAD_CTRL(NO_PAD_CTRL)),
>  };
> @@ -120,6 +130,14 @@ static void setup_iomux_enet(void)
>  {
>   SETUP_IOMUX_PADS(enet_pads);
>  
> + if (with_pmic) {
> + SETUP_IOMUX_PADS(enet_ar8035_power_pads);
> + /* enable AR8035 POWER */
> + gpio_direction_output(ETH_PHY_AR8035_POWER, 0);
> + }
> + /* wait until 3.3V of PHY and clock become stable */
> + mdelay(10);
> +
>   /* Reset AR8031 PHY */
>   gpio_direction_output(ETH_PHY_RESET, 0);
>   mdelay(10);
> @@ -192,6 +210,7 @@ int board_mmc_init(bd_t *bis)
>  static int ar8031_phy_fixup(struct phy_device *phydev)
>  {
>   unsigned short val;
> + int mask;
>  
>   /* To enable AR8031 ouput a 125MHz clk from CLK_25M */
>   phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x7);
> @@ -199,7 +218,12 @@ static int ar8031_phy_fixup(struct phy_device *phydev)
>   phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
>  
>   val = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
> - val &= 0xffe3;
> + if (with_pmic)
> + mask = 0xffe7;  /* AR8035 */
> + else
> + mask = 0xffe3;  /* AR8031 */
> +
> + val &= mask;
>   val |= 0x18;
>   phy_write(phydev, MDIO_DEVAD_NONE, 0xe, val);
>  
> @@ -257,6 +281,40 @@ struct i2c_pads_info mx6dl_i2c2_pad_info = {
>   }
>  };
>  
> +struct i2c_pads_info mx6q_i2c3_pad_info = {
> + .scl = {
> + .i2c_mode = MX6Q_PAD_GPIO_5__I2C3_SCL
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gpio_mode = MX6Q_PAD_GPIO_5__GPIO1_IO05
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gp = IMX_GPIO_NR(1, 5)
> + },
> + .sda = {
> + .i2c_mode = MX6Q_PAD_GPIO_16__I2C3_SDA
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gpio_mode = MX6Q_PAD_GPIO_16__GPIO7_IO11
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gp = IMX_GPIO_NR(7, 11)
> + }
> +};
> +
> +struct i2c_pads_info mx6dl_i2c3_pad_info = {
> + .scl = {
> + .i2c_mode = MX6DL_PAD_GPIO_5__I2C3_SCL
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gpio_mode = MX6DL_PAD_GPIO_5__GPIO1_IO05
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gp = IMX_GPIO_NR(1, 5)
> + },
> + .sda = {
> + .i2c_mode = MX6DL_PAD_GPIO_16__I2C3_SDA
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gpio_mode = MX6DL_PAD_GPIO_16__GPIO7_IO11
> + | MUX_PAD_CTRL(I2C_PAD_CTRL),
> + .gp = IMX_GPIO_NR(7, 11)
> + }
> +};
> +
>  static iomux_v3_cfg_t const fwadapt_7wvga_pads[] = {
>   IOMUX_PADS(PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK),
>   

Re: [U-Boot] [PATCH v1] doc: update imx_usb_loader URL

[Stefano Babic]

On 03/10/2017 16:43, Stefan Agner wrote:
> From: Stefan Agner 
> 
> The changes required to use U-Boot's Serial Download Protocol
> implementation are now available in upstream imx_usb_loader
> repository. Update the URL accordingly.
> 
> Signed-off-by: Stefan Agner 
> ---
> 
>  doc/README.sdp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/README.sdp b/doc/README.sdp
> index 9b438c0746..178ea688a7 100644
> --- a/doc/README.sdp
> +++ b/doc/README.sdp
> @@ -14,7 +14,7 @@ SoC's recovery mechanism is using.
>  The SDP protocol over USB is a USB HID class protocol. USB HID class
>  protocols allow to access a USB device without OS specific drivers. The
>  U-Boot implementation has primarly been tested using the open source
> -imx_loader utility (https://github.com/toradex/imx_loader).
> +imx_loader utility (https://github.com/boundarydevices/imx_usb_loader).
>  
>  The host side utilities are typically capable to interpret the i.MX
>  specific image header (see doc/README.imximage). There are extensions
> 

Applied to u-boot-imx, -master, thanks !

Best regards,
Stefano Babic

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

[U-Boot] [PATCH] armv8: ls1088a: Update MC boot sequence

[Bogdan Purcareata]

This patch follows the work of previous commits:
5707dfb02e drivers: net: fsl-mc: Fixup MAC addresses in DPC
33a8991a87 drivers: net: fsl-mc: Link MC boot to PHY_RESET_R
1161dbcc0a drivers: net: fsl-mc: Include MAC addr fixup to DPL

Add support for LS1088 platforms, to make sure u-boot env MAC addresses
are properly set in DPC / DPL.

Signed-off-by: Bogdan Purcareata 
---
 board/freescale/ls1088a/eth_ls1088aqds.c | 14 --
 board/freescale/ls1088a/eth_ls1088ardb.c | 13 -
 include/configs/ls1088a_common.h |  6 ++
 3 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/board/freescale/ls1088a/eth_ls1088aqds.c 
b/board/freescale/ls1088a/eth_ls1088aqds.c
index c19f59a..de70aee 100644
--- a/board/freescale/ls1088a/eth_ls1088aqds.c
+++ b/board/freescale/ls1088a/eth_ls1088aqds.c
@@ -14,14 +14,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "../common/qixis.h"
 
 #include "ls1088a_qixis.h"
 
-#define MC_BOOT_ENV_VAR "mcinitcmd"
-
 #ifdef CONFIG_FSL_MC_ENET
 
 #define SFP_TX 0
@@ -612,7 +611,6 @@ static void ls1088a_handle_phy_interface_rgmii(int dpmac_id)
 int board_eth_init(bd_t *bis)
 {
int error = 0, i;
-   char *mc_boot_env_var;
 #ifdef CONFIG_FSL_MC_ENET
struct memac_mdio_info *memac_mdio0_info;
char *env_hwconfig = env_get("hwconfig");
@@ -655,9 +653,6 @@ int board_eth_init(bd_t *bis)
}
}
 
-   mc_boot_env_var = env_get(MC_BOOT_ENV_VAR);
-   if (mc_boot_env_var)
-   run_command_list(mc_boot_env_var, -1, 0);
error = cpu_eth_init(bis);
 
if (hwconfig_f("xqsgmii", env_hwconfig)) {
@@ -681,3 +676,10 @@ int board_eth_init(bd_t *bis)
error = pci_eth_init(bis);
return error;
 }
+
+#if defined(CONFIG_RESET_PHY_R)
+void reset_phy(void)
+{
+   mc_env_boot();
+}
+#endif /* CONFIG_RESET_PHY_R */
diff --git a/board/freescale/ls1088a/eth_ls1088ardb.c 
b/board/freescale/ls1088a/eth_ls1088ardb.c
index 853d815..97accc9 100644
--- a/board/freescale/ls1088a/eth_ls1088ardb.c
+++ b/board/freescale/ls1088a/eth_ls1088ardb.c
@@ -15,15 +15,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define MC_BOOT_ENV_VAR "mcinitcmd"
 int board_eth_init(bd_t *bis)
 {
 #if defined(CONFIG_FSL_MC_ENET)
-   char *mc_boot_env_var;
int i, interface;
struct memac_mdio_info mdio_info;
struct mii_dev *dev;
@@ -92,11 +91,15 @@ int board_eth_init(bd_t *bis)
dev = miiphy_get_dev_by_name(DEFAULT_WRIOP_MDIO2_NAME);
wriop_set_mdio(WRIOP1_DPMAC2, dev);
 
-   mc_boot_env_var = env_get(MC_BOOT_ENV_VAR);
-   if (mc_boot_env_var)
-   run_command_list(mc_boot_env_var, -1, 0);
cpu_eth_init(bis);
 #endif /* CONFIG_FMAN_ENET */
 
return pci_eth_init(bis);
 }
+
+#if defined(CONFIG_RESET_PHY_R)
+void reset_phy(void)
+{
+   mc_env_boot();
+}
+#endif /* CONFIG_RESET_PHY_R */
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index 84e9b14..fa058f7 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -122,6 +122,12 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET0x00F2
 #define CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH   0x20
 #define CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET  0x0700
+
+/* Define phy_reset function to boot the MC based on mcinitcmd.
+ * This happens late enough to properly fixup u-boot env MAC addresses.
+ */
+#define CONFIG_RESET_PHY_R
+
 /*
  * Carve out a DDR region which will not be used by u-boot/Linux
  *
-- 
2.7.4

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

Re: [U-Boot] [PATCH] imx: serial: Wait for ongoing transmission to finish before serial reset

[Łukasz Majewski]

HI Lothar,


Hi,

On Tue,  3 Oct 2017 11:16:45 +0200 Lukasz Majewski wrote:

It may happen that the MXC serial IP block is performing some ongoing
transmission (started at e.g. board_init()) when the "initr_serial" is
called.

As a result the serial port IP block is reset, so transmitted data is
corrupted:

I2C:   ready
DRAM:  1 GiB
jSS('HH��SL_SDHC: 04 rev 0x0

This patch prevents from this situation, by waiting for transmission
complete bit set (UART Status Register 2 (UARTx_USR2), bit TXDC):

I2C:   ready
DRAM:  1 GiB
ID:unit type 0x4 rev 0x0

Signed-off-by: Lukasz Majewski 
---

  drivers/serial/serial_mxc.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index cce80a8..ef4eb12 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -141,6 +141,13 @@ struct mxc_uart {
  
  static void _mxc_serial_init(struct mxc_uart *base)

  {
+   /*
+* Wait for any ongoing transmission to finish - for example
+* from pre-relocation enabled UART
+*/
+   while (!(readl(>sr2) & USR2_TXDC))
+   ;
+


Loops that poll for HW activated bits should always have a timeout.
Hardware will definitely break some day and deliver unexpected results.
Software should cope with this as best as it can!


In principle yes.

Please find below rationale for this patch:

1. According to imx6q this bit shows emptiness of TxFIFO and Shift 
register [1]. It seems like a purely HW controlled bit.


2. Having timeout here would require first initialization of timer. 
However, this code is also used in a very early console initialization.


3. In Linux kernel [2] the same check is performed with:

while (!(readl(sport->port.membase + USR2) & USR2_TXDC))
barrier();


[1] - Transmitter Complete. Indicates that the transmit buffer (TxFIFO) 
and Shift Register is empty; therefore
the transmission is complete. TXDC is cleared automatically when data is 
written to the TxFIFO.


[2] - 
http://elixir.free-electrons.com/linux/v4.2/source/drivers/tty/serial/imx.c#L1379





Lothar Waßmann




--
Best regards,

Lukasz Majewski

--

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

Re: [U-Boot] Beagleboard xM boot broken due to FIT enable

[Guillaume Gardet]

Le 02/10/2017 à 18:14, Guillaume Gardet a écrit :



Le 02/10/2017 à 17:58, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 05:55:27PM +0200, Guillaume Gardet wrote:


Le 02/10/2017 à 15:53, Tom Rini a écrit :

On Mon, Oct 02, 2017 at 03:24:01PM +0200, Guillaume Gardet wrote:

Hi,

commit 46f9ef18461609064a1ffbc3f61dc027ec76b3ff
Author: Andrew F. Davis 
Date:   Fri Apr 21 10:01:28 2017 -0500

 Kconfig: Enable FIT support by default for TI platforms

 Almost all TI defconfigs enable this already, add this as a default
 and remove the explicit assignment.

 Signed-off-by: Andrew F. Davis 
 Reviewed-by: Tom Rini 

broke boot on Beagleboard xM. I mean the board hangs after:
 OMAP3630/3730-GP ES1.1, CPU-OPP2, L3-200MHz, Max CPU Clock 800 MHz
 OMAP3 Beagle board + LPDDR/NAND
 I2C:   ready
 DRAM:  512 MiB


To get back the board booting, I need to manually disable FIT (CONFIG_FIT) 
_and_ disable SHA256 hash support (CONFIG_SHA256).

If I enable FIT without sha256 : it breaks boot.
If I enable sha256 without FIT : it breaks boot.

Any idea what could cause this?

As a workaround we could disable it in the omap3_beagle_defconfig but I guess 
it would be better to fix it instead of workaround it, since other boards may 
also be affected.

Which Beagleboard xM rev do you have?  And how are you booting (FAT or
raw) ?  Mine, FAT booting, is working currently and is part of my
automated test farm, thanks!

This is a Beagleboard xM rev. B.
We use raw booting (instead of default FAT booting).

OK.  Can you test FAT booting?  Both should work, but I have an idea at
least on RAW, but I'd like to rule out anything else other than size
changes.   Thanks!


Indeed, if u-boot.img is on FAT partition, it boots properly!


So, what is the problem?
Are we limited in size for u-boot.img when raw booting is used?

Guillaume

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

Re: [U-Boot] [PATCH] imx: serial: Wait for ongoing transmission to finish before serial reset

[Lothar Waßmann]

Hi,

On Tue,  3 Oct 2017 11:16:45 +0200 Lukasz Majewski wrote:
> It may happen that the MXC serial IP block is performing some ongoing
> transmission (started at e.g. board_init()) when the "initr_serial" is
> called.
> 
> As a result the serial port IP block is reset, so transmitted data is
> corrupted:
> 
> I2C:   ready
> DRAM:  1 GiB
> jSS('HH��SL_SDHC: 04 rev 0x0
> 
> This patch prevents from this situation, by waiting for transmission
> complete bit set (UART Status Register 2 (UARTx_USR2), bit TXDC):
> 
> I2C:   ready
> DRAM:  1 GiB
> ID:unit type 0x4 rev 0x0
> 
> Signed-off-by: Lukasz Majewski 
> ---
> 
>  drivers/serial/serial_mxc.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> index cce80a8..ef4eb12 100644
> --- a/drivers/serial/serial_mxc.c
> +++ b/drivers/serial/serial_mxc.c
> @@ -141,6 +141,13 @@ struct mxc_uart {
>  
>  static void _mxc_serial_init(struct mxc_uart *base)
>  {
> + /*
> +  * Wait for any ongoing transmission to finish - for example
> +  * from pre-relocation enabled UART
> +  */
> + while (!(readl(>sr2) & USR2_TXDC))
> + ;
> +
>
Loops that poll for HW activated bits should always have a timeout.
Hardware will definitely break some day and deliver unexpected results.
Software should cope with this as best as it can!


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

Re: [U-Boot] [PATCH] fdt: update bcm283x device tree sources to Linux 4.14 state

[Fabian Vogt]

On Monday, October 4 2017, 06:33:37 CEST Alexander Graf wrote:
> Upstream Linux has received a few device tree updates to the RPi
> which we should propagate into the builtin U-Boot one as well to
> gain hardware support.
> 
> This patch bumps the dts files to their 4.14 Linux counterparts.

Looks good to me.

> Signed-off-by: Alexander Graf 
Acked-by: Fabian Vogt 

> ---
>  arch/arm/dts/bcm2835-rpi-a-plus.dts|  74 +++-
>  arch/arm/dts/bcm2835-rpi-a.dts |  76 +++-
>  arch/arm/dts/bcm2835-rpi-b-plus.dts|  75 +++-
>  arch/arm/dts/bcm2835-rpi-b-rev2.dts|  75 +++-
>  arch/arm/dts/bcm2835-rpi-b.dts |  76 +++-
>  arch/arm/dts/bcm2835-rpi.dtsi  |  34 +++-
>  arch/arm/dts/bcm2835.dtsi  |  10 +
>  arch/arm/dts/bcm2836-rpi-2-b.dts   |   9 +-
>  arch/arm/dts/bcm2836.dtsi  |  11 ++
>  arch/arm/dts/bcm2837-rpi-3-b.dts   |  35 +++-
>  arch/arm/dts/bcm2837.dtsi  |  13 +-
>  arch/arm/dts/bcm283x-rpi-smsc9512.dtsi |   2 +-
>  arch/arm/dts/bcm283x-rpi-smsc9514.dtsi |   2 +-
>  arch/arm/dts/bcm283x-rpi-usb-host.dtsi |   3 +
>  arch/arm/dts/bcm283x.dtsi  | 325 
> -
>  include/dt-bindings/clock/bcm2835.h|   2 +
>  include/dt-bindings/pinctrl/bcm2835.h  |   5 +
>  17 files changed, 801 insertions(+), 26 deletions(-)
>  create mode 100644 arch/arm/dts/bcm283x-rpi-usb-host.dtsi
> 
> diff --git a/arch/arm/dts/bcm2835-rpi-a-plus.dts 
> b/arch/arm/dts/bcm2835-rpi-a-plus.dts
> index 35ff4e7a4a..9f866491ef 100644
> --- a/arch/arm/dts/bcm2835-rpi-a-plus.dts
> +++ b/arch/arm/dts/bcm2835-rpi-a-plus.dts
> @@ -1,6 +1,7 @@
>  /dts-v1/;
>  #include "bcm2835.dtsi"
>  #include "bcm2835-rpi.dtsi"
> +#include "bcm283x-rpi-usb-host.dtsi"
>  
>  / {
>   compatible = "raspberrypi,model-a-plus", "brcm,bcm2835";
> @@ -21,7 +22,72 @@
>  };
>  
>   {
> - pinctrl-0 = <  _alt0 >;
> + /*
> +  * This is based on the unreleased schematic for the Model A+.
> +  *
> +  * Legend:
> +  * "NC" = not connected (no rail from the SoC)
> +  * "FOO" = GPIO line named "FOO" on the schematic
> +  * "FOO_N" = GPIO line named "FOO" on schematic, active low
> +  */
> + gpio-line-names = "SDA0",
> +   "SCL0",
> +   "SDA1",
> +   "SCL1",
> +   "GPIO_GCLK",
> +   "GPIO5",
> +   "GPIO6",
> +   "SPI_CE1_N",
> +   "SPI_CE0_N",
> +   "SPI_MISO",
> +   "SPI_MOSI",
> +   "SPI_SCLK",
> +   "GPIO12",
> +   "GPIO13",
> +   /* Serial port */
> +   "TXD0",
> +   "RXD0",
> +   "GPIO16",
> +   "GPIO17",
> +   "GPIO18",
> +   "GPIO19",
> +   "GPIO20",
> +   "GPIO21",
> +   "GPIO22",
> +   "GPIO23",
> +   "GPIO24",
> +   "GPIO25",
> +   "GPIO26",
> +   "GPIO27",
> +   "SDA0",
> +   "SCL0",
> +   "NC", /* GPIO30 */
> +   "NC", /* GPIO31 */
> +   "CAM_GPIO1", /* GPIO32 */
> +   "NC", /* GPIO33 */
> +   "NC", /* GPIO34 */
> +   "PWR_LOW_N", /* GPIO35 */
> +   "NC", /* GPIO36 */
> +   "NC", /* GPIO37 */
> +   "USB_LIMIT", /* GPIO38 */
> +   "NC", /* GPIO39 */
> +   "PWM0_OUT", /* GPIO40 */
> +   "CAM_GPIO0", /* GPIO41 */
> +   "NC", /* GPIO42 */
> +   "NC", /* GPIO43 */
> +   "NC", /* GPIO44 */
> +   "PWM1_OUT", /* GPIO45 */
> +   "HDMI_HPD_N",
> +   "STATUS_LED",
> +   /* Used by SD Card */
> +   "SD_CLK_R",
> +   "SD_CMD_R",
> +   "SD_DATA0_R",
> +   "SD_DATA1_R",
> +   "SD_DATA2_R",
> +   "SD_DATA3_R";
> +
> + pinctrl-0 = <  _alt0>;
>  
>   /* I2S interface */
>   i2s_alt0: i2s_alt0 {
> @@ -33,3 +99,9 @@
>   {
>   hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
>  };
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio14>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/bcm2835-rpi-a.dts b/arch/arm/dts/bcm2835-rpi-a.dts
> index 306a84ee98..4b1af06c8d 100644
> --- a/arch/arm/dts/bcm2835-rpi-a.dts
> +++ b/arch/arm/dts/bcm2835-rpi-a.dts
> @@ -1,6 +1,7 @@
>  

Re: [U-Boot] [PATCH 052/080] cfi_flash: Reduce the scope of some variables

[Mario Six]

Hi Masahiro,

On Fri, Sep 29, 2017 at 7:10 PM, Masahiro Yamada
 wrote:
> 2017-09-29 21:52 GMT+09:00 Mario Six :
>> Signed-off-by: Mario Six 
>> ---
>>  drivers/mtd/cfi_flash.c | 26 ++
>>  1 file changed, 14 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
>> index c47ba416b9..c597c621ca 100644
>> --- a/drivers/mtd/cfi_flash.c
>> +++ b/drivers/mtd/cfi_flash.c
>> @@ -179,10 +179,10 @@ __maybe_weak u64 flash_read64(void *addr)
>>  static flash_info_t *flash_get_info(ulong base)
>>  {
>> int i;
>> -   flash_info_t *info;
>>
>> for (i = 0; i < CONFIG_SYS_MAX_FLASH_BANKS; i++) {
>> -   info = _info[i];
>> +   flash_info_t *info = _info[i];
>> +
>> if (info->size && info->start[0] <= base &&
>> base <= info->start[0] + info->size - 1)
>> return info;
>> @@ -222,8 +222,6 @@ static inline void flash_unmap(flash_info_t *info, 
>> flash_sect_t sect,
>>  static void flash_make_cmd(flash_info_t *info, u32 cmd, void *cmdbuf)
>>  {
>> int i;
>> -   int cword_offset;
>> -   int cp_offset;
>>  #if defined(__LITTLE_ENDIAN) || defined(CONFIG_SYS_WRITE_SWAPPED_DATA)
>> u32 cmd_le = cpu_to_le32(cmd);
>>  #endif
>> @@ -231,9 +229,10 @@ static void flash_make_cmd(flash_info_t *info, u32 cmd, 
>> void *cmdbuf)
>> uchar *cp = (uchar *) cmdbuf;
>>
>> for (i = info->portwidth; i > 0; i--) {
>> -   cword_offset = (info->portwidth - i) % info->chipwidth;
>> +   int cword_offset = (info->portwidth - i) % info->chipwidth;
>> +   int cp_offset = info->portwidth - i;
>>  #if defined(__LITTLE_ENDIAN) || defined(CONFIG_SYS_WRITE_SWAPPED_DATA)
>> -   cp_offset = info->portwidth - i;
>> +
>> val = *((uchar *)_le + cword_offset);
>>  #else
>> cp_offset = i - 1;
>> @@ -2053,16 +2052,10 @@ static void flash_fixup_num(flash_info_t *info, 
>> struct cfi_qry *qry)
>>  ulong flash_get_size(phys_addr_t base, int banknum)
>>  {
>> flash_info_t *info = _info[banknum];
>> -   int i, j;
>> flash_sect_t sect_cnt;
>> phys_addr_t sector;
>> -   unsigned long tmp;
>> -   int size_ratio;
>> uchar num_erase_regions;
>> -   int erase_region_size;
>> -   int erase_region_count;
>> struct cfi_qry qry;
>> -   unsigned long max_size;
>>
>> memset(, 0, sizeof(qry));
>>
>> @@ -2075,6 +2068,11 @@ ulong flash_get_size(phys_addr_t base, int banknum)
>> info->start[0] = (ulong)map_physmem(base, info->portwidth, 
>> MAP_NOCACHE);
>>
>> if (flash_detect_cfi(info, )) {
>> +   int i;
>> +   int size_ratio;
>> +   unsigned long max_size;
>> +   unsigned long tmp;
>> +
>> info->vendor = le16_to_cpu(get_unaligned(_id));
>> info->ext_addr = le16_to_cpu(get_unaligned(_adr));
>> num_erase_regions = qry.num_erase_regions;
>> @@ -2159,6 +2157,10 @@ ulong flash_get_size(phys_addr_t base, int banknum)
>> sect_cnt = 0;
>> sector = base;
>> for (i = 0; i < num_erase_regions; i++) {
>> +   int j;
>> +   int erase_region_size;
>> +   int erase_region_count;
>> +
>> if (i > NUM_ERASE_REGIONS) {
>> printf("%d erase regions found, only %d 
>> used\n",
>> num_erase_regions, 
>> NUM_ERASE_REGIONS);
>> --
>
>
>
> Are these changes necessary?
>
> Looks like your personal preference to me.
>

Well, scope reduction of variables is a relatively common refactoring method
(see, for example, chapter 10.4 of Code Complete, Second Edition). Also, the
relatively commonly used CppCheck linter automatically finds these instances
very often, which is how I found them.

But no, it is not strictly necessary; I can drop these patches for v2.

Best regards,

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

Re: [U-Boot] [PATCH 002/080] mpc83xx: spd_sdram: Fix whitespace style violations

[Mario Six]

Hi Wolfgang,

On Fri, Sep 29, 2017 at 4:03 PM, Wolfgang Denk  wrote:
> Dear Mario,
>
> In message <20170929125238.26226-2-mario@gdsys.cc> you wrote:
>> Fix whitespace style violations in the MPC83xx SPD-SDRAM code.
> ...
>
>> - ddr->csbnds[1].csbnds = ( (banksize(spd.row_dens) >> 8)
>> -   | ((banksize(spd.row_dens) >> 23) - 1) );
>>   ddr->cs_config[1] = ( 1<<31
>> + ddr->csbnds[1].csbnds = ((banksize(spd.row_dens) >> 8)
>> +   | ((banksize(spd.row_dens) >> 23) - 1));
>>   | (odt_rd_cfg << 20)
>>   | (odt_wr_cfg << 16)
>>   | ((spd.nbanks == 8 ? 1 : 0) << 14)
>>   | ((spd.nrow_addr - 12) << 8)
>
> This looks as if you were changing the code, and not only whitespace ?
>
> I would expect that this does not even compile!
>

Argh, something went wrong when I split the commits; this and the next commit
were originally a single commit, but I split them in order to be more readable
(the next commit fixes the order of the lines again).

> Which sort of testing did you give to this patch series?
>

I tested the final, and some of the larger patches using buildman, but not
these ones. I'll put the entire series through the wringer for v2. Terribly
sorry for that.

> Best regards,
>
> Wolfgang Denk
>

Best regards,

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