Re: [PATCH] mtd: cfi: Fix PPB lock status readout

2021-04-15 Thread Joakim Tjernlund
On Thu, 2021-04-15 at 07:25 +0200, Stefan Roese wrote:
> On 11.04.21 20:47, Marek Vasut wrote:
> > According to S26KL512S datasheet [1] and S29GL01GS datasheet [2],
> > the procedure to read out PPB lock bits is to send the PPB Entry,
> > PPB Read, Reset/ASO Exit. Currently, the code does send incorrect
> > PPB Entry, PPB Read and Reset/ASO Exit is completely missing.
> > 
> > The PPB Entry sent is implemented by sending flash_unlock_seq()
> > and flash_write_cmd(..., FLASH_CMD_READ_ID). This translates to
> > sequence 0x555:0xaa, 0x2aa:0x55, 0x555:0x90=FLASH_CMD_READ_ID.
> > However, both [1] and [2] specify the last byte of PPB Entry as
> > 0xc0=AMD_CMD_SET_PPB_ENTRY instead of 0x90=FLASH_CMD_READ_ID,
> > that is  0x555:0xaa, 0x2aa:0x55, 0x555:0xc0=AMD_CMD_SET_PPB_ENTRY.
> > Since this does make sense, this patch fixes it and thus also
> > aligns the code in flash_get_size() with flash_real_protect().
> > 
> > The PPB Read returns 00h in case of Protected state and 01h in case
> > of Unprotected state, according to [1] Note 83 and [2] Note 17, so
> > invert the result. Moreover, align the arguments with similar code
> > in flash_real_protect().
> > 

Just saw the PPB lock words passing by and remembered the problems we had with
u-boot using PPB to lock/unlock flash.

This method is slow and persistent(unlike the Intel method) and this carries
all the way to fw_setenv.

PPB will write to internal flash bits(same bits every time) and this causes wear
on said flash. We had disable flash lock/unlock here due to this wear.

The DYB method is a much better fit for u-boot/linux flash locking needs.

 Jocke


Re: [PATCH] mpc83xx: Fix dcache setup in lock_ram_in_cache

2020-11-13 Thread Joakim Tjernlund
You can disregard this patch, unless you think this is a good idea in general.
The patch caused the same problem on another 83xx of very similar design.

ATM, it looks like disabling the icache while executing in flash(turn of once 
in RAM)
works for all boards.
Seems like something goes terribly wrong with the CPUs cache and the CPU just 
RESET itself

 Jocke

On Wed, 2020-11-11 at 13:54 +0100, Joakim Tjernlund wrote:
> Lock dcache before clearing INIT_RAM.
> More importantly, invalidate dcache contents before using it as RAM.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
> 
>  Something odd happend, on a stable mpc8321 board, small unrelated code
>  changes made the board unbootable. Debugging with an emulator
>  it looked like something pulled away the dcache while it was
>  in early boot stages.
>  I found that if I let the emulator init the DDR before executing,
>  all was OK again.
>  To me this looked like there was some garbage in the dcache causing
>  some DDR access. All this led me to lock_ram_in_cache and the
>  the resluting changes in this patch.
> 
>  86xx could possible need the same fix
> 
>  arch/powerpc/cpu/mpc83xx/start.S | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc83xx/start.S 
> b/arch/powerpc/cpu/mpc83xx/start.S
> index c00bb31363..a1f3b56433 100644
> --- a/arch/powerpc/cpu/mpc83xx/start.S
> +++ b/arch/powerpc/cpu/mpc83xx/start.S
> @@ -1071,18 +1071,22 @@ lock_ram_in_cache:
>   ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
>   li  r4, ((CONFIG_SYS_INIT_RAM_SIZE & ~31) + \
>    (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
> + /* Lock the data cache */
> + mfspr   r0, HID0
> + ori r0, r0, HID0_DLOCK|HID0_DCFI
> + sync
> + mtspr   HID0, r0
> + rlwinm  r0, r0, 0, ~HID0_DCFI /* Clear HID0_DCFI */
> + sync
> + mtspr   HID0, r0
> + sync
> +
>   mtctr   r4
>  1:
>   dcbzr0, r3
>   addir3, r3, 32
>   bdnz1b
>  
> 
> - /* Lock the data cache */
> - mfspr   r0, HID0
> - ori r0, r0, HID0_DLOCK
> - sync
> - mtspr   HID0, r0
> - sync
>   blr
>  
> 
>  #ifndef MINIMAL_SPL



[PATCH] mpc83xx: Fix dcache setup in lock_ram_in_cache

2020-11-11 Thread Joakim Tjernlund
Lock dcache before clearing INIT_RAM.
More importantly, invalidate dcache contents before using it as RAM.

Signed-off-by: Joakim Tjernlund 
---

 Something odd happend, on a stable mpc8321 board, small unrelated code
 changes made the board unbootable. Debugging with an emulator
 it looked like something pulled away the dcache while it was
 in early boot stages.
 I found that if I let the emulator init the DDR before executing,
 all was OK again.
 To me this looked like there was some garbage in the dcache causing
 some DDR access. All this led me to lock_ram_in_cache and the
 the resluting changes in this patch.

 86xx could possible need the same fix

 arch/powerpc/cpu/mpc83xx/start.S | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index c00bb31363..a1f3b56433 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -1071,18 +1071,22 @@ lock_ram_in_cache:
ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR & ~31)@l
li  r4, ((CONFIG_SYS_INIT_RAM_SIZE & ~31) + \
 (CONFIG_SYS_INIT_RAM_ADDR & 31) + 31) / 32
+   /* Lock the data cache */
+   mfspr   r0, HID0
+   ori r0, r0, HID0_DLOCK|HID0_DCFI
+   sync
+   mtspr   HID0, r0
+   rlwinm  r0, r0, 0, ~HID0_DCFI /* Clear HID0_DCFI */
+   sync
+   mtspr   HID0, r0
+   sync
+
mtctr   r4
 1:
dcbzr0, r3
addir3, r3, 32
bdnz1b
 
-   /* Lock the data cache */
-   mfspr   r0, HID0
-   ori r0, r0, HID0_DLOCK
-   sync
-   mtspr   HID0, r0
-   sync
blr
 
 #ifndef MINIMAL_SPL
-- 
2.26.2



Re: U-Boot FIT Signature Verification

2020-09-16 Thread Joakim Tjernlund
On Wed, 2020-09-16 at 13:55 +0200, Heinrich Schuchardt wrote:
> On 16.09.20 13:40, Joakim Tjernlund wrote:
> > On Wed, 2020-09-16 at 13:14 +0200, Heinrich Schuchardt wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > On 16.09.20 10:13, AKASHI Takahiro wrote:
> > > > On Wed, Sep 16, 2020 at 01:19:03AM +0200, Heinrich Schuchardt wrote:
> > > > > On 9/11/20 7:26 PM, Andrii Voloshyn wrote:
> > > > > > Hi there,
> > > > > > 
> > > > > > Does U-boot take into account certificate expiration date when 
> > > > > > verifying signed images in FIT? In other words, is date stored 
> > > > > > along with the public key in DTB file?
> > > > > > 
> > > > > > Cheers,
> > > > > > Andy
> > > > > > 
> > > > > 
> > > > > Hello Philippe,
> > > > > 
> > > > > looking at padding_pkcs_15_verify() in lib/rsa/rsa-verify.c I cannot
> > > > > find a comparison of the date on which an image was signed with the
> > > > > expiry date of the certificate. Shouldn't there be a check? Or did I
> > > > > simply look into the wrong function?
> > > > 
> > > > I think Simon is the right person to answer this question, but
> > > > 
> > > > as far as I know, we don't have any device tree property for the 
> > > > expiration
> > > > date of a public key. See doc/uImage.FIT/signature.txt.
> > > 
> > > Yes, the problem starts with mkimage not writing the dates available in
> > > the X509 certificate into the device tree.
> > > 
> > > The dates are accessible via the X509_get0_notBefore() and
> > > X509_get0_notAfter() functions of the OpenSSL library.
> > > 
> > > 
> > > Takahiro, could you, please, also look at the UEFI secure boot
> > > implementation in U-Boot. EDK2 validates the dates via the embedded
> > > OpenSSL library in
> > > CryptoPkg/Library/OpensslLib/openssl/crypto/x509/x509_vfy.c, function
> > > verify_chain(). We should not do less.
> > 
> > Does that mean that verified boot stops/fails when the date expires ?
> > How do you guarantee that the device has the correct time ?
> > 
> >    Jocke
> > 
> 
> We talking of the validity time range of the public key and the date of
> signature of the intermediate certificates and the loaded image. No RTC

OK, but still: will an invalid time range then stop booting ?




Re: U-Boot FIT Signature Verification

2020-09-16 Thread Joakim Tjernlund
On Wed, 2020-09-16 at 13:14 +0200, Heinrich Schuchardt wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 16.09.20 10:13, AKASHI Takahiro wrote:
> > On Wed, Sep 16, 2020 at 01:19:03AM +0200, Heinrich Schuchardt wrote:
> > > On 9/11/20 7:26 PM, Andrii Voloshyn wrote:
> > > > Hi there,
> > > > 
> > > > Does U-boot take into account certificate expiration date when 
> > > > verifying signed images in FIT? In other words, is date stored along 
> > > > with the public key in DTB file?
> > > > 
> > > > Cheers,
> > > > Andy
> > > > 
> > > 
> > > Hello Philippe,
> > > 
> > > looking at padding_pkcs_15_verify() in lib/rsa/rsa-verify.c I cannot
> > > find a comparison of the date on which an image was signed with the
> > > expiry date of the certificate. Shouldn't there be a check? Or did I
> > > simply look into the wrong function?
> > 
> > I think Simon is the right person to answer this question, but
> > 
> > as far as I know, we don't have any device tree property for the expiration
> > date of a public key. See doc/uImage.FIT/signature.txt.
> 
> Yes, the problem starts with mkimage not writing the dates available in
> the X509 certificate into the device tree.
> 
> The dates are accessible via the X509_get0_notBefore() and
> X509_get0_notAfter() functions of the OpenSSL library.
> 
> 
> Takahiro, could you, please, also look at the UEFI secure boot
> implementation in U-Boot. EDK2 validates the dates via the embedded
> OpenSSL library in
> CryptoPkg/Library/OpensslLib/openssl/crypto/x509/x509_vfy.c, function
> verify_chain(). We should not do less.

Does that mean that verified boot stops/fails when the date expires ?
How do you guarantee that the device has the correct time ?

   Jocke


Re: Changing U-boot relocation addres to SRAM (instead of DRAM)

2020-09-08 Thread Joakim Tjernlund
On Mon, 2020-09-07 at 22:24 +0300, Yusuf Altıparmak wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hello,
> 
> I want to modify U-boot to relocate itself to on-board SRAM of chip (T1042
> demo board) instead of DRAM.
> 
> At first, there is call list in u-boot/common/board_f.c and it has a line
> to call dram_init. I will change this line with my custom sram_init
> function.
> 
> [image: Capture.PNG]
> 
> The function board_f() is being called in start.S which is located at
> u-boot/arch/powerpc/cpu/mpc85xx/
> 
> start.S file also includes a region to relocate itself by changing Link
> Register. Code region is:
> 
> */**
> ** void relocate_code(addr_sp, gd, addr_moni)*
> ***
> ** This "function" does not return, instead it continues in RAM*
> ** after relocating the monitor code.*
> ***
> ** r3 = dest*
> ** r4 = src*
> ** r5 = length in bytes*
> ** r6 = cachelinesize*
> **/*
> *.globl relocate_code*
> *relocate_code:*
> *mr r1,r3 /* Set new stack pointer */*
> *mr r9,r4 /* Save copy of Init Data pointer */*
> *mr r10,r5 /* Save copy of Destination Address */*
> 
> *GET_GOT*
> *#ifndef CONFIG_SPL_SKIP_RELOCATE*
> *mr r3,r5 /* Destination Address */*
> *lis r4,CONFIG_SYS_MONITOR_BASE@h /* Source Address */*
> *ori r4,r4,CONFIG_SYS_MONITOR_BASE@l*
> *lwz r5,GOT(__init_end)*
> *sub r5,r5,r4*
> *li r6,CONFIG_SYS_CACHELINE_SIZE /* Cache Line Size */*
> 
> 
> My question is, in above code, how relocate_code() function is calculating
> the jump address of Link Register (CONFIG_SYS_MONITOR_BASE@h).
> 
> What should be done to change it to point SRAM of t1042 after we initialize
> it in board_init_f() function. ?

I don't think you should change anything here. Just make gd->relocaddr point to 
somewhere in SRAM

 Jocke



eSPI was: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self Refresh mode"

2020-05-27 Thread Joakim Tjernlund
On Sun, 2020-04-12 at 04:22 +, Priyanka Jain wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> > -Original Message-----
> > From: Joakim Tjernlund 
> > Sent: Friday, April 10, 2020 5:21 PM
> > To: Priyanka Jain ; Biwen Li (OSS)
> > 
> > Cc: u-boot@lists.denx.de; Biwen Li ; Jiafei Pan
> > 
> > Subject: Re: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self
> > Refresh mode"
> > 
> > On Fri, 2020-04-10 at 11:40 +0000, Priyanka Jain wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund 
> > > > Sent: Thursday, April 9, 2020 6:24 PM
> > > > To: Priyanka Jain ; Biwen Li (OSS)
> > > > 
> > > > Cc: u-boot@lists.denx.de; Biwen Li ; Jiafei Pan
> > > > 
> > > > Subject: Re: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in
> > > > Self Refresh mode"
> > > > 
> > > > On Thu, 2020-04-09 at 20:44 +0800, Biwen Li wrote:
> > > > 
> > > > This revert will bring back another bug, can you try finding out why
> > > > it does work?
> > > > May there are some minor tweaks needed ?
> > > > 
> > > >   Jocke
> > > The patch has impacted boot to prompt on many powerpc boards.
> > > I agree with you that we also need to have solution to the original 
> > > problem
> > reported by you.
> > > We are working on fixing of DDR errata workaround implementation issue
> > that you reported.
> > 
> > Is anyone working on the eSPI driver as well? I recall someone at NXP
> > volunteered but cannot recall who.
> > 
> Yes, "Xiaowei Bao" is working on that.
> The older version is in-review on maillist. He is working on rebasing to top 
> of tree
> Priyanka

Now upstream is removing the fsl_espi driver, what is the status?

   Jocke



Re: [PATCH 00/24] spi: dm-conversion (part2)

2020-05-27 Thread Joakim Tjernlund
On Wed, 2020-05-27 at 22:16 +0530, Jagan Teki wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> I believe some boards can directly enable DM_SPI if it has
> OF_CONTROL enabled already, so now it's the last call for
> board maintainers to take care of this.
> 
> Now all boards which are using fsl_espi are removed due to
> no action on dm conversion from years.

hmm, last I heard fsl_espi was beeing rewritten by NXP, is that not so anymore?
We use fsl_espi on our custom boards, but we are behind a bit ATM

 Jocke


USB gadget ethernet status ?

2020-05-13 Thread Joakim Tjernlund
I decided to check out USB gadget ethernet in u-boot and selected 
USB_ETHER/USB_ETH_RNDIS and tried
to build it but that fails due to missing __constant_cpu_to_leXX() definitions.

These are nowhere to find in u-boot so I wonder what shape above code is?

 Jocke


Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 13:06 +0200, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 12:47 +0200, Rasmus Villemoes wrote:
> > On 06/05/2020 12.18, Joakim Tjernlund wrote:
> > > On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> > > > On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > > > > CAUTION: This email originated from outside of the organization. Do 
> > > > > not click links or open attachments unless you recognize the sender 
> > > > > and know the content is safe.
> > > > > 
> > > > > 
> > > > > On 06/05/2020 11.21, Joakim Tjernlund wrote:
> > > > > 
> > > > > > I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv 
> > > > > > stuff should be simple to backport
> > > > > > How would fw_env.config be dealt with? Just ignored when auto size?
> > > > > 
> > > > > AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
> > > > > tools, so auto size has to be opt-in separately in fw_env.config, 
> > > > > which
> > > > > is where I did use 0 to mean auto (see the referenced commit
> > > > > e282c422e0). You should be able to test that part already with just
> > > > > fw_setenv built from master and an appropriate fw_env.config [or 
> > > > > perhaps
> > > > > you need to add another "mtdinfo.type == ..." condition first].
> > > > 
> > > > Oh, I misunderstood then. I was mostly interested in fw_setenv ATM
> > > > Looking at your fw_setenv commit I have one question:
> > > > Will this auto mode also work when erase size < env size ?
> > > > We have the case:
> > > > 
> > > > # MTD device name   Device offset   Env. size   Flash sector 
> > > > size
> > > 
> > > From my POV, this "Flash sector size" name is misleading. "Size to erase" 
> > > would be better.
> > > It must be >= Env. size and a multiple of EB size.
> > > auto would mean to select a size >= Env. size, round up to closest 
> > > multiple of EB size.
> > 
> > No, it is indeed supposed to be the flash sector size, and _not_ the
> > size to erase; that's why the code has logic to compute how many sectors
> > to erase (which you can also optionally specify in a fifth column, but
> > as I said, that's done automatically if not specified), and the erase
> > size is then, later yet, of course computed as (erase size)*#sectors.
> > 
> > All that has nothing at all to do with my patch, that's how it all used
> > to work.
> > 
> > > >  /dev/mtd1  0x  0x2000  0x1000
> > > > 
> > > > Above does not work because EB < Env. size, one have to set the sector 
> > > > size
> > > > to >= Env. size(0x2000)
> > 
> > Are you sure? As I said, it works just fine on my end. The only thing my
> > auto-patch does is to make
> 
> Yes, but then my fw_setenv is from 2015.04, not much has happened to 
> fw_setenv since then though
> I will test you auto fw_setenv soon

Some docs about this new auto mode in fw_env.config would probably be a good 
idea too.



Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 12:47 +0200, Rasmus Villemoes wrote:
> On 06/05/2020 12.18, Joakim Tjernlund wrote:
> > On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> > > On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > > > CAUTION: This email originated from outside of the organization. Do not 
> > > > click links or open attachments unless you recognize the sender and 
> > > > know the content is safe.
> > > > 
> > > > 
> > > > On 06/05/2020 11.21, Joakim Tjernlund wrote:
> > > > 
> > > > > I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff 
> > > > > should be simple to backport
> > > > > How would fw_env.config be dealt with? Just ignored when auto size?
> > > > 
> > > > AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
> > > > tools, so auto size has to be opt-in separately in fw_env.config, which
> > > > is where I did use 0 to mean auto (see the referenced commit
> > > > e282c422e0). You should be able to test that part already with just
> > > > fw_setenv built from master and an appropriate fw_env.config [or perhaps
> > > > you need to add another "mtdinfo.type == ..." condition first].
> > > 
> > > Oh, I misunderstood then. I was mostly interested in fw_setenv ATM
> > > Looking at your fw_setenv commit I have one question:
> > > Will this auto mode also work when erase size < env size ?
> > > We have the case:
> > > 
> > > # MTD device name Device offset   Env. size   Flash sector size
> > 
> > From my POV, this "Flash sector size" name is misleading. "Size to erase" 
> > would be better.
> > It must be >= Env. size and a multiple of EB size.
> > auto would mean to select a size >= Env. size, round up to closest multiple 
> > of EB size.
> 
> No, it is indeed supposed to be the flash sector size, and _not_ the
> size to erase; that's why the code has logic to compute how many sectors
> to erase (which you can also optionally specify in a fifth column, but
> as I said, that's done automatically if not specified), and the erase
> size is then, later yet, of course computed as (erase size)*#sectors.
> 
> All that has nothing at all to do with my patch, that's how it all used
> to work.
> 
> > >  /dev/mtd10x  0x2000  0x1000
> > > 
> > > Above does not work because EB < Env. size, one have to set the sector 
> > > size
> > > to >= Env. size(0x2000)
> 
> Are you sure? As I said, it works just fine on my end. The only thing my
> auto-patch does is to make

Yes, but then my fw_setenv is from 2015.04, not much has happened to fw_setenv 
since then though
I will test you auto fw_setenv soon

 Jocke
> 
> /dev/mtd1 0x  0x2000  0x1000
> 
> equivalent to
> 
> /dev/mtd1 0x  0x2000  0
> 
> if the flash does have 4k erase size, so my patch wouldn't make the
> latter work if the former didn't already. [But again, the reason I can't
> use the former is to be compatible with the boards that have 64K erase
> size].
> 
> Rasmus



Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 12:15 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 06/05/2020 12.00, Joakim Tjernlund wrote:
> > On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > > On 06/05/2020 11.21, Joakim Tjernlund wrote:
> > > 
> > > > I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff 
> > > > should be simple to backport
> > > > How would fw_env.config be dealt with? Just ignored when auto size?
> > > 
> > > AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
> > > tools, so auto size has to be opt-in separately in fw_env.config, which
> > > is where I did use 0 to mean auto (see the referenced commit
> > > e282c422e0). You should be able to test that part already with just
> > > fw_setenv built from master and an appropriate fw_env.config [or perhaps
> > > you need to add another "mtdinfo.type == ..." condition first].
> > 
> > Oh, I misunderstood then. I was mostly interested in fw_setenv ATM
> > Looking at your fw_setenv commit I have one question:
> > Will this auto mode also work when erase size < env size ?
> > We have the case:
> > 
> > # MTD device name Device offset   Env. size   Flash sector size
> >  /dev/mtd10x  0x2000  0x1000
> > 
> > Above does not work because EB < Env. size, one have to set the sector size
> > to >= Env. size(0x2000)
> 
> Yes, it should work just fine. My own board has env size 0x2000, so it
> spans two 4K sectors (on the boards with the newer flash). As long as
> one leaves the fifth column (number of sectors) empty or 0, the logic a
> bit further down will automatically compute how many sectors the
> environment occupies.

Nice, got to try your latest fw_setenv patch then :)

> 
> Are you saying that the above config is not accepted by fw_setenv or
> that it causes a run-time error when actually trying to save the env? If
> so, I'd like to see a strace output.

No, I have yet to try your patch. I am saying that
 /dev/mtd10x  0x2000  0x1000
in my somewhat older fw_setenv, I think it would silently ignore writing the 
env. in that case(if I recall correctly)



Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 12:00 +0200, Joakim Tjernlund wrote:
> On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> > CAUTION: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you recognize the sender and know 
> > the content is safe.
> > 
> > 
> > On 06/05/2020 11.21, Joakim Tjernlund wrote:
> > 
> > > I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff 
> > > should be simple to backport
> > > How would fw_env.config be dealt with? Just ignored when auto size?
> > 
> > AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
> > tools, so auto size has to be opt-in separately in fw_env.config, which
> > is where I did use 0 to mean auto (see the referenced commit
> > e282c422e0). You should be able to test that part already with just
> > fw_setenv built from master and an appropriate fw_env.config [or perhaps
> > you need to add another "mtdinfo.type == ..." condition first].
> 
> Oh, I misunderstood then. I was mostly interested in fw_setenv ATM
> Looking at your fw_setenv commit I have one question:
> Will this auto mode also work when erase size < env size ?
> We have the case:
> 
> # MTD device name Device offset   Env. size   Flash sector size

From my POV, this "Flash sector size" name is misleading. "Size to erase" would 
be better.
It must be >= Env. size and a multiple of EB size.
auto would mean to select a size >= Env. size, round up to closest multiple of 
EB size.

>  /dev/mtd10x  0x2000  0x1000
> 
> Above does not work because EB < Env. size, one have to set the sector size
> to >= Env. size(0x2000)
> 
>  Jocke



Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 11:37 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 06/05/2020 11.21, Joakim Tjernlund wrote:
> 
> > I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff 
> > should be simple to backport
> > How would fw_env.config be dealt with? Just ignored when auto size?
> 
> AFAIK, the U-Boot configuration doesn't affect the userspace fw_env
> tools, so auto size has to be opt-in separately in fw_env.config, which
> is where I did use 0 to mean auto (see the referenced commit
> e282c422e0). You should be able to test that part already with just
> fw_setenv built from master and an appropriate fw_env.config [or perhaps
> you need to add another "mtdinfo.type == ..." condition first].

Oh, I misunderstood then. I was mostly interested in fw_setenv ATM
Looking at your fw_setenv commit I have one question:
Will this auto mode also work when erase size < env size ?
We have the case:

# MTD device name   Device offset   Env. size   Flash sector size
 /dev/mtd1  0x  0x2000  0x1000

Above does not work because EB < Env. size, one have to set the sector size
to >= Env. size(0x2000)

 Jocke


Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 11:11 +0200, Rasmus Villemoes wrote:
> 
> On 06/05/2020 10.59, Joakim Tjernlund wrote:
> > On Wed, 2020-05-06 at 10:47 +0200, Rasmus Villemoes wrote:
> > > At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean
> > > "use the erase size the chip reports", but that config
> > > option is used in a number of preprocessor conditionals, and shared
> > > between ENV_IS_IN_FLASH and ENV_IS_IN_SPI_FLASH.
> > 
> > I see, It had been good if one could have used 0
> > 
> > > So instead, introduce a new boolean config option, which for now can
> > > only be used with ENV_IS_IN_SPI_FLASH. If left off, there's no change
> > > in behaviour.
> > 
> > Please don't stop at just SPI Flash, we could use this for common NOR 
> > flashes too.
> 
> Certainly, but I don't have any such hardware, and the code also seems
> to require a bit more work than the sf.c case due to the preprocessor
> uses. It's quite possible that the
> 
> #if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE
>   foo; bar;
> #endif
> 
> can be replaced by
> 
> u32 sect_size = CONFIG_ENV_SECT_SIZE;
> if (IS_ENABLED(CONFIG_ENV_SECT_SIZE_AUTO))
>   sect_size = [...however we want to get that info]
> 
> if (sect_size > CONFIG_ENV_SIZE {
>   foo; bar;
> }
> 
> but then there's the uses of CONFIG_ENV_SECT_SIZE to initialize end_addr
> and end_addr_new. So I think doing the flash.c part requires someone
> with hardware access.

I can test NOR Flash ,I am on an older u-boot ATM but fw_setenv stuff should be 
simple to backport
How would fw_env.config be dealt with? Just ignored when auto size?

   Jocke


Re: [PATCH 2/2] env: add CONFIG_ENV_SECT_SIZE_AUTO

2020-05-06 Thread Joakim Tjernlund
On Wed, 2020-05-06 at 10:47 +0200, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> This is roughly the U-Boot side equivalent to commit
> e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The
> motivation is the case where one has a board with several revisions,
> where the SPI flashes have different erase sizes.
> 
> In our case, we have an 8K environment, and the flashes have erase
> sizes of 4K (newer boards) and 64K (older boards). Currently, we must
> set CONFIG_ENV_SECT_SIZE to 64K to make the code work on the older
> boards, but for the newer ones, that ends up wasting quite a bit of
> time reading/erasing/restoring the last 56K.
> 
> At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean
> "use the erase size the chip reports", but that config
> option is used in a number of preprocessor conditionals, and shared
> between ENV_IS_IN_FLASH and ENV_IS_IN_SPI_FLASH.

I see, It had been good if one could have used 0

> 
> So instead, introduce a new boolean config option, which for now can
> only be used with ENV_IS_IN_SPI_FLASH. If left off, there's no change
> in behaviour.

Please don't stop at just SPI Flash, we could use this for common NOR flashes 
too.

> 
> The only slightly annoying detail is that, when selected, the compiler
> is apparently not smart enough to see that the the saved_size and
> saved_offset variables are only used under the same "if (sect_size >
> CONFIG_ENV_SIZE)" condition as where they are computed, so we need to
> initialize them to 0 to avoid "may be used uninitialized" warnings.
> 
> On our newer boards with the 4K erase size, saving the environment now
> takes 0.080 seconds instead of 0.53 seconds, which directly translates
> to that much faster boot time since our logic always causes the
> environment to be written during boot.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  env/Kconfig | 14 ++
>  env/sf.c| 10 --
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/env/Kconfig b/env/Kconfig
> index 969308fe6c..c90cd04604 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -317,6 +317,20 @@ config ENV_IS_IN_SPI_FLASH
>   during a "saveenv" operation. CONFIG_ENV_OFFSET_REDUND must be
>   aligned to an erase sector boundary.
> 
> +config ENV_SECT_SIZE_AUTO
> +   bool "Use automatically detected sector size"
> +   depends on ENV_IS_IN_SPI_FLASH
> +   help
> + Some boards exist in multiple variants, with different
> + flashes having different sector sizes. In such cases, you
> + can select this option to make U-Boot use the actual sector
> + size when figuring out how much to erase, which can thus be
> + more efficient on the flashes with smaller erase size. Since
> + the environment must always be aligned on a sector boundary,
> + CONFIG_ENV_OFFSET must be aligned to the largest of the
> + different sector sizes, and CONFIG_ENV_SECT_SIZE should be
> + set to that value.
> +
>  config USE_ENV_SPI_BUS
> bool "SPI flash bus for environment"
> depends on ENV_IS_IN_SPI_FLASH
> diff --git a/env/sf.c b/env/sf.c
> index cd5339578b..644e78fe3d 100644
> --- a/env/sf.c
> +++ b/env/sf.c
> @@ -69,7 +69,7 @@ static int env_sf_save(void)
>  {
> env_t   env_new;
> char*saved_buffer = NULL, flag = ENV_REDUND_OBSOLETE;
> -   u32 saved_size, saved_offset, sector;
> +   u32 saved_size = 0, saved_offset = 0, sector;
> u32 sect_size = CONFIG_ENV_SECT_SIZE;
> int ret;
> 
> @@ -77,6 +77,9 @@ static int env_sf_save(void)
> if (ret)
> return ret;
> 
> +   if (IS_ENABLED(CONFIG_ENV_SECT_SIZE_AUTO))
> +   sect_size = env_flash->mtd.erasesize;
> +
> ret = env_export(_new);
> if (ret)
> return -EIO;
> @@ -184,7 +187,7 @@ out:
>  #else
>  static int env_sf_save(void)
>  {
> -   u32 saved_size, saved_offset, sector;
> +   u32 saved_size = 0, saved_offset = 0, sector;
> u32 sect_size = CONFIG_ENV_SECT_SIZE;
> char*saved_buffer = NULL;
> int ret = 1;
> @@ -194,6 +197,9 @@ static int env_sf_save(void)
> if (ret)
> return ret;
> 
> +   if (IS_ENABLED(CONFIG_ENV_SECT_SIZE_AUTO))
> +   sect_size = env_flash->mtd.erasesize;
> +
> /* Is the sector larger than the env (i.e. embedded) */
> if (sect_size > CONFIG_ENV_SIZE) {
> saved_size = sect_size - CONFIG_ENV_SIZE;
> --
> 2.23.0
> 



Re: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self Refresh mode"

2020-04-10 Thread Joakim Tjernlund
On Fri, 2020-04-10 at 11:40 +, Priyanka Jain wrote:
> 
> > -Original Message-
> > From: Joakim Tjernlund 
> > Sent: Thursday, April 9, 2020 6:24 PM
> > To: Priyanka Jain ; Biwen Li (OSS)
> > 
> > Cc: u-boot@lists.denx.de; Biwen Li ; Jiafei Pan
> > 
> > Subject: Re: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self
> > Refresh mode"
> > 
> > On Thu, 2020-04-09 at 20:44 +0800, Biwen Li wrote:
> > 
> > This revert will bring back another bug, can you try finding out why it does
> > work?
> > May there are some minor tweaks needed ?
> > 
> >   Jocke
> The patch has impacted boot to prompt on many powerpc boards.
> I agree with you that we also need to have solution to the original problem 
> reported by you.
> We are working on fixing of DDR errata workaround implementation issue that 
> you reported.

Is anyone working on the eSPI driver as well? I recall someone at NXP 
volunteered but cannot recall who.

> 
> But I need this workaround patch to be reverted now as a quick fix for 
> v2020.04 release which is only few days away.

I see

 Jocke

> 
> Thanks
> Priyanka
> > > From: Biwen Li 
> > > 
> > > This reverts commit 2a5d5d27edfbdb0e02a7fcf05569f92c02ae44ee.
> > > After applied this patch, failed to boot to uboot(hang in ddr init) on
> > > P3041DS, P4080DS and so on.
> > > ---
> > >  drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 13 +++--
> > >  1 file changed, 7 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> > > b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> > > index 952b296dd8..a9b085db8c 100644
> > > --- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> > > +++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> > > @@ -370,8 +370,6 @@ step2:
> > > debug("Setting DEBUG_3[21] to 0x%08x\n",
> > > in_be32(>debug[2]));
> > > 
> > >  #endif /* part 1 of the workaound */
> > > -   /* Always start in self-refresh, clear after MEM_EN */
> > > -   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> > > 
> > > /*
> > >  * 500 painful micro-seconds must elapse between @@ -384,6
> > > +382,8 @@ step2:
> > > 
> > >  #ifdef CONFIG_DEEP_SLEEP
> > > if (is_warm_boot()) {
> > > +   /* enter self-refresh */
> > > +   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> > > /* do board specific memory setup */
> > > board_mem_sleep_setup();
> > > temp_sdram_cfg = (in_be32(>sdram_cfg) |
> > > SDRAM_CFG_BI); @@ -395,10 +395,6 @@ step2:
> > > out_be32(>sdram_cfg, temp_sdram_cfg |
> > SDRAM_CFG_MEM_EN);
> > > asm volatile("sync;isync");
> > > 
> > > -   /* Exit self-refresh after DDR conf as some ddr memories can 
> > > fail. */
> > > -   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> > > -   asm volatile("sync;isync");
> > > -
> > > total_gb_size_per_controller = 0;
> > > for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
> > > if (!(regs->cs[i].config & 0x8000)) @@ -548,4
> > > +544,9 @@ step2:
> > > clrbits_be32(>sdram_cfg, 0x2);
> > > }
> > >  #endif /* CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 */
> > > +#ifdef CONFIG_DEEP_SLEEP
> > > +   if (is_warm_boot())
> > > +   /* exit self-refresh */
> > > +   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> > > +#endif
> > >  }
> > > --
> > > 2.17.1
> > > 



Re: [PATCH] Revert "mpc85xx: ddr: Always start DDR RAM in Self Refresh mode"

2020-04-09 Thread Joakim Tjernlund
On Thu, 2020-04-09 at 20:44 +0800, Biwen Li wrote:

This revert will bring back another bug, can you try finding out why it does 
work?
May there are some minor tweaks needed ?

   Jocke 
> 
> From: Biwen Li 
> 
> This reverts commit 2a5d5d27edfbdb0e02a7fcf05569f92c02ae44ee.
> After applied this patch, failed to boot to uboot(hang in ddr init)
> on P3041DS, P4080DS and so on.
> ---
>  drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c 
> b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> index 952b296dd8..a9b085db8c 100644
> --- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> +++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
> @@ -370,8 +370,6 @@ step2:
> debug("Setting DEBUG_3[21] to 0x%08x\n", in_be32(>debug[2]));
> 
>  #endif /* part 1 of the workaound */
> -   /* Always start in self-refresh, clear after MEM_EN */
> -   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> 
> /*
>  * 500 painful micro-seconds must elapse between
> @@ -384,6 +382,8 @@ step2:
> 
>  #ifdef CONFIG_DEEP_SLEEP
> if (is_warm_boot()) {
> +   /* enter self-refresh */
> +   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> /* do board specific memory setup */
> board_mem_sleep_setup();
> temp_sdram_cfg = (in_be32(>sdram_cfg) | SDRAM_CFG_BI);
> @@ -395,10 +395,6 @@ step2:
> out_be32(>sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
> asm volatile("sync;isync");
> 
> -   /* Exit self-refresh after DDR conf as some ddr memories can fail. */
> -   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> -   asm volatile("sync;isync");
> -
> total_gb_size_per_controller = 0;
> for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
> if (!(regs->cs[i].config & 0x8000))
> @@ -548,4 +544,9 @@ step2:
> clrbits_be32(>sdram_cfg, 0x2);
> }
>  #endif /* CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 */
> +#ifdef CONFIG_DEEP_SLEEP
> +   if (is_warm_boot())
> +   /* exit self-refresh */
> +   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
> +#endif
>  }
> --
> 2.17.1
> 



Re: [PATCH] ddr: fsl: Impl. Erratum A008109

2019-12-17 Thread Joakim Tjernlund
On Tue, 2019-12-17 at 08:55 +, Priyanka Jain wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> > -Original Message-----
> > From: Joakim Tjernlund 
> > Sent: Monday, November 25, 2019 2:06 PM
> > To: Priyanka Jain ; u-boot@lists.denx.de
> > Cc: York Sun 
> > Subject: Re: [PATCH] ddr: fsl: Impl. Erratum A008109
> > 
> > On Wed, 2019-11-20 at 17:07 +0100, Joakim Tjernlund wrote:
> > > Impl. erratum as descibed in errata doc.
> > > Enable A008109 for T1040 and T1024
> > > 
> > > Signed-off-by: Joakim Tjernlund 
> > > ---
> > >  arch/powerpc/cpu/mpc85xx/Kconfig | 2 ++
> > >  drivers/ddr/fsl/Kconfig  | 3 +++
> > >  drivers/ddr/fsl/ctrl_regs.c  | 6 ++
> > >  3 files changed, 11 insertions(+)
> > > 
> > > diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig
> > > b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > index 8cc82f80b4..6caf5c8389 100644
> > > --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> > > +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> > > @@ -1038,6 +1038,7 @@ config ARCH_T1040
> > >  select SYS_FSL_DDR_VER_50
> > >  select SYS_FSL_ERRATUM_A008044
> > >  select SYS_FSL_ERRATUM_A008378
> > > +select SYS_FSL_ERRATUM_A008109
> > >  select SYS_FSL_ERRATUM_A009663
> > >  select SYS_FSL_ERRATUM_A009942
> > >  select SYS_FSL_ERRATUM_ESDHC111
> > > @@ -1061,6 +1062,7 @@ config ARCH_T1042
> > >  select SYS_FSL_DDR_VER_50
> > >  select SYS_FSL_ERRATUM_A008044
> > >  select SYS_FSL_ERRATUM_A008378
> > > +select SYS_FSL_ERRATUM_A008109
> > >  select SYS_FSL_ERRATUM_A009663
> > >  select SYS_FSL_ERRATUM_A009942
> > >  select SYS_FSL_ERRATUM_ESDHC111
> > > diff --git a/drivers/ddr/fsl/Kconfig b/drivers/ddr/fsl/Kconfig index
> > > 1b73df82de..f75d97b15c 100644
> > > --- a/drivers/ddr/fsl/Kconfig
> > > +++ b/drivers/ddr/fsl/Kconfig
> > > @@ -151,6 +151,9 @@ endmenu
> > >  config SYS_FSL_ERRATUM_A008378
> > >  bool
> > > 
> > > +config SYS_FSL_ERRATUM_A008109
> > > +bool
> > > +
> > >  config SYS_FSL_ERRATUM_A008511
> > >  bool
> > > 
> > > diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
> > > index 98ccbb70de..d467160d0c 100644
> > > --- a/drivers/ddr/fsl/ctrl_regs.c
> > > +++ b/drivers/ddr/fsl/ctrl_regs.c
> > > @@ -2626,6 +2626,12 @@ compute_fsl_memctl_config_regs(const unsigned
> > int ctrl_num,
> > >  }
> > >  #endif
> > > 
> > > +#ifdef CONFIG_SYS_FSL_ERRATUM_A008109
> > > +ddr->ddr_sdram_cfg_2 = ddr_in32(>ddr_sdram_cfg_2) | 0x800;
> > /* DDR_SLOW */
> > > +ddr->debug[18] = ddr_in32(>debug[18]) | 0x2;
> > > +ddr->debug[28] = 0x3000;
> > > +#endif
> > > +
> > 
> > I just noticed something odd(buggy?). Each errata reads from DDR controller
> > bug saves the new value in a RAM variable(ddr->debug[X]) but does not write
> > values back to HW.
> > 
> > As several erratas update the same register, this looses the previous data.
> > Also, are theses errtas/debug stateless? Now the code tries gather all 
> > writes
> > into a RAM variable and write the total change in one go later on, this will
> > only work if all errata fixes are stateless.
> > 
> It seems Errata fixes are not stateless.
> We need to program HW register separately for each errata workaround.
> In SoC chip errata document: section A-008109,
> order of errata workaround implementation is mentioned
> as first implement A-008378, then A-008109 and then A-009942.
> Can you please check if things works fine at your end with this order.
> Meanwhile I will also check within NXP.
> > >  #ifdef CONFIG_SYS_FSL_ERRATUM_A009942
> > >  ddr_freq = get_ddr_freq(ctrl_num) / 100;
> > >  ddr->debug[28] |= ddr_in32(>debug[28]);
> Priyanka

Hi Priyanka

I have given up on this errata, any impl. attempt didn't make a difference and 
I could
not get any details from NXP w.r.t this errata.

The thing that did fix the problem was the patch: "mpc85xx: ddr: Always start 
DDR RAM in Self Refresh mode"
NXP did confirm that starting in SR should have no ill effects but could not 
confirm if it fixed any HW bug
in the controller. Starting in SR mode provides a softer transition from 
configuration to full operation though.

I cannot help thinking that errata A008109 and my SR fix is related but I think 
you will have to
sort that out.

   Jocke


Re: [PATCH v2 1/2] common: fdt_support: add support for setting usable memory

2019-12-03 Thread Joakim Tjernlund
On Tue, 2019-12-03 at 14:04 +0200, Igor Opaniuk wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> From: Igor Opaniuk 
> 
> Add support for setting linux,usable-memory property in the memory
> node of device tree for the kernel [1].

Isn't this same/similar to fdt_add_mem_rsv() ?

 Jocke



[U-Boot] [PATCH] mpc85xx: ddr: Always start DDR RAM in Self Refresh mode

2019-11-27 Thread Joakim Tjernlund
Some of our t1042 boards fails DDR init with an Automatic calibration error
every now and then. Investigations revealed that true Warm boots
newer failed. Warm boots has some extra steps performed, one being
to start DDRC in Self Refresh and then clearing SR right after.
Applying this SR method unconditionally made all our boards
stable again, regardless of Cold/Warm boot.

Signed-off-by: Joakim Tjernlund 
---
 drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c 
b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
index a9b085db8c..952b296dd8 100644
--- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
+++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
@@ -370,6 +370,8 @@ step2:
debug("Setting DEBUG_3[21] to 0x%08x\n", in_be32(>debug[2]));
 
 #endif /* part 1 of the workaound */
+   /* Always start in self-refresh, clear after MEM_EN */
+   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
 
/*
 * 500 painful micro-seconds must elapse between
@@ -382,8 +384,6 @@ step2:
 
 #ifdef CONFIG_DEEP_SLEEP
if (is_warm_boot()) {
-   /* enter self-refresh */
-   setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
/* do board specific memory setup */
board_mem_sleep_setup();
temp_sdram_cfg = (in_be32(>sdram_cfg) | SDRAM_CFG_BI);
@@ -395,6 +395,10 @@ step2:
out_be32(>sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
asm volatile("sync;isync");
 
+   /* Exit self-refresh after DDR conf as some ddr memories can fail. */
+   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
+   asm volatile("sync;isync");
+
total_gb_size_per_controller = 0;
for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
if (!(regs->cs[i].config & 0x8000))
@@ -544,9 +548,4 @@ step2:
clrbits_be32(>sdram_cfg, 0x2);
}
 #endif /* CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 */
-#ifdef CONFIG_DEEP_SLEEP
-   if (is_warm_boot())
-   /* exit self-refresh */
-   clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
-#endif
 }
