Re: [U-Boot] [PATCH] mmc: dw_mmc: Round up descriptor end to nearest multiple of cacheline size
On 3/30/19 10:18 PM, Simon Glass wrote: > Hi Marek, > > On Sat, 23 Mar 2019 at 11:55, Marek Vasut wrote: >> >> The driver currently calculates the end address of cache flush operation >> for the DMA descriptors by adding cacheline size to the start address of >> the last DMA descriptor. This is not safe, as the cacheline size may be, >> in some unlikely cases, smaller than the DMA descriptor size. Replace the >> addition with roundup() applied on the end address of the last DMA >> descriptor to round it up to the nearest cacheline size multiple. >> >> Signed-off-by: Marek Vasut >> Cc: Jaehoon Chung >> Cc: Simon Glass >> --- >> drivers/mmc/dw_mmc.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c >> index 72570235cb..bec30b1479 100644 >> --- a/drivers/mmc/dw_mmc.c >> +++ b/drivers/mmc/dw_mmc.c >> @@ -74,15 +74,15 @@ static void dwmci_prepare_data(struct dwmci_host *host, >> dwmci_set_idma_desc(cur_idmac, flags, cnt, >> (ulong)bounce_buffer + (i * PAGE_SIZE)); >> >> + cur_idmac++; > > What is this change for? I don't see it mentioned above. AFAIR you need to increment the pointer to cur_idmac before breaking out of the loop, otherwise data_end might point a bit before the actual end of the buffer. >> if (blk_cnt <= 8) >> break; >> blk_cnt -= 8; >> - cur_idmac++; >> i++; >> } while(1); >> >> data_end = (ulong)cur_idmac; >> - flush_dcache_range(data_start, data_end + ARCH_DMA_MINALIGN); >> + flush_dcache_range(data_start, roundup(data_end, ARCH_DMA_MINALIGN)); >> >> ctrl = dwmci_readl(host, DWMCI_CTRL); >> ctrl |= DWMCI_IDMAC_EN | DWMCI_DMA_EN; >> -- >> 2.20.1 >> > > Regards, > Simon > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/11] sound: Add sound support for Nyan
Hi Jon, On Fri, 8 Feb 2019 at 02:50, Jon Hunter wrote: > > > On 08/02/2019 04:14, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 21 Jan 2019 at 16:43, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Mon, 21 Jan 2019 at 10:46, Tom Warren wrote: > >>> > >>> Let's have Jon Hunter take a look, I'll take it in to tegra/master if he > >>> acks it. > >> > >> OK thank you. For now I've picked up the non-Tegra patches from that > >> series so I can get this out. > > > > Any news on this? is it still pending? > > I have reviewed patches 7-11 on patchwork (sorry I don't have the > originals and so cannot reply inline as normal). Overall looks fine to > me but a couple minor comments ... > > Patch 7 there is a typo in the Kconfig ... > > +config I2S_TEGRA > + bool "Enable I2C support for Nvidia Tegra SoCs" > > s/I2C/I2S > > Patch 8, in the function 'i2s_tx_init' it should not be necessary to > program the slot_ctrl register for I2S mode. OK I will fix those too in v2. > > Patch 8, where is 'audio_pll_clk' used? The rate looks a bit odd. For > example, on the Jetson TK1 (which has the rt5677 codec), the codec > operates with an MCLK of 256*fs, so at 48kHz that would be 12.288MHz. Actually the clock is calculated, so this field is just set for completeness. It isn't used in the tegra path. Regards, SImon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon,
On Sat, 30 Mar 2019 at 15:40, Simon Goldschmidt
wrote:
>
>
>
> Simon Glass schrieb am Sa., 30. März 2019, 22:18:
>>
>> Hi Simon,
>>
>> On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt
>> wrote:
>> >
>> >
>> >
>> > Simon Goldschmidt schrieb am Sa., 30.
>> > März 2019, 21:18:
>> >>
>> >>
>> >>
>> >> Simon Glass schrieb am Sa., 30. März 2019, 21:06:
>> >>>
>> >>> Hi Simon,
>> >>>
>> >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt
>> >>> wrote:
>> >>> >
>> >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it
>> >>> > clears
>> >>> > the bss before calling board_init_f() instead of clearing it before
>> >>> > calling
>> >>> > board_init_r().
>> >>> >
>> >>> > This also ensures that variables placed in BSS can be shared between
>> >>> > board_init_f() and board_init_r() in SPL.
>> >>> >
>> >>> > Such global variables are used, for example, when loading things from
>> >>> > FAT
>> >>> > before SDRAM is available: the full heap required for FAT uses global
>> >>> > variables and clearing BSS after board_init_f() would reset the heap
>> >>> > state.
>> >>> > An example for such a usage is socfpa_arria10 where an FPGA
>> >>> > configuration
>> >>> > is required before SDRAM can be used.
>> >>> >
>> >>> > Make the new option depend on ARM for now until more implementations
>> >>> > follow.
>> >>> >
>> >>>
>> >>> I still have objections to this series and I think we should discuss
>> >>> other ways of solving this problem.
>> >>>
>> >>> Does socfgpa have SRAM that could be used before SDRAM is available?
>> >>> If so, can we not use that for the configuration? What various are
>> >>> actually in BSS that are needed before board_init_r() is called? Can
>> >>> they not be in a struct created from malloc()?
>> >>
>> >>
>> >> The problem is the board needs to load an FPGA configuration from FAT
>> >> before SDRAM is available. Yes, this is loaded into SRAM of course, but
>> >> the whole code until that is done uses so many malloc/free iterations
>> >> that The simple mall of implementation would require too much memory.
>> >>
>> >> And it's the full malloc state variables only that use BSS, not the FAT
>> >> code.
>> >>
>> >> One way out could be to move the full mall of state variables into 'gd'...
>> >
>> >
>> > Maybe I should point out again that the whole purpose of this series is to
>> > have an SPL that uses full malloc right from the start. This is currently
>> > not possible as full malloc needs BSS.
>>
>> Right, and our assumption/design is that full malloc() requires SRAM.
>>
>> Here we have an architecture that requires FAT just to init its SDRAM.
>> FAT requires malloc() and free() and there is not enough SRAM to skip
>> the free() calls. So we have to use full malloc() and that uses BSS.
>> But BSS is not available before board_init_r(). But we need to init
>> SDRAM before board_init_r().
>>
>> Firstly I'd point out that someone should speak to the chip designers.
>> Did anyone try to boot U-Boot on the SoC model?
>
>
> Well, it's a U-Boot thing to load it from FAT. It could probably be loaded
> from RAW mmc without problems, so I don't know if it's a chip designers
> issue. I think it's an issue that we need to fix in U-Boot: we have a good
> full malloc implementation but it's not usable in all cases were it should be.
OK then why use FAT? I assumed it was a boot-ROM requirement. How does
the boot ROM load SPL?
>
>>
>> I think it is possible to change dlmalloc to put its variables in a
>> struct. Then I suppose the struct pointer could be kept in gd. That
>> would be one solution. Then full malloc() could be inited in
>> spl_common_init() perhaps.
>
>
> That might be worth a try.
Yes shouldn't be too painful. I suspect it would be neutral on code size, too.
>
>>
>> Another option might be to update the FAT code to use
>> ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in
>> places, and perhaps to disable all caching for this case. Then it
>> might work with simple malloc().
>
>
> Hmm, then the next platform will have problems because allocating via malloc
> would be preferable. If really rather fix using dlmalloc instead.
Hmm but there is no obvious analysis behind your preference. If we
have code like this:
do_something_with_fat()
{
void *buf = malloc(...);
...
free(buf);
}
it seems to me we should convert it to use the stack instead, unless
there is some recursion problem, etc. Otherwise we are just causing
pointless churn on malloc().
>
>>
>> Another option would be to put the FPGA image in a known position on
>> the media, outside the FAT partition. The position could perhaps be
>> written into a FAT file, and reading just that file in SPL might not
>> involve many free() operations.
>
>
> Sounds like a workaround, too. I think the U-Boot infrastructure should work
> for the boards, not placing restrictions on them.
I'll await your answer to my first question in this email before
passing judgement.
>
>>
>>
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Sa., 30. März 2019, 22:18: > Hi Simon, > > On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt > wrote: > > > > > > > > Simon Goldschmidt schrieb am Sa., 30. > März 2019, 21:18: > >> > >> > >> > >> Simon Glass schrieb am Sa., 30. März 2019, 21:06: > >>> > >>> Hi Simon, > >>> > >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > >>> wrote: > >>> > > >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > clears > >>> > the bss before calling board_init_f() instead of clearing it before > calling > >>> > board_init_r(). > >>> > > >>> > This also ensures that variables placed in BSS can be shared between > >>> > board_init_f() and board_init_r() in SPL. > >>> > > >>> > Such global variables are used, for example, when loading things > from FAT > >>> > before SDRAM is available: the full heap required for FAT uses global > >>> > variables and clearing BSS after board_init_f() would reset the heap > state. > >>> > An example for such a usage is socfpa_arria10 where an FPGA > configuration > >>> > is required before SDRAM can be used. > >>> > > >>> > Make the new option depend on ARM for now until more implementations > follow. > >>> > > >>> > >>> I still have objections to this series and I think we should discuss > >>> other ways of solving this problem. > >>> > >>> Does socfgpa have SRAM that could be used before SDRAM is available? > >>> If so, can we not use that for the configuration? What various are > >>> actually in BSS that are needed before board_init_r() is called? Can > >>> they not be in a struct created from malloc()? > >> > >> > >> The problem is the board needs to load an FPGA configuration from FAT > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > whole code until that is done uses so many malloc/free iterations that The > simple mall of implementation would require too much memory. > >> > >> And it's the full malloc state variables only that use BSS, not the FAT > code. > >> > >> One way out could be to move the full mall of state variables into > 'gd'... > > > > > > Maybe I should point out again that the whole purpose of this series is > to have an SPL that uses full malloc right from the start. This is > currently not possible as full malloc needs BSS. > > Right, and our assumption/design is that full malloc() requires SRAM. > > Here we have an architecture that requires FAT just to init its SDRAM. > FAT requires malloc() and free() and there is not enough SRAM to skip > the free() calls. So we have to use full malloc() and that uses BSS. > But BSS is not available before board_init_r(). But we need to init > SDRAM before board_init_r(). > > Firstly I'd point out that someone should speak to the chip designers. > Did anyone try to boot U-Boot on the SoC model? > Well, it's a U-Boot thing to load it from FAT. It could probably be loaded from RAW mmc without problems, so I don't know if it's a chip designers issue. I think it's an issue that we need to fix in U-Boot: we have a good full malloc implementation but it's not usable in all cases were it should be. > I think it is possible to change dlmalloc to put its variables in a > struct. Then I suppose the struct pointer could be kept in gd. That > would be one solution. Then full malloc() could be inited in > spl_common_init() perhaps. > That might be worth a try. > Another option might be to update the FAT code to use > ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in > places, and perhaps to disable all caching for this case. Then it > might work with simple malloc(). > Hmm, then the next platform will have problems because allocating via malloc would be preferable. If really rather fix using dlmalloc instead. > Another option would be to put the FPGA image in a known position on > the media, outside the FAT partition. The position could perhaps be > written into a FAT file, and reading just that file in SPL might not > involve many free() operations. > Sounds like a workaround, too. I think the U-Boot infrastructure should work for the boards, not placing restrictions on them. > I hesitate to suggest enhancing simple malloc() to support a free > list. That would increase the code size and I'm not sure it would be > better than using full malloc(). > Yes, I think that might result in making a second dlmalloc :-) Thanks for your thoughts and input! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] usb: kbd: Properly translate up/down arrow keys
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > So far arrows key pressed on an USB keyboard got translated to some > low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand > these codes, but the standard for those keys is to use ANSI control Which standard? > sequences for cursor movement (ESC [ A). > Our own boot menu is a victim of this, currently we cannot change the > selection with an USB keyboard due to this. > > Since we already implement a queue for USB key codes, we can just insert > the three character ANSI sequence into the key buffer. This fixes the > bootmenu, and is more universal for other users (UEFI) as well. > > Signed-off-by: Andre Przywara > --- > common/usb_kbd.c | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] sunxi: allow boards to de-select SYS_WHITE_ON_BLACK font scheme
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > In the sunxi-common.h config header we unconditionally define > CONFIG_SYS_WHITE_ON_BLACK, although it's actually a Kconfig option which > could be individually selected by a user. > Remove this #define from the header and let it default to "y" on sunxi > boards (like we do for other platforms). > > Signed-off-by: Andre Przywara > --- > drivers/video/Kconfig | 2 +- > include/configs/sunxi-common.h | 1 - > 2 files changed, 1 insertion(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: Calculate timeout from transfer length
Hi Marek,
On Sat, 23 Mar 2019 at 11:55, Marek Vasut wrote:
>
> The current 4-minute data transfer timeout is misleading and broken.
> Instead of such a long wait, calculate the timeout duration based on
> the length of the data transfer. The current formula is the transfer
> length in bits, divided by a multiplication of bus frequency in Hz,
> bus width, DDR mode and converted the mSec. The value is bounded from
> the bottom to 1000 mSec.
>
> Signed-off-by: Marek Vasut
> Cc: Jaehoon Chung
> Cc: Simon Glass
> ---
> drivers/mmc/dw_mmc.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 93a836eac3..8278f1dacb 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -116,20 +116,29 @@ static int dwmci_fifo_ready(struct dwmci_host *host,
> u32 bit, u32 *len)
>
> static int dwmci_data_transfer(struct dwmci_host *host, struct mmc_data
> *data)
> {
> + struct mmc *mmc = host->mmc;
> int ret = 0;
> - u32 timeout = 24;
> - u32 mask, size, i, len = 0;
> + u32 timeout, mask, size, i, len = 0;
> u32 *buf = NULL;
> ulong start = get_timer(0);
> u32 fifo_depth = (((host->fifoth_val & RX_WMARK_MASK) >>
> RX_WMARK_SHIFT) + 1) * 2;
>
> - size = data->blocksize * data->blocks / 4;
> + size = data->blocksize * data->blocks;
> if (data->flags == MMC_DATA_READ)
> buf = (unsigned int *)data->dest;
> else
> buf = (unsigned int *)data->src;
>
> + timeout = size * 8 * 1000; /* counting in bits and msec */
> + timeout *= 2; /* wait twice as long */
> + timeout /= mmc->clock;
> + timeout /= mmc->bus_width;
> + timeout /= mmc->ddr_mode ? 2 : 1;
> + timeout = (timeout < 1000) ? 1000 : timeout;
Can you put all this in a function (like calc_timeout_ms(size, clock,
bus_width, ddr_mode)) that returns the correct timeout given the
parameters? That would provide a modicum of documentation.
> +
> + size /= 4;
> +
> for (;;) {
> mask = dwmci_readl(host, DWMCI_RINTSTS);
> /* Error during data transfer. */
> --
> 2.20.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] video/console: Convert UTF-8 codes to CP437 code points
Hi Andre, On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > The character set used by U-Boot's built-in fonts is the old "code > page 437" (from the original IBM PC). > However people would probably expect UTF-8 on a terminal these days, the > UEFI code definitely does. > > Provide a conversion routine to convert a UTF-8 byte stream into a CP437 > character code. This uses a combination of arrays and switch/case > statements to provide an efficient way of translating the large Unicode > character range to the 8 bits used for CP437. > > This fixes UEFI display on the DM_VIDEO console, which were garbled for > any non-ASCII characters, for instance for the block graphic characters > used by Grub to display the menu. > > Signed-off-by: Andre Przywara > --- > drivers/video/Makefile| 1 + > drivers/video/utf8_cp437.c| 170 > ++ > drivers/video/vidconsole-uclass.c | 8 +- > include/video_console.h | 9 ++ > 4 files changed, 186 insertions(+), 2 deletions(-) > create mode 100644 drivers/video/utf8_cp437.c OMG unicode comes to U-Boot. This might be the beginning of the end. Can we make this a Kconfig option to avoid increasing code size? We can imply it when EFI is enabled. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address
Hi Eugeniu, On Mon, 25 Mar 2019 at 04:44, Eugeniu Rosca wrote: > > Hello Simon, > > On Sun, Mar 10, 2019 at 03:51:47PM -0600, Simon Glass wrote: > [..] > > Reviewed-by: Simon Glass > > Can this fix go to u-boot-dm or is more review required? > Yes it looks like it is in my queue. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] video/console: Factor out actual character output
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > In preparation for doing character set translations, factor out the > actual glyph display functionality into a separate function. > This will be used in a subsequent patch. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 42 > +-- > 1 file changed, 27 insertions(+), 15 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 5/9] Makefile: use custom ITS to build u-boot.img if SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set
On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot wrote: > > If SPL_FIT_SOURCE or SPL_FIT_GENERATOR are set, then the default output > image should be built using the provided/generated ITS, not using the > default template implemented by mkimage. > In that case, make u-boot.img a symbolic link to u-boot.itb > > Signed-off-by: Jean-Jacques Hiblot > --- > > Makefile | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT
On Fri, 15 Mar 2019 at 11:13, Krzysztof Kozlowski wrote:
>
> The CONFIG_DM_I2C_COMPAT was introduced in
> include/configs/exynos5-common.h in commit 189d80166b31 ("exynos5:
> enable dm i2c") and then it propagated up to configs/arndale_defconfig.
> However since beginning the Arndale board (Exynos5250) was not using
> I2C.
>
> In fact, the Arndale board is not configuring its PMIC (S5M8767) which
> uses I2C bus. This setting can be thus safely removed to fix build
> warning:
>
> This board uses CONFIG_DM_I2C_COMPAT. Please remove
> (possibly in a subsequent patch in your series)
> before sending patches to the mailing list.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Not tested on Arndale board. Testing is welcomed.
> ---
> configs/arndale_defconfig | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] rk3288-board: remove pinctrl call for debug uart
Hi Urja, On Fri, 22 Mar 2019 at 13:15, Urja Rannikko wrote: > > This failed and caused a boot failure on c201, and afaik > the pins should be setup by the new pinctrl driver. It should be set up in SPL, if enabled. I wonder when this code is actually used? > > Signed-off-by: Urja Rannikko > --- > arch/arm/mach-rockchip/rk3288-board.c | 12 > 1 file changed, 12 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] vsprintf: Support phys_addr_t specifier unconditionally
On Tue, 12 Mar 2019 at 04:38, Thierry Reding wrote:
>
> From: Thierry Reding
>
> When phys_addr_t printf specifier support was first introduced in commit
> 1eebd14b7902 ("vsprintf: Add modifier for phys_addr_t"), it was enabled
> only if CONFIG_CMD_NET was selected. Since physical addresses are not
> unique to networking support it doesn't make sense to conditionally add
> it in those cases only. Move support for it outside of the CMD_NET guard
> so that the specifier is always supported.
>
> Signed-off-by: Thierry Reding
> ---
> lib/vsprintf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Is there a code-size impact here? Perhaps instead it should be a new
Kconfig option, implied by CMD_NET?
Reviewed-by: Simon Glass
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] serial: add skipping init option
Hi Lukasz, On Wed, 27 Mar 2019 at 03:34, Lukasz Majewski wrote: > > Hi Simon, Jun, > > > Hi Jun, > > > > On Fri, 22 Mar 2019 at 16:02, Jun Nie wrote: > > > > > > Simon Glass 于2019年3月22日周五 下午3:56写道： > > > > > > > > Hi Jun, > > > > > > > > On Fri, 22 Mar 2019 at 15:20, Jun Nie > > > > wrote: > > > > > > > > > > add skipping init option to avoid corrupt data in console > > > > > if serial is already initilized when u-boot start its excution. > > > > > > > > > > Signed-off-by: Jun Nie > > > > > --- > > > > > drivers/serial/Kconfig | 6 ++ > > > > > 1 file changed, 6 insertions(+) > > > > > > > > Could we use a device-tree property for this? Some UARTs have a > > > > 'skip-init' property. > > > > > > > > Regards, > > > > Simon > > > > > > Hi Simon, > > > > > > It is a good suggestion. But device tree is board specific, while > > > the config is boot flow specific. For ATF -> OPTEE -> U-BOOT case, > > > initialization should be skipped. Without earlier initialization > > > from firmware, U-boot should do it by itself. So I need find a > > > solution that is defconfig specific, instead of device tree > > > specific. > > > > So you want something that is flow-specific, I think. Your thinking is > > that the defconfig specifies this. Is that because certain boards > > require ATF/Optee? > > > > Should we consider having a way to tell U-Boot that it is running > > from Optee? > > > > Could the UART driver detect that the UART is already inited? > > Isn't this issue similar to: > http://patchwork.ozlabs.org/patch/820824/ > > and > > http://patchwork.ozlabs.org/patch/865963/ > Yes. But in the case of this patch I'm hoping we don't need it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Fri, 22 Mar 2019 at 09:32, Dalon Westergreen wrote: > > From: Dalon Westergreen > > CONFIG_OF_EMBED was primarily enabled to support the stratix10 > spl hex file requirements. Since this option now produces a > warning during build, and the spl hex can be created using > alternate methods, CONFIG_OF_EMBED is no longer needed. > > Signed-off-by: Dalon Westergreen > --- > configs/socfpga_stratix10_defconfig | 1 - > include/configs/socfpga_stratix10_socdk.h | 4 ++-- > 2 files changed, 2 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] video/console: Fix DM_VIDEO font glyph array indexing
Hi Andre, On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > When the character to be printed on a DM_VIDEO console is from the > "extended ASCII" range (0x80 - 0xff), it will be treated as a negative > number, as it's declared as a signed char. This leads to negative array > indicies into the glyph bitmap array, and random garbled characters. > > Cast the character to an unsigned type to make the index always positive > and avoid an out-of-bounds access. > > Signed-off-by: Andre Przywara > --- > drivers/video/console_normal.c | 3 ++- > drivers/video/console_rotate.c | 7 --- > 2 files changed, 6 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass Should use u8 instead of uint8_t. It might make sense to adjust one of the tests to output such a character. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: remove pre reloc properties in SPL and TPL device tree
Hi Patrick,
On Wed, 20 Mar 2019 at 11:24, Patrick DELAUNAY wrote:
>
> Hi Simon,
>
> > From: Simon Glass
> > Sent: mardi 19 mars 2019 02:25
> >
> > Hi Patrick,
> >
> > On Mon, 11 Feb 2019 at 19:50, Patrick Delaunay
> > wrote:
> > >
> > > We can remove the pre reloc property in SPL and TPL device-tree:
> > > - u-boot,dm-pre-reloc
> > > - u-boot,dm-spl
> > > - u-boot,dm-tpl
> > > As only the needed node are kept by fdtgrep (1st pass).
> > >
> > > The associated function (XXX_pre_reloc) are simple for SPL/TPL:
> > > return always true.
> > >
> > >
> > > Signed-off-by: Patrick Delaunay
> > > ---
> > >
> > > remove pre reloc properties in SPL and TPL device tree
> > >
> > > Patch created after some remarks on previous
> > > http://patchwork.ozlabs.org/patch/1035797/
> > >
> > > I check the current code and I found a way to reduce the SPL device
> > > tree
> > > size: remove the un-necessary pre reloc parameters in SPL/TPL DT (as
> > > the node check is already managed by fdtgrep)
> > >
> > > But I need to change the DM code to avoid the check on presence of
> > > this parameters...
> > >
> > > On my board stm32mp1-ev1, the SPL device tree is reduced by 790 bytes
> > > (11149 to 10419) and the SPL binary u-boot-spl.stm32 by 798 bytes
> > > (64745 to 63947); the boot is not broken and I have the expected delta
> > > between generated device tree.
> > >
> > > But I don't sure that I see all the side impact of the code change in
> > > SPL/TPL.
> > >
> > > PS: I already see a side effect on this patch, because all node are now
> > > bounded in SPL/TPL, it is no more needed to TAG all the device tree
> > > path but only the last needed children.
> > > But in this case phandle for parent node are not keep.
> >
> > Yes that makes sense. I suppose we could enhance fdtgrep to handle this.
>
> Probably but I checked the code but I don't found a way to handle with
> lidfdt.
>
> I think is completely handle when a region is dumped (for father mode with
> FDT_REG_SUPERNODES)
> in dump_fdt_regions is doen without any property (including phandle),
> only FDT_BEGIN_NODE and FDT_END_NODE are used
>
> => p.want = WANT_NODES_ONLY vs WANT_NODES_AND_PROPS
>
>
> > >
> > >
> > > drivers/core/ofnode.c | 16
> > > drivers/core/util.c | 31 +++
> > > scripts/Makefile.lib | 1 +
> > > 3 files changed, 24 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c index
> > > 0e584c1..5a109dd 100644
> > > --- a/drivers/core/ofnode.c
> > > +++ b/drivers/core/ofnode.c
> > > @@ -700,18 +700,18 @@ int ofnode_read_simple_size_cells(ofnode node)
> > >
> > > bool ofnode_pre_reloc(ofnode node)
> > > {
> > > +#if defined(CONFIG_SPL_BUILD) || defined(CONFIG_TPL_BUILD)
> > > + /* for SPL and TPL the remaining nodes after the fdtgrep 1st pass
> > > +* had property dm-pre-reloc or u-boot,dm-spl/tpl.
> > > +* They are removed in final dtb (fdtgrep 2nd pass)
> > > +*/
> > > + return true;
> > > +#else
> > > if (ofnode_read_bool(node, "u-boot,dm-pre-reloc"))
> > > return true;
> > > if (ofnode_read_bool(node, "u-boot,dm-pre-proper"))
> > > return true;
> > >
> > > -#ifdef CONFIG_TPL_BUILD
> > > - if (ofnode_read_bool(node, "u-boot,dm-tpl"))
> > > - return true;
> > > -#elif defined(CONFIG_SPL_BUILD)
> > > - if (ofnode_read_bool(node, "u-boot,dm-spl"))
> > > - return true;
> > > -#else
> > > /*
> > > * In regular builds individual spl and tpl handling both
> > > * count as handled pre-relocation for later second init.
> > > @@ -719,9 +719,9 @@ bool ofnode_pre_reloc(ofnode node)
> > > if (ofnode_read_bool(node, "u-boot,dm-spl") ||
> > > ofnode_read_bool(node, "u-boot,dm-tpl"))
> > > return true;
> > > -#endif
> > >
> > > return false;
> > > +#endif
> > > }
> > >
> > > int ofnode_read_resource(ofnode node, uint index, struct resource
> > > *res) diff --git a/drivers/core/util.c b/drivers/core/util.c index
> > > 27a6848..451f772 100644
> > > --- a/drivers/core/util.c
> > > +++ b/drivers/core/util.c
> > > @@ -33,16 +33,15 @@ int list_count_items(struct list_head *head)
> > >
> > > bool dm_fdt_pre_reloc(const void *blob, int offset)
> >
> > This function should really be removed. We should be able to use the ofnode
> > version always.
>
> Ok, I migrate the 2 calls of the function =
>drivers/clk/at91/pmc.c:64:!dm_fdt_pre_reloc(fdt,
> offset))
>drivers/clk/altera/clk-arria10.c:257: if (pre_reloc_only &&
> !dm_fdt_pre_reloc(fdt, offset))
>
> and remove the function dm_fdt_pre_reloc in a separet patchset (today I
> think)
>
> => [PATCH 0/3] remove dm_fdt_pre_reloc, replaced by dm_ofnode_pre_reloc
> http://patchwork.ozlabs.org/project/uboot/list/?series=98272
>
> PS: it is already done for dm_ofnode_pre_reloc() in
> h
Re: [U-Boot] [PATCH 4/8] video/console: Implement ANSI clear line command
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > There is a standard ANSI terminal escape sequence to clear a whole line > of text. So far the DM_VIDEO console was missing this code. > > Detect the sequence and use vidconsole_set_row with the background > colour to fix this omission. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 19 +++ > 1 file changed, 19 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Makefile: Add target to generate hex output for combined spl and dtb
Hi,
On Fri, 22 Mar 2019 at 09:32, Dalon Westergreen
wrote:
>
> From: Dalon Westergreen
>
> Some architectures, Stratix10, require a hex formatted spl that combines
> the spl image and dtb. This adds a target to create said hex file with
> and offset of SPL_TEXT_BASE.
>
> Signed-off-by: Dalon Westergreen
> ---
> Makefile | 9 +
> 1 file changed, 9 insertions(+)
Reviewed-by: Simon Glass
Please see below.
>
> diff --git a/Makefile b/Makefile
> index c52a33b403..ecba06ffce 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1074,6 +1074,11 @@ OBJCOPYFLAGS_u-boot-spl.hex =
> $(OBJCOPYFLAGS_u-boot.hex)
> spl/u-boot-spl.hex: spl/u-boot-spl FORCE
> $(call if_changed,objcopy)
>
> +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex
> --change-address=$(CONFIG_SPL_TEXT_BASE)
Can we drop the -dtb part here? u-boot-spl includes the DTB anyway. It
is the -nodtb version which does not.
> +
> +spl/u-boot-spl-dtb.hex: spl/u-boot-spl-dtb.bin FORCE
> + $(call if_changed,objcopy)
> +
> binary_size_check: u-boot-nodtb.bin FORCE
> @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> map_size=$(shell cat u-boot.map | \
> @@ -1643,6 +1648,10 @@ u-boot.lds: $(LDSCRIPT) prepare FORCE
>
> spl/u-boot-spl.bin: spl/u-boot-spl
> @:
> +
> +spl/u-boot-spl-dtb.bin: spl/u-boot-spl
> + @:
> +
> spl/u-boot-spl: tools prepare \
> $(if
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
> $(if
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
> --
> 2.20.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] video/console: Implement relative cursor movement ANSI handling
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > The ANSI terminal escapce sequence standard defines relative cursor > movement commands (ESC [ A-F). So far the DM_VIDEO console code was > ignoring them. > > Interpret those sequences and move the cursor by the requested amount of > rows or columns in the right direction. This brings the code on par with > the legacy video console driver (cfb_console). > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 37 + > 1 file changed, 37 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: Handle return value from bounce_buffer_start()
On Sat, 23 Mar 2019 at 11:55, Marek Vasut wrote: > > The bounce_buffer_start() can return -ENOMEM in case memory allocation > failed. However, in that case, the bounce buffer address is the same as > the possibly unaligned input address, and the cache maintenance operations > were not applied to this address. This could cause subtle problems. Add > handling for the bounce_buffer_start() return value to prevent such a > problem from happening. > > Signed-off-by: Marek Vasut > Cc: Jaehoon Chung > Cc: Simon Glass > --- > drivers/mmc/dw_mmc.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: Simplying cache flush code
On Wed, 27 Mar 2019 at 17:50, Trent Piepho wrote: > > The cache flush of the kernel load area needs to be aligned outward to > the DMA cache alignment. The operations are simpler if we think of this > as aligning the start down, ALIGN_DOWN(load, ARCH_DMA_MINALIGN), and > aligning the end up, ALIGN(load_end, ARCH_DMA_MINALIGN), and then find > the length of the flushed region by subtracting the former from the > latter. > > Cc: Tom Rini > Cc: Simon Glass > Cc: Bryan O'Donoghue > Signed-off-by: Trent Piepho > --- > common/bootm.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] video/console: Implement reverse video ANSI sequence for DM_VIDEO
On Fri, 22 Mar 2019 at 19:32, Andre Przywara wrote: > > The video console for DM_VIDEO compliant drivers only understands a very > small number of ANSI sequences. First and foremost it misses the "reverse > video" command, which is used by our own bootmenu command to highlight > the selected entry. > > To avoid forcing people to use their imagination when using the > bootmenu, let's just implement the rather simple reverse effect. We need > to store the background colour index for that, so that we can > recalculate both the foreground and background colour pixel values. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 11 ++- > drivers/video/video-uclass.c | 1 + > include/video.h | 2 ++ > 3 files changed, 13 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: Add a No-op uclass
Hi Jean-Jacques, On Fri, 22 Mar 2019 at 10:44, Jean-Jacques Hiblot wrote: > > This uclass is intended for devices that do not need any features from the > uclass, including binding children. > This will typically be used by devices that are used to bind child devices > but do not use dm_scan_fdt_dev() to do it. > Can you expand this motivation a little? I am not sure why calling dm_scan_fdt_dev() would be problematic. Also if you do add a new uclass it should have a sandbox driver and test. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 4/9] Makefile: Pass the board name to the FIT generator scripts
On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot wrote: > > Currently the FIT generator scripts are passed only a list of dtbs. > However some platforms may also require information about the board itself. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Makefile | 2 +- > arch/arm/mach-imx/mkimage_fit_atf.sh | 3 ++- > arch/arm/mach-rockchip/make_fit_atf.py | 5 +++-- > 3 files changed, 6 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] pinctrl: exit pinconfig_post_bind if there are no subnodes
On Fri, 22 Mar 2019 at 13:15, Urja Rannikko wrote: > > This fixes RK3288 SPL hanging or hitting this assert: > drivers/core/ofnode.c:183: ofnode_first_subnode: Assertion > `ofnode_valid(node)' failed. > > Signed-off-by: Urja Rannikko > --- > drivers/pinctrl/pinctrl-uclass.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/13] libfdt: Add phandle generation helper
Hi Thierry, On Mon, 25 Mar 2019 at 01:27, Thierry Reding wrote: > > On Fri, Mar 22, 2019 at 03:52:59PM +0800, Simon Glass wrote: > > On Fri, 22 Mar 2019 at 02:10, Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > The new fdt_generate_phandle() function can be used to generate a new, > > > unused phandle given a specific device tree blob. The implementation is > > > somewhat naive in that it simply walks the entire device tree to find > > > the highest phandle value and then returns a phandle value one higher > > > than that. A more clever implementation might try to find holes in the > > > current set of phandle values and fill them. But this implementation is > > > relatively simple and works reliably. > > > > > > Also add a test that validates that phandles generated by this new API > > > are indeed unique. > > > > > > Signed-off-by: Thierry Reding > > > --- > > > Changes in v3: > > > - update to latest upstream commit > > > > > > lib/libfdt/fdt_ro.c | 31 +++ > > > scripts/dtc/libfdt/fdt_ro.c | 31 +++ > > > scripts/dtc/libfdt/libfdt.h | 19 +++ > > > scripts/dtc/libfdt/libfdt_env.h | 1 + > > > 4 files changed, 82 insertions(+) > > > > Reviewed-by: Simon Glass > > Looks like this was reverted again upstream (for, in my opinion, dubious > reasons). Shall I just move it to fdtdec again and we can convert to > whatever we end up with upstream, if anything, later on? Yes that is OK with me. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Prioritize external dtb if defined
On Mon, 25 Mar 2019 at 08:55, Michal Simek wrote: > > Prioritize external dtb if its passed via EXT_DTB > than the dtb that was built in the tree. With this > patch it appends the specified external dtb to > the u-boot image. > > Signed-off-by: Michal Simek > Signed-off-by: Siva Durga Prasad Paladugu > --- > > Makefile | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] rockchip: use 'arch-rockchip' as header file path
Hi Kever, On Wed, 27 Mar 2019 at 21:01, Kever Yang wrote: > > Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common > header file path, so that we can get the correct path directly. Can you give a few more details on the reason for this change? I cannot see the benefit? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1 3/9] Makefile: Fix u-boot.itb generation when building outside the source tree
On Fri, 22 Mar 2019 at 08:39, Jean-Jacques Hiblot wrote: > > Include the object tree and the source tree in the search path of the > FIT compîler (dtc). This allows to use paths relative to the root of the > source or object trees in the ITS instead of working backward from the > actual location of the ITS. > It also allows to use a build directory different of the source directory. > > Signed-off-by: Jean-Jacques Hiblot > --- > > Makefile| 5 +++-- > board/theobroma-systems/lion_rk3368/fit_spl_atf.its | 6 +++--- > board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 8 > 3 files changed, 10 insertions(+), 9 deletions(-) > Reviewed-by: Simon Glass But I think the 'Makefile' change should be in a separate patch from board-specific stuff. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv3 3/6] dm: cache: Create a uclass for cache
Hi Dinh, On Mon, 25 Mar 2019 at 09:20, Dinh Nguyen wrote: > > The cache UCLASS will be used for configure settings that can be found > in a CPU's L2 cache controller. > > Add a uclass and a test for cache. > > Signed-off-by: Dinh Nguyen > --- > v3: Add cache_get_info() to check for non-zero value > Add comments to cache_info struct > v2: separate out uclass patch from driver and add test > --- > drivers/Kconfig | 2 ++ > drivers/Makefile | 1 + > drivers/cache/Kconfig | 16 +++ > drivers/cache/Makefile| 3 +++ > drivers/cache/cache-uclass.c | 24 ++ > drivers/cache/sandbox_cache.c | 34 +++ > include/cache.h | 38 +++ > include/dm/uclass-id.h| 1 + > test/dm/cache.c | 20 ++ > 9 files changed, 139 insertions(+) > create mode 100644 drivers/cache/Kconfig > create mode 100644 drivers/cache/Makefile > create mode 100644 drivers/cache/cache-uclass.c > create mode 100644 drivers/cache/sandbox_cache.c > create mode 100644 include/cache.h > create mode 100644 test/dm/cache.c Reviewed-by: Simon Glass One nit - make sure that cache.h becomes before dm.h in the include order. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] rk3288-board: cosmetic: document selecting RK PWM
On Fri, 22 Mar 2019 at 13:15, Urja Rannikko wrote: > > Atleast hat is what it says in the TRM. At least that > > Signed-off-by: Urja Rannikko > --- > arch/arm/mach-rockchip/rk3288-board.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: Round up descriptor end to nearest multiple of cacheline size
Hi Marek, On Sat, 23 Mar 2019 at 11:55, Marek Vasut wrote: > > The driver currently calculates the end address of cache flush operation > for the DMA descriptors by adding cacheline size to the start address of > the last DMA descriptor. This is not safe, as the cacheline size may be, > in some unlikely cases, smaller than the DMA descriptor size. Replace the > addition with roundup() applied on the end address of the last DMA > descriptor to round it up to the nearest cacheline size multiple. > > Signed-off-by: Marek Vasut > Cc: Jaehoon Chung > Cc: Simon Glass > --- > drivers/mmc/dw_mmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c > index 72570235cb..bec30b1479 100644 > --- a/drivers/mmc/dw_mmc.c > +++ b/drivers/mmc/dw_mmc.c > @@ -74,15 +74,15 @@ static void dwmci_prepare_data(struct dwmci_host *host, > dwmci_set_idma_desc(cur_idmac, flags, cnt, > (ulong)bounce_buffer + (i * PAGE_SIZE)); > > + cur_idmac++; What is this change for? I don't see it mentioned above. > if (blk_cnt <= 8) > break; > blk_cnt -= 8; > - cur_idmac++; > i++; > } while(1); > > data_end = (ulong)cur_idmac; > - flush_dcache_range(data_start, data_end + ARCH_DMA_MINALIGN); > + flush_dcache_range(data_start, roundup(data_end, ARCH_DMA_MINALIGN)); > > ctrl = dwmci_readl(host, DWMCI_CTRL); > ctrl |= DWMCI_IDMAC_EN | DWMCI_DMA_EN; > -- > 2.20.1 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] serial: add skipping init option
Hi Jun,
On Wed, 27 Mar 2019 at 03:55, Jun Nie wrote:
>
> Lukasz Majewski 于2019年3月27日周三 下午5:34写道：
> >
> > Hi Simon, Jun,
> >
> > > Hi Jun,
> > >
> > > On Fri, 22 Mar 2019 at 16:02, Jun Nie wrote:
> > > >
> > > > Simon Glass 于2019年3月22日周五 下午3:56写道：
> > > > >
> > > > > Hi Jun,
> > > > >
> > > > > On Fri, 22 Mar 2019 at 15:20, Jun Nie
> > > > > wrote:
> > > > > >
> > > > > > add skipping init option to avoid corrupt data in console
> > > > > > if serial is already initilized when u-boot start its excution.
> > > > > >
> > > > > > Signed-off-by: Jun Nie
> > > > > > ---
> > > > > > drivers/serial/Kconfig | 6 ++
> > > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > Could we use a device-tree property for this? Some UARTs have a
> > > > > 'skip-init' property.
> > > > >
> > > > > Regards,
> > > > > Simon
> > > >
> > > > Hi Simon,
> > > >
> > > > It is a good suggestion. But device tree is board specific, while
> > > > the config is boot flow specific. For ATF -> OPTEE -> U-BOOT case,
> > > > initialization should be skipped. Without earlier initialization
> > > > from firmware, U-boot should do it by itself. So I need find a
> > > > solution that is defconfig specific, instead of device tree
> > > > specific.
> > >
> > > So you want something that is flow-specific, I think. Your thinking is
> > > that the defconfig specifies this. Is that because certain boards
> > > require ATF/Optee?
> > >
> > > Should we consider having a way to tell U-Boot that it is running
> > > from Optee?
> > >
> > > Could the UART driver detect that the UART is already inited?
> >
> > Isn't this issue similar to:
> > http://patchwork.ozlabs.org/patch/820824/
> >
> > and
> >
> > http://patchwork.ozlabs.org/patch/865963/
> >
> My case is that console does not emit any log when OPTEE runs into u-boot.
> I already root caused that there is a bug in uart clock handling.
> UART1_CLK_ROOT
> is hard coded in imx_get_uartclk() of arch/arm/mach-imx/mx7/clock.c
> If the console serial is not UART1, 0 may be returned and console does not
> work.
>
> But when I add an IMX_UART_PORT config option in Kconfig to dynamic configure
> the CLK_ROOT ID as below, the expansion result is
> UARTCONFIG_IMX_UART_PORT_CLK_ROOT instead of UART1_CLK_ROOT.
> It seems macro expansion happens before the inclusion of defconfig. Do you see
> any better idea other than add the definition in
> include/configs/pico-imx7d.h directly?
>
> #define IMX_UART_CLK_ROOT UART##CONFIG_IMX_UART_PORT##_CLK_ROOT
>
> Current plan is to add below change so that platform can define
> different clock root other
> than UART1_CLK_ROOT.
>
> +++ b/arch/arm/mach-imx/mx7/clock.c
> @@ -51,9 +51,12 @@ static u32 get_ipg_clk(void)
> return get_ahb_clk() / 2;
> }
>
> +#ifndef UART_CLK_ROOT
> +#define UART_CLK_ROOT UART1_CLK_ROOT
> +#endif
> u32 imx_get_uartclk(void)
> {
> - return get_root_clk(UART1_CLK_ROOT);
> + return get_root_clk(UART_CLK_ROOT);
> }
>
I'm not very knowledgeable on this platform. This seems OK to me but
you should send a patch for iMX people to review.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
On Tue, 26 Mar 2019 at 06:39, Simon Goldschmidt
wrote:
>
> This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
>
> The 'eeprom' command has been converted to work with DM_I2C in a patch
> submitted around the same time as this commit:
> commit 0c07a9b4078d ("eeprom: Add device model based I2C support to eeprom
> command")
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v2:
> - added patch to fix DM_I2C eeprom code to work without
> CONFIG_SYS_I2C_EEPROM_BUS
>
> cmd/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Simon Glass
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Sat, 30 Mar 2019 at 14:50, Simon Goldschmidt wrote: > > > > Simon Goldschmidt schrieb am Sa., 30. März > 2019, 21:18: >> >> >> >> Simon Glass schrieb am Sa., 30. März 2019, 21:06: >>> >>> Hi Simon, >>> >>> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >>> wrote: >>> > >>> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it >>> > clears >>> > the bss before calling board_init_f() instead of clearing it before >>> > calling >>> > board_init_r(). >>> > >>> > This also ensures that variables placed in BSS can be shared between >>> > board_init_f() and board_init_r() in SPL. >>> > >>> > Such global variables are used, for example, when loading things from FAT >>> > before SDRAM is available: the full heap required for FAT uses global >>> > variables and clearing BSS after board_init_f() would reset the heap >>> > state. >>> > An example for such a usage is socfpa_arria10 where an FPGA configuration >>> > is required before SDRAM can be used. >>> > >>> > Make the new option depend on ARM for now until more implementations >>> > follow. >>> > >>> >>> I still have objections to this series and I think we should discuss >>> other ways of solving this problem. >>> >>> Does socfgpa have SRAM that could be used before SDRAM is available? >>> If so, can we not use that for the configuration? What various are >>> actually in BSS that are needed before board_init_r() is called? Can >>> they not be in a struct created from malloc()? >> >> >> The problem is the board needs to load an FPGA configuration from FAT before >> SDRAM is available. Yes, this is loaded into SRAM of course, but the whole >> code until that is done uses so many malloc/free iterations that The simple >> mall of implementation would require too much memory. >> >> And it's the full malloc state variables only that use BSS, not the FAT code. >> >> One way out could be to move the full mall of state variables into 'gd'... > > > Maybe I should point out again that the whole purpose of this series is to > have an SPL that uses full malloc right from the start. This is currently not > possible as full malloc needs BSS. Right, and our assumption/design is that full malloc() requires SRAM. Here we have an architecture that requires FAT just to init its SDRAM. FAT requires malloc() and free() and there is not enough SRAM to skip the free() calls. So we have to use full malloc() and that uses BSS. But BSS is not available before board_init_r(). But we need to init SDRAM before board_init_r(). Firstly I'd point out that someone should speak to the chip designers. Did anyone try to boot U-Boot on the SoC model? I think it is possible to change dlmalloc to put its variables in a struct. Then I suppose the struct pointer could be kept in gd. That would be one solution. Then full malloc() could be inited in spl_common_init() perhaps. Another option might be to update the FAT code to use ALLOC_CACHE_ALIGN_BUFFER() instead of malloc(), as it already does in places, and perhaps to disable all caching for this case. Then it might work with simple malloc(). Another option would be to put the FPGA image in a known position on the media, outside the FAT partition. The position could perhaps be written into a FAT file, and reading just that file in SPL might not involve many free() operations. I hesitate to suggest enhancing simple malloc() to support a free list. That would increase the code size and I'm not sure it would be better than using full malloc(). [..] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: rmobile: rcar-gen2: Activate bootm_size
Hi Marek,
On Sat, Mar 30, 2019 at 07:47:34AM +0100, Marek Vasut wrote:
> Commit d245059ff797 ("ARM: rmobile: rcar-gen3: Activate bootm_size")
> only fixed the superfluous CONFIG_SYS_BOOTMAPSZ for R-Car Gen3 [..]
I don't think 'superfluous' is the best wording here, since
(according to its README description) CONFIG_SYS_BOOTMAPSZ
invalidates/overrides the user-provided 'bootm_size' by taking
precedence over the latter.
But I agree with the contents of this patch, since it resembles the
aforementioned commit and brings more harmony between Gen2 and Gen3.
I don't have any Gen2 board to test it, but from code review standpoint:
Reviewed-by: Eugeniu Rosca
Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pico-imx6ul: Fix eMMC boot after DM_MMC conversion
Hi Stefano, On Thu, Mar 21, 2019 at 10:59 AM Fabio Estevam wrote: > > After the DM_MMC conversion the following eMMC boot error is observed: > > U-Boot SPL 2019.04-rc4 (Mar 20 2019 - 18:53:28 +) > Trying to boot from MMC1 > MMC Device 0 not found > spl: could not find mmc device 0. error: -19 > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > This happens because the SPL code does not initialize the SDHC pins > and clock. > > Fix it by moving the original eMMC initialization from U-Boot proper > to SPL. > > Reported-by: Otavio Salvador > Signed-off-by: Fabio Estevam > Tested-by: Fabio Berton > Reviewed-by: Otavio Salvador Could you please consider this one for 2019.04? It is needed to fix a boot regression after DM conversion. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Goldschmidt schrieb am Sa., 30. März 2019, 21:18: > > > Simon Glass schrieb am Sa., 30. März 2019, 21:06: > >> Hi Simon, >> >> On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt >> wrote: >> > >> > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it >> clears >> > the bss before calling board_init_f() instead of clearing it before >> calling >> > board_init_r(). >> > >> > This also ensures that variables placed in BSS can be shared between >> > board_init_f() and board_init_r() in SPL. >> > >> > Such global variables are used, for example, when loading things from >> FAT >> > before SDRAM is available: the full heap required for FAT uses global >> > variables and clearing BSS after board_init_f() would reset the heap >> state. >> > An example for such a usage is socfpa_arria10 where an FPGA >> configuration >> > is required before SDRAM can be used. >> > >> > Make the new option depend on ARM for now until more implementations >> follow. >> > >> >> I still have objections to this series and I think we should discuss >> other ways of solving this problem. >> >> Does socfgpa have SRAM that could be used before SDRAM is available? >> If so, can we not use that for the configuration? What various are >> actually in BSS that are needed before board_init_r() is called? Can >> they not be in a struct created from malloc()? >> > > The problem is the board needs to load an FPGA configuration from FAT > before SDRAM is available. Yes, this is loaded into SRAM of course, but the > whole code until that is done uses so many malloc/free iterations that The > simple mall of implementation would require too much memory. > > And it's the full malloc state variables only that use BSS, not the FAT > code. > > One way out could be to move the full mall of state variables into 'gd'... > Maybe I should point out again that the whole purpose of this series is to have an SPL that uses full malloc right from the start. This is currently not possible as full malloc needs BSS. Regards, Simon > Another way would be to continue into board_init_f without SDRAM enabled > and in it it later... > > Regards, > Simon > > >> If this is a limitation of FAT, then I think we should fix that, instead. >> >> Regards, >> Simon >> >> > Signed-off-by: Simon Goldschmidt >> > --- >> > >> > Changes in v3: >> > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed >> > >> > Changes in v2: >> > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now >> > >> > common/spl/Kconfig | 12 >> > 1 file changed, 12 insertions(+) >> > >> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig >> > index 206c24076d..6a4270516a 100644 >> > --- a/common/spl/Kconfig >> > +++ b/common/spl/Kconfig >> > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN >> > to give board_init_r() a larger heap then the initial heap in >> > SRAM which is limited to SYS_MALLOC_F_LEN bytes. >> > >> > +config SPL_CLEAR_BSS_F >> > + bool "Clear BSS section before calling board_init_f" >> > + depends on ARM >> > + help >> > + The BSS section is initialized to zero. In SPL, this is >> normally done >> > + before calling board_init_r(). >> > + For platforms using BSS in board_init_f() already, enable >> this to >> > + clear the BSS section before calling board_init_f() instead of >> > + clearing it before calling board_init_r(). This also ensures >> that >> > + variables placed in BSS can be shared between board_init_f() >> and >> > + board_init_r(). >> > + >> > config SPL_SEPARATE_BSS >> > bool "BSS section is in a different memory region from text" >> > help >> > -- >> > 2.17.1 >> > >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Simon Glass schrieb am Sa., 30. März 2019, 21:06: > Hi Simon, > > On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt > wrote: > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > clears > > the bss before calling board_init_f() instead of clearing it before > calling > > board_init_r(). > > > > This also ensures that variables placed in BSS can be shared between > > board_init_f() and board_init_r() in SPL. > > > > Such global variables are used, for example, when loading things from FAT > > before SDRAM is available: the full heap required for FAT uses global > > variables and clearing BSS after board_init_f() would reset the heap > state. > > An example for such a usage is socfpa_arria10 where an FPGA configuration > > is required before SDRAM can be used. > > > > Make the new option depend on ARM for now until more implementations > follow. > > > > I still have objections to this series and I think we should discuss > other ways of solving this problem. > > Does socfgpa have SRAM that could be used before SDRAM is available? > If so, can we not use that for the configuration? What various are > actually in BSS that are needed before board_init_r() is called? Can > they not be in a struct created from malloc()? > The problem is the board needs to load an FPGA configuration from FAT before SDRAM is available. Yes, this is loaded into SRAM of course, but the whole code until that is done uses so many malloc/free iterations that The simple mall of implementation would require too much memory. And it's the full malloc state variables only that use BSS, not the FAT code. One way out could be to move the full mall of state variables into 'gd'... Another way would be to continue into board_init_f without SDRAM enabled and in it it later... Regards, Simon > If this is a limitation of FAT, then I think we should fix that, instead. > > Regards, > Simon > > > Signed-off-by: Simon Goldschmidt > > --- > > > > Changes in v3: > > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed > > > > Changes in v2: > > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > > > common/spl/Kconfig | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > index 206c24076d..6a4270516a 100644 > > --- a/common/spl/Kconfig > > +++ b/common/spl/Kconfig > > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN > > to give board_init_r() a larger heap then the initial heap in > > SRAM which is limited to SYS_MALLOC_F_LEN bytes. > > > > +config SPL_CLEAR_BSS_F > > + bool "Clear BSS section before calling board_init_f" > > + depends on ARM > > + help > > + The BSS section is initialized to zero. In SPL, this is > normally done > > + before calling board_init_r(). > > + For platforms using BSS in board_init_f() already, enable this > to > > + clear the BSS section before calling board_init_f() instead of > > + clearing it before calling board_init_r(). This also ensures > that > > + variables placed in BSS can be shared between board_init_f() > and > > + board_init_r(). > > + > > config SPL_SEPARATE_BSS > > bool "BSS section is in a different memory region from text" > > help > > -- > > 2.17.1 > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Wed, 27 Mar 2019 at 13:40, Simon Goldschmidt wrote: > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears > the bss before calling board_init_f() instead of clearing it before calling > board_init_r(). > > This also ensures that variables placed in BSS can be shared between > board_init_f() and board_init_r() in SPL. > > Such global variables are used, for example, when loading things from FAT > before SDRAM is available: the full heap required for FAT uses global > variables and clearing BSS after board_init_f() would reset the heap state. > An example for such a usage is socfpa_arria10 where an FPGA configuration > is required before SDRAM can be used. > > Make the new option depend on ARM for now until more implementations follow. > I still have objections to this series and I think we should discuss other ways of solving this problem. Does socfgpa have SRAM that could be used before SDRAM is available? If so, can we not use that for the configuration? What various are actually in BSS that are needed before board_init_r() is called? Can they not be in a struct created from malloc()? If this is a limitation of FAT, then I think we should fix that, instead. Regards, Simon > Signed-off-by: Simon Goldschmidt > --- > > Changes in v3: > - improve commit message to show why CONFIG_CLEAR_BSS_F is needed > > Changes in v2: > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > common/spl/Kconfig | 12 > 1 file changed, 12 insertions(+) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 206c24076d..6a4270516a 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN > to give board_init_r() a larger heap then the initial heap in > SRAM which is limited to SYS_MALLOC_F_LEN bytes. > > +config SPL_CLEAR_BSS_F > + bool "Clear BSS section before calling board_init_f" > + depends on ARM > + help > + The BSS section is initialized to zero. In SPL, this is normally > done > + before calling board_init_r(). > + For platforms using BSS in board_init_f() already, enable this to > + clear the BSS section before calling board_init_f() instead of > + clearing it before calling board_init_r(). This also ensures that > + variables placed in BSS can be shared between board_init_f() and > + board_init_r(). > + > config SPL_SEPARATE_BSS > bool "BSS section is in a different memory region from text" > help > -- > 2.17.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] spl: add Kconfig option to clear bss early
Hi Simon, On Fri, 22 Mar 2019 at 02:16, Simon Goldschmidt wrote: > > Hi Simon, > > On Fri, Mar 22, 2019 at 8:53 AM Simon Glass wrote: > > > > Hi, > > > > On Sat, 16 Mar 2019 at 04:13, Simon Goldschmidt > > wrote: > > > > > > This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it > > > clears > > > the bss before calling board_init_f() instead of clearing it before > > > calling > > > board_init_r(). > > > > > > This also ensures that variables placed in BSS can be shared between > > > board_init_f() and board_init_r() in SPL. > > > > > > Make the new option depend on ARM for now until more implementations > > > follow. > > > > > > Signed-off-by: Simon Goldschmidt > > > --- > > > > > > Changes in v2: > > > - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now > > > > > > common/spl/Kconfig | 12 > > > 1 file changed, 12 insertions(+) > > > > The current restriction is that you are not allowed to use BSS before > > board_init_r(). > > I understood that, but I did not understand why. This is perfectly valid for > U-Boot proper or for SPL if SPL_SEPARATE_BSS is used and bss is in > SDRAM. However, the latter seems to be seldom used and for the "default" > case where bss is in SRAM, it's available right from the start and clearing > it after board_init_f() has been run seems quite unuseful and unexpected. Well this is the API. We have to have some order and conventions otherwise things just decend into chaos, with so many options that it all becomes bewildering. See 'Board Initialisation Flow:' in the README. > > > > > Can you please add a motivation to change this? > > The motivation is to allow SPL to use full malloc in board_init_f() > like required > by socfpga_arria10 (see patch 5/6). Without this, the malloc pointers get > overwritten after board_init_f() and further calls to malloc() fail. Can you call spl_early_init() instead? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dfu: usb: Update MAINTAINERS file regarding DFU/USB gadget support
Signed-off-by: Lukasz Majewski --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3166ec74f0cb..f9ee4281d948 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -439,6 +439,11 @@ DFU M: Lukasz Majewski S: Maintained T: git git://git.denx.de/u-boot-dfu.git +F: cmd/dfu.c +F: cmd/usb_*.c +F: common/dfu.c +F: common/update.c +F: common/usb_storage.c F: drivers/dfu/ F: drivers/usb/gadget/ -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/Makefile: build host tools with -std=gnu99
> On 30.03.2019, at 15:29, Thomas Petazzoni > wrote: > > Parts of the code are using C99 constructs (such as variables declared > inside loops), but also GNU extensions (such as typeof), so using > -std=gnu99 is necessary to build with older versions of gcc that don't > default to building with gnu99. > > It fixes the following build failure: > > ./tools/../lib/crc16.c: In function "crc16_ccitt": > ./tools/../lib/crc16.c:70:2: error: "for" loop initial declarations are only > allowed in C99 mode > for (int i = 0; i < len; i++) > ^ > ./tools/../lib/crc16.c:70:2: note: use option -std=c99 or -std=gnu99 to > compile your code > > when building the host tools with gcc 4.7. > > Signed-off-by: Thomas Petazzoni Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tools/Makefile: build host tools with -std=gnu99
Parts of the code are using C99 constructs (such as variables declared inside loops), but also GNU extensions (such as typeof), so using -std=gnu99 is necessary to build with older versions of gcc that don't default to building with gnu99. It fixes the following build failure: ./tools/../lib/crc16.c: In function "crc16_ccitt": ./tools/../lib/crc16.c:70:2: error: "for" loop initial declarations are only allowed in C99 mode for (int i = 0; i < len; i++) ^ ./tools/../lib/crc16.c:70:2: note: use option -std=c99 or -std=gnu99 to compile your code when building the host tools with gcc 4.7. Signed-off-by: Thomas Petazzoni --- tools/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/Makefile b/tools/Makefile index 081383d7a7..d377d85f74 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -254,7 +254,8 @@ HOST_EXTRACFLAGS += -include $(srctree)/include/compiler.h \ -I$(srctree)/tools \ -DUSE_HOSTCC \ -D__KERNEL_STRICT_NAMES \ - -D_GNU_SOURCE + -D_GNU_SOURCE \ + -std=gnu99 __build: $(LOGO-y) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] usb: convert dwc2 gadget to driver model, used in stm32mp1
On 29/03/2019 14:42, Patrick Delaunay wrote: > > This patch-set created after Marek remarks on patch > board: stm32mp1: Add tx_fifo_sz_array support > http://patchwork.ozlabs.org/patch/1056452/ > > This serie convert the DWC2 to driver model and use it for the > stm32mp1 boards. > > USB device and cable connection tested on EV1 and DK2. > > This serie superseded the Patrice patches: > http://patchwork.ozlabs.org/project/uboot/list/?series=97121 > > Warning: the serie need to be apply after > http://patchwork.ozlabs.org/project/uboot/list/?series=91422 > http://patchwork.ozlabs.org/project/uboot/list/?series=91497 Hi Patrice, The second patch series doesn't apply cleanly anymore, could you rebase and resend so I can test this series? Regards, Jack. > > > > Patrice Chotard (1): > usb: dwc2_udc_otg: Add tx_fifo_sz array support > > Patrick Delaunay (15): > phy: usbphyc: remove unused variable index > phy: usbphyc: update xlate with DT binding > phy: usbphyc: Binding update of vdda supply > phy: usbphyc: move vdda1v1 and vdda1v8 in phy_init > phy: usbphyc: increase PLL wait timeout > usb: dwc2: remove unused variable regs_otg > usb: dwc2: convert driver to DM_USB_GADGET > usb: dwc2: force reset assert before to probe the driver > usb: dwc2: Add force-b-session-valid support > usb: dwc2: Add function for session B check > usb: dwc2_udc_otg: Read MAX_HW_ENDPOINT from HWCFG4 register > usb: dwc2: add support for STM32MP1 > stm32mp1: remove CONFIG_USB_DWC2, HOST support for USBO > stm32mp1: migrate USBOTG device to driver model > stm32mp1: add stusb1600 support for DK1 and DK2 board > > arch/arm/dts/stm32mp157-pinctrl.dtsi | 7 + > arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 3 +- > arch/arm/dts/stm32mp157a-dk1.dts | 34 +- > arch/arm/dts/stm32mp157c-ed1.dts | 8 - > arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 1 + > arch/arm/dts/stm32mp157c.dtsi | 5 +- > board/st/stm32mp1/stm32mp1.c | 185 +++--- > configs/stm32mp15_basic_defconfig | 2 +- > configs/stm32mp15_trusted_defconfig| 2 +- > doc/device-tree-bindings/phy/phy-stm32-usbphyc.txt | 4 +- > doc/device-tree-bindings/usb/dwc2.txt | 58 +++ > drivers/phy/phy-stm32-usbphyc.c| 111 +++--- > drivers/usb/gadget/dwc2_udc_otg.c | 388 > - > drivers/usb/gadget/dwc2_udc_otg_priv.h | 1 - > drivers/usb/gadget/dwc2_udc_otg_regs.h | 31 +- > include/usb/dwc2_udc.h | 7 + > 16 files changed, 627 insertions(+), 220 deletions(-) > create mode 100644 doc/device-tree-bindings/usb/dwc2.txt > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] configs: mscc_jr2: Add network support
Update default confing to use network driver for Jaguar2 SoCs. Signed-off-by: Horatiu Vultur --- configs/mscc_jr2_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/mscc_jr2_defconfig b/configs/mscc_jr2_defconfig index 95562b7..92c22b8 100644 --- a/configs/mscc_jr2_defconfig +++ b/configs/mscc_jr2_defconfig @@ -28,7 +28,10 @@ CONFIG_CMD_MEMTEST=y CONFIG_CMD_GPIO=y CONFIG_CMD_SF=y CONFIG_CMD_SPI=y -# CONFIG_CMD_NET is not set +CONFIG_CMD_DHCP=y +# CONFIG_NET_TFTP_VARS is not set +# CONFIG_CMD_NFS is not set +CONFIG_CMD_PING=y CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi_flash" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:1m(UBoot),256k(Env),256k(Env.bk)" @@ -66,3 +69,4 @@ CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_LZMA=y +CONFIG_MSCC_JR2_SWITCH=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] net: Add MSCC Jaguar2 network driver.
Add network driver for Microsemi Ethernet switch. It is present on Jaguar2 SoCs. Signed-off-by: Horatiu Vultur --- drivers/net/mscc_eswitch/Kconfig |7 + drivers/net/mscc_eswitch/Makefile |1 + drivers/net/mscc_eswitch/jr2_switch.c | 1075 + include/configs/vcoreiii.h|2 +- 4 files changed, 1084 insertions(+), 1 deletion(-) create mode 100644 drivers/net/mscc_eswitch/jr2_switch.c diff --git a/drivers/net/mscc_eswitch/Kconfig b/drivers/net/mscc_eswitch/Kconfig index 88e5a97..3f9d14b 100644 --- a/drivers/net/mscc_eswitch/Kconfig +++ b/drivers/net/mscc_eswitch/Kconfig @@ -15,3 +15,10 @@ config MSCC_LUTON_SWITCH select PHYLIB help This driver supports the Luton network switch device. + +config MSCC_JR2_SWITCH + bool "Jaguar2 switch driver" + depends on DM_ETH && ARCH_MSCC + select PHYLIB + help + This driver supports the Jaguar2 network switch device. diff --git a/drivers/net/mscc_eswitch/Makefile b/drivers/net/mscc_eswitch/Makefile index 751a839..0a1b863 100644 --- a/drivers/net/mscc_eswitch/Makefile +++ b/drivers/net/mscc_eswitch/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_miim.o mscc_xfer.o mscc_mac_table.o obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o mscc_mac_table.o +obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o diff --git a/drivers/net/mscc_eswitch/jr2_switch.c b/drivers/net/mscc_eswitch/jr2_switch.c new file mode 100644 index 000..d4a2498 --- /dev/null +++ b/drivers/net/mscc_eswitch/jr2_switch.c @@ -0,0 +1,1075 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2018 Microsemi Corporation + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include "mscc_xfer.h" + +#define GCB_MIIM_MII_STATUS0x0 +#defineGCB_MIIM_STAT_BUSY BIT(3) +#define GCB_MIIM_MII_CMD 0x8 +#defineGCB_MIIM_MII_CMD_SCAN BIT(0) +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1) +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2) +#defineGCB_MIIM_MII_CMD_SINGLE_SCANBIT(3) +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4) +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) << 20) +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) << 25) +#defineGCB_MIIM_MII_CMD_VLDBIT(31) +#define GCB_MIIM_DATA 0xC +#defineGCB_MIIM_DATA_ERROR (0x3 << 16) + +#define ANA_AC_RAM_CTRL_RAM_INIT 0x94358 +#define ANA_AC_STAT_GLOBAL_CFG_PORT_RESET 0x94370 + +#define ANA_CL_PORT_VLAN_CFG(x)(0x24018 + 0xc8 * (x)) +#defineANA_CL_PORT_VLAN_CFG_AWARE_ENA BIT(19) +#defineANA_CL_PORT_VLAN_CFG_POP_CNT(x) ((x) << 17) + +#define ANA_L2_COMMON_FWD_CFG 0x8a2a8 +#defineANA_L2_COMMON_FWD_CFG_CPU_DMAC_COPY_ENA BIT(6) + +#define ASM_CFG_STAT_CFG 0x3508 +#define ASM_CFG_PORT(x)(0x36c4 + 0x4 * (x)) +#defineASM_CFG_PORT_NO_PREAMBLE_ENABIT(8) +#defineASM_CFG_PORT_INJ_FORMAT_CFG(x) ((x) << 1) +#define ASM_RAM_CTRL_RAM_INIT 0x39b8 + +#define DEV_DEV_CFG_DEV_RST_CTRL 0x0 +#defineDEV_DEV_CFG_DEV_RST_CTRL_SPEED_SEL(x) ((x) << 20) +#define DEV_MAC_CFG_MAC_ENA0x1c +#defineDEV_MAC_CFG_MAC_ENA_RX_ENA BIT(4) +#defineDEV_MAC_CFG_MAC_ENA_TX_ENA BIT(0) +#defineDEV_MAC_CFG_MAC_IFG 0x34 +#defineDEV_MAC_CFG_MAC_IFG_TX_IFG(x) ((x) << 8) +#defineDEV_MAC_CFG_MAC_IFG_RX_IFG2(x) ((x) << 4) +#defineDEV_MAC_CFG_MAC_IFG_RX_IFG1(x) (x) +#defineDEV_PCS1G_CFG_PCS1G_CFG 0x40 +#defineDEV_PCS1G_CFG_PCS1G_CFG_PCS_ENA BIT(0) +#defineDEV_PCS1G_CFG_PCS1G_MODE0x44 +#defineDEV_PCS1G_CFG_PCS1G_SD 0x48 +#defineDEV_PCS1G_CFG_PCS1G_ANEG0x4c +#defineDEV_PCS1G_CFG_PCS1G_ANEG_ADV_ABILITY(x) ((x) << 16) + +#define DSM_RAM_CTRL_RAM_INIT 0x8 + +#define HSIO_ANA_SERDES1G_DES_CFG 0xac +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_HYST(x)((x) << 1) +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_ANA(x) ((x) << 5) +#defineHSIO_ANA_SERDES1G_DES_CFG_MBTR_CTRL(x) ((x) << 8) +#defineHSIO_ANA_SERDES1G_DES_CFG_PHS_CTRL(x) ((x) << 13) +#define HSIO_ANA_SERDES1G_IB_CFG 0xb0 +#defineHSIO_ANA
[U-Boot] [PATCH v3 2/4] board: mscc: jr2: Update MSCC Jaguar2 boards
In Jaguar2 SoC family there are 3 different pcb. Each of this needs
to configure the phys in different ways. Therefore implement the
function board_phy_config and based on pcb configure them accordingly.
Signed-off-by: Horatiu Vultur
---
board/mscc/jr2/jr2.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c
index 58a4a04..6e5ef4c 100644
--- a/board/mscc/jr2/jr2.c
+++ b/board/mscc/jr2/jr2.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
enum {
BOARD_TYPE_PCB110 = 0xAABBCE00,
@@ -64,6 +65,28 @@ static void vcoreiii_gpio_set_alternate(int gpio, int mode)
}
}
+int board_phy_config(struct phy_device *phydev)
+{
+ if (gd->board_type == BOARD_TYPE_PCB110 ||
+ gd->board_type == BOARD_TYPE_PCB112) {
+ phy_write(phydev, 0, 31, 0x10);
+ phy_write(phydev, 0, 18, 0x80F0);
+ while (phy_read(phydev, 0, 18) & 0x8000)
+ ;
+ phy_write(phydev, 0, 31, 0);
+ }
+ if (gd->board_type == BOARD_TYPE_PCB111) {
+ phy_write(phydev, 0, 31, 0x10);
+ phy_write(phydev, 0, 18, 0x80A0);
+ while (phy_read(phydev, 0, 18) & 0x8000)
+ ;
+ phy_write(phydev, 0, 14, 0x800);
+ phy_write(phydev, 0, 31, 0);
+ }
+
+ return 0;
+}
+
void board_debug_uart_init(void)
{
/* too early for the pinctrl driver, so configure the UART pins here */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] net: mscc: jaguar2: Add ethenet nodes for Jaguar2.
Add ethernet nodes for Jaguar2 SoCs family. There are 3 pcb in this
family: pcb110, pcb111 and pcb112.
Signed-off-by: Horatiu Vultur
---
arch/mips/dts/jr2_pcb110.dts| 76 +++
arch/mips/dts/jr2_pcb111.dts| 400
arch/mips/dts/mscc,jr2.dtsi | 116 +++
arch/mips/dts/serval2_pcb112.dts| 44
include/dt-bindings/mscc/jr2_data.h | 19 ++
5 files changed, 655 insertions(+)
create mode 100644 include/dt-bindings/mscc/jr2_data.h
diff --git a/arch/mips/dts/jr2_pcb110.dts b/arch/mips/dts/jr2_pcb110.dts
index ddc30ff..4a5a584 100644
--- a/arch/mips/dts/jr2_pcb110.dts
+++ b/arch/mips/dts/jr2_pcb110.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include "mscc,jr2.dtsi"
+#include
/ {
model = "Jaguar2 Cu8-Sfp16 PCB110 Reference Board";
@@ -72,3 +73,78 @@
sgpio-ports = <0x3f00>;
gpio-ranges = <&sgpio2 0 0 96>;
};
+
+&mdio1 {
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ phy2: ethernet-phy@2 {
+ reg = <2>;
+ };
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ };
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ };
+ phy6: ethernet-phy@6 {
+ reg = <6>;
+ };
+ phy7: ethernet-phy@7 {
+ reg = <7>;
+ };
+};
+
+&switch {
+ ethernet-ports {
+
+ port0: port@0 {
+ reg = <0>;
+ phy-handle = <&phy0>;
+ phys = <&serdes_hsio 0 SERDES1G(1) PHY_MODE_SGMII>;
+ };
+ port1: port@1 {
+ reg = <1>;
+ phy-handle = <&phy1>;
+ phys = <&serdes_hsio 1 SERDES1G(2) PHY_MODE_SGMII>;
+ };
+ port2: port@2 {
+ reg = <2>;
+ phy-handle = <&phy2>;
+ phys = <&serdes_hsio 2 SERDES1G(3) PHY_MODE_SGMII>;
+ };
+ port3: port@3 {
+ reg = <3>;
+ phy-handle = <&phy3>;
+ phys = <&serdes_hsio 3 SERDES1G(4) PHY_MODE_SGMII>;
+ };
+ port4: port@4 {
+ reg = <4>;
+ phy-handle = <&phy4>;
+ phys = <&serdes_hsio 4 SERDES1G(5) PHY_MODE_SGMII>;
+ };
+ port5: port@5 {
+ reg = <5>;
+ phy-handle = <&phy5>;
+ phys = <&serdes_hsio 5 SERDES1G(6) PHY_MODE_SGMII>;
+ };
+ port6: port@6 {
+ reg = <6>;
+ phy-handle = <&phy6>;
+ phys = <&serdes_hsio 6 SERDES1G(7) PHY_MODE_SGMII>;
+ };
+ port7: port@7 {
+ reg = <7>;
+ phy-handle = <&phy7>;
+ phys = <&serdes_hsio 7 SERDES1G(8) PHY_MODE_SGMII>;
+ };
+ };
+};
diff --git a/arch/mips/dts/jr2_pcb111.dts b/arch/mips/dts/jr2_pcb111.dts
index 4d411b6..f37ebc7 100644
--- a/arch/mips/dts/jr2_pcb111.dts
+++ b/arch/mips/dts/jr2_pcb111.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include "mscc,jr2.dtsi"
+#include
/ {
model = "Jaguar2 Cu48 PCB111 Reference Board";
@@ -72,3 +73,402 @@
sgpio-ports = <0xff00>;
gpio-ranges = <&sgpio2 0 0 96>;
};
+
+&mdio1 {
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ phy2: ethernet-phy@2 {
+ reg = <2>;
+ };
+ phy3: ethernet-phy@3 {
+ reg = <3>;
+ };
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+ phy5: ethernet-phy@5 {
+ reg = <5>;
+ };
+ phy6: ethernet-phy@6 {
+ reg = <6>;
+ };
+ phy7: ethernet-phy@7 {
+ reg = <7>;
+ };
+ phy8: ethernet-phy@8 {
+ reg = <8>;
+ };
+ phy9: ethernet-phy@9 {
+ reg = <9>;
+ };
+ phy10: ethernet-phy@10 {
+ reg = <10>;
+ };
+ phy11: ethernet-phy@11 {
+ reg = <11>;
+ };
+ phy12: ethernet-phy@12 {
+ reg = <12>;
+ };
+ phy13: ethernet-phy@13 {
+ reg = <13>;
+ };
+ phy14: ethernet-phy@14 {
+ reg = <14>;
+ };
+ phy15: ethernet-phy@15 {
+ reg = <15>;
+ };
+ phy16: ethernet-phy@16 {
+ reg = <16>;
+ };
+ phy17: ethernet-phy@17 {
+ reg = <17>;
+ };
+ phy18: ethernet-phy@18 {
+ reg = <18>;
+
[U-Boot] [PATCH v3 0/4] Add network support for Jaguar2 SoCs
v3-changes: - move serdes setup in network driver and read serdes configuration from DT. v2-changes: - create serdes6g_setup and serdes1g_setup functions to be easier to extand for future boards. Horatiu Vultur (4): net: Add MSCC Jaguar2 network driver. board: mscc: jr2: Update MSCC Jaguar2 boards net: mscc: jaguar2: Add ethenet nodes for Jaguar2. configs: mscc_jr2: Add network support arch/mips/dts/jr2_pcb110.dts | 76 +++ arch/mips/dts/jr2_pcb111.dts | 400 arch/mips/dts/mscc,jr2.dtsi | 116 arch/mips/dts/serval2_pcb112.dts | 44 ++ board/mscc/jr2/jr2.c | 23 + configs/mscc_jr2_defconfig|6 +- drivers/net/mscc_eswitch/Kconfig |7 + drivers/net/mscc_eswitch/Makefile |1 + drivers/net/mscc_eswitch/jr2_switch.c | 1075 + include/configs/vcoreiii.h|2 +- include/dt-bindings/mscc/jr2_data.h | 19 + 11 files changed, 1767 insertions(+), 2 deletions(-) create mode 100644 drivers/net/mscc_eswitch/jr2_switch.c create mode 100644 include/dt-bindings/mscc/jr2_data.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: fit: handle mmc read to sram case in rockchip SoCs
Kever, > On 30.03.2019, at 02:43, Kever Yang wrote: > > Hi Simon, > > > On 03/29/2019 11:33 PM, Simon Goldschmidt wrote: >> >> >> On 29.03.19 15:09, Kever Yang wrote: >>> Rockchip fit image with atf may have firmware for sram, >>> so the fit driver need to read data from mmc to sram, >>> but Rockchip mmc controller does not support this data >>> path, we have to read into ddr first and then copy it >>> to sram. >>> >>> Signed-off-by: Kever Yang >>> --- >>> >>> common/spl/spl_fit.c | 10 ++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c >>> index c9bfe0cc8a..5c5b58f69d 100644 >>> --- a/common/spl/spl_fit.c >>> +++ b/common/spl/spl_fit.c >>> @@ -9,6 +9,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #ifndef CONFIG_SYS_BOOTM_LEN >>> @@ -215,6 +216,15 @@ static int spl_load_fit_image(struct >>> spl_load_info *info, ulong sector, >>> return -ENOENT; >>> load_ptr = (load_addr + align_len) & ~align_len; >>> +#if defined(CONFIG_ROCKCHIP_RK3399) || defined(CONFIG_ROCKCHIP_RK3368) >> >> This looks hacky. I don't think we should clutter platform independent >> code with platform dependent ifdefs. You're totally violating code >> abstraction here. >> > > Thanks for your comment, I know this looks hacky, could you share you > idea about how to implement this better? > We do need this to make things work. A more appropriate way would be to leverage the bounce buffers in the SD/MMC drivers and to make sure that the 0x memory region is not allocated as a DMA-able target address via bounce buffers. Note that this is the same issue that I had highlighted about a year and a half ago and that we ended up working around by loading the PMU firmware into DRAM, pass the info about the loadables to ATF as part of the FDT, and finally have ATF relocate the loadables to INTMEM. > Thanks, > - Kever >> Regards, >> Simon >> >>> +/* >>> + * Rockchip SOC's mmc controller does not support read data >>> + * from mmc to sram, we have to read to sdram first, and then >>> + * copy to sram. >>> + */ >>> +if ((load_ptr & 0x) != CONFIG_SYS_SDRAM_BASE) >>> +load_ptr = (ulong)memalign(ARCH_DMA_MINALIGN, len); >>> +#endif >>> length = len; >>> overhead = get_aligned_image_overhead(info, offset); >>> >> > > > > ___ > 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 1/2] ARM: dts: rmobile: Activate I2C7 on Alt
Activate I2C7 on Alt to allow access to the PMIC.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7794-alt-u-boot.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/r8a7794-alt-u-boot.dts
b/arch/arm/dts/r8a7794-alt-u-boot.dts
index 593a418c3b..14cd39297e 100644
--- a/arch/arm/dts/r8a7794-alt-u-boot.dts
+++ b/arch/arm/dts/r8a7794-alt-u-boot.dts
@@ -8,6 +8,11 @@
#include "r8a7794-alt.dts"
#include "r8a7794-u-boot.dtsi"
+&i2c7 {
+ status = "okay";
+ clock-frequency = <10>;
+};
+
&scif2 {
u-boot,dm-pre-reloc;
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: rmobile: alt: Fix I2C bus number
The I2C bus number to access the PMIC is I2C 7, fix this.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
board/renesas/alt/alt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/renesas/alt/alt.c b/board/renesas/alt/alt.c
index 7b85000203..0726776a57 100644
--- a/board/renesas/alt/alt.c
+++ b/board/renesas/alt/alt.c
@@ -107,7 +107,7 @@ int board_phy_config(struct phy_device *phydev)
void reset_cpu(ulong addr)
{
struct udevice *dev;
- const u8 pmic_bus = 1;
+ const u8 pmic_bus = 7;
const u8 pmic_addr = 0x58;
u8 data;
int ret;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: alt: Increase USB power-good delay
Increase the USB power good delay on Alt, this is required with certain USB sticks, otherwise they might not be detected. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- include/configs/alt.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/alt.h b/include/configs/alt.h index 3f7f379e06..3a515eef00 100644 --- a/include/configs/alt.h +++ b/include/configs/alt.h @@ -39,7 +39,8 @@ #define CONFIG_SYS_CLK_FREQRMOBILE_XTAL_CLK #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootm_size=0x1000\0" + "bootm_size=0x1000\0" \ + "usb_pgood_delay=2000\0" /* SPL support */ #define CONFIG_SPL_TEXT_BASE 0xe630 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
