回复: [PATCH V8] arm: add initial support for the Phytium Pomelo Board

2年2月28日 23:21 收件人: Nicholas zheng 主题: Re: [PATCH V8] arm: add initial support for the Phytium Pomelo Board Please reply on list instead of sending private emails. On Sun, Feb 27, 2022 at 8:50 PM Nicholas zheng wrote: > > I'm very sorry. Maybe my meaning is not clear. Phytium is alrea

回复: [PATCH V1] arm: add initial support for the Phytium Pomelo Board

Is this structure describing some hardware register layout? Or some interface with the firmware? Then please use explicit types: uint8_t, uint16_t, ... I want to use uint8_t,but checkpatch.pl showed “Prefer kernel type 'u8' over 'uint8_t'”.So I don't know which is better. Thanks.

回复: [PATCH] arm: add initial support for the Phytium Pomelo Board

Is this some internal board? Or something China only? Google couldn't find any useful hits about the platform. This board corresponds to Phytium D2000. The name of the public edition has not been announced. For other questions, I will submit a new patch after modifying it. thanks.

PPC440EPx Evaluation Board Schematic

communicate with the EBC. Thank you Nicholas I

[U-Boot] [PATCH v2 0/2] Fix to keystone2 uinitrd fixup logic

the call of ft_board_setup_ex() since keystone2 devices will require it. Changes in v2: - Add reviewed-by tag - Add reviewed-by tag, removed RFC/RESEND Nicholas Faustini (2): fdt: add call to ft_board_setup_ex() for ks2 boards board: ks2: move uinitrd fixup logic inside ft_board_setup_ex board

[U-Boot] [PATCH v2 1/2] fdt: add call to ft_board_setup_ex() for ks2 boards

When updating the board FDT, some of the operations are performed by ft_board_setup_ex() and should be executed also by the fdt command. Signed-off-by: Nicholas Faustini Reviewed-by: Tom Rini --- Changes in v2: - Add reviewed-by tag cmd/fdt.c | 3 +++ 1 file changed, 3 insertions(+) diff

[U-Boot] [PATCH v2 2/2] board: ks2: move uinitrd fixup logic inside ft_board_setup_ex

The uinitrd fixup logic should be executed after the FDT /chosen node has been properly populated by fdt_initrd() Signed-off-by: Nicholas Faustini Reviewed-by: Tom Rini --- Changes in v2: - Add reviewed-by tag, removed RFC/RESEND board/ti/ks2_evm/board.c | 44

[U-Boot] [RFC/RESEND PATCH v1 2/2] board: ks2: move uinitrd fixup logic inside ft_board_setup_ex

The uinitrd fixup logic should be executed after the FDT /chosen node has been properly populated by fdt_initrd() Signed-off-by: Nicholas Faustini --- board/ti/ks2_evm/board.c | 44 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/board

[U-Boot] [RFC/RESEND PATCH v1 1/2] fdt: add call to ft_board_setup_ex() for ks2 boards

When updating the board FDT, some of the operations are performed by ft_board_setup_ex() and should be executed also by the fdt command. Signed-off-by: Nicholas Faustini --- cmd/fdt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmd/fdt.c b/cmd/fdt.c index 28de467f96..8a19a3fdbf

[U-Boot] [RFC/RESEND PATCH v1 0/2] Fix to keystone2 uinitrd fixup logic

the call of ft_board_setup_ex() since keystone2 devices will require it. Nicholas Faustini (2): fdt: add call to ft_board_setup_ex() for ks2 boards board: ks2: move uinitrd fixup logic inside ft_board_setup_ex board/ti/ks2_evm/board.c | 44 cmd/fdt.c

[U-Boot] [RFC PATCH v1 2/2] board: ks2: move uinitrd fixup logic inside ft_board_setup_ex

The uinitrd fixup logic should be executed after the FDT /chosen node has been properly populated by fdt_initrd() Signed-off-by: Nicholas Faustini --- board/ti/ks2_evm/board.c | 44 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/board

[U-Boot] [RFC PATCH v1 0/2] Fix to keystone2 uinitrd fixup logic

the call of ft_board_setup_ex() since keystone2 devices will require it. Nicholas Faustini (2): fdt: add call to ft_board_setup_ex() for ks2 boards board: ks2: move uinitrd fixup logic inside ft_board_setup_ex board/ti/ks2_evm/board.c | 44 cmd/fdt.c