-- 
2.23.0

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


Re: [U-Boot] [PATCH] ddr: fsl: Impl. Erratum A008109

2019-11-25 Thread Joakim Tjernlund
On Wed, 2019-11-20 at 17:07 +0100, Joakim Tjernlund wrote:
> Impl. erratum as descibed in errata doc.
> Enable A008109 for T1040 and T1024
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  arch/powerpc/cpu/mpc85xx/Kconfig | 2 ++
>  drivers/ddr/fsl/Kconfig  | 3 +++
>  drivers/ddr/fsl/ctrl_regs.c  | 6 ++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig 
> b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 8cc82f80b4..6caf5c8389 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -1038,6 +1038,7 @@ config ARCH_T1040
>   select SYS_FSL_DDR_VER_50
>   select SYS_FSL_ERRATUM_A008044
>   select SYS_FSL_ERRATUM_A008378
> + select SYS_FSL_ERRATUM_A008109
>   select SYS_FSL_ERRATUM_A009663
>   select SYS_FSL_ERRATUM_A009942
>   select SYS_FSL_ERRATUM_ESDHC111
> @@ -1061,6 +1062,7 @@ config ARCH_T1042
>   select SYS_FSL_DDR_VER_50
>   select SYS_FSL_ERRATUM_A008044
>   select SYS_FSL_ERRATUM_A008378
> + select SYS_FSL_ERRATUM_A008109
>   select SYS_FSL_ERRATUM_A009663
>   select SYS_FSL_ERRATUM_A009942
>   select SYS_FSL_ERRATUM_ESDHC111
> diff --git a/drivers/ddr/fsl/Kconfig b/drivers/ddr/fsl/Kconfig
> index 1b73df82de..f75d97b15c 100644
> --- a/drivers/ddr/fsl/Kconfig
> +++ b/drivers/ddr/fsl/Kconfig
> @@ -151,6 +151,9 @@ endmenu
>  config SYS_FSL_ERRATUM_A008378
>   bool
>  
> +config SYS_FSL_ERRATUM_A008109
> + bool
> +
>  config SYS_FSL_ERRATUM_A008511
>   bool
>  
> diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
> index 98ccbb70de..d467160d0c 100644
> --- a/drivers/ddr/fsl/ctrl_regs.c
> +++ b/drivers/ddr/fsl/ctrl_regs.c
> @@ -2626,6 +2626,12 @@ compute_fsl_memctl_config_regs(const unsigned int 
> ctrl_num,
>   }
>  #endif
>  
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A008109
> + ddr->ddr_sdram_cfg_2 = ddr_in32(>ddr_sdram_cfg_2) | 0x800; /* 
> DDR_SLOW */
> + ddr->debug[18] = ddr_in32(>debug[18]) | 0x2;
> + ddr->debug[28] = 0x3000;
> +#endif
> +

I just noticed something odd(buggy?). Each errata reads from DDR controller bug 
saves the new
value in a RAM variable(ddr->debug[X]) but does not write values back to HW.

As several erratas update the same register, this looses the previous data.
Also, are theses errtas/debug stateless? Now the code tries gather all writes 
into a RAM variable and
write the total change in one go later on, this will only work if all errata 
fixes are stateless.

>  #ifdef CONFIG_SYS_FSL_ERRATUM_A009942
>   ddr_freq = get_ddr_freq(ctrl_num) / 100;
>   ddr->debug[28] |= ddr_in32(>debug[28]);

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


[U-Boot] [PATCH] ddr: fsl: Impl. Erratum A008109

2019-11-20 Thread Joakim Tjernlund
Impl. erratum as descibed in errata doc.
Enable A008109 for T1040 and T1024

Signed-off-by: Joakim Tjernlund 
---
 arch/powerpc/cpu/mpc85xx/Kconfig | 2 ++
 drivers/ddr/fsl/Kconfig  | 3 +++
 drivers/ddr/fsl/ctrl_regs.c  | 6 ++
 3 files changed, 11 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 8cc82f80b4..6caf5c8389 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1038,6 +1038,7 @@ config ARCH_T1040
select SYS_FSL_DDR_VER_50
select SYS_FSL_ERRATUM_A008044
select SYS_FSL_ERRATUM_A008378
+   select SYS_FSL_ERRATUM_A008109
select SYS_FSL_ERRATUM_A009663
select SYS_FSL_ERRATUM_A009942
select SYS_FSL_ERRATUM_ESDHC111
@@ -1061,6 +1062,7 @@ config ARCH_T1042
select SYS_FSL_DDR_VER_50
select SYS_FSL_ERRATUM_A008044
select SYS_FSL_ERRATUM_A008378
+   select SYS_FSL_ERRATUM_A008109
select SYS_FSL_ERRATUM_A009663
select SYS_FSL_ERRATUM_A009942
select SYS_FSL_ERRATUM_ESDHC111
diff --git a/drivers/ddr/fsl/Kconfig b/drivers/ddr/fsl/Kconfig
index 1b73df82de..f75d97b15c 100644
--- a/drivers/ddr/fsl/Kconfig
+++ b/drivers/ddr/fsl/Kconfig
@@ -151,6 +151,9 @@ endmenu
 config SYS_FSL_ERRATUM_A008378
bool
 
+config SYS_FSL_ERRATUM_A008109
+   bool
+
 config SYS_FSL_ERRATUM_A008511
bool
 
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 98ccbb70de..d467160d0c 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -2626,6 +2626,12 @@ compute_fsl_memctl_config_regs(const unsigned int 
ctrl_num,
}
 #endif
 
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008109
+   ddr->ddr_sdram_cfg_2 = ddr_in32(>ddr_sdram_cfg_2) | 0x800; /* 
DDR_SLOW */
+   ddr->debug[18] = ddr_in32(>debug[18]) | 0x2;
+   ddr->debug[28] = 0x3000;
+#endif
+
 #ifdef CONFIG_SYS_FSL_ERRATUM_A009942
ddr_freq = get_ddr_freq(ctrl_num) / 100;
ddr->debug[28] |= ddr_in32(>debug[28]);
-- 
2.23.0

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


Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI driver to driver model

2019-08-21 Thread Joakim Tjernlund
On Wed, 2019-08-21 at 09:46 +, Xiaowei Bao wrote:
> > -Original Message-
> > From: Joakim Tjernlund 
> > Sent: 2019年8月21日 15:52
> > To: Prabhakar Kushwaha ; Ruchika Gupta
> > ; Xiaowei Bao ;
> > Shengzhou Liu ; w...@denx.de;
> > ja...@amarulasolutions.com
> > Cc: u-boot@lists.denx.de; Jiafei Pan ; Chuanhua Han
> > 
> > Subject: Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI driver 
> > to
> > driver model
> > 
> > On Wed, 2019-08-21 at 01:19 +, Xiaowei Bao wrote:
> > > > -Original Message-
> > > > From: Joakim Tjernlund 
> > > > Sent: 2019年8月20日 19:04
> > > > To: Prabhakar Kushwaha ; Ruchika
> > Gupta
> > > > ; Xiaowei Bao ;
> > > > Shengzhou Liu ; w...@denx.de;
> > > > ja...@amarulasolutions.com
> > > > Cc: u-boot@lists.denx.de; Jiafei Pan ; Chuanhua
> > > > Han 
> > > > Subject: Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI
> > > > driver to driver model
> > > > 
> > > > On Tue, 2019-08-20 at 06:59 +, Xiaowei Bao wrote:
> > > > > From: Chuanhua Han 
> > > > > 
> > > > > Modify the Freescale ESPI driver to support the driver model.
> > > > > Also resolved the following problems:
> > > > > 
> > > > > = WARNING == This
> > > > board does
> > > > > not use CONFIG_DM_SPI. Please update the board before v2019.04 for
> > > > > no dm conversion and v2019.07 for partially dm converted drivers.
> > > > > Failure to update can lead to driver/board removal See
> > > > > doc/driver-model/MIGRATION.txt for more info.
> > > > > 
> > > > > = WARNING == This
> > > > board does
> > > > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > > > Failure to update by the deadline may result in board removal.
> > > > > See doc/driver-model/MIGRATION.txt for more info.
> > > > > 
> > > > 
> > > > These are not the only problems with this driver it is borken for
> > > > anything but loading small amount of data from SPI NOR flash.
> > > > Look at spi_xfer:
> > > >   overuse of malloc/memcpy
> > > >   misuse of word size(always 32 bits) making proper of
> > > > ESPI_EV_RNE/ESPI_EV_TNF impossible.
> > > >   random test of 0x0b:
> > > >   memcpy(data_in, buffer + 2 * cmd_len, tran_len);
> > > >   if (*buffer == 0x0b) {
> > > >   data_in += tran_len;
> > > >   data_len -= tran_len;
> > > >   *(int *)buffer += tran_len;
> > > >   }
> > > > 
> > > > I think fixing the driver to work properly first is preferable to DM
> > conversion.
> > > Thanks a lot for your comments, in fact, these code exist all the
> > > time, I never modify this part code, and I have verified the SPI flash
> > > use 4K data, the test result is ok, I will check and analyze this part 
> > > code, and
> > give the reply later, thanks.
> > 
> > Yes, this code has been borken for years and like I said, it only works for 
> > SPI
> > NOR flash which is what you tested.
> > Try a simple SPI device, reading and writing registers.
> > 
> > Here is an old hack for loading FPGAs using ESPI_COM_TO, hopefully this can
> > be of some use:
> > https://patch
> > work.ozlabs.org%2Fpatch%2F330242%2Fdata=02%7C01%7Cxiaowei.b
> > ao%40nxp.com%7Cbb03e40adaf14ddabb3308d7260c624a%7C686ea1d3bc2
> > b4c6fa92cd99c5c301635%7C0%7C0%7C637019706960729747sdata=
> > LBnGwExukwfx4Txln7gbC797CK0Nuu1Q%2BG8iK4lCR4M%3Dreserved
> > =0
> > 
> > In short, the inner working of spi_xfer() needs a full rewrite, using the 
> > proper
> > SPI word size, you have no chance of supporting SPI_LSB_FIRST without
> > correct word size.
> Thanks a lot, I think I need to do another new patch which reimplement the 
> xfer function,
> This is better, because this issue fix should not in DM patch, I will submit 
> another new patch to fix
> this issue, but maybe spend some time, because I am not very clear about the 
> FSL ESPI
> driver, and the verification will be a problem, because I don't find other 
> SPI device except
> SPI flash device in our RDB or QDS board, but I am going to do this.