[U-Boot] [RFC PATCH v1 1/2] fdt: add call to ft_board_setup_ex() for ks2 boards

When updating the board FDT, some of the operations are performed by ft_board_setup_ex() and should be executed also by the fdt command. Signed-off-by: Nicholas Faustini --- cmd/fdt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmd/fdt.c b/cmd/fdt.c index 28de467f96..8a19a3fdbf

Re: [U-Boot] [PATCH v5] u-boot: remove driver lookup loop from env_save()

Hi Tom, On gio, 2018-07-26 at 20:29 -0400, Tom Rini wrote: > On Thu, Jul 26, 2018 at 10:16:01PM +0200, Goldschmidt Simon wrote: > > > > > + Tom: > > > > I don't know via which tree this would go in. I think you took the > > last env > > changes directly? > > > > v1..v4 are detached threads, I

[U-Boot] [PATCH v5] u-boot: remove driver lookup loop from env_save()

nction should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call. Signed-off-by: Nicholas Faustini Reviewed-by: Simon Goldschmidt --- Changes in v5: - Correction to 'Reviewed-by' tag

[U-Boot] [PATCH v4] u-boot: remove driver lookup loop from env_save()

nction should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call. Signed-off-by: Nicholas Faustini Reviewed-by: Simon Goldschmidt --- Changes in v4: - Remove env_load_location from g

Re: [U-Boot] [PATCH v3] u-boot: remove driver lookup loop from env_save()

On ven, 2018-07-13 at 11:15 +0200, Simon Goldschmidt wrote: > > On 13.07.2018 11:03, Nicholas Faustini wrote: > > > > When called with ENVOP_SAVE, env_get_location() only returns the > > gd->env_load_location variable without actually checking for > > the

[U-Boot] [PATCH v3] u-boot: remove driver lookup loop from env_save()

nction should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call. Signed-off-by: Nicholas Faustini --- Changes in v3: - Add comment when env_load() fails and the env location is

Re: [U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()

On gio, 2018-07-12 at 13:02 +0200, Simon Goldschmidt wrote: > > On 12.07.2018 12:52, Nicholas Faustini wrote: > > > > When called with ENVOP_SAVE, env_get_location() only returns the > > gd->env_load_location variable without actually checking for > > the

[U-Boot] [RFC PATCH v2] u-boot: remove driver lookup loop from env_save()

nction should not loop through the environment location list but it should save the environment into the location stored in gd->env_load_location by the last env_load() call. Signed-off-by: Nicholas Faustini --- Changes in v2: - Restore gd->env_load_location to the highest priority l

Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

On mer, 2018-07-11 at 12:01 +0200, Simon Goldschmidt wrote: > > On 11.07.2018 11:48, Maxime Ripard wrote: > > > > Hi, > > > > On Wed, Jul 11, 2018 at 10:33:28AM +0200, Nicholas wrote: > > > > > > Hi Simon, > > > > >

Re: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

he default here :-( > > Resending without the disclaimer to make possible follow-ups cleaner: > > On 10.07.2018 22:49, Simon Glass wrote: > > > > Hi Nicholas, > > > > On 10 July 2018 at 06:57, Nicholas Faustini > > wrote: > > > > > >

[U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save()

all into an infinite loop when the low-level drv->save() call fails. The env_save() function should not loop through the environment location list but it should use the previously discovered environment driver once. Signed-off-by: Nicholas Faustini --- env/env.c | 8 1 file chan

Re: [U-Boot] [PATCH v2] Makefile: Fix linking with modern binutils

On Tue, 21 Mar 2017 11:16:50 -0400 Tom Rini wrote: > On Tue, Mar 21, 2017 at 08:59:04AM -0500, Jon wrote: > > > Likewise tested on Fedora rawhide with: binutils-2.28-5.fc27 > > > > This patch allows our distro u-boot builds to succeed. +1 > > > > Tested-by: Jon Disnard

[U-Boot] U-Boot Build Failure

To whom it may concern, My name is Nicholas Bowman and I am currently a summer intern at NASA’s Jet Propulsion Laboratory working on developing bootloaders for hardware boards designed to fly on CubeSat missions. I have recently been working with U-Boot and more specifically the U-Boot-Sparc

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

Nicholas Kinar wrote: I now strongly believe that the bootargs are not being passed in properly to the kernel. Having found a posting on the AT91 website [1], I now realize that the Linux kernel has been built with a load address of 0x20008000, but must be loaded to different address

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

On 11-03-29 03:46 PM, Nicholas Kinar wrote: Thanks for your response, Wolfgang - I will switch the file system to UBI/UBIFS, and then post back what I've done. I've been looking in the include/configs/sheevaplug.h directory, and I think that this small embedded computer is now using UBIFS

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

Nicholas Kinar wrote: I then used the ubifsload command to load the uImage into SDRAM memory: U-Boot ubifsload 0x2200 uImage Loading file 'uImage' to addr 0x2200 with size 1256920 (0x00132dd8)... Done The bootargs environment variable was set to be the following: U-Boot setenv

[U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

Hello, I've designed a custom circuit board based around the AT91SAM9RL64 processor from Atmel. This is an ARM9 AT91SAM9 series chip. The Atmel evaluation kit for this processor is supported by U-Boot, and the configuration header file can be found in the u-boot-2010.09 source code

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

On 29/03/2011 10:14 AM, Nicholas Kinar wrote: Also as instructed in the README.NAND, README.JFFS2 and README.JFFS2_NAND files found in the /doc/ directory, I've tried defining the following in my /include/configs/at91sam9rlek.h configuration file: #define CONFIG_JFFS2_NAND 1 #define

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

On 29/03/2011 11:56 AM, Scott Wood wrote: On Tue, 29 Mar 2011 11:37:25 -0600 Nicholas Kinarn.ki...@usask.ca wrote: On 29/03/2011 10:14 AM, Nicholas Kinar wrote: Also as instructed in the README.NAND, README.JFFS2 and README.JFFS2_NAND files found in the /doc/ directory, I've tried defining

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

On 29/03/2011 2:46 PM, Scott Wood wrote: On Tue, 29 Mar 2011 14:35:26 -0600 Nicholas Kinarn.ki...@usask.ca wrote: I have two additional questions associated with booting the kernel from NAND flash on my custom hardware: (1) Does replacing jffs2_1pass.c with jffs2_nand_1pass.c in the fs

Re: [U-Boot] Booting kernel from NAND flash on AT91SAM9 custom board using fsload

On 29/03/2011 3:05 PM, Wolfgang Denk wrote: Dear Nicholas Kinar, In message4d92428e.6030...@usask.ca you wrote: (1) Does replacing jffs2_1pass.c with jffs2_nand_1pass.c in the fs/jffs2 directory influence the robustness of the fsload code? JFFS2 is more or less deprecated these days

[U-Boot] the mips cache code question ?

hello, On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer amd...@gmail.com wrote: On Dec 1, 2010 12:26 AM, 奥刘 happyo...@gmail.com wrote:   In the file .\cpu\mips\cache.s , i found some code confounded .   line 152 to line 156 :                        cache_op Index_Store_Tag_I t0                    

Re: [U-Boot] the mips cache code question ?

Sorry for the two successive posts, I looked at the disassembly... On Wed, Dec 1, 2010 at 1:26 AM, 奥刘 happyo...@gmail.com wrote: Dear All:   Recently , i have build a embedded environment with Uboot . And My Chip is adm5120 , mips4kc code.   In the file .\cpu\mips\cache.s , i found some

[U-Boot] DEC21140 driver netconsole new target.

Hello, I have a board which uses dec21140-like ethernet, non-pci. In Linksys' GPL release is old u-boot (seems 1.1.4). I had same problem with 2010.09, in that when I enable netconsole, I saw each putc/puts twice! I read dec2114x datasheet in detail, and firstly, wonder if anyone else has

Re: [U-Boot] DEC21140 driver netconsole new target.

Hello, On Wed, Nov 24, 2010 at 4:18 PM, Wolfgang Denk w...@denx.de wrote: Dear Scott Nicholas, In message aanlktikpg0duvni9fb_onpz-xydzzse=qoz89ap6f...@mail.gmail.com you wrote: There is no dec21140 Ethernet driver in mainline U-Boot, so it's pretty unlikely that there will be much