Thanks, I think random access(read/write) to SPI NOR flash will be enough for 
testing.
It won't be any worse than today as it is broken already.

 Jocke

> >  Jocke
> > 
> > > > Jocke

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


Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI driver to driver model

2019-08-21 Thread Joakim Tjernlund
On Wed, 2019-08-21 at 01:19 +, Xiaowei Bao wrote:
> 
> > -Original Message-
> > From: Joakim Tjernlund 
> > Sent: 2019年8月20日 19:04
> > To: Prabhakar Kushwaha ; Ruchika Gupta
> > ; Xiaowei Bao ;
> > Shengzhou Liu ; w...@denx.de;
> > ja...@amarulasolutions.com
> > Cc: u-boot@lists.denx.de; Jiafei Pan ; Chuanhua Han
> > 
> > Subject: Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI driver 
> > to
> > driver model
> > 
> > On Tue, 2019-08-20 at 06:59 +, Xiaowei Bao wrote:
> > > From: Chuanhua Han 
> > > 
> > > Modify the Freescale ESPI driver to support the driver model.
> > > Also resolved the following problems:
> > > 
> > > = WARNING == This
> > board does
> > > not use CONFIG_DM_SPI. Please update the board before v2019.04 for no
> > > dm conversion and v2019.07 for partially dm converted drivers.
> > > Failure to update can lead to driver/board removal See
> > > doc/driver-model/MIGRATION.txt for more info.
> > > 
> > > = WARNING == This
> > board does
> > > not use CONFIG_DM_SPI_FLASH. Please update the board to use
> > > CONFIG_SPI_FLASH before the v2019.07 release.
> > > Failure to update by the deadline may result in board removal.
> > > See doc/driver-model/MIGRATION.txt for more info.
> > > 
> > 
> > These are not the only problems with this driver it is borken for anything 
> > but
> > loading small amount of data from SPI NOR flash.
> > Look at spi_xfer:
> >   overuse of malloc/memcpy
> >   misuse of word size(always 32 bits) making proper of
> > ESPI_EV_RNE/ESPI_EV_TNF impossible.
> >   random test of 0x0b:
> >   memcpy(data_in, buffer + 2 * cmd_len, tran_len);
> >   if (*buffer == 0x0b) {
> >   data_in += tran_len;
> >   data_len -= tran_len;
> >   *(int *)buffer += tran_len;
> >   }
> > 
> > I think fixing the driver to work properly first is preferable to DM 
> > conversion.
> Thanks a lot for your comments, in fact, these code exist all the time, I 
> never modify
> this part code, and I have verified the SPI flash use 4K data, the test 
> result is ok,
> I will check and analyze this part code, and give the reply later, thanks.

Yes, this code has been borken for years and like I said, it only works for SPI 
NOR flash which is what you tested.
Try a simple SPI device, reading and writing registers.

Here is an old hack for loading FPGAs using ESPI_COM_TO, hopefully this can be 
of some use:
https://patchwork.ozlabs.org/patch/330242/

In short, the inner working of spi_xfer() needs a full rewrite, using the 
proper SPI word size, you have no chance
of supporting SPI_LSB_FIRST without correct word size.

 Jocke

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


Re: [U-Boot] [PATCH v5 2/5] dm: spi: Convert Freescale ESPI driver to driver model

2019-08-20 Thread Joakim Tjernlund
On Tue, 2019-08-20 at 06:59 +, Xiaowei Bao wrote:
> 
> From: Chuanhua Han 
> 
> Modify the Freescale ESPI driver to support the driver model.
> Also resolved the following problems:
> 
> = WARNING ==
> This board does not use CONFIG_DM_SPI. Please update
> the board before v2019.04 for no dm conversion
> and v2019.07 for partially dm converted drivers.
> Failure to update can lead to driver/board removal
> See doc/driver-model/MIGRATION.txt for more info.
> 
> = WARNING ==
> This board does not use CONFIG_DM_SPI_FLASH. Please update
> the board to use CONFIG_SPI_FLASH before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/MIGRATION.txt for more info.
> 

These are not the only problems with this driver it is borken for anything
but loading small amount of data from SPI NOR flash.
Look at spi_xfer:
  overuse of malloc/memcpy
  misuse of word size(always 32 bits) making proper of ESPI_EV_RNE/ESPI_EV_TNF 
impossible.
  random test of 0x0b: 
memcpy(data_in, buffer + 2 * cmd_len, tran_len);
if (*buffer == 0x0b) {
data_in += tran_len;
data_len -= tran_len;
*(int *)buffer += tran_len;
}

I think fixing the driver to work properly first is preferable to DM conversion.

Jocke

> 
> Signed-off-by: Chuanhua Han 
> ---
> Changes in v5:
> - Modify the function spi_cs_activate to fsl_spi_cs_activate.
> - Move cs to the parameter of the fsl_spi_cs_activate function.
> Changes in v4:
> - Update copyright information.
> - Move the fsl_espi_platdata data structure to the
> include/dm/platform_data/.
> - Merge the contents of the fsl_espi_priv structure into
> the fsl_spi_slave structure.
> - Implement the fsl_espi_set_speed function.
> - Implement the fsl_espi_set_mode function.
> - Implement the espi_release_bus function.
> - Remove unwanted fsl_espi_bind functions.
> - Implement the fsl_espi_child_pre_probe function as needed.
> - Use #if CONFIG_IS_ENABLED(OF_CONTROL) && 
> !CONFIG_IS_ENABLED(OF_PLATDATA).
> Changes in v3:
> - Add a cover-letter for this patch set.
> Changes in v2:
> - The fsl_espi driver support both OF_CONTROL and PLATDATA.
> 
>  drivers/spi/fsl_espi.c  | 445 
> ++--
>  include/dm/platform_data/fsl_espi.h |  16 ++
>  2 files changed, 337 insertions(+), 124 deletions(-)
>  create mode 100644 include/dm/platform_data/fsl_espi.h
> 
> diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> index 7444ae1..4b33fae 100644
> --- a/drivers/spi/fsl_espi.c
> +++ b/drivers/spi/fsl_espi.c
> @@ -3,18 +3,25 @@
>   * eSPI controller driver.
>   *
>   * Copyright 2010-2011 Freescale Semiconductor, Inc.
> + * Copyright 2019 NXP
>   * Author: Mingkai Hu (mingkai...@freescale.com)
> + *Chuanhua Han (chuanhua@nxp.com)
>   */
> 
>  #include 
> -
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> 
>  struct fsl_spi_slave {
> struct spi_slave slave;
> ccsr_espi_t *espi;
> +   u32 speed_hz;
> +   unsigned int cs;
> unsigned intdiv16;
> unsigned intpm;
> int tx_timeout;
> @@ -28,6 +35,9 @@ struct fsl_spi_slave {
>  #define to_fsl_spi_slave(s) container_of(s, struct fsl_spi_slave, slave)
>  #define US_PER_SECOND  100UL
> 
> +/* default SCK frequency, unit: HZ */
> +#define FSL_ESPI_DEFAULT_SCK_FREQ   1000
> +
>  #define ESPI_MAX_CS_NUM4
>  #define ESPI_FIFO_WIDTH_BIT32
> 
> @@ -62,116 +72,27 @@ struct fsl_spi_slave {
> 
>  #define ESPI_MAX_DATA_TRANSFER_LEN 0xFFF0
> 
> -struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
> -   unsigned int max_hz, unsigned int mode)
> -{
> -   struct fsl_spi_slave *fsl;
> -   sys_info_t sysinfo;
> -   unsigned long spibrg = 0;
> -   unsigned long spi_freq = 0;
> -   unsigned char pm = 0;
> -
> -   if (!spi_cs_is_valid(bus, cs))
> -   return NULL;
> -
> -   fsl = spi_alloc_slave(struct fsl_spi_slave, bus, cs);
> -   if (!fsl)
> -   return NULL;
> -
> -   fsl->espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
> -   fsl->mode = mode;
> -   fsl->max_transfer_length = ESPI_MAX_DATA_TRANSFER_LEN;
> -
> -   /* Set eSPI BRG clock source */
> -   get_sys_info();
> -   spibrg = sysinfo.freq_systembus / 2;
> -   fsl->div16 = 0;
> -   if ((spibrg / max_hz) > 32) {
> -   fsl->div16 = ESPI_CSMODE_DIV16;
> -   pm = spibrg / (max_hz * 16 * 2);
> -   if (pm > 16) {
> -   

Re: [U-Boot] [PATCH v2 10/19] spi: mpc8xxx: Simplify logic a bit

2019-05-15 Thread Joakim Tjernlund
On Wed, 2019-05-15 at 07:02 +0200, Mario Six wrote:
> On Tue, May 14, 2019 at 3:53 PM Jagan Teki  wrote:
> > On Thu, May 2, 2019 at 2:37 PM Joakim Tjernlund
> >  wrote:
> > > On Thu, 2019-05-02 at 07:31 +0200, Mario Six wrote:
> > > > CAUTION: This email originated from outside of the organization. Do not 
> > > > click links or open attachments unless you recognize the sender and 
> > > > know the content is safe.
> > > > 
> > > > 
> > > > Hi Jagan and Jocke,
> > > > 
> > > > I'm back from vacation, so here's my answer:
> > > > 
> > > > On Mon, Apr 29, 2019 at 12:41 PM Jagan Teki 
> > > >  wrote:
> > > > > + Mario
> > > > > 
> > > > > On Mon, Apr 29, 2019 at 2:48 PM Joakim Tjernlund
> > > > >  wrote:
> > > > > > On Mon, 2019-04-29 at 01:58 +0530, Jagan Teki wrote:
> > > > > > > From: Mario Six 
> > > > > > > 
> > > > > > > We do nothing in the loop if the "not empty" event was not 
> > > > > > > detected. To
> > > > > > > simplify the logic, check if this is the case, and skip the 
> > > > > > > execution of
> > > > > > > the loop early to reduce the nesting level and flag checking.
> > > > > > 
> > > > > > Looked at the driver to refresh memory and noticed:
> > > > > > if (charSize == 32) {
> > > > > > /* Advance output buffer by 32 bits */
> > > > > > din += 4;
> > > > > > }
> > > > > > which suggests that only 32 bit char will increase the din ptr so 
> > > > > > does other bitlens
> > > > > > work for reading?
> > > > Yes, It will work. When charSize < 32 in a loop execution, we 
> > > > necessarily also
> > > > have numBlks == 0, since numBlks = DIV_ROUND_UP(bitlen, 32) and 
> > > > charSize =
> > > > (bitlen >= 32 ? 32 : bitlen); in other words: we're at the very end of 
> > > > the data
> > > > to be sent/received and also the final loop execution, so we don't have 
> > > > to
> > > > advance the pointer anymore.
> > > 
> > > Ahh, I see now.
> > > 
> > > But this over use of always 32 bits cause complexity/subtile bugs. The 
> > > driver should use
> > > the requested charsize(wordlen) throughout. As is now you cannot use the 
> > > NF/NE flag as intended or
> > > toggle LSB_FIRST
> > 
> > Look like Joakim has a point here. better we can check the required
> > charsize instead of looking for magic 32 number. What do you say
> > Mario?
> 
> I agree, the driver code could be made more readable and cleaned up a bit, but
> I don't know if it's worth postponing this series for a code readability issue
> that's not a functional bug; I'd say that's an optimization that could be made
> later on.

I would not call it just an optimization but I am fine with applying this patch.

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


Re: [U-Boot] [PATCH v2 10/19] spi: mpc8xxx: Simplify logic a bit

2019-05-02 Thread Joakim Tjernlund
On Thu, 2019-05-02 at 07:31 +0200, Mario Six wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi Jagan and Jocke,
> 
> I'm back from vacation, so here's my answer:
> 
> On Mon, Apr 29, 2019 at 12:41 PM Jagan Teki  
> wrote:
> > + Mario
> > 
> > On Mon, Apr 29, 2019 at 2:48 PM Joakim Tjernlund
> >  wrote:
> > > On Mon, 2019-04-29 at 01:58 +0530, Jagan Teki wrote:
> > > > From: Mario Six 
> > > > 
> > > > We do nothing in the loop if the "not empty" event was not detected. To
> > > > simplify the logic, check if this is the case, and skip the execution of
> > > > the loop early to reduce the nesting level and flag checking.
> > > 
> > > Looked at the driver to refresh memory and noticed:
> > > if (charSize == 32) {
> > > /* Advance output buffer by 32 bits */
> > > din += 4;
> > > }
> > > which suggests that only 32 bit char will increase the din ptr so does 
> > > other bitlens
> > > work for reading?
> Yes, It will work. When charSize < 32 in a loop execution, we necessarily also
> have numBlks == 0, since numBlks = DIV_ROUND_UP(bitlen, 32) and charSize =
> (bitlen >= 32 ? 32 : bitlen); in other words: we're at the very end of the 
> data
> to be sent/received and also the final loop execution, so we don't have to
> advance the pointer anymore.

Ahh, I see now.

But this over use of always 32 bits cause complexity/subtile bugs. The driver 
should use
the requested charsize(wordlen) throughout. As is now you cannot use the NF/NE 
flag as intended or
toggle LSB_FIRST
I think fsl_espi driver is worse though.

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


Re: [U-Boot] [PATCH v2 10/19] spi: mpc8xxx: Simplify logic a bit

2019-04-29 Thread Joakim Tjernlund
On Mon, 2019-04-29 at 01:58 +0530, Jagan Teki wrote:
> 
> From: Mario Six 
> 
> We do nothing in the loop if the "not empty" event was not detected. To
> simplify the logic, check if this is the case, and skip the execution of
> the loop early to reduce the nesting level and flag checking.

Looked at the driver to refresh memory and noticed:
if (charSize == 32) {
/* Advance output buffer by 32 bits */
din += 4;
}
which suggests that only 32 bit char will increase the din ptr so does other 
bitlens
work for reading?

 Jocke

> 
> Signed-off-by: Mario Six 
> ---
>  drivers/spi/mpc8xxx_spi.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/spi/mpc8xxx_spi.c b/drivers/spi/mpc8xxx_spi.c
> index 962ef710f8..a2e698ea17 100644
> --- a/drivers/spi/mpc8xxx_spi.c
> +++ b/drivers/spi/mpc8xxx_spi.c
> @@ -149,25 +149,28 @@ int spi_xfer(struct spi_slave *slave, uint bitlen, 
> const void *dout, void *din,
> bool have_ne = event & SPI_EV_NE;
> bool have_nf = event & SPI_EV_NF;
> 
> -   if (have_ne) {
> -   tmpdin = in_be32(>rx);
> -   setbits_be32(>event, SPI_EV_NE);
> -
> -   *(u32 *)din = (tmpdin << (32 - char_size));
> -   if (char_size == 32) {
> -   /* Advance output buffer by 32 bits */
> -   din += 4;
> -   }
> +   if (!have_ne)
> +   continue;
> +
> +   tmpdin = in_be32(>rx);
> +   setbits_be32(>event, SPI_EV_NE);
> +
> +   *(u32 *)din = (tmpdin << (32 - char_size));
> +   if (char_size == 32) {
> +   /* Advance output buffer by 32 bits */
> +   din += 4;
> }
> +
> /*
>  * Only bail when we've had both NE and NF events.
>  * This will cause timeouts on RO devices, so maybe
>  * in the future put an arbitrary delay after writing
>  * the device.  Arbitrary delays suck, though...
>  */
> -   if (have_ne && have_nf)
> +   if (have_nf)
> break;
> }
> +
> if (tm >= SPI_TIMEOUT)
> debug("*** %s: Time out during SPI transfer\n",
>   __func__);
> --
> 2.18.0.321.gffc6fa0e3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Flistinfo%2Fu-bootdata=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cb423ca475f53471860b308d6cc195be8%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C636920806635383891sdata=PxiqErmkjcpBVL4yBUi2UYiJ5oqtBTI4fCnb4XBTpmE%3Dreserved=0

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


[U-Boot] eMMC boot partition possible with an eMMC 4.2 controller ?

2019-02-05 Thread Joakim Tjernlund
Trying to figure out if it will be possible to boot u-boot from an eMMC boot 
partition using an
eMMC 4.2 controller(eMMC boot part. was introduced in 4.3) ?

I know this might not be the best list to ask this but I have been unable to 
find this out using Google
and I hope there is someone here that knows the answer.

 Jocke

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


Re: [U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

2019-01-10 Thread Joakim Tjernlund
On Wed, 2019-01-09 at 17:39 -0500, Tom Rini wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > Hi Soeren,
> > 
> > On 08/01/19 12:03, Soeren Moch wrote:
> > > Hi Stefano,
> > > 
> > > On 08.01.19 11:24, Stefano Babic wrote:
> > > > Hi Soeren,
> > > > 
> > > > On 08/01/19 11:14, Soeren Moch wrote:
> > > > > Stefano,
> > > > > 
> > > > > can you apply this for v2019.01? This is really a important fix to 
> > > > > avoid
> > > > >  environment and u-boot binary overwriting each other.
> > > > > It is also a small local fix which cannot hurt anybody else.
> > > > I will apply and I send a new PR. This is not the first fix in this
> > > > direction, u-boot becomes pretty large, it is becoming a common problem.
> > > > 
> > > Thank you very much.
> > > 
> > > Yes, "in the good old days (tm)" there was much effort put into not
> > > increasing the binary size for existing boards when adding new features.
> > 
> > Right, fully agree.
> > 
> > > Unfortunately this is not true anymore.
> > 
> > I get in the same trouble with more as one project. A previous rule of
> > thumb was to reserve 512KB to the bootloader because it was pretty
> > unthinkable that bootloader could be larger. Mhmmhhthis remember me
> > someone else who said that 640Kb is enough for everything.
> > 
> > Anyway, as you noted, this is a big problem in field and it makes
> > difficult an upgrade without returning back the device to factory, what
> > nobody wants.
> 
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.
> 
> And I do look at size changes, at least per push to master.  So most of
> the time it comes in "drips and drabs".  Right now I'm going to grow
> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> that's not super interesting, so lets look at v2018.09 to now.  That's
> 1800 bytes.  That's not too bad and looks like it's maybe half bug
> fixes, half working on various frameworks (sure, DM/DT stuff but also
> hash algos.  If we jump back to v2018.01, so more or less a year worth
> of changes, that's 19KiB.  Without trying to break down _everything_
> that's a good bit of EFI and a little bit everywhere else.

If you looking to save a few more bytes you could take a look at my old patch
for handling the env. without a lot of static variables:
  https://patchwork.ozlabs.org/patch/746419/


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


[U-Boot] [PATCH] mpc85xx: Add support for -msingle-pic-base

2018-12-06 Thread Joakim Tjernlund
-msingle-pic-base is a new gcc(from 4.6) option for ppc and
it reduces the size of my u-boot with about 4-5 KB.
While at it, add -fno-jump-tables too to save a
few more bytes.

e5500 core:
size u-boot.bef
   textdata bss dec hex filename
 473043   23772  307104  803919   c444f u-boot.bef
size u-boot.aft
   textdata bss dec hex filename
 453195   23772  307104  784071   bf6c7 u-boot.aft

e500 core:
size u-boot.bef
   textdata bss dec hex filename
 292998   17868   24968  335834   51fda u-boot.bef
size u-boot.aft
   textdata bss dec hex filename
 288002   17868   24968  330838   50c56 u-boot.aft

Signed-off-by: Joakim Tjernlund 
---
 arch/powerpc/cpu/mpc85xx/config.mk | 1 +
 arch/powerpc/cpu/mpc85xx/start.S   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/config.mk 
b/arch/powerpc/cpu/mpc85xx/config.mk
index 44d69add68..7a1d81cf2d 100644
--- a/arch/powerpc/cpu/mpc85xx/config.mk
+++ b/arch/powerpc/cpu/mpc85xx/config.mk
@@ -4,6 +4,7 @@
 # Xianghua Xiao, x.x...@motorola.com
 
 PLATFORM_CPPFLAGS += -Wa,-me500 -msoft-float -mno-string
+PLATFORM_RELFLAGS += -msingle-pic-base -fno-jump-tables
 
 # -mspe=yes is needed to have -mno-spe accepted by a buggy GCC;
 # see "[PATCH,rs6000] make -mno-spe work as expected" on
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 932aa08b27..dbc705388c 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1216,6 +1216,9 @@ _start_cont:
mr  r1,r3   /* Transfer to SP(r1) */
 
GET_GOT
+   /* Needed for -msingle-pic-base */
+   bl  _GLOBAL_OFFSET_TABLE_@local-4
+   mflrr30
 
/* Pass our potential ePAPR device tree pointer to cpu_init_early_f */
mr  r3, r24
-- 
2.18.1

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


[U-Boot] [PATCH] mpc83xx: Add support for -msingle-pic-base

2018-11-28 Thread Joakim Tjernlund
-msingle-pic-base is a new gcc(from 4.6) option for ppc and
it reduces the size of my u-boot with about 4 KB.
While at it, add -fno-jump-tables too to save a
few more bytes.

Signed-off-by: Joakim Tjernlund 
---

 I think all PowerPC's can use this but I have only tested
 83xx so just enable for this cpu for now.

 arch/powerpc/cpu/mpc83xx/config.mk | 1 +
 arch/powerpc/cpu/mpc83xx/start.S   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc83xx/config.mk 
b/arch/powerpc/cpu/mpc83xx/config.mk
index 14870eec4d..a07df4d389 100644
--- a/arch/powerpc/cpu/mpc83xx/config.mk
+++ b/arch/powerpc/cpu/mpc83xx/config.mk
@@ -3,3 +3,4 @@
 # Copyright 2004 Freescale Semiconductor, Inc.
 
 PLATFORM_CPPFLAGS += -DCONFIG_E300 -msoft-float
+PLATFORM_RELFLAGS += -msingle-pic-base -fno-jump-tables
diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S
index a3bacf138c..c00bb31363 100644
--- a/arch/powerpc/cpu/mpc83xx/start.S
+++ b/arch/powerpc/cpu/mpc83xx/start.S
@@ -288,6 +288,9 @@ in_flash:
/*--*/
 
GET_GOT /* initialize GOT access*/
+   /* Needed for -msingle-pic-base */
+   bl  _GLOBAL_OFFSET_TABLE_@local-4
+   mflrr30
 
/* r3: IMMR */
lis r3, CONFIG_SYS_IMMR@h
-- 
2.18.1

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


Re: [U-Boot] [PATCH v2 1/9] powerpc, mpc8xx: clear top of stack

2018-11-21 Thread Joakim Tjernlund
On Wed, 2018-11-21 at 08:51 +, Christophe Leroy wrote:
> 
> Reported-by: Joakim Tjernlund 
> Signed-off-by: Christophe Leroy 

Reviewed-by: Joakim Tjernlund 

Leroy, if you need space, you may want to revive:
 
https://github.com/u-boot/u-boot/commit/39768f7715ed637ef02f49fc7de664cc1aaf14b3#diff-e2f25512eac55747ede53068dd1e
it got reverted as some odd 8xx boards broke. I think these are gone now.

 Jocke
> ---
>  arch/powerpc/cpu/mpc8xx/start.S | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S
> index 8dde4beeea1..b8bdaaec2fa 100644
> --- a/arch/powerpc/cpu/mpc8xx/start.S
> +++ b/arch/powerpc/cpu/mpc8xx/start.S
> @@ -144,9 +144,11 @@ in_flash:
> ori r2, r2, CONFIG_SYS_DER@l
> mtspr   DER, r2
> 
> -   /* set up the stack in internal DPRAM */
> +   /* set up the stack on top of internal DPRAM */
> lis r3, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@h
> ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR + 
> CONFIG_SYS_INIT_RAM_SIZE)@l
> +   stw r0, -4(r3)
> +   stw r0, -8(r3)
> addir1, r3, -8
> 
> bl  board_init_f_alloc_reserve
> --
> 2.13.3
> 
> ___
> 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] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba

2018-10-11 Thread Joakim Tjernlund
On Thu, 2018-10-11 at 16:11 +0200, Dirk Eibach wrote:
> 
> Hello,
> 
> we have a 16 bit value here, so we have to define whether bit0(containin the 
> information for IO0.0) is in the first or the second byte. Since the PCA9555 
> does this encoding little endian, the conversion is allright. 
> 

You used it as some number but this is really just a bunch I/O pins. I haven't 
seen any
endian conversion in the kernel driver, have you? 
This is a bigger question than this driver really, so:

Does IO pins have an endian?

  Jocke

> Cheers
> Dirk
> Am Do., 11. Okt. 2018 um 07:42 Uhr schrieb Heiko Schocher :
> >
> > Hello Joakim,
> >
> > Am 10.10.2018 um 19:34 schrieb Joakim Tjernlund:
> > > This commit broke our pca953x usage(on ppc).
> > >
> > > I wonder why gpio pins here has an endian, its not a number.
> > > If there must be an endian connected with this, should it not
> > > be a cpu_to_be16 instead, which will retain compatibility ?
> >
> > Hmm.. good question, I think you are right. May dirk can do a test?
> > I have no pca953x with 16bit for doing a test.
> >
> > bye,
> > Heiko
> > --
> > DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

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


[U-Boot] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba

2018-10-10 Thread Joakim Tjernlund
This commit broke our pca953x usage(on ppc).

I wonder why gpio pins here has an endian, its not a number.
If there must be an endian connected with this, should it not
be a cpu_to_be16 instead, which will retain compatibility ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] fw_setenv: avoid writing environment when nothing has changed

2018-09-24 Thread Joakim Tjernlund
On Mon, 2018-09-24 at 08:42 +0100, Alex Kiernan wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Wed, Sep 5, 2018 at 8:23 PM Rasmus Villemoes
>  wrote:
> > 
> > In the case where one deletes an already-non-existing variable, or sets
> > a variable to the value it already has, there is no point in writing the
> > environment back, thus reducing wear on the underlying storage
> > device.
> > 
> > Signed-off-by: Rasmus Villemoes 
> 
> If you were running with a redundant env, and you were trying to sync
> both copies, wouldn't you want a non-changing write to happen?

That is a valid point, I have sometimes used this property to make
sure I have a valid env. in both copies.

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


Re: [U-Boot] Fwd: Parallel build is broken

2018-09-05 Thread Joakim Tjernlund
On Tue, 2018-09-04 at 17:43 -0400, Tom Rini wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Tue, Sep 04, 2018 at 09:05:55PM +0300, Andy Shevchenko wrote:
> > On Tue, Sep 4, 2018 at 9:00 PM Tom Rini  wrote:
> > > 
> > > On Tue, Sep 04, 2018 at 07:33:10PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Sep 4, 2018 at 6:47 PM Andy Shevchenko
> > > >  wrote:
> > > > > 
> > > > > On Tue, Sep 4, 2018 at 6:14 PM Tom Rini  wrote:
> > > > > > On Tue, Sep 04, 2018 at 05:50:33PM +0300, Andy Shevchenko wrote:
> > > > > > > On Tue, Sep 4, 2018 at 5:00 PM Tom Rini  
> > > > > > > wrote:
> > > > > > > > On Tue, Sep 04, 2018 at 03:42:05PM +0300, Andy Shevchenko wrote:
> > > > > > > make clean && make edison_defconfig && make -j16
> > > > > > > 
> > > > > > > gcc (Debian 8.2.0-4) 8.2.0
> > > > > > > Copyright (C) 2018 Free Software Foundation, Inc.
> > > > > > > This is free software; see the source for copying conditions.  
> > > > > > > There is NO
> > > > > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A 
> > > > > > > PARTICULAR PURPOSE.
> > > > > > 
> > > > > > I assume this is on Debian/unstable?
> > > > > 
> > > > > testing
> > > > > 
> > > > > >  I can't directly replicate this on
> > > > > > my 24core (Debian/stretch) or 16core(Ubuntu/xenial) machines.  I'll
> > > > > > setup a chroot soon, but since you've said -j64 is fine there too I
> > > > > > suspect you have more cores than I.  This may be something you have 
> > > > > > to
> > > > > > bisect for us if I can't replicate it myself.  Can you confirm how 
> > > > > > many
> > > > > > cores you have?  I might be able to spin something up in Google 
> > > > > > compute.
> > > > > 
> > > > > $ sed -n -e '/cpu cores/ { p; q }' /proc/cpuinfo
> > > > > cpu cores   : 22
> > > > 
> > > > Did few runs (~6) on this machine with -j4, no failures so far.
> > > > Reruning same with -j16 brings failure on ~2-3 iteration.
> > > > 
> > > > It seems the scope can be narrowed to:
> > > > - many cores build system, and
> > > > - Debian testing/unstable toolchain, and/or
> > > > - U-Boot build system
> > > 
> > > I'm pretty sure it's a dependency problem somewhere.  Since this was
> > > working reliably for you recently (right?) and I can't reproduce it and
> > > you can, if you can run a git bisect to figure out what commit is
> > > breaking things, that would be very helpful.  Thanks!
> > 

There was a patch recently to make 4.2.1 to fix some parallel build issue.
No idea if that fix applies to your case though.

   Jocke

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2018-08-02 Thread Joakim Tjernlund
York, did this go anywhere?

 Jocke

On Tue, 2018-02-27 at 19:54 +, York Sun wrote:
> 
> On 02/27/2018 11:52 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-02-27 at 19:30 +, York Sun wrote:
> > > 
> > > On 11/21/2017 10:20 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-11-21 at 18:04 +, York Sun wrote:
> > > > > 
> > > > > 
> > > > > On 11/21/2017 09:52 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-11-21 at 17:45 +, York Sun wrote:
> > > > > > > 
> > > > > > > On 11/21/2017 09:41 AM, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> > > > > > > > > CAUTION: This email originated from outside of the 
> > > > > > > > > organization. Do not click links or open attachments unless 
> > > > > > > > > you recognize the sender and know the content is safe.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > > > > > > > > > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > > > > > > > > > CAUTION: This email originated from outside of the 
> > > > > > > > > > > organization. Do not click links or open attachments 
> > > > > > > > > > > unless you recognize the sender and know the content is 
> > > > > > > > > > > safe.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > > > > > > > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > Most FSL PCIe controllers expects 333 MHz PCI 
> > > > > > > > > > > > > reference clock.
> > > > > > > > > > > > > This clock is derived from the CCB but in many cases 
> > > > > > > > > > > > > the ref.
> > > > > > > > > > > > > clock is not 333 MHz and a divisor needs to be 
> > > > > > > > > > > > > configured.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This adds PEX_CCB_DIV #define which can be defined 
> > > > > > > > > > > > > for each
> > > > > > > > > > > > > type of CPU/platform.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Signed-off-by: Joakim Tjernlund 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > > > > > > > > > >  1 file changed, 6 insertions(+)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/drivers/pci/fsl_pci_init.c 
> > > > > > > > > > > > > b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > > > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct 
> > > > > > > > > > > > > pci_controller *hose, struct fsl_pci_info *pci_info)
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > > > > > > 
> > > > > > > > > > > > > +#ifdef PEX_CCB_DIV
> > > > > > > > > > > > > +/* Configure the PCIE controller core clock 
> > > > > > > > > > > > > ratio */
> > > > > > > > > > > > > +pci_hose_write_config_dwor

Re: [U-Boot] [PATCH] fs: btrfs: Fix wrong comparison in logical to physical mapping

2018-07-04 Thread Joakim Tjernlund
On Wed, 2018-07-04 at 19:10 +0200, Marek Behún wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> The comparison
>   logical > item->logical + item->length
> in btrfs_map_logical_to_physical is wrong and should be instead
>   logical >= item->logical + item->length
> For example, if
>   item->logical = 4096
>   item->length = 4096
> and we are looking for logical = 8192, it is not part of item (item is
> [4096, 8191]). But the comparison is false and we think we have found
> the correct item, although we should be searing in the right subtree.
> 
> This fixes some bugs I encountered.
> 
> Signed-off-by: Marek Behun 
> ---
>  fs/btrfs/chunk-map.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/chunk-map.c b/fs/btrfs/chunk-map.c
> index beb6a4bb92..31619f6241 100644
> --- a/fs/btrfs/chunk-map.c
> +++ b/fs/btrfs/chunk-map.c
> @@ -78,7 +78,7 @@ u64 btrfs_map_logical_to_physical(u64 logical)
> 
> if (item->logical > logical)
> node = node->rb_left;
> -   else if (logical > item->logical + item->length)
> +   else if (logical > item->logical + item->length - 1)
maybe  logical >= item->logical + item->length   ?

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


Re: [U-Boot] [PATCH] Makefile: Ensure we build with -std=gnu11

2018-06-20 Thread Joakim Tjernlund
On Tue, 2018-06-19 at 23:57 -0400, Tom Rini wrote:
> 
> 
> With the move to using at least gcc-6 for many targets we now have C
> code that requires the GNU11 C standard to be used in all cases.

Requiring gcc-6 is a bit much I think, there are lots of cross gcc's out there
that is older. I don't think even the kernel needs gcc-6

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


Re: [U-Boot] [PATCH RFCv2 0/6] Beginning of migration of MPC8xx to DM model

2018-05-04 Thread Joakim Tjernlund
On Fri, 2018-05-04 at 12:33 +0200, Christophe LEROY wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi Mario,
> 
> Le 04/05/2018 à 11:56, Mario Six a écrit :
> > Hi Christophe,
> > 
> > On Fri, May 4, 2018 at 7:20 AM, Christophe LEROY
> >  wrote:
> > > Hello,
> > > 
> > > 
> > > Le 16/03/2018 à 17:32, Christophe Leroy a écrit :
> > > > 
> > > > This serie is the beginning of MPC8xx migration to DM model.
> > > 
> > > 
> > > I didn't get any feedback on this serie. I don't feel totally confortable 
> > > as
> > > it is my first implementation of DM and also the first time powerpc uses 
> > > DT
> > > for U-boot.
> > > 
> > > I'd rather someone look at it.
> > > 
> > 
> > One thing I'm noticing: Are you setting up pre-relocation malloc? Since 
> > MPC8xx
> > is another old powerpc platform, I suspect that the start.S doesn't do it, 
> > and
> > DM needs it to function correctly.
> 
> Yes, I did it with the following patch:
> 
> https://patchwork.ozlabs.org/patch/886980/

Hi 

Had a quick look at that patch and it looks like you lost zeroing the
stack frame (stwu   r0, -4(r1) ...) ?

Also, don't use touch r1 until the stack is ready, otherwise gdb will
try accessing the stack if you single step over this part.

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


Re: [U-Boot] [PATCH v2 00/18] spi: mpc8xxx: DM conversion

2018-04-26 Thread Joakim Tjernlund
On Thu, 2018-04-26 at 11:35 +0530, Jagan Teki wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Thu, Apr 26, 2018 at 11:24 AM, Mario Six  wrote:
> > Hi Jagan,
> > 
> > On Thu, Apr 26, 2018 at 7:30 AM, Jagan Teki  
> > wrote:
> > > On Thu, Apr 19, 2018 at 6:06 PM, Mario Six  wrote:
> > > > This is v2 of a patch series that adds support for DM to the MPC8XXX SPI
> > > > driver, cleans up the driver code, fixes a few minor problems.
> > > > 
> > > > Some TODOs are left over for later, such as proper SPI speed setting,
> > > > and support for SPI mode setting. These would be enhancements to the
> > > > original functionality, and can come later.
> > > > 
> > > > The legacy functionality is removed in this version, so old boards in
> > > > the tree might end up with broken SPI functionality.
> > > > 
> > > > Mario Six (18):
> > > >   spi: mpc8xxx: Use short type names
> > > >   spi: mpc8xxx: Fix comments
> > > >   spi: mpc8xxx: Rename camel-case variables
> > > >   spi: mpc8xxx: Fix space after cast
> > > >   spi: mpc8xxx: Fix function names in strings
> > > >   spi: mpc8xxx: Replace defines with enums
> > > >   spi: mpc8xxx: Use IO accessors
> > > >   spi: mpc8xxx: Simplify if
> > > >   spi: mpc8xxx: Get rid of is_read
> > > >   spi: mpc8xxx: Simplify logic a bit
> > > >   spi: mpc8xxx: Reduce scope of loop variables
> > > >   spi: mpc8xxx: Make code more readable
> > > >   spi: mpc8xxx: Rename variable
> > > >   spi: mpc8xxx: Document LEN setting better
> > > >   spi: mpc8xxx: Re-order transfer setup
> > > >   spi: mpc8xxx: Fix if check
> > > >   spi: mpc8xxx: Use get_timer
> > > >   spi: mpc8xxx: Convert to DM
> > > 
> > > Boards with
> > > - configs/MPC8349EMDS_defconfig
> > > - configs/ids8313_defconfig
> > > 
> > > are using this driver, so Kim, Heiko please convert enable DM_SPI for the 
> > > same.
> > > 
> > > Use below tree for respective changes and update on top of this.
> > > http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next
> > > 
> > 
> > I have a few series in the making that will enable DM on the MPC83xx 
> > platform
> > (I'm doing a respin on the first right now). If there is still interests in 
> > the
> > boards, I could push it to the MPC83xx repository (but mind that the work
> > required per board is quite extensive).
> > 
> > Also, MPC8349EMDS is de facto abandoned, and I don't have access to the
> > hardware, so I can't really maintain it.
> 
> It's up to you, look like this board maintained by Kim is not
> available with freescale e-mail (or may be changed) if none can't
> maintain, it better to drop the board.

we use custom 832x boards so please don't remove 83xx from u-boot.

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2018-02-27 Thread Joakim Tjernlund
On Tue, 2018-02-27 at 19:30 +, York Sun wrote:
> 
> On 11/21/2017 10:20 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-11-21 at 18:04 +, York Sun wrote:
> > > 
> > > 
> > > On 11/21/2017 09:52 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-11-21 at 17:45 +, York Sun wrote:
> > > > > 
> > > > > On 11/21/2017 09:41 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> > > > > > > CAUTION: This email originated from outside of the organization. 
> > > > > > > Do not click links or open attachments unless you recognize the 
> > > > > > > sender and know the content is safe.
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > > > > > > > CAUTION: This email originated from outside of the 
> > > > > > > > > organization. Do not click links or open attachments unless 
> > > > > > > > > you recognize the sender and know the content is safe.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > > > > > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > > > > > > > > > Most FSL PCIe controllers expects 333 MHz PCI reference 
> > > > > > > > > > > clock.
> > > > > > > > > > > This clock is derived from the CCB but in many cases the 
> > > > > > > > > > > ref.
> > > > > > > > > > > clock is not 333 MHz and a divisor needs to be configured.
> > > > > > > > > > > 
> > > > > > > > > > > This adds PEX_CCB_DIV #define which can be defined for 
> > > > > > > > > > > each
> > > > > > > > > > > type of CPU/platform.
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Joakim Tjernlund 
> > > > > > > > > > > <joakim.tjernl...@infinera.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > > > > > > > >  1 file changed, 6 insertions(+)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/pci/fsl_pci_init.c 
> > > > > > > > > > > b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct 
> > > > > > > > > > > pci_controller *hose, struct fsl_pci_info *pci_info)
> > > > > > > > > > > 
> > > > > > > > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > > > > 
> > > > > > > > > > > +#ifdef PEX_CCB_DIV
> > > > > > > > > > > +/* Configure the PCIE controller core clock ratio */
> > > > > > > > > > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > > > > > > > > > +((gd->bus_clk / 100) 
> > > > > > > > > > > *
> > > > > > > > > > > + (16 / PEX_CCB_DIV)) / 
> > > > > > > > > > > 333);
> > > > > > > > > > > +#endif
> > > 
> > > 
> > > 
> > > I took another look at this patch. Would it be appropriate to alway
> > > write to this register with correct clock?
> > 
> > I sure hope so, the docs I have only mentions this reg having a default 
> > value which
> > needs to be changed in most cases I guess.
> > 
> > > 
> > > 
> > > 
> > > > > > > > > > >  block_re

Re: [U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

2018-02-13 Thread Joakim Tjernlund
On Tue, 2018-02-13 at 16:05 +, York Sun wrote:
> 
> On 02/13/2018 04:49 AM, Wolfgang Denk wrote:
> > Dear York,
> > 
> > In message 
> > <vi1pr04mb20785ef7d2578e39c048ee219a...@vi1pr04mb2078.eurprd04.prod.outlook.com>
> >  you wrote:
> > > 
> > > Nobody said anything. Some addresses bounced. And most changes made out
> > > people outside Freescale/NXP are minor changes, except twice the files
> > > were moved during U-Boot structure change. What options do I have?
> > 
> > Ask all people who contributed to that code for their explicit
> > permission.  Legally it is a huge difference between actively
> > confirming approval and not reacting at all.
> > 
> 
> All people (except Freescale and NXP employees) contributed to this code
> are in the CC list. Please give your explicit approval for this license
> change. Thanks.

I approve

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


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-02-07 Thread Joakim Tjernlund
On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 06.02.2018 09:20, Joakim Tjernlund wrote:
> > On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> > 
> > .
> > > > Reviewed-by: Andre Przywara <andre.przyw...@arm.com>
> > > > Reviewed-by: Simon Glass <s...@chromium.org>
> > > > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> > > > ---
> > > >env/env.c | 80 
> > > > +++-
> > > >1 file changed, 50 insertions(+), 30 deletions(-)
> > > > 
> > > > diff --git a/env/env.c b/env/env.c
> > > > index 906f28ee50a1..1182fdb545db 100644
> > > > --- a/env/env.c
> > > > +++ b/env/env.c
> > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum 
> > > > env_location loc)
> > > >return NULL;
> > > >}
> > > > 
> > > > +static enum env_location env_locations[] = {
> > 
> > Don't use static/global variables. They cause a lot of relocation work/size
> > and is less flexible.
> 
> In this specific case, I think this array should be const anyway, would
> that prevent the relocation problems you see?

> 
> > There is no way to #define ENVL_EEPROM to a function
> > when a variable.
> 
> ENVL_EEPROM is an enum value, why would you define it to a function?

I got boards that very similar but differ in where/how env. is stored, like 
different
flash so I need to be able to select at runtime how get my env., I haven't
looked if this particular area is affected but ideally I would like if all
env. related "constants" could be impl. with a function instead.

Also, using static/global vars takes more space than simple assignments in 
code, ideally
everything needed early (before reloc/ in SPL) should avoid relocations to save 
space.

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


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-02-07 Thread Joakim Tjernlund
On Thu, 1970-01-01 at 00:00 +, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Feb 06, 2018 at 08:20:49AM +0000, Joakim Tjernlund wrote:
> > On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:
> > 
> > .
> > > > Reviewed-by: Andre Przywara <andre.przyw...@arm.com>
> > > > Reviewed-by: Simon Glass <s...@chromium.org>
> > > > Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> > > > ---
> > > >   env/env.c | 80 
> > > > +++-
> > > >   1 file changed, 50 insertions(+), 30 deletions(-)
> > > > 
> > > > diff --git a/env/env.c b/env/env.c
> > > > index 906f28ee50a1..1182fdb545db 100644
> > > > --- a/env/env.c
> > > > +++ b/env/env.c
> > > > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum 
> > > > env_location loc)
> > > >   return NULL;
> > > >   }
> > > > 
> > > > +static enum env_location env_locations[] = {
> > 
> > Don't use static/global variables. They cause a lot of relocation work/size
> > and is less flexible. There is no way to #define ENVL_EEPROM to a function 
> > when a variable.
> 
> Is that last sentence truncated?
> 
> Can you elaborate a bit more on what is the source of the relocation
> issues you're mentionning? Is that because of the section it ends up
> in?

Mainly that its adds relocation entries that take up space, more space than 
doing
a simple assignment directly in code.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 09/15] env: Support multiple environments

2018-02-06 Thread Joakim Tjernlund
On Thu, 1970-01-01 at 00:00 +, Simon Goldschmidt wrote:

.
> > Reviewed-by: Andre Przywara 
> > Reviewed-by: Simon Glass 
> > Signed-off-by: Maxime Ripard 
> > ---
> >   env/env.c | 80 +++-
> >   1 file changed, 50 insertions(+), 30 deletions(-)
> > 
> > diff --git a/env/env.c b/env/env.c
> > index 906f28ee50a1..1182fdb545db 100644
> > --- a/env/env.c
> > +++ b/env/env.c
> > @@ -26,6 +26,41 @@ static struct env_driver *_env_driver_lookup(enum 
> > env_location loc)
> >   return NULL;
> >   }
> > 
> > +static enum env_location env_locations[] = {

Don't use static/global variables. They cause a lot of relocation work/size
and is less flexible. There is no way to #define ENVL_EEPROM to a function 
when a variable.

 Jocke

> > +#ifdef CONFIG_ENV_IS_IN_EEPROM
> > + ENVL_EEPROM,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_FAT
> > + ENVL_FAT,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_FLASH
> > + ENVL_FLASH,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_MMC
> > + ENVL_MMC,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_NAND
> > + ENVL_NAND,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_NVRAM
> > + ENVL_NVRAM,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_REMOTE
> > + ENVL_REMOTE,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
> > + ENVL_SPI_FLASH,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_IN_UBI
> > + ENVL_UBI,
> > +#endif
> > +#ifdef CONFIG_ENV_IS_NOWHERE
> > + ENVL_NOWHERE,
> > +#endif
> > +};
> > +
> > +static enum env_location env_load_location = ENVL_UNKNOWN;
> > +
> >   /**
> >* env_get_location() - Returns the best env location for a board
> >* @op: operations performed on the environment
> > @@ -45,36 +80,21 @@ static struct env_driver *_env_driver_lookup(enum 
> > env_location loc)
> >*/
> >   static enum env_location env_get_location(enum env_operation op, int prio)
> >   {
> > - /*
> > -  * We support a single environment, so any environment asked
> > -  * with a priority that is not zero is out of our supported
> > -  * bounds.
> > -  */
> > - if (prio >= 1)
> > - return ENVL_UNKNOWN;
> > -
> > - if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
> > - return ENVL_EEPROM;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
> > - return ENVL_FAT;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
> > - return ENVL_FLASH;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
> > - return ENVL_MMC;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_NAND)
> > - return ENVL_NAND;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_NVRAM)
> > - return ENVL_NVRAM;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_REMOTE)
> > - return ENVL_REMOTE;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)
> > - return ENVL_SPI_FLASH;
> > - else if IS_ENABLED(CONFIG_ENV_IS_IN_UBI)
> > - return ENVL_UBI;
> > - else if IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
> > - return ENVL_NOWHERE;
> > - else
> > - return ENVL_UNKNOWN;
> > + switch (op) {
> > + case ENVOP_GET_CHAR:
> > + case ENVOP_INIT:
> > + case ENVOP_LOAD:
> > + if (prio >= ARRAY_SIZE(env_locations))
> > + return ENVL_UNKNOWN;
> > +
> > + env_load_location = env_locations[prio];
> > + return env_load_location;
> > +
> > + case ENVOP_SAVE:
> > + return env_load_location;
> > + }
> > +
> > + return ENVL_UNKNOWN;
> >   }
> > 
> > 
> 
> ___
> 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] U-Boot 2015 and u-boot-fw-utils 2017.09

2018-01-11 Thread Joakim Tjernlund
On Thu, 1970-01-01 at 00:00 +, Wolfgang Denk wrote:
> 
> Hello,
> 
> In message <2018000422.7957c7f3@jawa> you wrote:
> > 
> > > I am using U-Boot 2015.04, and the new root file system for my
> > > platform includes u-boot-fw-utils 2017.09. I have noticed that
> > > fw_{print,set}env utilities are no longer working.
> > 
> > Strace output would be helpful here
> 
> Definitely.  Ideally both for the old, working, and for the new,
> failing, version.
> 
> > The fw_* utils were a bit reworked around 2017.09 (there were some
> > build breaks of it IIRC), so yes you may see some problems.
> 
> But then, the actual format of the environment data has never been
> changed, so we really need more details.

Speaking of the fw tools, I have always wanted to be able to specify
"whole mtd device" for plain NOR flash in fw_env.config so instead of 
 /dev/mtd1  0x  0x4000  0x4000
One could jsut say 
 /dev/mtd1  0x  0x4000
like one can do for SPI flash. Thoughts ?

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


Re: [U-Boot] [PATCH v2 0/9] reduce the size of the mmc core

2018-01-04 Thread Joakim Tjernlund
On Thu, 2018-01-04 at 15:23 +0100, Jean-Jacques Hiblot wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> This series applies on u-boot/next
> 
> It aims at reducing the size taken by the mmc core in the SPL.
> Recent changes (for which I'm to blame) have bloated the mmc core and have
> broken platforms that were already tight on code space. This is achieved 
> mostly
> by compiling out parts of the initialization process that are not required 
> when
> the SD/MMC write operations are not used.

I have not looked at the code so maybe this off ...

You can save a lot of space/code if you avoid static/global variables.
Instead of
  #define MYSTR "some cool feature"
  static char *mystr = MYSTR;
do
  fun()
  {
 char *mystr = MYSTR;
 ...
  }

Avoid static/global vars at all cost!

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


Re: [U-Boot] U-Boot proper(not SPL) relocate option

2017-11-29 Thread Joakim Tjernlund
On Wed, 2017-11-29 at 19:11 +0900, Masahiro Yamada wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi Simon,
> 
> 
> 2017-11-28 2:13 GMT+09:00 Simon Glass :
> > (Tom - any thoughts about a more expansive cc list on this?)
> > 
> > Hi Masahiro,
> > 
> > On 26 November 2017 at 07:16, Masahiro Yamada
> >  wrote:
> > > 2017-11-26 20:38 GMT+09:00 Simon Glass :
> > > > Hi Philipp,
> > > > 
> > > > On 25 November 2017 at 16:31, Dr. Philipp Tomsich
> > > >  wrote:
> > > > > Hi,
> > > > > 
> > > > > > On 25 Nov 2017, at 23:34, Simon Glass  wrote:
> > > > > > 
> > > > > > +Tom, Masahiro, Philipp
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > On 22 November 2017 at 03:27, Wolfgang Denk  wrote:
> > > > > > > Dear Kever Yang,
> > > > > > > 
> > > > > > > In message  
> > > > > > > you wrote:
> > > > > > > > 
> > > > > > > > I can understand this feature, we always do dram_init_banks() 
> > > > > > > > first,
> > > > > > > > then we relocate to 'known' area, then will be no risk to 
> > > > > > > > access memory.
> > > > > > > > I believe there must be some historical reason for some kind of 
> > > > > > > > device,
> > > > > > > > the relocate feature is a wonderful idea for it.
> > > > > > > 
> > > > > > > This is actuallyu not so much a feature needed to support some
> > > > > > > specific device (in this case much simpler approahces would be
> > > > > > > possible), but to support a whole set of features.  Unfortunately
> > > > > > > these appear to get forgotten / ignored over time.
> > > > > > > 
> > > > > > > > many other SoCs should be similar.
> > > > > > > > - Without relocate we can save many step, some of our customer 
> > > > > > > > really
> > > > > > > > care much about the boot time duration.
> > > > > > > > * no need to relocate everything
> > > > > > > > * no need to copy all the code
> > > > > > > > * no need init the driver more than once
> > > > > > > 
> > > > > > > Please have a look at the README, section "Memory Management".
> > > > > > > The reloaction is not done to any _fixed_ address, but the address
> > > > > > > is actually computed at runtime, depending on a number features
> > > > > > > enabled (at least this is how it used to be - appearently little 
> > > > > > > of
> > > > > > > this is tested on a regular base, so I would not be surprised if
> > > > > > > things are broken today).
> > > > > > > 
> > > > > > > The basic idea was to reserve areas of memory at the top of RAM,
> > > > > > > that would not be initialized / modified by U-Boot and Linux, not
> > > > > > > even across a reset / warm boot.
> > > > > > > 
> > > > > > > This was used for exaple for:
> > > > > > > 
> > > > > > > - pRAM (Protected RAM) which could be used to store all kind of 
> > > > > > > data
> > > > > > >  (for example, using a pramfs [Protected and Persistent RAM
> > > > > > >  Filesystem]) that could be kept across reboots of the OS.
> > > > > > > 
> > > > > > > - shared frame buffer / video memory. U-Boot and Linux would be 
> > > > > > > able
> > > > > > >  to initialize the video memory just once (in U-Boot) and then
> > > > > > >  share it, maybe even across reboots.  especially, this would 
> > > > > > > allow
> > > > > > >  for a very early splash screen that gets passed (flicker free) to
> > > > > > >  Linux until some Linux GUI takes over (much more difficult 
> > > > > > > today).
> > > > > > > 
> > > > > > > - shared log buffer: U-Boot and Linux used to use the same syslog
> > > > > > >  buffer mechanism, so you could share it between U-Boot and Linux.
> > > > > > >  this allows for example to
> > > > > > >  * read the Linux kernel panic messages after reset in U-Boot; 
> > > > > > > this
> > > > > > >is very useful when you bring up a new system and Linux crashes
> > > > > > >before it can display the log buffer on the console
> > > > > > >  * pass U-Boot POST results on to Linux, so the application code
> > > > > > >can read and process these
> > > > > > >  * process the system log of the previous run (especially after a
> > > > > > >panic) in Lunux after it rebootet.
> > > > > > > 
> > > > > > > etc.
> > > > > > > 
> > > > > > > There are a number of such features which require to reserve room 
> > > > > > > at
> > > > > > > the top of RAM, the size of which is calculatedat runtime, often
> > > > > > > depending on user settable environment data.
> > > > > > > 
> > > > > > > All this cannot be done without relocation to a (dynmaically
> > > > > > > computed) target address.
> > > > > > > 
> > > > > > > 
> > > > > > > Yes, the code could be simpler and faster without that - but then,
> > > > > > > you cut off a number of 

Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-11-21 at 18:35 +, York Sun wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 11/21/2017 10:20 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-11-21 at 18:04 +, York Sun wrote:
> > > 
> > > 
> > > On 11/21/2017 09:52 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-11-21 at 17:45 +, York Sun wrote:
> > > > > 
> > > > > On 11/21/2017 09:41 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> > > > > > > CAUTION: This email originated from outside of the organization. 
> > > > > > > Do not click links or open attachments unless you recognize the 
> > > > > > > sender and know the content is safe.
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > > > > > > > CAUTION: This email originated from outside of the 
> > > > > > > > > organization. Do not click links or open attachments unless 
> > > > > > > > > you recognize the sender and know the content is safe.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > > > > > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > > > > > > > > > Most FSL PCIe controllers expects 333 MHz PCI reference 
> > > > > > > > > > > clock.
> > > > > > > > > > > This clock is derived from the CCB but in many cases the 
> > > > > > > > > > > ref.
> > > > > > > > > > > clock is not 333 MHz and a divisor needs to be configured.
> > > > > > > > > > > 
> > > > > > > > > > > This adds PEX_CCB_DIV #define which can be defined for 
> > > > > > > > > > > each
> > > > > > > > > > > type of CPU/platform.
> > > > > > > > > > > 
> > > > > > > > > > > Signed-off-by: Joakim Tjernlund 
> > > > > > > > > > > <joakim.tjernl...@infinera.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > > > > > > > >  1 file changed, 6 insertions(+)
> > > > > > > > > > > 
> > > > > > > > > > > diff --git a/drivers/pci/fsl_pci_init.c 
> > > > > > > > > > > b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct 
> > > > > > > > > > > pci_controller *hose, struct fsl_pci_info *pci_info)
> > > > > > > > > > > 
> > > > > > > > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > > > > 
> > > > > > > > > > > +#ifdef PEX_CCB_DIV
> > > > > > > > > > > +/* Configure the PCIE controller core clock ratio */
> > > > > > > > > > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > > > > > > > > > +((gd->bus_clk / 100) 
> > > > > > > > > > > *
> > > > > > > > > > > + (16 / PEX_CCB_DIV)) / 
> > > > > > > > > > > 333);
> > > > > > > > > > > +#endif
> > > 
> > > 
> > > 
> > > I took another look at this patch. Would it be appropriate to alway
> > > write to this register with correct clock?
> > 
> > I sure hope so, the docs I have only mentions this reg having a default 
> > value which
> > needs to be changed in most cases I guess.
> 
> 
> The only case we don't need to set this register is when the actual
> clock is 333MHz. I wonder why we didn't have a problem so far. Maybe we
> just didn't realize it.

Have you tried higher PCI speeds? I remember a board we had didn't work with 
higher
speeds so we settled for less than max. Don't hav the board handy now.

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-11-21 at 18:04 +, York Sun wrote:
> 
> 
> On 11/21/2017 09:52 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-11-21 at 17:45 +, York Sun wrote:
> > > 
> > > On 11/21/2017 09:41 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> > > > > CAUTION: This email originated from outside of the organization. Do 
> > > > > not click links or open attachments unless you recognize the sender 
> > > > > and know the content is safe.
> > > > > 
> > > > > 
> > > > > On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > > > > > CAUTION: This email originated from outside of the organization. 
> > > > > > > Do not click links or open attachments unless you recognize the 
> > > > > > > sender and know the content is safe.
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > > > > > > > Most FSL PCIe controllers expects 333 MHz PCI reference clock.
> > > > > > > > > This clock is derived from the CCB but in many cases the ref.
> > > > > > > > > clock is not 333 MHz and a divisor needs to be configured.
> > > > > > > > > 
> > > > > > > > > This adds PEX_CCB_DIV #define which can be defined for each
> > > > > > > > > type of CPU/platform.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Joakim Tjernlund 
> > > > > > > > > <joakim.tjernl...@infinera.com>
> > > > > > > > > ---
> > > > > > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > > > > > >  1 file changed, 6 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/drivers/pci/fsl_pci_init.c 
> > > > > > > > > b/drivers/pci/fsl_pci_init.c
> > > > > > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller 
> > > > > > > > > *hose, struct fsl_pci_info *pci_info)
> > > > > > > > > 
> > > > > > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > > 
> > > > > > > > > +#ifdef PEX_CCB_DIV
> > > > > > > > > +/* Configure the PCIE controller core clock ratio */
> > > > > > > > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > > > > > > > +((gd->bus_clk / 100) *
> > > > > > > > > + (16 / PEX_CCB_DIV)) / 333);
> > > > > > > > > +#endif
> 
> 
> 
> I took another look at this patch. Would it be appropriate to alway
> write to this register with correct clock?

I sure hope so, the docs I have only mentions this reg having a default value 
which
needs to be changed in most cases I guess.

> 
> 
> 
> > > > > > > > >  block_rev = in_be32(>block_rev1);
> > > > > > > > >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > > > > >  pi = >pit[2];  /* 0xDC0 */
> > > > > > > > 
> > > > > > > > Ping?
> > > > > > > > 
> > > > > > > >  Jocke
> > > > > > > > 
> > > > > > > 
> > > > > > > I believe Mingkai's last comment was "to add the PCIe clock in 
> > > > > > > gd".
> > > > > > 
> > > > > > Right, I seem to have forgotten to comment on that ...
> > > > > > Why add that complexity/bloat? This is a constant defined by the 
> > > > > > CPU/SOC so
> > > > > > it makes perfect sense to just #define it.
> > > > > > 
> > > > > 
> > > > > I am

Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-11-21 at 17:45 +, York Sun wrote:
> 
> On 11/21/2017 09:41 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > > > CAUTION: This email originated from outside of the organization. Do 
> > > > > not click links or open attachments unless you recognize the sender 
> > > > > and know the content is safe.
> > > > > 
> > > > > 
> > > > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > > > > > Most FSL PCIe controllers expects 333 MHz PCI reference clock.
> > > > > > > This clock is derived from the CCB but in many cases the ref.
> > > > > > > clock is not 333 MHz and a divisor needs to be configured.
> > > > > > > 
> > > > > > > This adds PEX_CCB_DIV #define which can be defined for each
> > > > > > > type of CPU/platform.
> > > > > > > 
> > > > > > > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > > > > ---
> > > > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > > > >  1 file changed, 6 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/drivers/pci/fsl_pci_init.c 
> > > > > > > b/drivers/pci/fsl_pci_init.c
> > > > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller 
> > > > > > > *hose, struct fsl_pci_info *pci_info)
> > > > > > > 
> > > > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > 
> > > > > > > +#ifdef PEX_CCB_DIV
> > > > > > > +/* Configure the PCIE controller core clock ratio */
> > > > > > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > > > > > +((gd->bus_clk / 100) *
> > > > > > > + (16 / PEX_CCB_DIV)) / 333);
> > > > > > > +#endif
> > > > > > >  block_rev = in_be32(>block_rev1);
> > > > > > >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > > >  pi = >pit[2];  /* 0xDC0 */
> > > > > > 
> > > > > > Ping?
> > > > > > 
> > > > > >  Jocke
> > > > > > 
> > > > > 
> > > > > I believe Mingkai's last comment was "to add the PCIe clock in gd".
> > > > 
> > > > Right, I seem to have forgotten to comment on that ...
> > > > Why add that complexity/bloat? This is a constant defined by the 
> > > > CPU/SOC so
> > > > it makes perfect sense to just #define it.
> > > > 
> > > 
> > > I am leaning to agree with you. The clock is either CCB clock, or CCB/2.
> > > Would it be better if you use a Kconfig option and select the divisor by
> > > SoC?
> > 
> > No, this is not something that needs Kconfig, just add the PEX_CCB_DIV 
> > #define
> > in relevant PPC CPU, like in config_mpc85xx.h
> > 
> 
> So what should be in Kconfig, and what shouldn't? This is per SoC macro.
> Sounds like CONFIG_SYS_ in old days.

I must confess, I am not up to date with Kconfig stuff. I based my suggestion on
what already exists in config_mpc85xx.h:
#elif defined(CONFIG_PPC_T1040) || defined(CONFIG_PPC_T1042) ||\
defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#define CONFIG_E5500
#define CONFIG_FSL_CORENET  /* Freescale CoreNet platform */
#define CONFIG_SYS_FSL_QORIQ_CHASSIS2   /* Freescale Chassis generation 2 */
#define CONFIG_SYS_FSL_CORES_PER_CLUSTER 1
#define CONFIG_SYS_FSL_QMAN_V3  /* QMAN version 3 */
#ifdef CONFIG_SYS_FSL_DDR4
#define CONFIG_SYS_FSL_DDRC_GEN4
#endif
#if defined(CONFIG_PPC_T1040) || defined(CONFIG_PPC_T1042)
#define CONFIG_MAX_CPUS 4
#elif defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
#define CONFIG_MAX_CPUS 2
#endif
#define CONFIG_SYS_FSL_NUM_CC_PLLS  2
#define CONFIG_SYS_FSL_CLUSTER_CLOCKS   { 1, 1, 1, 1 }
#define CONFIG_SYS_FSL_NUM_LAWS 16
#define CONFIG_SYS_FSL_SRDS_1
#define CONFIG_SYS_FSL_SEC_COMPAT   5
#define CONFIG_SYS_NUM_FMAN 1
#define CONFIG_SYS_NUM_FM1_DTSEC5

etc.

Seems like a good place to put another CPU constant.

Anyhow, that patch stands of its own I think. Where to put all constants 
is another patch for NXP.

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-11-21 at 17:32 +, York Sun wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 11/21/2017 09:29 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > > > Most FSL PCIe controllers expects 333 MHz PCI reference clock.
> > > > > This clock is derived from the CCB but in many cases the ref.
> > > > > clock is not 333 MHz and a divisor needs to be configured.
> > > > > 
> > > > > This adds PEX_CCB_DIV #define which can be defined for each
> > > > > type of CPU/platform.
> > > > > 
> > > > > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > > > ---
> > > > >  drivers/pci/fsl_pci_init.c | 6 ++
> > > > >  1 file changed, 6 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> > > > > index 52792dcd59..4d00b3f26c 100644
> > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller *hose, 
> > > > > struct fsl_pci_info *pci_info)
> > > > > 
> > > > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > 
> > > > > +#ifdef PEX_CCB_DIV
> > > > > +/* Configure the PCIE controller core clock ratio */
> > > > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > > > +((gd->bus_clk / 100) *
> > > > > + (16 / PEX_CCB_DIV)) / 333);
> > > > > +#endif
> > > > >  block_rev = in_be32(>block_rev1);
> > > > >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > >  pi = >pit[2];  /* 0xDC0 */
> > > > 
> > > > Ping?
> > > > 
> > > >  Jocke
> > > > 
> > > 
> > > I believe Mingkai's last comment was "to add the PCIe clock in gd".
> > 
> > Right, I seem to have forgotten to comment on that ...
> > Why add that complexity/bloat? This is a constant defined by the CPU/SOC so
> > it makes perfect sense to just #define it.
> > 
> 
> I am leaning to agree with you. The clock is either CCB clock, or CCB/2.
> Would it be better if you use a Kconfig option and select the divisor by
> SoC?

No, this is not something that needs Kconfig, just add the PEX_CCB_DIV #define
in relevant PPC CPU, like in config_mpc85xx.h 

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-11-21 at 17:23 +, York Sun wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 11/21/2017 09:18 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> > > Most FSL PCIe controllers expects 333 MHz PCI reference clock.
> > > This clock is derived from the CCB but in many cases the ref.
> > > clock is not 333 MHz and a divisor needs to be configured.
> > > 
> > > This adds PEX_CCB_DIV #define which can be defined for each
> > > type of CPU/platform.
> > > 
> > > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > > ---
> > >  drivers/pci/fsl_pci_init.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> > > index 52792dcd59..4d00b3f26c 100644
> > > --- a/drivers/pci/fsl_pci_init.c
> > > +++ b/drivers/pci/fsl_pci_init.c
> > > @@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller *hose, 
> > > struct fsl_pci_info *pci_info)
> > > 
> > >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > 
> > > +#ifdef PEX_CCB_DIV
> > > +/* Configure the PCIE controller core clock ratio */
> > > +pci_hose_write_config_dword(hose, dev, 0x440,
> > > +((gd->bus_clk / 100) *
> > > + (16 / PEX_CCB_DIV)) / 333);
> > > +#endif
> > >  block_rev = in_be32(>block_rev1);
> > >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > >  pi = >pit[2];  /* 0xDC0 */
> > 
> > Ping?
> > 
> >  Jocke
> > 
> 
> I believe Mingkai's last comment was "to add the PCIe clock in gd".

Right, I seem to have forgotten to comment on that ...
Why add that complexity/bloat? This is a constant defined by the CPU/SOC so
it makes perfect sense to just #define it.

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


Re: [U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-11-21 Thread Joakim Tjernlund
On Tue, 2017-09-12 at 19:56 +0200, Joakim Tjernlund wrote:
> Most FSL PCIe controllers expects 333 MHz PCI reference clock.
> This clock is derived from the CCB but in many cases the ref.
> clock is not 333 MHz and a divisor needs to be configured.
> 
> This adds PEX_CCB_DIV #define which can be defined for each
> type of CPU/platform.
> 
> Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> ---
>  drivers/pci/fsl_pci_init.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> index 52792dcd59..4d00b3f26c 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller *hose, struct 
> fsl_pci_info *pci_info)
>  
>   pci_setup_indirect(hose, cfg_addr, cfg_data);
>  
> +#ifdef PEX_CCB_DIV
> + /* Configure the PCIE controller core clock ratio */
> + pci_hose_write_config_dword(hose, dev, 0x440,
> + ((gd->bus_clk / 100) *
> +  (16 / PEX_CCB_DIV)) / 333);
> +#endif
>   block_rev = in_be32(>block_rev1);
>   if (PEX_IP_BLK_REV_2_2 <= block_rev) {
>   pi = >pit[2];  /* 0xDC0 */

Ping? 

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


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-11-08 Thread Joakim Tjernlund
On Wed, 2017-11-08 at 21:05 +, York Sun wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On 10/22/2017 07:39 PM, Xiaowei Bao wrote:
> > 
> > -Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Friday, October 20, 2017 9:13 PM
> > To: w...@denx.de; Mingkai Hu <mingkai...@nxp.com>; 
> > tony.obr...@alliedtelesis.co.nz; u-boot@lists.denx.de; Z.q. Hou 
> > <zhiqiang@nxp.com>; York Sun <york@nxp.com>; Xiaowei Bao 
> > <xiaowei@nxp.com>; hamish.mar...@alliedtelesis.co.nz; M.h. Lian 
> > <minghuan.l...@nxp.com>
> > Subject: Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state 
> > judgement more specific
> > 
> > On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > For some special reset times for longer pcie devices, the pcie device
> > > may on polling compliance state, the RC considers the pcie device is
> > > link up, but the pcie device is not link up, only the L0 state is link
> > > up state.
> > > 
> > > Signed-off-by: Bao Xiaowei <xiaowei@nxp.com>
> > > ---
> > >  arch/powerpc/include/asm/fsl_pci.h |  2 ++
> > >  drivers/pci/fsl_pci_init.c | 10 ++
> > >  2 files changed, 8 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/arch/powerpc/include/asm/fsl_pci.h
> > > b/arch/powerpc/include/asm/fsl_pci.h
> > > index 70a5461..323b182 100644
> > > --- a/arch/powerpc/include/asm/fsl_pci.h
> > > +++ b/arch/powerpc/include/asm/fsl_pci.h
> > > @@ -25,6 +25,8 @@
> > >  #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State 
> > > Machine */
> > >  #define PCI_LTSSM_L0   0x16/* L0 state */
> > >  #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
> > > +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
> > > +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */
> > > 
> > >  int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
> > > int fsl_is_pci_agent(struct pci_controller *hose); diff --git
> > > a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c index
> > > be57e53..9b5f386 100644
> > > --- a/drivers/pci/fsl_pci_init.c
> > > +++ b/drivers/pci/fsl_pci_init.c
> > > @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller 
> > > *hose,
> > > pci_ltssm_l0 = PCI_LTSSM_L0;
> > > 
> > > ltssm = fsl_get_ltssm(hose, pci_info);
> > > -
> > > -   if (ltssm == pci_ltssm_l0) {
> > > +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> > > +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> > > +   enabled = 0;
> > > +   } else if (ltssm == pci_ltssm_l0) {
> > > enabled = 1;
> > > } else {
> > > -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
> > > +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
> > > ltssm = fsl_get_ltssm(hose, pci_info);
> > > udelay(1000);
> > 
> > Do you really need this long loop here ? It causes a long delay in case the 
> > PCIe device is in permanent polling state. Our device is in polling state 
> > until clocks is configured and that will be done from user space in Linux
> > 
> > Yes, if the pcie device is in permanent polling state, it will take 
> > probably 100ms delay, but this case is occur very few special devices, if 
> > we want to use the pcie device in uboot, we have to wait the device link up 
> > state is ok, so need some time to wait the pcie device ready. if the pcie 
> > slot have no device, the function will return at once, will not bring delay.
> 
> Joakim,
> 
> Are we OK with this change? Can you test it to make sure no negative
> impact on your boards?

Not really happy, what device needs 100 ms extra to exit polling state? 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] Powerpc: pcie: Make pcie link state judgement more specific

2017-10-20 Thread Joakim Tjernlund
On Fri, 2017-10-20 at 18:16 +0800, Bao Xiaowei wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> For some special reset times for longer pcie devices, the pcie device
> may on polling compliance state, the RC considers the pcie device is
> link up, but the pcie device is not link up, only the L0 state is link
> up state.
> 
> Signed-off-by: Bao Xiaowei 
> ---
>  arch/powerpc/include/asm/fsl_pci.h |  2 ++
>  drivers/pci/fsl_pci_init.c | 10 ++
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/fsl_pci.h 
> b/arch/powerpc/include/asm/fsl_pci.h
> index 70a5461..323b182 100644
> --- a/arch/powerpc/include/asm/fsl_pci.h
> +++ b/arch/powerpc/include/asm/fsl_pci.h
> @@ -25,6 +25,8 @@
>  #define PCI_LTSSM  0x404   /* PCIe Link Training, Status State Machine */
>  #define PCI_LTSSM_L0   0x16/* L0 state */
>  #define PCI_LTSSM_L0_PEX_REV3  0x11/* L0 state for pex rev3*/
> +#define LTSSM_PCIE_DETECT_QUIET0x00/* Detect state */
> +#define LTSSM_PCIE_DETECT_ACTIVE   0x01/* Detect state */
> 
>  int fsl_setup_hose(struct pci_controller *hose, unsigned long addr);
>  int fsl_is_pci_agent(struct pci_controller *hose);
> diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
> index be57e53..9b5f386 100644
> --- a/drivers/pci/fsl_pci_init.c
> +++ b/drivers/pci/fsl_pci_init.c
> @@ -335,15 +335,17 @@ static int fsl_pci_link_up(struct pci_controller *hose,
> pci_ltssm_l0 = PCI_LTSSM_L0;
> 
> ltssm = fsl_get_ltssm(hose, pci_info);
> -
> -   if (ltssm == pci_ltssm_l0) {
> +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> +   enabled = 0;
> +   } else if (ltssm == pci_ltssm_l0) {
> enabled = 1;
> } else {
> -   for (i = 0; i < 100 && ltssm < pci_ltssm_l0; i++) {
> +   for (i = 0; i < 100 && ltssm != pci_ltssm_l0; i++) {
> ltssm = fsl_get_ltssm(hose, pci_info);
> udelay(1000);
Do you really need this long loop here ? It causes a long delay in case the 
PCIe device
is in permanent polling
state. Our device is in polling state until clocks is configured
and that will be done from user space in Linux

> }
> -   enabled = ltssm >= pci_ltssm_l0;
> +   enabled = (ltssm == pci_ltssm_l0) ? 1 : 0;
> }
> 
> return enabled;
> --
> 2.7.4
> 
> ___
> 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


[U-Boot] [PATCH] FSL PCI: Configure PCIe reference ratio

2017-09-12 Thread Joakim Tjernlund
Most FSL PCIe controllers expects 333 MHz PCI reference clock.
This clock is derived from the CCB but in many cases the ref.
clock is not 333 MHz and a divisor needs to be configured.

This adds PEX_CCB_DIV #define which can be defined for each
type of CPU/platform.

Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
---
 drivers/pci/fsl_pci_init.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 52792dcd59..4d00b3f26c 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -322,6 +322,12 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 
pci_setup_indirect(hose, cfg_addr, cfg_data);
 
+#ifdef PEX_CCB_DIV
+   /* Configure the PCIE controller core clock ratio */
+   pci_hose_write_config_dword(hose, dev, 0x440,
+   ((gd->bus_clk / 100) *
+(16 / PEX_CCB_DIV)) / 333);
+#endif
block_rev = in_be32(>block_rev1);
if (PEX_IP_BLK_REV_2_2 <= block_rev) {
pi = >pit[2];  /* 0xDC0 */
-- 
2.13.5

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


Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-09-07 Thread Joakim Tjernlund
On Thu, 2017-09-07 at 06:45 +, Mingkai Hu wrote:
> > -Original Message-
> > From: Mingkai Hu
> > Sent: Wednesday, September 06, 2017 5:37 PM
> > To: 'Joakim Tjernlund' <joakim.tjernl...@infinera.com>; Roy Zang
> > <roy.z...@nxp.com>; York Sun <york@nxp.com>
> > Cc: u-boot@lists.denx.de
> > Subject: RE: setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?
> > 
> > 
> > 
> > > -Original Message-
> > > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > > Sent: Tuesday, September 05, 2017 8:45 PM
> > > To: Mingkai Hu <mingkai...@nxp.com>; Roy Zang <roy.z...@nxp.com>;
> > 
> > York
> > > Sun <york@nxp.com>
> > > Cc: u-boot@lists.denx.de
> > > Subject: Re: setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?
> > > 
> > > On Wed, 2017-08-30 at 15:25 +, York Sun wrote:
> > > > On 08/30/2017 06:05 AM, Joakim Tjernlund wrote:
> > > > > On Tue, 2017-08-29 at 17:33 +, York Sun wrote:
> > > > > > +Roy Zang to comment on PCIe clock source
> > > > > > 
> > > > > > On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> > > > > > > On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> > > > > > > > On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > > > > > > > > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > > > > > > > > As we are looking at PCI stuff ATM I would like to ask
> > > > > > > > > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is
> > > > > > > > > > setup at all for E500 but I THINK this is required.
> > > > > > > > > > 
> > > > > > > > > > In 83xx one do:
> > > > > > > > > > get_clocks();
> > > > > > > > > > /* Configure the PCIE controller core clock ratio */
> > > > > > > > > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > > > > > > > > 
> > > > > > > > > A bit strange with out_le32 instead of out_be32 ?
> > > > > > > > > 
> > > > > > > > > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk) /
> > > > > > > > > > 100) * 16) / 333); udelay(100);
> > > > > > > > > > 
> > > > > > > > > > Any clues?
> > > > > > > > > > 
> > > > > > > > > > Jocke
> > > > > > > > > 
> > > > > > > > > Seems like only 83xx is setting this parameter.
> > > > > > > > > 
> > > > > > > > > Anyhow, I put together this patch:
> > > > > > > > > 
> > > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > > @@ -322,6 +322,10 @@ void fsl_pci_init(struct
> > > > > > > > > pci_controller *hose, struct fsl_pci_info *pci_info)
> > > > > > > > > 
> > > > > > > > >pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > > 
> > > > > > > > > +   /* Configure the PCIE controller core clock ratio */
> > > > > > > > > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd-
> > > > 
> > > > bus_clk / 3) * 16);
> > > > > > > > > +   /* udelay(100) needed here ?*/
> > > > > > > > > +
> > > > > > > > >block_rev = in_be32(>block_rev1);
> > > > > > > > >if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > > > > >pi = >pit[2];  /* 0xDC0 */
> > > > > > > > > 
> > > > > > > > > Any chance this will work for all supported FSL PCIe 
> > > > > > > > > controllers?
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Jocke,
> > > > > > > > 
> > > > > > > > You don't need to program this register if the actual PCIe
> > > > > > > > 

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-09-06 Thread Joakim Tjernlund
On Wed, 2017-09-06 at 09:36 +, Mingkai Hu wrote:
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Tuesday, September 05, 2017 8:45 PM
> > To: Mingkai Hu <mingkai...@nxp.com>; Roy Zang <roy.z...@nxp.com>;
> > York Sun <york@nxp.com>
> > Cc: u-boot@lists.denx.de
> > Subject: Re: setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?
> > 
> > On Wed, 2017-08-30 at 15:25 +, York Sun wrote:
> > > On 08/30/2017 06:05 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-08-29 at 17:33 +, York Sun wrote:
> > > > > +Roy Zang to comment on PCIe clock source
> > > > > 
> > > > > On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> > > > > > > On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > > > > > > > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > > > > > > > As we are looking at PCI stuff ATM I would like to ask
> > > > > > > > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is
> > > > > > > > > setup at all for E500 but I THINK this is required.
> > > > > > > > > 
> > > > > > > > > In 83xx one do:
> > > > > > > > > get_clocks();
> > > > > > > > > /* Configure the PCIE controller core clock ratio */
> > > > > > > > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > > > > > > > 
> > > > > > > > A bit strange with out_le32 instead of out_be32 ?
> > > > > > > > 
> > > > > > > > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk) /
> > > > > > > > > 100) * 16) / 333); udelay(100);
> > > > > > > > > 
> > > > > > > > > Any clues?
> > > > > > > > > 
> > > > > > > > > Jocke
> > > > > > > > 
> > > > > > > > Seems like only 83xx is setting this parameter.
> > > > > > > > 
> > > > > > > > Anyhow, I put together this patch:
> > > > > > > > 
> > > > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > > > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller
> > > > > > > > *hose, struct fsl_pci_info *pci_info)
> > > > > > > > 
> > > > > > > >pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > > > 
> > > > > > > > +   /* Configure the PCIE controller core clock ratio */
> > > > > > > > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd-
> > > 
> > > bus_clk / 3) * 16);
> > > > > > > > +   /* udelay(100) needed here ?*/
> > > > > > > > +
> > > > > > > >block_rev = in_be32(>block_rev1);
> > > > > > > >if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > > > >pi = >pit[2];  /* 0xDC0 */
> > > > > > > > 
> > > > > > > > Any chance this will work for all supported FSL PCIe 
> > > > > > > > controllers?
> > > > > > > > 
> > > > > > > 
> > > > > > > Jocke,
> > > > > > > 
> > > > > > > You don't need to program this register if the actual PCIe
> > > > > > > clock is the same as default. Since SerDes reference clock has
> > > > > > > to be 100MHz for PCIe protocol, my guess is the PCIe clock is
> > > > > > > always correct. The bus_clk you are referring is not the PCIe
> > > > > > > clock. Again, I am not a PCIe expert, I could be wrong. Since
> > > > > > > PCIe (SerDes) has been working on multiple platforms, I guess the
> > 
> > clock is correct.
> > > > > > 
> > > > > > I don't think so. Here is what T1042 says about this:
> > > > > > 
> > > > > > The PCI Express controller clock frequency is one-half the platform
> > 
> > clo

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-09-05 Thread Joakim Tjernlund
On Wed, 2017-08-30 at 15:25 +, York Sun wrote:
> On 08/30/2017 06:05 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-08-29 at 17:33 +, York Sun wrote:
> > > +Roy Zang to comment on PCIe clock source
> > > 
> > > On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> > > > > On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > > > > > As we are looking at PCI stuff ATM I would like to ask
> > > > > > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> > > > > > > at all for E500 but I THINK this is required.
> > > > > > > 
> > > > > > > In 83xx one do:
> > > > > > > get_clocks();
> > > > > > > /* Configure the PCIE controller core clock ratio */
> > > > > > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > > > > > 
> > > > > > A bit strange with out_le32 instead of out_be32 ?
> > > > > > 
> > > > > > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> > > > > > > / 100) * 16) / 333);
> > > > > > > udelay(100);
> > > > > > > 
> > > > > > > Any clues?
> > > > > > > 
> > > > > > > Jocke
> > > > > > 
> > > > > > Seems like only 83xx is setting this parameter.
> > > > > > 
> > > > > > Anyhow, I put together this patch:
> > > > > > 
> > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, 
> > > > > > struct fsl_pci_info *pci_info)
> > > > > > 
> > > > > >pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > 
> > > > > > +   /* Configure the PCIE controller core clock ratio */
> > > > > > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk 
> > > > > > / 3) * 16);
> > > > > > +   /* udelay(100) needed here ?*/
> > > > > > +
> > > > > >block_rev = in_be32(>block_rev1);
> > > > > >if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > >pi = >pit[2];  /* 0xDC0 */
> > > > > > 
> > > > > > Any chance this will work for all supported FSL PCIe controllers?
> > > > > > 
> > > > > 
> > > > > Jocke,
> > > > > 
> > > > > You don't need to program this register if the actual PCIe clock is 
> > > > > the
> > > > > same as default. Since SerDes reference clock has to be 100MHz for 
> > > > > PCIe
> > > > > protocol, my guess is the PCIe clock is always correct. The bus_clk 
> > > > > you
> > > > > are referring is not the PCIe clock. Again, I am not a PCIe expert, I
> > > > > could be wrong. Since PCIe (SerDes) has been working on multiple
> > > > > platforms, I guess the clock is correct.
> > > > 
> > > > I don't think so. Here is what T1042 says about this:
> > > > 
> > > > The PCI Express controller clock frequency is one-half the platform 
> > > > clock frequency.
> > > > 
> > > > The PCI Express controller core clock ratio register is used to program 
> > > > the ratio of the
> > > > actual PCI Express controller clock frequency to the default controller 
> > > > core frequency
> > > > ( 333 MHz ). This is required only when a PCI Express controller clock 
> > > > frequency other
> > > > than the default 333 MHz has to be used.
> > > > As an example of programming PEX_GCLK_RATIO, consider the case where 
> > > > the actual
> > > > PCI Express controller clock is 250 MHz, the ratio of the actual clock 
> > > > to the default clock
> > > > ( 333 MHz) is 3:4. that is, the default core clock has to be multiplied 
> > > > by the ratio (3/4,
> > > > which is equivalent to 12/16). So the register has to be programmed 
> > > > with the decimal
>

Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-09-05 Thread Joakim Tjernlund
On Mon, 2017-08-28 at 17:14 +, York Sun wrote:
> +Xiaowei
> 
> On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> > On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
> > > On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> > > > FSL PCIe controller drivers before REV 3 has this test for link up:
> > > > enabled = ltssm >= PCI_LTSSM_L0;
> > > > 
> > > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when 
> > > > non ready
> > > > for PCI transaktions. When FSL PCIe controller tries to access this 
> > > > device, it
> > > > hangs forever.
> > > > 
> > > > Is LTSSM=0x51 really a "legal" state for link up?
> > > > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
> > > > 
> > > >Jocke
> > > > 
> > > > BTW, the same test is valid in Linux too.
> > > > 
> > > 
> > > Jocke,
> > > 
> > > I am not an expert on PCIe. Please if this thread is helpful,
> > 
> > Me neither .. :)
> > >   
> > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D=0.
> > 
> > It mentions polling compliance but this driver already tests for:
> > if (ltssm < LTSSM_PCIE_L0)
> > return 0;
> > return 1;
> > 
> > It just adds some delay if the device is in Polling Compliance to see if 
> > that
> > changes to L0.
> > Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I 
> > suspect
> > the ltssm >= L0 is bogus.
> > 
> 
> Xiaowei, can you comment?
> 
> York

Ping?
Should I just send a patch ?

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


Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-08-30 Thread Joakim Tjernlund
On Wed, 2017-08-30 at 15:25 +, York Sun wrote:
> On 08/30/2017 06:05 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-08-29 at 17:33 +, York Sun wrote:
> > > +Roy Zang to comment on PCIe clock source
> > > 
> > > On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> > > > > On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > > > > > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > > > > > As we are looking at PCI stuff ATM I would like to ask
> > > > > > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> > > > > > > at all for E500 but I THINK this is required.
> > > > > > > 
> > > > > > > In 83xx one do:
> > > > > > > get_clocks();
> > > > > > > /* Configure the PCIE controller core clock ratio */
> > > > > > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > > > > > 
> > > > > > A bit strange with out_le32 instead of out_be32 ?
> > > > > > 
> > > > > > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> > > > > > > / 100) * 16) / 333);
> > > > > > > udelay(100);
> > > > > > > 
> > > > > > > Any clues?
> > > > > > > 
> > > > > > > Jocke
> > > > > > 
> > > > > > Seems like only 83xx is setting this parameter.
> > > > > > 
> > > > > > Anyhow, I put together this patch:
> > > > > > 
> > > > > > --- a/drivers/pci/fsl_pci_init.c
> > > > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > > > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, 
> > > > > > struct fsl_pci_info *pci_info)
> > > > > > 
> > > > > >pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > > > > 
> > > > > > +   /* Configure the PCIE controller core clock ratio */
> > > > > > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk 
> > > > > > / 3) * 16);
> > > > > > +   /* udelay(100) needed here ?*/
> > > > > > +
> > > > > >block_rev = in_be32(>block_rev1);
> > > > > >if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > > > >pi = >pit[2];  /* 0xDC0 */
> > > > > > 
> > > > > > Any chance this will work for all supported FSL PCIe controllers?
> > > > > > 
> > > > > 
> > > > > Jocke,
> > > > > 
> > > > > You don't need to program this register if the actual PCIe clock is 
> > > > > the
> > > > > same as default. Since SerDes reference clock has to be 100MHz for 
> > > > > PCIe
> > > > > protocol, my guess is the PCIe clock is always correct. The bus_clk 
> > > > > you
> > > > > are referring is not the PCIe clock. Again, I am not a PCIe expert, I
> > > > > could be wrong. Since PCIe (SerDes) has been working on multiple
> > > > > platforms, I guess the clock is correct.
> > > > 
> > > > I don't think so. Here is what T1042 says about this:
> > > > 
> > > > The PCI Express controller clock frequency is one-half the platform 
> > > > clock frequency.
> > > > 
> > > > The PCI Express controller core clock ratio register is used to program 
> > > > the ratio of the
> > > > actual PCI Express controller clock frequency to the default controller 
> > > > core frequency
> > > > ( 333 MHz ). This is required only when a PCI Express controller clock 
> > > > frequency other
> > > > than the default 333 MHz has to be used.
> > > > As an example of programming PEX_GCLK_RATIO, consider the case where 
> > > > the actual
> > > > PCI Express controller clock is 250 MHz, the ratio of the actual clock 
> > > > to the default clock
> > > > ( 333 MHz) is 3:4. that is, the default core clock has to be multiplied 
> > > > by the ratio (3/4,
> > > > which is equivalent to 12/16). So the register has to be programmed 
> > > > with the decimal
>

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-08-30 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 17:33 +, York Sun wrote:
> +Roy Zang to comment on PCIe clock source
> 
> On 08/29/2017 10:06 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> > > On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > > > As we are looking at PCI stuff ATM I would like to ask
> > > > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> > > > > at all for E500 but I THINK this is required.
> > > > > 
> > > > > In 83xx one do:
> > > > > get_clocks();
> > > > > /* Configure the PCIE controller core clock ratio */
> > > > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > > > 
> > > > A bit strange with out_le32 instead of out_be32 ?
> > > > 
> > > > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> > > > > / 100) * 16) / 333);
> > > > > udelay(100);
> > > > > 
> > > > > Any clues?
> > > > > 
> > > > >Jocke
> > > > 
> > > > Seems like only 83xx is setting this parameter.
> > > > 
> > > > Anyhow, I put together this patch:
> > > > 
> > > > --- a/drivers/pci/fsl_pci_init.c
> > > > +++ b/drivers/pci/fsl_pci_init.c
> > > > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, 
> > > > struct fsl_pci_info *pci_info)
> > > >
> > > >   pci_setup_indirect(hose, cfg_addr, cfg_data);
> > > >
> > > > +   /* Configure the PCIE controller core clock ratio */
> > > > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 
> > > > 3) * 16);
> > > > +   /* udelay(100) needed here ?*/
> > > > +
> > > >   block_rev = in_be32(>block_rev1);
> > > >   if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> > > >   pi = >pit[2];  /* 0xDC0 */
> > > > 
> > > > Any chance this will work for all supported FSL PCIe controllers?
> > > > 
> > > 
> > > Jocke,
> > > 
> > > You don't need to program this register if the actual PCIe clock is the
> > > same as default. Since SerDes reference clock has to be 100MHz for PCIe
> > > protocol, my guess is the PCIe clock is always correct. The bus_clk you
> > > are referring is not the PCIe clock. Again, I am not a PCIe expert, I
> > > could be wrong. Since PCIe (SerDes) has been working on multiple
> > > platforms, I guess the clock is correct.
> > 
> > I don't think so. Here is what T1042 says about this:
> > 
> > The PCI Express controller clock frequency is one-half the platform clock 
> > frequency.
> > 
> > The PCI Express controller core clock ratio register is used to program the 
> > ratio of the
> > actual PCI Express controller clock frequency to the default controller 
> > core frequency
> > ( 333 MHz ). This is required only when a PCI Express controller clock 
> > frequency other
> > than the default 333 MHz has to be used.
> > As an example of programming PEX_GCLK_RATIO, consider the case where the 
> > actual
> > PCI Express controller clock is 250 MHz, the ratio of the actual clock to 
> > the default clock
> > ( 333 MHz) is 3:4. that is, the default core clock has to be multiplied by 
> > the ratio (3/4,
> > which is equivalent to 12/16). So the register has to be programmed with 
> > the decimal
> > numerator value 12 or 0x_000C.
> > 
> > Our CCB is 250 MHz so this should be set to 0xc.
> > 
> > I found this on Google too:
> > The PEX controller hardware requires for timing tuning in order to operate 
> > properly at given CCB/2 clock
> > frequency. PEX_GCLK_RATIO register controls this tuning with 333MHz/16 
> > granularities. So for given CCB
> > frequency Fccb [MHz] we must write to PEX_GCLK_RATIO nearest integer of 
> > ((Fccb/2)/(333/16)). So for Fccb=375
> > we have to write 18.
> 
> Jocke,
> 
> Basically I agree with you, if the clock is different from default, you 
> need to set the ratio. T104x indeed uses 1/2 platform clock as PCIe 
> clock. I am not sure if P2010 uses the same way. Let me add Roy to this 
> thread.
> 
> Roy, how do we get PCIe clock for P1/T1 (and other mpc85xx) SoCs? Don't 
> we need to set PEX_GCLK_RATIO register? It is not even in the 

Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-08-29 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 15:43 +, York Sun wrote:
> On 08/29/2017 06:21 AM, Joakim Tjernlund wrote:
> > On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> > > As we are looking at PCI stuff ATM I would like to ask
> > > about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> > > at all for E500 but I THINK this is required.
> > > 
> > > In 83xx one do:
> > > get_clocks();
> > > /* Configure the PCIE controller core clock ratio */
> > > out_le32(hose_cfg_base + PEX_GCLK_RATIO,
> > 
> > A bit strange with out_le32 instead of out_be32 ?
> > 
> > > (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> > > / 100) * 16) / 333);
> > > udelay(100);
> > > 
> > > Any clues?
> > > 
> > >   Jocke
> > 
> > Seems like only 83xx is setting this parameter.
> > 
> > Anyhow, I put together this patch:
> > 
> > --- a/drivers/pci/fsl_pci_init.c
> > +++ b/drivers/pci/fsl_pci_init.c
> > @@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
> > fsl_pci_info *pci_info)
> >   
> >  pci_setup_indirect(hose, cfg_addr, cfg_data);
> >   
> > +   /* Configure the PCIE controller core clock ratio */
> > +   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 
> > 3) * 16);
> > +   /* udelay(100) needed here ?*/
> > +
> >  block_rev = in_be32(>block_rev1);
> >  if (PEX_IP_BLK_REV_2_2 <= block_rev) {
> >  pi = >pit[2];  /* 0xDC0 */
> > 
> > Any chance this will work for all supported FSL PCIe controllers?
> > 
> 
> Jocke,
> 
> You don't need to program this register if the actual PCIe clock is the 
> same as default. Since SerDes reference clock has to be 100MHz for PCIe 
> protocol, my guess is the PCIe clock is always correct. The bus_clk you 
> are referring is not the PCIe clock. Again, I am not a PCIe expert, I 
> could be wrong. Since PCIe (SerDes) has been working on multiple 
> platforms, I guess the clock is correct.

I don't think so. Here is what T1042 says about this:

The PCI Express controller clock frequency is one-half the platform clock 
frequency.

The PCI Express controller core clock ratio register is used to program the 
ratio of the
actual PCI Express controller clock frequency to the default controller core 
frequency
( 333 MHz ). This is required only when a PCI Express controller clock 
frequency other
than the default 333 MHz has to be used.
As an example of programming PEX_GCLK_RATIO, consider the case where the actual
PCI Express controller clock is 250 MHz, the ratio of the actual clock to the 
default clock
( 333 MHz) is 3:4. that is, the default core clock has to be multiplied by the 
ratio (3/4,
which is equivalent to 12/16). So the register has to be programmed with the 
decimal
numerator value 12 or 0x_000C.

Our CCB is 250 MHz so this should be set to 0xc.

I found this on Google too:
The PEX controller hardware requires for timing tuning in order to operate 
properly at given CCB/2 clock
frequency. PEX_GCLK_RATIO register controls this tuning with 333MHz/16 
granularities. So for given CCB
frequency Fccb [MHz] we must write to PEX_GCLK_RATIO nearest integer of 
((Fccb/2)/(333/16)). So for Fccb=375
we have to write 18.

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


Re: [U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-08-29 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 12:47 +0200, Joakim Tjernlund wrote:
> As we are looking at PCI stuff ATM I would like to ask
> about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
> at all for E500 but I THINK this is required.
> 
> In 83xx one do:
> get_clocks();
> /* Configure the PCIE controller core clock ratio */
> out_le32(hose_cfg_base + PEX_GCLK_RATIO,

A bit strange with out_le32 instead of out_be32 ?

> (((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
> / 100) * 16) / 333);
> udelay(100);
> 
> Any clues?
> 
>  Jocke
Seems like only 83xx is setting this parameter.

Anyhow, I put together this patch:

--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -322,6 +322,10 @@ void fsl_pci_init(struct pci_controller *hose, struct 
fsl_pci_info *pci_info)
 
pci_setup_indirect(hose, cfg_addr, cfg_data);
 
+   /* Configure the PCIE controller core clock ratio */
+   pci_hose_write_config_dword(hose, dev, 0x440, (gd->bus_clk / 3) 
* 16);
+   /* udelay(100) needed here ?*/
+
block_rev = in_be32(>block_rev1);
if (PEX_IP_BLK_REV_2_2 <= block_rev) {
pi = >pit[2];  /* 0xDC0 */

Any chance this will work for all supported FSL PCIe controllers?

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


Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-08-29 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 10:46 +, Xiaowei Bao wrote:
> Hi Joakim,
> 
> I think this can work for layerscape platform.
> The layerscape platform and the powerpc platform have different  pcie core, 
> and also the LTSSM reg is not same, the pcie controller driver is different 
> in uboot or kernel,  this solution is used for layerscape platform.
> 

I am not asking about the layerscape platform, I want to know what to do with 
FSL.
Please read the whole thread.

> Thanks
> 
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] 
> Sent: Tuesday, August 29, 2017 6:27 PM
> To: Xiaowei Bao <xiaowei@nxp.com>; York Sun <york@nxp.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> 
> On Tue, 2017-08-29 at 09:53 +, Xiaowei Bao wrote:
> > Hi,
> > 
> > This solution is got by discuss with minghuan and zhiqiang, according to 
> > the customer's response to this problem in the uboot period, when the 
> > kernel will not exist after the start of the problem. Because if the uboot 
> > scan the pcie device, the kernel also find this device. 
> > 
> 
> But this does not solve my problem and the solution is only for layerscape 
> ATM.
> I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test to 
> something more sane that will work for me and the rest of FSL u-boot/linux 
> users.
> 
> 
> > Thanks
> > 
> > 
> > -Original Message-
> > From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> > Sent: Tuesday, August 29, 2017 2:45 PM
> > To: Xiaowei Bao <xiaowei@nxp.com>; York Sun <york@nxp.com>
> > Cc: u-boot@lists.denx.de
> > Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> > 
> > On Tue, 2017-08-29 at 03:19 +, Xiaowei Bao wrote:
> > > Hi York,
> > > 
> > > > +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> > > > +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> > > 
> > > When the pcie slot have no device, the pcie controller access this 
> > > register return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE 
> > > state, In order to avoid unnecessary delay, return directly.
> > > 
> > > Reference the spec, except L0 state, the L0s L1 L2state can consider the 
> > > link state, but these state regards the power management, our pcie driver 
> > > have not power management code in uboot, so just need to judge the L0 
> > > state.
> > > 
> > 
> > But Linux has power mgmt(I guess this is ASPM?). Could we come up with a 
> > new test that work for both Linux and u-boot ? Is the LTSSM reg. 
> > standardized for all FSL PCIe controllers?
> > 
> >   Jocke
> > 
> > > Thanks
> > > 
> > > -Original Message-
> > > From: York Sun
> > > Sent: Tuesday, August 29, 2017 1:15 AM
> > > To: Xiaowei Bao <xiaowei@nxp.com>
> > > Cc: Joakim Tjernlund <joakim.tjernl...@infinera.com>; 
> > > u-boot@lists.denx.de
> > > Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> > > 
> > > +Xiaowei
> > > 
> > > On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> > > > On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
> > > > > On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> > > > > > FSL PCIe controller drivers before REV 3 has this test for link up:
> > > > > > enabled = ltssm >= PCI_LTSSM_L0;
> > > > > > 
> > > > > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling
> > > > > > Compliance) when non ready for PCI transaktions. When FSL PCIe 
> > > > > > controller tries to access this device, it hangs forever.
> > > > > > 
> > > > > > Is LTSSM=0x51 really a "legal" state for link up?
> > > > > > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
> > > > > > 
> > > > > >Jocke
> > > > > > 
> > > > > > BTW, the same test is valid in Linux too.
> > > > > > 
> > > > > 
> > > > > Jocke,
> > > > > 
> > > > > I am not an expert on PCIe. Please if this thread is helpful,
> > > > 
> > > > Me neither .. :)
> > > > >   
> > > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D=0.
> > > > 
> > > > It mentions polling compliance but this driver already tests for:
> > > > if (ltssm < LTSSM_PCIE_L0)
> > > > return 0;
> > > > return 1;
> > > > 
> > > > It just adds some delay if the device is in Polling Compliance to 
> > > > see if that changes to L0.
> > > > Since both layerscape and fsl >= rev 3 already require ltssm to be 
> > > > == L0, I suspect the ltssm >= L0 is bogus.
> > > > 
> > > 
> > > Xiaowei, can you comment?
> > > 
> > > York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] setup of PEX_GCLK_RATIO in E500 CPUs(P2010) missing ?

2017-08-29 Thread Joakim Tjernlund
As we are looking at PCI stuff ATM I would like to ask
about PEX_GCLK_RATIO in E500 CPUs. I cannot find this is setup
at all for E500 but I THINK this is required.

In 83xx one do:
get_clocks();
/* Configure the PCIE controller core clock ratio */
out_le32(hose_cfg_base + PEX_GCLK_RATIO,
(((bus ? gd->arch.pciexp2_clk : gd->arch.pciexp1_clk)
/ 100) * 16) / 333);
udelay(100);

Any clues?

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


Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-08-29 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 09:53 +, Xiaowei Bao wrote:
> Hi,
> 
> This solution is got by discuss with minghuan and zhiqiang, according to the 
> customer's response to this problem in the uboot period, when the kernel will 
> not exist after the start of the problem. Because if the uboot scan the pcie 
> device, the kernel also find this device. 
> 

But this does not solve my problem and the solution is only for layerscape ATM.
I am asking FSL PCI guys if we could just rewrite the old ltssm >= L0 test
to something more sane that will work for me and the rest of FSL u-boot/linux 
users.


> Thanks 
> 
> 
> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com] 
> Sent: Tuesday, August 29, 2017 2:45 PM
> To: Xiaowei Bao <xiaowei@nxp.com>; York Sun <york@nxp.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> 
> On Tue, 2017-08-29 at 03:19 +, Xiaowei Bao wrote:
> > Hi York,
> > 
> > > + if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> > > + ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> > 
> > When the pcie slot have no device, the pcie controller access this register 
> > return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order 
> > to avoid unnecessary delay, return directly.
> > 
> > Reference the spec, except L0 state, the L0s L1 L2state can consider the 
> > link state, but these state regards the power management, our pcie driver 
> > have not power management code in uboot, so just need to judge the L0 state.
> > 
> 
> But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new 
> test that work for both Linux and u-boot ? Is the LTSSM reg. standardized for 
> all FSL PCIe controllers?
> 
>   Jocke
> 
> > Thanks
> > 
> > -Original Message-
> > From: York Sun
> > Sent: Tuesday, August 29, 2017 1:15 AM
> > To: Xiaowei Bao <xiaowei....@nxp.com>
> > Cc: Joakim Tjernlund <joakim.tjernl...@infinera.com>; 
> > u-boot@lists.denx.de
> > Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> > 
> > +Xiaowei
> > 
> > On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> > > On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
> > > > On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> > > > > FSL PCIe controller drivers before REV 3 has this test for link up:
> > > > > enabled = ltssm >= PCI_LTSSM_L0;
> > > > > 
> > > > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling 
> > > > > Compliance) when non ready for PCI transaktions. When FSL PCIe 
> > > > > controller tries to access this device, it hangs forever.
> > > > > 
> > > > > Is LTSSM=0x51 really a "legal" state for link up?
> > > > > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
> > > > > 
> > > > >Jocke
> > > > > 
> > > > > BTW, the same test is valid in Linux too.
> > > > > 
> > > > 
> > > > Jocke,
> > > > 
> > > > I am not an expert on PCIe. Please if this thread is helpful,
> > > 
> > > Me neither .. :)
> > > >   
> > > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D=0.
> > > 
> > > It mentions polling compliance but this driver already tests for:
> > > if (ltssm < LTSSM_PCIE_L0)
> > >   return 0;
> > >   return 1;
> > > 
> > > It just adds some delay if the device is in Polling Compliance to 
> > > see if that changes to L0.
> > > Since both layerscape and fsl >= rev 3 already require ltssm to be 
> > > == L0, I suspect the ltssm >= L0 is bogus.
> > > 
> > 
> > Xiaowei, can you comment?
> > 
> > York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-08-29 Thread Joakim Tjernlund
On Tue, 2017-08-29 at 03:19 +, Xiaowei Bao wrote:
> Hi York,
> 
> > +   if (ltssm == LTSSM_PCIE_DETECT_QUIET ||
> > +   ltssm == LTSSM_PCIE_DETECT_ACTIVE) {
> 
> When the pcie slot have no device, the pcie controller access this register 
> return LTSSM_PCIE_DETECT_QUIET or LTSSM_PCIE_DETECT_ACTIVE state, In order to 
> avoid unnecessary delay, return directly.
> 
> Reference the spec, except L0 state, the L0s L1 L2state can consider the link 
> state, but these state regards the power management, our pcie driver have not 
> power management code in uboot, so just need to judge the L0 state.
> 

But Linux has power mgmt(I guess this is ASPM?). Could we come up with a new 
test that work for
both Linux and u-boot ? Is the LTSSM reg. standardized for all FSL PCIe 
controllers?

  Jocke

> Thanks
> 
> -Original Message-
> From: York Sun 
> Sent: Tuesday, August 29, 2017 1:15 AM
> To: Xiaowei Bao <xiaowei@nxp.com>
> Cc: Joakim Tjernlund <joakim.tjernl...@infinera.com>; u-boot@lists.denx.de
> Subject: Re: FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up
> 
> +Xiaowei
> 
> On 08/28/2017 10:09 AM, Joakim Tjernlund wrote:
> > On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
> > > On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> > > > FSL PCIe controller drivers before REV 3 has this test for link up:
> > > > enabled = ltssm >= PCI_LTSSM_L0;
> > > > 
> > > > We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) 
> > > > when non ready for PCI transaktions. When FSL PCIe controller tries 
> > > > to access this device, it hangs forever.
> > > > 
> > > > Is LTSSM=0x51 really a "legal" state for link up?
> > > > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
> > > > 
> > > >Jocke
> > > > 
> > > > BTW, the same test is valid in Linux too.
> > > > 
> > > 
> > > Jocke,
> > > 
> > > I am not an expert on PCIe. Please if this thread is helpful,
> > 
> > Me neither .. :)
> > >   
> > > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatchwork.ozlabs.org%2Fpatch%2F801519%2F=01%7C01%7Cyork.sun%40nxp.com%7Cf46ff5111ba04e631a9b08d4ee377ecc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=n9%2B2NIjEvsMBCljRLHS6NVVN4ANa3nBGpwUjI4Od%2Bhs%3D=0.
> > 
> > It mentions polling compliance but this driver already tests for:
> > if (ltssm < LTSSM_PCIE_L0)
> > return 0;
> > return 1;
> > 
> > It just adds some delay if the device is in Polling Compliance to see 
> > if that changes to L0.
> > Since both layerscape and fsl >= rev 3 already require ltssm to be == 
> > L0, I suspect the ltssm >= L0 is bogus.
> > 
> 
> Xiaowei, can you comment?
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-08-28 Thread Joakim Tjernlund
On Mon, 2017-08-28 at 16:55 +, York Sun wrote:
> On 08/28/2017 09:48 AM, Joakim Tjernlund wrote:
> > FSL PCIe controller drivers before REV 3 has this test for link up:
> >enabled = ltssm >= PCI_LTSSM_L0;
> > 
> > We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non 
> > ready
> > for PCI transaktions. When FSL PCIe controller tries to access this device, 
> > it
> > hangs forever.
> > 
> > Is LTSSM=0x51 really a "legal" state for link up?
> > If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?
> > 
> >   Jocke
> > 
> > BTW, the same test is valid in Linux too.
> > 
> 
> Jocke,
> 
> I am not an expert on PCIe. Please if this thread is helpful,
Me neither .. :)
>  
> http://patchwork.ozlabs.org/patch/801519/.

It mentions polling compliance but this driver already tests for:
if (ltssm < LTSSM_PCIE_L0)
return 0; 
return 1;

It just adds some delay if the device is in Polling Compliance to see if that
changes to L0.
Since both layerscape and fsl >= rev 3 already require ltssm to be == L0, I 
suspect
the ltssm >= L0 is bogus.

 Jocke


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


[U-Boot] FSL PCIe LTSSM >= PCI_LTSSM_L0 equals link up

2017-08-28 Thread Joakim Tjernlund
FSL PCIe controller drivers before REV 3 has this test for link up: 
  enabled = ltssm >= PCI_LTSSM_L0;

We have a PCIe dev. that stays in LTSSM=0x51 (Polling Compliance) when non ready
for PCI transaktions. When FSL PCIe controller tries to access this device, it
hangs forever.

Is LTSSM=0x51 really a "legal" state for link up?
If not, what is a suitable range(maybe LO <= ltssm <= L0s(0x27)) ?

 Jocke

BTW, the same test is valid in Linux too.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Orphan Freescale PowerPC boards

2017-05-17 Thread Joakim Tjernlund
On Wed, 2017-05-17 at 13:25 -0400, Tom Rini wrote:
> On Wed, May 17, 2017 at 04:57:57PM +, york sun wrote:
> > On 05/09/2017 08:52 AM, York Sun wrote:
> > > On 05/09/2017 08:49 AM, Tom Rini wrote:
> > > > On Tue, May 09, 2017 at 08:46:46AM -0700, York Sun wrote:
> > > > > On 05/09/2017 05:36 AM, Tom Rini wrote:
> > > > > > On Tue, May 09, 2017 at 09:19:37PM +0900, Masahiro Yamada wrote:
> > > > > > > Hi York,
> > > > > > > 
> > > > > > > I see some orphan boards under board/freescale directory.
> > > > > > > 
> > > > > > > $ find board/freescale -name MAINTAINERS | xargs grep Orphan
> > > > > > > board/freescale/mpc8555cds/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > board/freescale/mpc8641hpcn/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > board/freescale/mpc8540ads/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > board/freescale/mpc8541cds/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > board/freescale/mx31ads/MAINTAINERS:S: Orphan (since 2013-09)
> > > > > > > board/freescale/m5253evbe/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > board/freescale/mpc8560ads/MAINTAINERS:S: Orphan (since 2014-06)
> > > > > > > 
> > > > > > > Will you pick up the maintainership if you want to keep them?
> > > > > > 
> > > > > > Related to that, there's also mpc83xx support, do you wish to pick 
> > > > > > that
> > > > > > up?  Thanks!
> > > > > 
> > > > > What options do I have? They are really old boards.
> > > > 
> > > > Well, if you don't want to pick them up, we can drop them.  If someone
> > > > later wants to support them, they can step up.
> > > > 
> > > 
> > > Let me ask our FAEs to see if there is any customer using these boards.
> > > If not, and nobody in this community cares them, we can drop them.
> > > 
> > 
> > I will pick up the ownership of MPC8555CDS, MPC8641HPCN, MPC8541CDS, and 
> > drop the support of MPC8540ADS and MPC8560ADS.
> > 
> > It is not clear who will maintain mpc83xx, and other orphan boards. In 
> > 2015, Sinan Akman offered to maintain mpc83xx. The discussion didn't 
> > yield any result.
> 
> I think we'll just drop mpc83xx then. Thanks for looking into this!

We still use custom mpc83xx boards and we would like to continue to
do so in later u-boot.

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


Re: [U-Boot] [PATCH] sunxi: Explicitly call fdt_fixup_ethernet() in our ft_board_setup()

2017-04-28 Thread Joakim Tjernlund
On Fri, 2017-04-28 at 11:05 +0200, Maxime Ripard wrote:
> On Fri, Apr 28, 2017 at 03:33:53PM +0800, Chen-Yu Tsai wrote:
> > The sunxi platform relies on the core boot sequence to load and process
> > device tree blobs, including writing back any MAC addresses we generate
> > by an implicit call to fdt_fixup_ethernet() within the image loading
> > mechanism. This call was removed in commit 3f66149d9fb4 ("Remove extra
> > fdt_fixup_ethernet() call"), resuling in Linux using random MAC
> > addresses.
> > 
> > This patch adds an explicit call to fdt_fixup_ethernet() in our
> > ft_board_setup() function.
> > 
> > Fixes: 3f66149d9fb4 ("Remove extra fdt_fixup_ethernet() call")
> 
> I would just revert that commit. The function mentionned in the commit
> log is platform specific, it just doesn't make any sense to remove
> some generic code just because it would work on your platform.

The Generic code was both added later and wrong so no need to restore that.

One could remove the platform specific code and add back a generic one but then
make sure it is called BEFORE any board setup.

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


Re: [U-Boot] Remove global variable env_t *env_ptr ?

2017-04-04 Thread Joakim Tjernlund
On Tue, 2017-04-04 at 13:27 +0200, Wolfgang Denk wrote:
> Dear Joakim,
> 
> In message <1491302640.30240.1.ca...@infinera.com> you wrote:
> > 
> > > That is my exact question - when would this happen?  Flash sectors
> > > do now wander around in memory or change size :-)
> > 
> > No, but they happens when you are forced to update you HW with new type of 
> > flashes
> > with different layout so you have to move where the environment is stored.
> > Sure, this can be fixed by having two different u-boot images but that will
> > in our case be just painful to carry around an extra u-boot img, then in 
> > field
> > devise a method to chose the right img. for what looks like the same HW but 
> > the flash.
> 
> I see. Well, this obviously means that you are _not_ using an
> embedded environment, as otherwise the linker generated image would
> be wrong for the "other" type of flash chips - which means, the
> environment is somewhare outside, separate from the U-Boot image.

Right. The env. is on separate sectors not in u-boot's own space.

> 
> So you have old hardware, running old U-Boot, which does not support
> the new flash.  For this, you need a new U-Boot, which then shall
> support both the old and the new flash, right?  But why can you then
> not simply come up with a new flash layout, which is compatoble with
> the old and new flashes, so it can use a common configuration,
> without code changes?

Because the old flash has its env. in "small" sectors which does
not exist on new flash so the layout on the new flash has both different env.
address as well as a bigger env. sector size. I cannot move the old
env. either as there is no free space for that(the rest of the flash is a JFFS2 
FS)

> 
> I'm aware that embedded environment is not used very often these
> days any more, as is parallel NOR flash, but changes in this are
> have caused trouble more than once in the past, so I am not
> convinced that it's wise to touch such ancient, "stable" code for
> an exotic feature that probably nobody else will ever need?

Again, I don't think I am changing much(if anything) for your embedded case.
Please read the WIP patch I sent earlier and perhaps you can point me to
a potential problem area?

Not sure about "nobody else will ever need" as Micron are terminating the
Intel/cmdset0001 flashes(don't know if this applies to all Intel chips though)
and we have to swap to AMD/cmd0002, we are just early with this change. 

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


Re: [U-Boot] Remove global variable env_t *env_ptr ?

2017-04-04 Thread Joakim Tjernlund
On Tue, 2017-04-04 at 12:31 +0200, Wolfgang Denk wrote:
> Dear Joakim,
> 
> In message <1491301459.28343.1.ca...@infinera.com> you wrote:
> > 
> > Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non 
> > constants.
> 
> That is my exact question - when would this happen?  Flash sectors
> do now wander around in memory or change size :-)

No, but they happens when you are forced to update you HW with new type of 
flashes
with different layout so you have to move where the environment is stored.
Sure, this can be fixed by having two different u-boot images but that will
in our case be just painful to carry around an extra u-boot img, then in field
devise a method to chose the right img. for what looks like the same HW but the 
flash.

What I have done is not that earth shattering, basically just move from:
  static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
to
 int env_init(void)
 {
   ...
   env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;

This allows CONFIG_ENV_ADDR to be a function but it does not have to, you also
lose a relocation entry as a static variable is removed.

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


Re: [U-Boot] Remove global variable env_t *env_ptr ?

2017-04-04 Thread Joakim Tjernlund
On Tue, 2017-04-04 at 10:55 +0200, Lukasz Majewski wrote:
> Hi Joakim,
> 
> > I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR
> > as we need to replace out flash but we don't want to create a new
> > u-boot binairy just for this simple change.
> 
> Please correct me if I did not understand your use case correctly.
> 
> Other boards have separate regions in flash to store ENV variables -
> even redundancy is supported (from ./include/mccmon6.h)
> 
> /* Envs are stored in NOR flash */
> #define CONFIG_ENV_IS_IN_FLASH
> #define CONFIG_ENV_SECT_SIZE(SZ_128K)
> #define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE + 0x4)
> 
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_ADDR_REDUND  (CONFIG_SYS_FLASH_BASE + 0x6)
> #define CONFIG_ENV_SIZE_REDUND  CONFIG_ENV_SIZE

Use case is when CONFIG_ENV_SECT_SIZE and/or CONFIG_ENV_ADDR are non constants.
Then, in my case, these becomes:
#define CONFIG_ENV_SECT_SIZE(get_env_sect_size())
#define CONFIG_ENV_ADDR(get_env_address())

Jocke
> 
> You can extract the ENV variables by using following script:
> 
> scripts/get_default_envs.sh > default_envs.txt
> 
> and then create updated env image (with [*]) to be stored on flash.
> 
> 
> Note:
> 
> [*] 
> ./tools/mkenvimage -s 131072 -o ${UBOOT_ENVS_DEFAULT} default_envs.txt
> 
> Best regards,
> Łukasz Majewski
> 
> > 
> > While converting env_flash.c I noted the global variable
> >  env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
> > which cannot be runtime decided.
> > Looking at users of this variable I only find one in pmc405de.c(not
> > sure what that board is doing) and for what I can tell this variable
> > is not correct for redundant env. either.
> > 
> > Anyhow, I am faced wit two choices, either remove the env_ptr or
> > convert it to a function call.
> > 
> > What do fellow u-booters think about env_ptr?
> > 
> >  Jocke
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Remove global variable env_t *env_ptr ?

2017-04-04 Thread Joakim Tjernlund
On Mon, 2017-04-03 at 22:17 +0200, Wolfgang Denk wrote:
> Dear Joakim,

Dear Wolfgang,

> 
> In message <1491221969.4177.81.ca...@infinera.com> you wrote:
> > I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR as
> > we need to replace out flash but we don't want to create a new u-boot 
> > binairy
> > just for this simple change.
> 
> I doubt this will work for configurations that use embedded
> environment.

I see, I don't think so but will look closer.

> 
> > While converting env_flash.c I noted the global variable
> >  env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
> > which cannot be runtime decided.
> > Looking at users of this variable I only find one in pmc405de.c(not sure 
> > what that board is doing)
> > and for what I can tell this variable is not correct for redundant env. 
> > either.
> 
> Did you look in the code only, or in all files?

code only, for the use of the env_ptr variable only as this is the variable I 
looking at.

> 
> > Anyhow, I am faced wit two choices, either remove the env_ptr or
> > convert it to a function call.
> 
> Probably neither will work for all use cases.  You remember the good
> old times when we had parallel NOR flash with a few smaller sectors
> somewhere near the beginning or the end of the device?  It was

Sure do, this is the reason I am having this problem. The new flashes do
not have such smaller sectors, they are all uniform :(

> pretty usual to use these small sectors for the environment, and it
> was the task of thelinker script to "wrap" the rest of the code
> around these reserved sectors.  For this, the environment location
> must be known not only in the code, but also in the linker script.

After a brief look I think we are good. Let me explain, I am only
making it possible to #define CONFIG_ENV_ADDR, CONFIG_ENV_SECT_SIZE etc.
as non constant data by moving the assignment of flash_addr etc. to runtime,
removing the static variable(less relocs to perform too :), I not forcing
anyone to do so and only for env_flash.c

The only variable that I can't do away with it the:
 env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
as it is global. Nothing really uses this global variable(except pmc405de.c 
which is EPROM),
not even the linker scripts below. They use #defines directly(CONFIG_ENV_OFFSET,
CONFIG_SYS_FLASH_BASE etc. except for env_embedded.c which uses other variables)

As nothing really uses env_ptr and a variable isn't really a good 
interface(compare 
with the errno variable) I propose that the env_ptr variable in code is removed 
but
lets start with removing it for env_flash.c first.

> 
> Without thorough checking , at least these files look suspicious to
> me:
> 
> arch/powerpc/cpu/mpc5xx/u-boot.lds:  . = env_start;
> arch/powerpc/cpu/mpc5xx/u-boot.lds:  .ppcenv :
> arch/powerpc/cpu/mpc5xx/u-boot.lds:common/env_embedded.o (.ppcenv)
> arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds:. = DEFINED(env_offset) 
> ? env_offset : .;
> arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds:common/env_embedded.o
>   (.ppcenv*)
> board/tqc/tqm8xx/u-boot.lds:. = DEFINED(env_offset) ? env_offset : .;
> board/tqc/tqm8xx/u-boot.lds:common/env_embedded.o   (.ppcenv*)
> board/freescale/mx31ads/u-boot.lds:   . = DEFINED(env_offset) ? 
> env_offset : .;
> board/freescale/mx31ads/u-boot.lds:   common/env_embedded.o(.text*)
> 
> Please have a look at these, and verify that the image layout does
> not change for these with any such changes.
> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Remove global variable env_t *env_ptr ?

2017-04-03 Thread Joakim Tjernlund
I am looking at adding support for runtime sizing of CONFIG_ENV_ADDR as
we need to replace out flash but we don't want to create a new u-boot binairy
just for this simple change.

While converting env_flash.c I noted the global variable
 env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
which cannot be runtime decided.
Looking at users of this variable I only find one in pmc405de.c(not sure what 
that board is doing)
and for what I can tell this variable is not correct for redundant env. either.

Anyhow, I am faced wit two choices, either remove the env_ptr or
convert it to a function call.

What do fellow u-booters think about env_ptr?

 Jocke

PS. Adding my work so far here:
From 5d3791099fb6a2c503b83298ac1f6135331466dc Mon Sep 17 00:00:00 2001
From: David Gounaris 
Date: Fri, 31 Mar 2017 11:31:40 +0200
Subject: [PATCH 2/4] env_flash.c: Support dynamic sector size

This lay the ground work for supporting a non constant
sector size environment data.
---
 common/env_flash.c | 152 +
 1 file changed, 83 insertions(+), 69 deletions(-)

diff --git a/common/env_flash.c b/common/env_flash.c
index 004e884..306ef42 100644
--- a/common/env_flash.c
+++ b/common/env_flash.c
@@ -36,31 +36,20 @@ char *env_name_spec = "Flash";
 #ifdef ENV_IS_EMBEDDED
 env_t *env_ptr = 
 
-static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
-
 #else /* ! ENV_IS_EMBEDDED */
 
 env_t *env_ptr = (env_t *)CONFIG_ENV_ADDR;
-static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
 #endif /* ENV_IS_EMBEDDED */
 
-#if defined(CMD_SAVEENV) || defined(CONFIG_ENV_ADDR_REDUND)
-/* CONFIG_ENV_ADDR is supposed to be on sector boundary */
-static ulong end_addr = CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE - 1;
-#endif
-
-#ifdef CONFIG_ENV_ADDR_REDUND
-static env_t *flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND;
-
-/* CONFIG_ENV_ADDR_REDUND is supposed to be on sector boundary */
-static ulong end_addr_new = CONFIG_ENV_ADDR_REDUND + CONFIG_ENV_SECT_SIZE - 1;
-#endif /* CONFIG_ENV_ADDR_REDUND */
-
-
 #ifdef CONFIG_ENV_ADDR_REDUND
 int env_init(void)
 {
int crc1_ok = 0, crc2_ok = 0;
+   env_t *flash_addr;
+   env_t *flash_addr_new;
+
+   flash_addr = (env_t *)CONFIG_ENV_ADDR;
+   flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND;
 
uchar flag1 = flash_addr->flags;
uchar flag2 = flash_addr_new->flags;
@@ -109,9 +98,28 @@ int saveenv(void)
char*saved_data = NULL;
charflag = OBSOLETE_FLAG, new_flag = ACTIVE_FLAG;
int rc = 1;
-#if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE
-   ulong   up_data = 0;
-#endif
+   ulong   up_data = 0;
+   env_t *flash_addr;
+   env_t *flash_addr_new;
+   ulong end_addr;
+   ulong end_addr_new;
+
+   flash_addr = (env_t *)CONFIG_ENV_ADDR;
+   flash_addr_new = (env_t *)CONFIG_ENV_ADDR_REDUND;
+   end_addr = CONFIG_ENV_ADDR + CONFIG_ENV_SECT_SIZE - 1;
+   end_addr_new = CONFIG_ENV_ADDR_REDUND + CONFIG_ENV_SECT_SIZE - 1;
+
+   if (gd->env_addr != (ulong)&(flash_addr->data)) {
+   /* Swap new and old ptrs */
+   env_t *etmp = flash_addr;
+   ulong ltmp = end_addr;
+
+   flash_addr = flash_addr_new;
+   flash_addr_new = etmp;
+
+   end_addr = end_addr_new;
+   end_addr_new = ltmp;
+   }
 
debug("Protect off %08lX ... %08lX\n", (ulong)flash_addr, end_addr);
 
@@ -129,24 +137,25 @@ int saveenv(void)
return rc;
env_new.flags   = new_flag;
 
-#if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE
-   up_data = end_addr_new + 1 - ((long)flash_addr_new + CONFIG_ENV_SIZE);
-   debug("Data to save 0x%lX\n", up_data);
-   if (up_data) {
-   saved_data = malloc(up_data);
-   if (saved_data == NULL) {
-   printf("Unable to save the rest of sector (%ld)\n",
-   up_data);
-   goto done;
+   if(CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE) {
+   up_data = end_addr_new + 1 - ((long)flash_addr_new + 
CONFIG_ENV_SIZE);
+   debug("Data to save 0x%lX\n", up_data);
+   if (up_data) {
+   saved_data = malloc(up_data);
+   if (saved_data == NULL) {
+   printf("Unable to save the rest of sector 
(%ld)\n",
+  up_data);
+   goto done;
+   }
+   memcpy(saved_data,
+  (void *)((long)flash_addr_new + CONFIG_ENV_SIZE),
+  up_data);
+   debug("Data (start 0x%lX, len 0x%lX) saved at 0x%p\n",
+ (long)flash_addr_new + CONFIG_ENV_SIZE,
+ up_data, saved_data);
}
-   memcpy(saved_data,
-   (void 

Re: [U-Boot] [PATCH] Remove extra fdt_fixup_ethernet() call

2017-04-03 Thread Joakim Tjernlund
On Fri, 2017-03-31 at 22:21 -0600, Simon Glass wrote:
> Hi Joakim,
> 
> On 23 March 2017 at 11:02, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > ft_cpu_setup() already calls fdt_fixup_ethernet(), calling it
> > in image_setup_libfdt() is both redundant and breaks any modifications
> > done by ft_board_setup(). Restore the old behavior by removing
> > the call in image_setup_libfdt()
> 
> Which old behaviour? Can you please add a Fixes: tag with the details?

The feature of having the possibility to rewrite the dev trees MAC addresses in
ft_board_setup(). Currently such rewrites are overwritten by the call to 
dt_fixup_ethernet(blob)
in image_setup_libfdt().
Looking into the history I see that commit 13d06981(by you as it happens :) is 
the one adding
the extra call to fdt_fixup_ethernet()
> 
> Also, which ft_cpu_setup()?
# > git grep fdt_fixup_ethernet
arch/arm/cpu/armv7/ls102xa/fdt.c:   fdt_fixup_ethernet(blob);
arch/mips/lib/bootm.c:  fdt_fixup_ethernet(images->ft_addr);
arch/nios2/cpu/fdt.c:   fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc512x/cpu.c: fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc8260/cpu.c: fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc83xx/fdt.c: fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc85xx/fdt.c: fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc86xx/fdt.c: fdt_fixup_ethernet(blob);
arch/powerpc/cpu/mpc8xx/fdt.c:  fdt_fixup_ethernet(blob);
arch/powerpc/cpu/ppc4xx/fdt.c:  fdt_fixup_ethernet(blob);

Seems like it is mostly PPC which has fdt_fixup_ethernet() call though.

 Jocke
> 
> > 
> > Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> > ---
> >  common/image-fdt.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/common/image-fdt.c b/common/image-fdt.c
> > index 80e3e63..b8f5654 100644
> > --- a/common/image-fdt.c
> > +++ b/common/image-fdt.c
> > @@ -498,7 +498,6 @@ int image_setup_libfdt(bootm_headers_t *images, void 
> > *blob,
> > goto err;
> > }
> > }
> > -   fdt_fixup_ethernet(blob);
> > 
> > /* Delete the old LMB reservation */
> > lmb_free(lmb, (phys_addr_t)(u32)(uintptr_t)blob,
> > --
> > 2.10.2
> > 
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] Remove extra fdt_fixup_ethernet() call

2017-03-28 Thread Joakim Tjernlund
On Thu, 2017-03-23 at 18:02 +0100, Joakim Tjernlund wrote:
> ft_cpu_setup() already calls fdt_fixup_ethernet(), calling it
> in image_setup_libfdt() is both redundant and breaks any modifications
> done by ft_board_setup(). Restore the old behavior by removing
> the call in image_setup_libfdt()
> 
> Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
> ---
>  common/image-fdt.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/common/image-fdt.c b/common/image-fdt.c
> index 80e3e63..b8f5654 100644
> --- a/common/image-fdt.c
> +++ b/common/image-fdt.c
> @@ -498,7 +498,6 @@ int image_setup_libfdt(bootm_headers_t *images, void 
> *blob,
>   goto err;
>   }
>   }
> - fdt_fixup_ethernet(blob);
>  
>   /* Delete the old LMB reservation */
>   lmb_free(lmb, (phys_addr_t)(u32)(uintptr_t)blob,

Ping ?

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


[U-Boot] [PATCH] Remove extra fdt_fixup_ethernet() call

2017-03-23 Thread Joakim Tjernlund
ft_cpu_setup() already calls fdt_fixup_ethernet(), calling it
in image_setup_libfdt() is both redundant and breaks any modifications
done by ft_board_setup(). Restore the old behavior by removing
the call in image_setup_libfdt()

Signed-off-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>
---
 common/image-fdt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index 80e3e63..b8f5654 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -498,7 +498,6 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
goto err;
}
}
-   fdt_fixup_ethernet(blob);
 
/* Delete the old LMB reservation */
lmb_free(lmb, (phys_addr_t)(u32)(uintptr_t)blob,
-- 
2.10.2

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


Re: [U-Boot] libfdt SWIG build error with Python 3.x

2017-02-09 Thread Joakim Tjernlund
On Thu, 2017-02-09 at 13:17 +, Ricardo Martins wrote:
> In some Linux distributions (e.g., Arch Linux) the Python binary points to
> Python 3.x instead of Python 2.x. This is an issue when building the libfdt
> SWIG extension, as the generated extension file will be called something
> like _libfdt.cpython-36m-x86_64-linux-gnu.so instead of just _libfdt.so. By
> simply changing python to python2 in tools/Makefile this issue goes away.
> Should I submit a patch to fix this ?

Yes

Please include tools/binman/binman.py too as it has the same problem.
I guess most python programs is python2 only so if you can find
more of them, fix these too.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] PHY less eth on x86 u-boot?

2017-02-03 Thread Joakim Tjernlund
How does PHY less ethernet work on x86 u-boot? In powerpc we have the
device tree where one can express a "fixed-link", does this work for x86 too?

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


Re: [U-Boot] u-boot.git or u-boot-x86.git for x86_64 u-boots?

2017-01-24 Thread Joakim Tjernlund
On Sat, 2017-01-14 at 10:06 -0700, Simon Glass wrote:
> Hi Joakim,
> 
> On 14 January 2017 at 04:51, Bin Meng <bmeng...@gmail.com> wrote:
> > +Simon,
> > 
> > On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
> > <joakim.tjernl...@infinera.com> wrote:
> > > I found two repos w.r.t x86_64 for u-boot, which one should I use?
> > > 
> > 
> > U-Boot x86_64 support is not in mainstream yet.
> 
> I'll be sending v3 fairly soon. But even then it is not complete.
> Various things need fixing up and polishing - e.g. SDRAM sizing,
> graphics ROMs, actually booting Linux!
> 
> > 
> > > I am ATM only looking at USING the qemu-x86 target for now.
> > > 
> > > BTW, I found tools/binman/binman.py only worked with python 2.7, maybe 
> > > you can change
> > > the shebang to python2.7 as my default python is 3.4
> 
> We should probably patch it to work on 3.4 also.

I did a quick test using: 2to3 -w binman.py

This makes binman.py "build" on both 2.7 and 3.4 but running it on 3.4
hangs forever until Ctrl-C:
BINMAN  u-boot.rom
Traceback (most recent call last):
  File "./tools/binman/binman", line 113, in 
ret_code = RunBinman(options, args)
  File "./tools/binman/binman", line 101, in RunBinman
ret_code = control.Binman(options, args)
  File "/usr/local/src/u-boot-x86/tools/binman/control.py", line 95, in Binman
fdt = fdt_select.FdtScan(dtb_fname)
  File "/usr/local/src/u-boot-x86/tools/binman/../dtoc/fdt_select.py", line 28, 
in FdtScan
dtb.Scan()
  File "/usr/local/src/u-boot-x86/tools/binman/../dtoc/fdt.py", line 229, in 
Scan
self._root.Scan()
  File "/usr/local/src/u-boot-x86/tools/binman/../dtoc/fdt_fallback.py", line 
61, in Scan
for name, byte_list_str in self._fdt.GetProps(self.path).items():
  File "/usr/local/src/u-boot-x86/tools/binman/../dtoc/fdt_fallback.py", line 
128, in GetProps
out = command.Output('fdtget', self._fname, node, '-p')
  File "/usr/local/src/u-boot-x86/tools/binman/../patman/command.py", line 109, 
in Output
return RunPipe([cmd], capture=True, raise_on_error=raise_on_error).stdout
  File "/usr/local/src/u-boot-x86/tools/binman/../patman/command.py", line 97, 
in RunPipe
last_pipe.CommunicateFilter(None))
  File "/usr/local/src/u-boot-x86/tools/binman/../patman/cros_subprocess.py", 
line 168, in CommunicateFilter
rlist, wlist, _ = select.select(read_set, write_set, [], 0.2)
KeyboardInterrupt
Makefile:1070: recipe for target 'u-boot.rom' failed
make: *** [u-boot.rom] Error 1

Please just change shebang to python2.7 for now. This is the only fix needed
to build the x86 qemu target.

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


Re: [U-Boot] [PATCH v2 1/2] powerpc: mpc83xx: Minimize r1 modification

2017-01-17 Thread Joakim Tjernlund
On Tue, 2017-01-17 at 08:33 +0100, Mario Six wrote:
> The r1 register is modified several times during the cache-ram setup of
> the MPC83xx SoCs.
> 
> Since this SP modification confuses debuggers, we use a general purpose
> register to compute the new stack pointer value, and only set the SP
> once after all computations are done.
> 
> Signed-off-by: Mario Six <mario....@gdsys.cc>
Reviewed-by: Joakim Tjernlund <joakim.tjernl...@infinera.com>

> ---
> 
> Changes in v2:
> 
> Patch added (following a suggestion by Joakim Tjernlund)
> 
> ---
>  arch/powerpc/cpu/mpc83xx/start.S | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc83xx/start.S 
> b/arch/powerpc/cpu/mpc83xx/start.S
> index 0001687703..c366f615e7 100644
> --- a/arch/powerpc/cpu/mpc83xx/start.S
> +++ b/arch/powerpc/cpu/mpc83xx/start.S
> @@ -258,14 +258,17 @@ in_flash:
>  #endif
> 
>   /* set up the stack pointer in our newly created
> -  * cache-ram (r1) */
> - lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)@h
> - ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + 
> CONFIG_SYS_GBL_DATA_OFFSET)@l
> +  * cache-ram; use r3 to keep the new SP for now to
> +  * avoid overiding the SP it uselessly */
> + lis r3, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET)@h
> + ori r3, r3, (CONFIG_SYS_INIT_RAM_ADDR + 
> CONFIG_SYS_GBL_DATA_OFFSET)@l
> 
>   li  r0, 0   /* Make room for stack frame header and */
> - stwur0, -4(r1)  /* clear final stack frame so that  */
> - stwur0, -4(r1)  /* stack backtraces terminate cleanly   */
> + stwur0, -4(r3)  /* clear final stack frame so that  */
> + stwur0, -4(r3)  /* stack backtraces terminate cleanly   */
> 
> + /* Finally, actually set SP */
> + mr  r1, r3
> 
>   /* let the C-code set up the rest   */
>   /*  */
> --
> 2.11.0
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] u-boot.git or u-boot-x86.git for x86_64 u-boots?

2017-01-15 Thread Joakim Tjernlund
On Sat, 2017-01-14 at 10:06 -0700, Simon Glass wrote:
> Hi Joakim,
> 
> On 14 January 2017 at 04:51, Bin Meng <bmeng...@gmail.com> wrote:
> > +Simon,
> > 
> > On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
> > <joakim.tjernl...@infinera.com> wrote:
> > > I found two repos w.r.t x86_64 for u-boot, which one should I use?
> > > 
> > 
> > U-Boot x86_64 support is not in mainstream yet.
> 
> I'll be sending v3 fairly soon. But even then it is not complete.
> Various things need fixing up and polishing - e.g. SDRAM sizing,
> graphics ROMs, actually booting Linux!

Great, getting closer every day.
Any idea for how much is missing in u-boot to bring up a 
Rangeley(C2758), no graphics required. Need networking, rs232, USB and maybe 
SATA.

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


Re: [U-Boot] u-boot.git or u-boot-x86.git for x86_64 u-boots?

2017-01-14 Thread Joakim Tjernlund
On Sat, 2017-01-14 at 19:51 +0800, Bin Meng wrote:
> +Simon,
> 
> On Fri, Jan 13, 2017 at 4:12 AM, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > I found two repos w.r.t x86_64 for u-boot, which one should I use?
> > 
> 
> U-Boot x86_64 support is not in mainstream yet.

So I should use u-boot-x86.git for now then.
Strangely u-boot.git did work too.

> 
> > I am ATM only looking at USING the qemu-x86 target for now.
> > 
> > BTW, I found tools/binman/binman.py only worked with python 2.7, maybe you 
> > can change
> > the shebang to python2.7 as my default python is 3.4
> > 
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] u-boot.git or u-boot-x86.git for x86_64 u-boots?

2017-01-12 Thread Joakim Tjernlund
I found two repos w.r.t x86_64 for u-boot, which one should I use?

I am ATM only looking at USING the qemu-x86 target for now.

BTW, I found tools/binman/binman.py only worked with python 2.7, maybe you can 
change
the shebang to python2.7 as my default python is 3.4

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


Re: [U-Boot] [PATCH] powerpc: mpc83xx: Enable pre-relocation malloc

2017-01-06 Thread Joakim Tjernlund
On Fri, 2017-01-06 at 14:56 +0100, Mario Six wrote:
> To enable DM on MPC83xx, we need pre-relocation malloc, which is
> implemented in this patch.
> 

Would be nice if you could avoid using r1, each time you modify r1 gdb will be
upset/confused if you ever try to debug start.S with gdb.

I guess the whole file need a bit of trimming to avoid using r1 but one has to 
start somewhere.

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


Re: [U-Boot] [PATCH v3 0/3] dm: gpio: Add driver for MPC85xx GPIO controller

2016-05-13 Thread Joakim Tjernlund
On Fri, 2016-05-13 at 13:15 +0200, Mario Six wrote:
> The functions for accessing GPIOs on MPC85xx are hardcoded in
> arch/powerpc/include/asm/mpc85xx_gpio.h This leads to problems if another GPIO
> controller supporting the driver model is to be used simultaneously.
> 
> Therefore, this patch moves the "static" functions into a DM-compatible 
> driver,
> and also introduces a set of functions into the GPIO uclass that expose the
> controller's capability to switch individual GPIOs into open-drain-mode.
> 
> v3 also implements shadowing of the GPDAT register to work around a known 
> issue
> in some MPC85xx GPIO controllers (as pointed out by Joakim Tjernlund).
> 

Nice, thanks.

Do you have any plans to do mpc83xx also? It needs the same gpdat shadow.

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


Re: [U-Boot] GPIO driver for Freescale QorIQ T2080

2016-05-11 Thread Joakim Tjernlund
On Wed, 2016-05-11 at 11:54 +0200, Mario Six wrote:
> On Tue, May 10, 2016 at 1:22 AM, Hamish Martin <
> hamish.mar...@alliedtelesis.co.nz> wrote:
> 
> > 
> > Hi,
> > 
> > I'm looking for uboot driver support for the Freescale QorIQ T2080 CPU.
> > This has 4 blocks of GPIOs similar to the single block defined in
> > arch/powerpc/include/asm/mpc85xx_gpio.h.
> > 
> > If someone is working on a driver for that CPU or similar, let me know.
> > Ideally this would fit the new driver model. I'd be happy to help test
> > it out and debug it.
> > 
> > Alternatively, if you know another way to drive those GPIO blocks with
> > existing code, feel free to suggest a way.
> > 
> > Cheers,
> > Hamish Martin.
> > 
> Hi Hamish,
> 
> I posted v2 of a patch series for a MPC85xx GPIO DM driver just yesterday;
> it was
> tested on a P1022, but it's quite likely that it will work with other
> QorIQs,
> too (it's basically arpc/powerpc/include/asm/mpc85xx_gpio.h turned into a
> proper DM driver).

I have not read you patch but I wanted to mention a defect in QorIO:
It cannot read back the DAT register, it always read the pin values.
This means one needs to hold the DAT register in a RAM copy or risk
malfunction when using open drain etc.

See GPIO for QorIO in the kernel for details.

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


Re: [U-Boot] [PATCH v3] spi: fsl_espi: Return all data read from device unmodified

2015-12-12 Thread Joakim Tjernlund
On Fri, 2015-12-11 at 21:19 -0500, Dale P. Smith wrote:
> Signed-off-by: Dale P. Smith 
> ---
> Changes for v2:
>    - First attempt at using git format-patch
> Changes for v3:
>    - Fix subject.
>    - Add changelog

While this is a step in the right direction, this driver needs a rewrite.
- The malloc/memcpy crap need to go.
- TXing 4 bytes a time while while word size is still one byte makes Not 
full/Not empty
  HW flags useless.
There is no real maintainer of this driver though so I am afraid nobody will do 
make this happen.

> 
>  drivers/spi/fsl_espi.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> index b1586d1..c84a7ea 100644
> --- a/drivers/spi/fsl_espi.c
> +++ b/drivers/spi/fsl_espi.c
> @@ -345,17 +345,11 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
> bitlen, const void *data_out,
>   }
>   }
>   }
> - if (data_in) {
> - memcpy(data_in, buffer + 2 * cmd_len, tran_len);
> - if (*buffer == 0x0b) {
> - data_in += tran_len;
> - data_len -= tran_len;
> - *(int *)buffer += tran_len;
> - }
> - }
>   spi_cs_deactivate(slave);
>   }
>  
> + if (data_in)
> + memcpy(data_in, buffer + rx_offset, len);
>   free(buffer);
>   return 0;
>  }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/2] Reserve secure memory

2015-11-16 Thread Joakim Tjernlund
On Mon, 2015-11-16 at 08:34 -0800, York Sun wrote:
> Secure memory is at the end of memory, separated and reserved
> from OS, tracked by gd->secure_ram. Secure memory can host
> MMU tables, security monitor, etc.

Don't see the difference with pram here?
Also, do you really wan't to hide the memory from Linux or will
a resv map do? You get a lot of small TLB maps if memory is non power of 2

 Jocke

> 
> Signed-off-by: York Sun 
> 
> ---
> 
> Changes in v4: None
> Changes in v3:
>   Put ifdef around secure_ram
>   Move defining CONFIG_SYS_MEM_RESERVE_SECURE to patch 2/2
> 
> Changes in v2:
>   Do not use CONFIG_SYS_MEM_TOP_HIDE mechanism
> 
> Changes in v1:
>   Initial patch.
>   Depends on http://patchwork.ozlabs.org/patch/540248/
> 
>  README|8 
>  common/board_f.c  |9 +
>  include/asm-generic/global_data.h |4 
>  3 files changed, 21 insertions(+)
> 
> diff --git a/README b/README
> index ef8d437..61cbc82 100644
> --- a/README
> +++ b/README
> @@ -3881,6 +3881,14 @@ Configuration Settings:
>   Scratch address used by the alternate memory test
>   You only need to set this if address zero isn't writeable
>  
> +- CONFIG_SYS_MEM_RESERVE_SECURE
> + If defined, the size of CONFIG_SYS_MEM_RESERVE_SECURE memory
> + is substracted from total RAM and won't be reported to OS.
> + This memory can be used as secure memory. A variable
> + gd->secure_ram is used to track the location. In systems
> + the RAM base is not zero, or RAM is divided into banks,
> + this variable needs to be recalcuated to get the address.
> +
>  - CONFIG_SYS_MEM_TOP_HIDE (PPC only):
>   If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config 
> header,
>   this specified memory area will get subtracted from the top
> diff --git a/common/board_f.c b/common/board_f.c
> index 725eb18..8061105 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -323,6 +323,15 @@ static int setup_dest_addr(void)
>    * Ram is setup, size stored in gd !!
>    */
>   debug("Ram size: %08lX\n", (ulong)gd->ram_size);
> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
> + /* Reserve memory for secure MMU tables, and/or security monitor */
> + gd->ram_size -= CONFIG_SYS_MEM_RESERVE_SECURE;
> + /*
> +  * Record secure memory location. Need recalcuate if memory splits
> +  * into banks, or the ram base is not zero.
> +  */
> + gd->secure_ram = gd->ram_size;
> +#endif
>  #if defined(CONFIG_SYS_MEM_TOP_HIDE)
>   /*
>    * Subtract specified amount of memory to hide so that it won't
> diff --git a/include/asm-generic/global_data.h 
> b/include/asm-generic/global_data.h
> index d0383f3..8cdafd6 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -58,6 +58,10 @@ typedef struct global_data {
>  
>   unsigned long relocaddr;/* Start address of U-Boot in RAM */
>   phys_size_t ram_size;   /* RAM size */
> +#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
> + /* Secure memory addr. LSB is a flag for "secured". */
> + phys_addr_t secure_ram;
> +#endif
>   unsigned long mon_len;  /* monitor len */
>   unsigned long irq_sp;   /* irq stack pointer */
>   unsigned long start_addr_sp;/* start_addr_stackpointer */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1] armv8: fsl-layerscale: Rewrite reserving memory for MC and debug server

2015-11-16 Thread Joakim Tjernlund
On Mon, 2015-11-16 at 09:03 -0800, York Sun wrote:
> 
> On 11/12/2015 02:54 PM, Joakim Tjernlund wrote:
> > On Thu, 2015-11-12 at 14:20 -0800, York Sun wrote:
> > > Introduce a new function to calculate reserved memory to replace macro
> > > CONFIG_SYS_MEM_TOP_HIDE for more flexibility. Legacy use of this macro is
> > > still supported. MC and debug server are not board-specific. Move the
> > > reservation function to SoC file. Reduce debug server memory by 2MB to
> > > make room for secure memory.
> > 
> > I would make sure "pram" is first to reserve memory, is it?
> > 
> 
> (previous reply wasn't caught by patchwork, adding more info)
> 
> Yes, pram is used to reserve small memory from the top of u-boot memory, not
> necessarily the top of total memory. For example, a 32-bit u-boot with large
> memory. This patch deals with carving memory from the end of memory, which 
> could
> be far away from u-boot top. Even in system with small memory, it is still
> correct, because pram reserves memory from the _top_ of u-boot and this
> mechanism reserved memory is hidden from u-boot.

And I realize I am mixing pram and CONFIG_SYS_MEM_TOP_HIDE. Your patch
reserves memory before CONFIG_SYS_MEM_TOP_HIDE which might be confusing
for some. Why do you need another( then CONFIG_SYS_MEM_TOP_HIDE) method to 
reserve memory?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1] armv8: fsl-layerscale: Rewrite reserving memory for MC and debug server

2015-11-12 Thread Joakim Tjernlund
On Thu, 2015-11-12 at 14:20 -0800, York Sun wrote:
> Introduce a new function to calculate reserved memory to replace macro
> CONFIG_SYS_MEM_TOP_HIDE for more flexibility. Legacy use of this macro is
> still supported. MC and debug server are not board-specific. Move the
> reservation function to SoC file. Reduce debug server memory by 2MB to
> make room for secure memory.

I would make sure "pram" is first to reserve memory, is it?

 Jocke

> 
> Signed-off-by: York Sun 
> 
> ---
> 
>  README  |6 +++---
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c |   18 ++
>  board/freescale/ls2085a/ls2085a.c   |   17 -
>  board/freescale/ls2085aqds/ls2085aqds.c |   17 -
>  board/freescale/ls2085ardb/ls2085ardb.c |   17 -
>  common/board_f.c|   14 +++---
>  include/configs/ls2085a_common.h|5 ++---
>  7 files changed, 34 insertions(+), 60 deletions(-)
> 
> diff --git a/README b/README
> index 61cbc82..390ee10 100644
> --- a/README
> +++ b/README
> @@ -3889,7 +3889,7 @@ Configuration Settings:
>   the RAM base is not zero, or RAM is divided into banks,
>   this variable needs to be recalcuated to get the address.
>  
> -- CONFIG_SYS_MEM_TOP_HIDE (PPC only):
> +- CONFIG_SYS_MEM_TOP_HIDE:
>   If CONFIG_SYS_MEM_TOP_HIDE is defined in the board config 
> header,
>   this specified memory area will get subtracted from the top
>   (end) of RAM and won't get "touched" at all by U-Boot. By
> @@ -5068,8 +5068,8 @@ This firmware often needs to be loaded during U-Boot 
> booting.
>  - CONFIG_SYS_DEBUG_SERVER_DRAM_BLOCK_MIN_SIZE
>   Define minimum DDR size required for debug server image
>  
> -- CONFIG_SYS_MEM_TOP_HIDE_MIN
> - Define minimum DDR size to be hided from top of the DDR memory
> +- CONFIG_SYS_MC_RESERV_MEM_ALIGN
> + Define alignment of reserved memory MC requires
>  
>  Reproducible builds
>  ---
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> index cda8d9b..72cb9d9 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
> @@ -663,3 +663,21 @@ void reset_cpu(ulong addr)
>   val |= 0x02;
>   scfg_out32(rstcr, val);
>  }
> +
> +unsigned long board_reserve_ram_top(unsigned long ram_size)
> +{
> + unsigned long ram_top = ram_size;
> +
> +/* Carve the Debug Server private DRAM block from the end of DRAM */
> +#ifdef CONFIG_FSL_DEBUG_SERVER
> + ram_top -= debug_server_get_dram_block_size();
> +#endif
> +
> +/* Carve the MC private DRAM block from the end of DRAM */
> +#ifdef CONFIG_FSL_MC_ENET
> + ram_top -= mc_get_dram_block_size();
> + ram_top &= ~(CONFIG_SYS_MC_RESERV_MEM_ALIGN - 1);
> +#endif
> +
> + return ram_size - ram_top;
> +}
> diff --git a/board/freescale/ls2085a/ls2085a.c 
> b/board/freescale/ls2085a/ls2085a.c
> index 27481e2..6f4c3d4 100644
> --- a/board/freescale/ls2085a/ls2085a.c
> +++ b/board/freescale/ls2085a/ls2085a.c
> @@ -66,23 +66,6 @@ int arch_misc_init(void)
>  }
>  #endif
>  
> -unsigned long get_dram_size_to_hide(void)
> -{
> - unsigned long dram_to_hide = 0;
> -
> -/* Carve the Debug Server private DRAM block from the end of DRAM */
> -#ifdef CONFIG_FSL_DEBUG_SERVER
> - dram_to_hide += debug_server_get_dram_block_size();
> -#endif
> -
> -/* Carve the MC private DRAM block from the end of DRAM */
> -#ifdef CONFIG_FSL_MC_ENET
> - dram_to_hide += mc_get_dram_block_size();
> -#endif
> -
> - return roundup(dram_to_hide, CONFIG_SYS_MEM_TOP_HIDE_MIN);
> -}
> -
>  int board_eth_init(bd_t *bis)
>  {
>   int error = 0;
> diff --git a/board/freescale/ls2085aqds/ls2085aqds.c 
> b/board/freescale/ls2085aqds/ls2085aqds.c
> index b02d6e8..8898cc3 100644
> --- a/board/freescale/ls2085aqds/ls2085aqds.c
> +++ b/board/freescale/ls2085aqds/ls2085aqds.c
> @@ -251,23 +251,6 @@ int arch_misc_init(void)
>  }
>  #endif
>  
> -unsigned long get_dram_size_to_hide(void)
> -{
> - unsigned long dram_to_hide = 0;
> -
> -/* Carve the Debug Server private DRAM block from the end of DRAM */
> -#ifdef CONFIG_FSL_DEBUG_SERVER
> - dram_to_hide += debug_server_get_dram_block_size();
> -#endif
> -
> -/* Carve the MC private DRAM block from the end of DRAM */
> -#ifdef CONFIG_FSL_MC_ENET
> - dram_to_hide += mc_get_dram_block_size();
> -#endif
> -
> - return roundup(dram_to_hide, CONFIG_SYS_MEM_TOP_HIDE_MIN);
> -}
> -
>  #ifdef CONFIG_FSL_MC_ENET
>  void fdt_fixup_board_enet(void *fdt)
>  {
> diff --git a/board/freescale/ls2085ardb/ls2085ardb.c 
> b/board/freescale/ls2085ardb/ls2085ardb.c
> index 18953b8..efddf74 100644
> --- a/board/freescale/ls2085ardb/ls2085ardb.c
> +++ b/board/freescale/ls2085ardb/ls2085ardb.c
> @@ -217,23 +217,6 @@ int arch_misc_init(void)
>  }
>  #endif
>  
> -unsigned long get_dram_size_to_hide(void)
> -{

Re: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3

2015-11-11 Thread Joakim Tjernlund
On Thu, 2015-11-05 at 12:47 -0800, York Sun wrote:
> 
> On 11/05/2015 11:53 AM, Joakim Tjernlund wrote:
> > On Thu, 2015-11-05 at 10:29 -0800, York Sun wrote:
> > > 
> > > On 11/05/2015 10:19 AM, Joakim Tjernlund wrote:
> > > > On Thu, 2015-11-05 at 09:42 -0800, York Sun wrote:
> > > > > 
> > > > > On 11/05/2015 01:55 AM, Joakim Tjernlund wrote:
> > > > > > On Thu, 2015-11-05 at 08:23 +, Yuantian Tang wrote:
> > > > > > > Hi Jocke,
> > > > > > > 
> > > > > > > we achieved deep sleep mode that did exactly what you asked for.
> > > > > > > If waken up from deep sleep, soc will resume from uboot and 
> > > > > > > re-initialized DDR controller with
> > > > > > > contents
> > > > > > > untouched.
> > > > > > > Please refer to drivers/ddr/fsl/fsl_ddr_gen4.c and look at 
> > > > > > > DEEP_SLEEP related code.
> > > > > > 
> > > > > > Looking at it now and it looks the same as for ddr3? Some questions 
> > > > > > though:
> > > > > >  289if (is_warm_boot()) {
> > > > > >  289 /* enter self-refresh */
> > > > > >  290 temp_sdram_cfg = ddr_in32(>sdram_cfg_2);
> > > > > >  291 temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
> > > > > >  292 ddr_out32(>sdram_cfg_2, temp_sdram_cfg);
> > > > > > 
> > > > > > Why do you need to force SR here? The DDR RAM must already be in SR 
> > > > > > at this point?
> > > > > > I come from CPU reset state so my DDR controller has HW default 
> > > > > > values so
> > > > > > this does not feel safe.
> > > > > 
> > > > > This may be redundant. If the code runs to this line, it should come 
> > > > > back from a
> > > > > deep sleep. The core is in reset state but the DDR controller is not. 
> > > > > It should
> > > > > be in self-refresh mode. I will leave that to Yuantian to comment.
> > > > 
> > > > OK
> > > > 
> > > > > 
> > > > > > 
> > > > > >  293 /* do board specific memory setup */
> > > > > >  294 board_mem_sleep_setup();
> > > > > >  295 
> > > > > >  296 temp_sdram_cfg = (ddr_in32(>sdram_cfg) | 
> > > > > > SDRAM_CFG_BI);
> > > > > > SDRAM_CFG_BI skips a lot(all?) init of DDR RAM. What if you want to 
> > > > > > change some DDR RAM
> > > > > > timing/config due to a bug? Then you would have to force a cold 
> > > > > > start.
> > > > > > 
> > > > > > Do you use ECC? Seems to be some issues with ECC if you skip D_INIT
> > > > > > 
> > > > > 
> > > > > To perform a warm start, the data in DDR is preserved. So you don't 
> > > > > need to init
> > > > > the data again for ECC. To preserve data, you cannot run D_INIT 
> > > > > again, which
> > > > > will destroy the data for sure.
> > > > 
> > > > yes, but what about SDRAM_CFG_BI? Why do you need to set that here?
> > > > I much rather just skip D_INIT and reconfigure DDR RAM, just in case 
> > > > one wants
> > > > to correct some aspect of DDR config in later releases and feels a lot 
> > > > more robust.
> > > > 
> > > > Our systems cannot be coldstarted just because you upgrade SW on them.
> > > 
> > > Jocke,
> > > 
> > > If your memory has been intialized, you can set [BI] bit to bypass
> > > re-initialization. It does different things than D_INIT. In short, D_INIT
> > > initialize the data, i.e. the content of DDR, while BI bypassing 
> > > initializing
> > > DDR memory (or "chip" if that is easier to understand).
> > 
> > Yes, that is what I want, reinit of chip, but not data contents.
> > I wrote why:
> > "just in case one wants to correct some aspect of DDR config in later 
> > releases and feels a lot more
> > robust"
> 
> Jocke,
> 
> I am not 100% sure. I will take this question to our DDR designer.

I am really want to know ...

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


Re: [U-Boot] [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for LSCH3

2015-11-06 Thread Joakim Tjernlund
On Fri, 2015-11-06 at 02:24 +, Yuantian Tang wrote:
> 
> > -Original Message-
> > From: York Sun [mailto:york...@freescale.com]
> > Sent: Friday, November 06, 2015 1:42 AM
> > To: Joakim Tjernlund <joakim.tjernl...@transmode.se>; Tang Yuantian-
> > B29983 <yuantian.t...@freescale.com>; u-boot@lists.denx.de
> > Cc: Kushwaha Prabhakar-B32579 <prabha...@freescale.com>; Sharma
> > Bhupesh-B45370 <bhupesh.sha...@freescale.com>; tr...@konsulko.com;
> > Liu Shengzhou-B36685 <shengzhou@freescale.com>;
> > c...@cumulusnetworks.com; l.majew...@samsung.com;
> > yamad...@jp.panasonic.com
> > Subject: Re: [PATCH v1 0/7] Enable high speed and heavy load for DDR4 for
> > LSCH3
> > 
> > 
> > 
> > On 11/05/2015 01:55 AM, Joakim Tjernlund wrote:
> > > On Thu, 2015-11-05 at 08:23 +, Yuantian Tang wrote:
> > > > Hi Jocke,
> > > > 
> > > > we achieved deep sleep mode that did exactly what you asked for.
> > > > If waken up from deep sleep, soc will resume from uboot and
> > > > re-initialized DDR controller with contents untouched.
> > > > Please refer to drivers/ddr/fsl/fsl_ddr_gen4.c and look at DEEP_SLEEP
> > related code.
> > > 
> > > Looking at it now and it looks the same as for ddr3? Some questions 
> > > though:
> > >  289  if (is_warm_boot()) {
> > >  289 /* enter self-refresh */
> > >  290 temp_sdram_cfg = ddr_in32(>sdram_cfg_2);
> > >  291 temp_sdram_cfg |= SDRAM_CFG2_FRC_SR;
> > >  292 ddr_out32(>sdram_cfg_2, temp_sdram_cfg);
> > > 
> > > Why do you need to force SR here? The DDR RAM must already be in SR at
> > this point?
> > > I come from CPU reset state so my DDR controller has HW default values
> > > so this does not feel safe.
> > 
> > This may be redundant. If the code runs to this line, it should come back 
> > from
> > a deep sleep. The core is in reset state but the DDR controller is not. It 
> > should
> > be in self-refresh mode. I will leave that to Yuantian to comment.
> > 
> This is mandatory.  the steps are: re-enter SR mode, enable DDR controller, 
> exit SR mode. We do that to 
> smooth the transition and avoid any glitch caused when controller takes over 
> memory.

hmm, why not do this always? I can't hurt normal operation I think.
It would be less special code for this type of operation.

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


  1   2   3   4   5   6   7   >