Re: [PATCH 2/2] mtd: spi-nor-ids: Add Gigadevice GD25LQ64C
On Sat, Oct 31, 2020 at 9:50 PM Alper Nebi Yasak wrote: > > Add GD25LQ24C 64Mbit chip to spi-nor id table. This chip is used on > rk3399-gru-kevin: > > => sf probe > SF: Detected gd25lq64c with page size 256 Bytes, erase size 4 KiB, total > 8 MiB > => sf erase 0x60 0x20 > SF: 2097152 bytes @ 0x60 Erased: OK > => sf test 0x70 0x1000 > SPI flash test: > 0 erase: 52 ticks, 76 KiB/s 0.608 Mbps > 1 check: 5 ticks, 800 KiB/s 6.400 Mbps > 2 write: 14 ticks, 285 KiB/s 2.280 Mbps > 3 read: 3 ticks, 1333 KiB/s 10.664 Mbps > Test passed > 0 erase: 52 ticks, 76 KiB/s 0.608 Mbps > 1 check: 5 ticks, 800 KiB/s 6.400 Mbps > 2 write: 14 ticks, 285 KiB/s 2.280 Mbps > 3 read: 3 ticks, 1333 KiB/s 10.664 Mbps > > The values are the same as in Linux, except adjusted for the U-Boot > definition of INFO(). > > Signed-off-by: Alper Nebi Yasak > --- Applied to u-boot-spi/master
Re: [PATCH] mtd: spi-nor.h: Change spaces to tabs
On Mon, Feb 1, 2021 at 1:30 PM Bin Meng wrote: > > On Wed, Jan 6, 2021 at 8:59 PM Bin Meng wrote: > > > > U-Boot coding convention prefers tabs over spaces. > > > > Signed-off-by: Bin Meng > > --- > > > > include/linux/mtd/spi-nor.h | 20 ++-- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > Ping? Ping?
Re: [PATCH V2] spi: imx: Implement set_speed
On Wed, Feb 3, 2021 at 10:24 PM Marek Vasut wrote: > > The set_speed() callback should configure the bus speed, make it so. > > Signed-off-by: Marek Vasut > Cc: Jagan Teki > Cc: Stefano Babic > --- > V2: Rename dev_get_platdata() to dev_get_plat() > --- Applied to u-boot-spi/master
Re: [PATCH] firmware: scmi: Replace memcpy_from/toio() by memcpy() in scmi_read/write_resp_from_smt()
Hi Mark On 2/24/21 3:05 PM, Mark Kettenis wrote: >> From: Patrice Chotard >> Date: Wed, 24 Feb 2021 13:47:55 +0100 >> >> To avoid "synchronous abort" in AARCH64 in case the "from" address >> is not aligned, replace memcpy_toio() and memcpy_fromio() by memcpy(). >> >> Signed-off-by: Patrice Chotard >> Signed-off-by: Patrice Chotard >> --- >> >> drivers/firmware/scmi/smt.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) > > This doesnt really make sense. There is no guarantee that memcpy() > doesn't do an unaligned load or store either. > > Unaligned loads and stores from/to normal memory should just work on > arm64, and memcpy_toio() and memcpy_fromio() make sure they don't do > unaligned loads and stores from/to "IO" memory (in this case the > shared memory buffer). You are right. After further analysis, i understood why the "synchronous abort" occurs. At early stage, before U-Boot relocation, MMU is disabled and then all the "normal" memory space is not yet configured with MT_NORMAL type. In this situation, all 64bits accesses to a none 64 bits aligned pointer in "normal memory" triggers a synchronous abort. Same accesses, with MMU configured (after U-Boot relocation), are OK. I will propose a new patch which will update memcpy_from/toio() and forbid 64bits accesses to non aligned 64bits pointer in case MMU is not yet enabled. Thanks Patrice > >> diff --git a/drivers/firmware/scmi/smt.c b/drivers/firmware/scmi/smt.c >> index d25478796a..b001163b62 100644 >> --- a/drivers/firmware/scmi/smt.c >> +++ b/drivers/firmware/scmi/smt.c >> @@ -93,7 +93,7 @@ int scmi_write_msg_to_smt(struct udevice *dev, struct >> scmi_smt *smt, >>SMT_HEADER_PROTOCOL_ID(msg->protocol_id) | >>SMT_HEADER_MESSAGE_ID(msg->message_id); >> >> -memcpy_toio(hdr->msg_payload, msg->in_msg, msg->in_msg_sz); >> +memcpy(hdr->msg_payload, msg->in_msg, msg->in_msg_sz); >> >> return 0; >> } >> @@ -124,7 +124,7 @@ int scmi_read_resp_from_smt(struct udevice *dev, struct >> scmi_smt *smt, >> >> /* Get the data */ >> msg->out_msg_sz = hdr->length - sizeof(hdr->msg_header); >> -memcpy_fromio(msg->out_msg, hdr->msg_payload, msg->out_msg_sz); >> +memcpy(msg->out_msg, hdr->msg_payload, msg->out_msg_sz); >> >> return 0; >> } >> -- >> 2.17.1 >> >>
[PATCH v2] cfi_flash: Fix detection of 8-bit bus flash devices via address shift
From: Jagannadha Sutradharudu Teki
We had a problem detecting 8/16bit flash devices connected only via
8bits to the SoC for quite a while. Commit 239cb9d9
[mtd: cfi_flash: Fix CFI flash driver for 8-bit bus support] finally
fixed this 8-bit bus support. But also broke some other boards using
this cfi driver. So this patch had to be reverted.
I spotted a different, simpler approach for this 8-bit bus support
on the barebox mailing list posted by
Oleksij Rempel :
http://www.spinics.net/lists/u-boot-v2/msg14687.html
Here the commit text:
"
Many cfi chips support 16 and 8 bit modes. Most important
difference is use of so called "Q15/A-1" pin. In 16bit mode this
pin is used for data IO. In 8bit mode, it is an address input
which add one more least significant bit (LSB). In this case
we should shift all adresses by one:
For example 0xaa << 1 = 0x154
"
This patch now is a port of this barebox patch to U-Boot.
Along with the change w.r.t from barebox,
Some flash chips can support multiple bus widths, override the
interface width and limit it to the port width.
Tested on 16-bit Spansion flash on sequoia.
Tested 8-bit flashes like 256M29EW, 512M29EW.
Signed-off-by: Stefan Roese
Tested-by: Jagannadha Sutradharudu Teki
Cc: Jagannadha Sutradharudu Teki
Cc: Aaron Williams
Cc: Chandrakala Chavva
Cc: Andre Przywara
Cc: Vignesh Raghavendra
Cc: Simon Glass
Cc: Mario Six
Cc: York Sun
Cc: Marek Vasut
---
v2:
- Rebase on current mainline
I've run into problems with CFI flash on the MIPS Octeon EBB7304, where
the CFI detection did not work. While testing and digging through the
very old CFI related patches, I stumbled over this patch which fixes
the problems on the EBB7304.
I would really like to see some further testing of this patch on other
boards using CFI parallel flash though. That's why I added some
developers who did send CFI related patches in the last few years. So
please test with this patch applied if possible.
Thanks,
Stefan
drivers/mtd/cfi_flash.c | 37 +
include/flash.h | 2 ++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b4512e3a5f..9642d7c7dc 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -218,7 +218,7 @@ flash_map(flash_info_t *info, flash_sect_t sect, uint
offset)
{
unsigned int byte_offset = offset * info->portwidth;
- return (void *)(info->start[sect] + byte_offset);
+ return (void *)(info->start[sect] + (byte_offset << info->chip_lsb));
}
static inline void flash_unmap(flash_info_t *info, flash_sect_t sect,
@@ -1918,12 +1918,27 @@ static int __flash_detect_cfi(flash_info_t *info,
struct cfi_qry *qry)
flash_read_cfi(info, qry, FLASH_OFFSET_CFI_RESP,
sizeof(struct cfi_qry));
info->interface = le16_to_cpu(qry->interface_desc);
+ /* Some flash chips can support multiple bus widths.
+* In this case, override the interface width and
+* limit it to the port width.
+*/
+ if ((info->interface == FLASH_CFI_X8X16) &&
+ (info->portwidth == FLASH_CFI_8BIT)) {
+ debug("Overriding 16-bit interface width to"
+ " 8-bit port width\n");
+ info->interface = FLASH_CFI_X8;
+ } else if ((info->interface == FLASH_CFI_X16X32) &&
+ (info->portwidth == FLASH_CFI_16BIT)) {
+ debug("Overriding 16-bit interface width to"
+ " 16-bit port width\n");
+ info->interface = FLASH_CFI_X16;
+ }
info->cfi_offset = flash_offset_cfi[cfi_offset];
debug("device interface is %d\n",
info->interface);
- debug("found port %d chip %d ",
- info->portwidth, info->chipwidth);
+ debug("found port %d chip %d chip_lsb %d ",
+ info->portwidth, info->chipwidth, info->chip_lsb);
debug("port %d bits chip %d bits\n",
info->portwidth << CFI_FLASH_SHIFT_WIDTH,
info->chipwidth << CFI_FLASH_SHIFT_WIDTH);
@@ -1962,9 +1977,23 @@ static int flash_detect_cfi(flash_info_t *info, struct
cfi_qry *qry)
info->portwidth <= FLASH_CFI_64BIT; info->portwidth <<= 1) {
for (info->chipwidth = FLASH_CFI_BY8;
info->chipwidth <= info->portwidth;
-info->chipwidth <<= 1)
+info->chipwidth <<= 1) {
+
[PATCH 2/2] of: addr: Translate 'dma-ranges' for parent nodes missing 'dma-ranges'
'dma-ranges' frequently exists without parent nodes having 'dma-ranges'.
While this is an error for 'ranges', this is fine because DMA capable
devices always have a translatable DMA address. Also, with no
'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with
no restrictions unless perhaps the device itself has implicit
restrictions.
This keeps in sync with Linux kernel commit:
81db12ee15cb: of/address: Translate 'dma-ranges' for parent nodes missing
'dma-ranges'
Signed-off-by: Bin Meng
---
drivers/core/of_addr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 36cdfd3..b9abf90 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -174,12 +174,12 @@ static int of_translate_one(const struct device_node
*parent,
u64 offset = OF_BAD_ADDR;
ranges = of_get_property(parent, rprop, );
- if (ranges == NULL) {
+ if (ranges == NULL && strcmp(rprop, "dma-ranges")) {
debug("no ranges; cannot translate\n");
return 1;
}
- if (rlen == 0) {
+ if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
debug("empty ranges; 1:1 translation\n");
--
2.7.4
[PATCH 1/2] of: addr: Abort address translation for parent nodes missing 'ranges'
The implementation of of_translate_one() was taken from the one in
Linux kernel drivers/of/address.c, and the Linux one added a quirk
for Apple Macs that don't have the property in the parent
node. Since U-Boot does not support Apple Macs, remove the comment
block and adhere to the spec to abort the translation.
Signed-off-by: Bin Meng
---
drivers/core/of_addr.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 5bc6ca1..36cdfd3 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -173,25 +173,13 @@ static int of_translate_one(const struct device_node
*parent,
int rone;
u64 offset = OF_BAD_ADDR;
- /*
-* Normally, an absence of a "ranges" property means we are
-* crossing a non-translatable boundary, and thus the addresses
-* below the current cannot be converted to CPU physical ones.
-* Unfortunately, while this is very clear in the spec, it's not
-* what Apple understood, and they do have things like /uni-n or
-* /ht nodes with no "ranges" property and a lot of perfectly
-* useable mapped devices below them. Thus we treat the absence of
-* "ranges" as equivalent to an empty "ranges" property which means
-* a 1:1 translation at that level. It's up to the caller not to try
-* to translate addresses that aren't supposed to be translated in
-* the first place. --BenH.
-*
-* As far as we know, this damage only exists on Apple machines, so
-* This code is only enabled on powerpc. --gcl
-*/
-
ranges = of_get_property(parent, rprop, );
- if (ranges == NULL || rlen == 0) {
+ if (ranges == NULL) {
+ debug("no ranges; cannot translate\n");
+ return 1;
+ }
+
+ if (rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
debug("empty ranges; 1:1 translation\n");
--
2.7.4
Re: [PATCH] serial: ns16550: Correct the base address type
Hi Simon,
On Sun, Feb 7, 2021 at 8:16 AM Simon Glass wrote:
>
> On Wed, 3 Feb 2021 at 06:22, Bin Meng wrote:
> >
> > Currently ns16550_serial_assign_base() treats the argument 'base'
> > with type `ulong`. This is incorrect because the base address was
> > obtained from device tree with type `fdt_addr_t` that can represent
> > a physical address larger than 32-bit in a 32-bit system.
> >
> > Fixes: 9e6ce62190b7 ("serial: ns16550: Fix ordering of getting base
> > address")
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/serial/ns16550.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass
>
> Applied to u-boot-dm, thanks!
It looks like this is still not in u-boot/master yet?
Regards,
Bin
Re: [EXT] [PATCH] ARM: imx: Add OCRAM_S into iMX8M MMU tables
Hi Marek,
On Thu, 2021-02-25 at 21:52 +0100, Marek Vasut wrote:
> Caution: EXT Email
>
> The OCRAM_S is regular memory, just like the OCRAM, add it to the MMU
> tables so it can be used and cached.
>
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Peng Fan
> Cc: Stefano Babic
> ---
> arch/arm/mach-imx/imx8m/soc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-
> imx/imx8m/soc.c
> index 5456c10fb17..225e4e12500 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -104,6 +104,13 @@ static struct mm_region imx8m_mem_map[] = {
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> PTE_BLOCK_NON_SHARE |
> PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* OCRAM_S */
> + .virt = 0x18UL,
> + .phys = 0x18UL,
> + .size = 0x8000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> +PTE_BLOCK_OUTER_SHARE
> }, {
> /* TCM */
> .virt = 0x7CUL,
> --
> 2.30.0
>
OCRAM_S is used by ATF and SPL to pass DDR CSR data. It is better not
use it in u-boot to avoid any DDR issue.
And this imx8m_mem_map will be modified at runtime to get rid of optee
memory. When OCRAM_S is added, the index used in enable_caches and
dram_init need update as well.
Best regards,
Ye Li
[PATCH] cmd: mmc: modify more readable about hwpartition usage
Modified more readable about hwpartition usage.
Because it's difficult to understand how to use its command.
The arguments didn't optional.
mmc hwpartition needs to passas arguments.
Description about each arguments what is required is the below:
USER - <{on|off}>
GP - <{gp1|gp2|gp3|gp4}><{on|off}>
MODE - <{check|set|complete}>
Signed-off-by: Jaehoon Chung
---
cmd/mmc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/cmd/mmc.c b/cmd/mmc.c
index cb6b59f36a43..c1c00d0f325d 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -1008,11 +1008,14 @@ U_BOOT_CMD(
"mmc list - lists available devices\n"
"mmc wp - power on write protect boot partitions\n"
#if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
- "mmc hwpartition [args...] - does hardware partitioning\n"
+ "mmc hwpartition- does hardware partitioning\n"
" arguments (sizes in 512-byte blocks):\n"
- "[user [enh start cnt] [wrrel {on|off}]] - sets user data area
attributes\n"
- "[gp1|gp2|gp3|gp4 cnt [enh] [wrrel {on|off}]] - general purpose
partition\n"
- "[check|set|complete] - mode, complete set partitioning completed\n"
+ " USER - <{on|off}>\n"
+ " : sets user data area attributes\n"
+ " GP - <{gp1|gp2|gp3|gp4}><{on|off}>\n"
+ " : general purpose partition\n"
+ " MODE - <{check|set|complete}>\n"
+ " : mode, complete set partitioning completed\n"
" WARNING: Partitioning is a write-once setting once it is set to
complete.\n"
" Power cycling is required to initialize partitions after set to
complete.\n"
#endif
--
2.29.0
Re: imx8mq: phycore-imx8mp
Hello Heiko, Am Donnerstag, den 25.02.2021, 14:46 +0100 schrieb Heiko Schocher: > Hello Peng, Teresa, > > I am just trying to get linux-stable 5.10.y kernel with current > mainline > U-Boot on the pyhcore imx8mp board up and running, and fail detecting > sd > card on usdhc2 in linux. > > With U-Boot 2021.01 *same* kernel image/dts detects fine the sd card > on > usdhc2. So I have no idea, why kernel is here dependent on U-Boot > setup! > Which is also a bug I think ... > > @Peng: Now started a small git bisect in U-Boot tree and your commit > > cf8842bc29 - arm: dts: imx8mp: sync dts from Linux Kernel > > poped up... with the commit before: > > 374866a724 - imx8m: clock: add type of set_clk_eqos > > the phycore imx8mp board boots fine linux kernel and kernel detects > sd card... > > Attention: The phytec board support came later into u-boot tree with > commit: > > c661c511e9 - board: phytec: imx8mp: Add PHYTEC phyCORE-i.MX8MP > support > > So the board support patch was pending on the list and not tested > with > your patches I think... yes, there where not. > > Any ideas, what could be the problem? So far I was able to narrow it down to the changes done in the clock-controller@3038 node of arch/arm/dts/imx8mp.dtsi: --- a/arch/arm/dts/imx8mp.dtsi +++ b/arch/arm/dts/imx8mp.dtsi @@ -383,6 +383,22 @@ < IMX8MP_CLK_IPG_AUDIO_ROOT>, < IMX8MP_AUDIO_PLL1>, < IMX8MP_AUDIO_PLL2>; + assigned-clock-parents = < IMX8MP_SYS_PLL1_800M>, +< IMX8MP_ARM_PLL_OUT>, +< IMX8MP_SYS_PLL2_1000M>, +< IMX8MP_SYS_PLL1_800M>, +< IMX8MP_SYS_PLL2_500M>, +< IMX8MP_SYS_PLL1_800M>, +< IMX8MP_SYS_PLL1_800M>; + assigned-clock-rates = <0>, <0>, + <10>, + <8>, + <5>, + <4>, + <8>, + <4>, + <393216000>, + <361267200>; If I remove this part again it is booting. Regards, Teresa > > Thanks! > > bye, > Heiko
Pull request: u-boot-samsung master
Dear Tom, The following changes since commit 8f7a16aac36c2a38956bd04b53cb7b94b7a70180: Merge tag 'u-boot-amlogic-20210222' of https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic (2021-02-22 12:37:02 -0500) are available in the git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-samsung.git master for you to fetch changes up to 0b547b40b149cf76c9f857fc9df2223aa88759e7: samsung: origen: change maintainer (2021-02-23 15:43:27 +0900) Jaehoon Chung (2): board: samsung: covert to driver model about power_key_pressed power: pmic: remove pmic_max8997/8 files Mark Kettenis (1): serial: s5p: Allow independent selection Minkyu Kang (6): samsung: goni: change maintainer samsung: smdk5250: change maintainer samsung: smdk5420: change maintainer samsung: smdkv310: change maintainer samsung: espresso7420: change maintainer samsung: origen: change maintainer board/samsung/common/misc.c| 27 +++-- board/samsung/espresso7420/MAINTAINERS | 2 +- board/samsung/goni/MAINTAINERS | 2 +- board/samsung/origen/MAINTAINERS | 2 +- board/samsung/smdk5250/MAINTAINERS | 4 ++-- board/samsung/smdk5420/MAINTAINERS | 2 +- board/samsung/smdkv310/MAINTAINERS | 2 +- drivers/power/pmic/Makefile| 2 -- drivers/power/pmic/pmic_max8997.c | 107 -- drivers/power/pmic/pmic_max8998.c | 32 - drivers/serial/Kconfig | 7 ++ drivers/serial/Makefile| 2 +- 12 files changed, 29 insertions(+), 162 deletions(-) delete mode 100644 drivers/power/pmic/pmic_max8997.c delete mode 100644 drivers/power/pmic/pmic_max8998.c -- Thanks, Minkyu Kang.
Re: [PATCH 1/1] efi_loader: fix documentation in efi_loader.h
On Thu, Feb 25, 2021 at 12:03:48PM +0100, Heinrich Schuchardt wrote:
> Correct missing descriptions and typos in efi_loader.h.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> include/efi_loader.h | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index f470bbd636..68daa1a4a9 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -242,7 +242,7 @@ struct efi_open_protocol_info_item {
> * @link:link to the list of protocols of a handle
> * @guid:GUID of the protocol
> * @protocol_interface: protocol interface
> - * @open_infos link to the list of open protocol info items
> + * @open_infos: link to the list of open protocol info items
> */
> struct efi_handler {
> struct list_head link;
> @@ -258,9 +258,13 @@ struct efi_handler {
> * started image.
> */
> enum efi_object_type {
> + /** @EFI_OBJECT_TYPE_UNDEFINED: undefined image type */
> EFI_OBJECT_TYPE_UNDEFINED = 0,
> + /** @EFI_OBJECT_TYPE_U_BOOT_FIRMWARE: U-Boot firmware */
> EFI_OBJECT_TYPE_U_BOOT_FIRMWARE,
> + /** @EFI_OBJECT_TYPE_LOADED_IMAGE: loaded image (not started) */
> EFI_OBJECT_TYPE_LOADED_IMAGE,
> + /** @EFI_OBJECT_TYPE_STARTED_IMAGE: started image */
> EFI_OBJECT_TYPE_STARTED_IMAGE,
> };
>
> @@ -270,6 +274,7 @@ enum efi_object_type {
> * @link:pointers to put the handle into a linked list
> * @protocols: linked list with the protocol interfaces installed on
> this
> * handle
> + * @type:image type if the handle relates to an image
> *
> * UEFI offers a flexible and expandable object model. The objects in the
> UEFI
> * API are devices, drivers, and loaded images. struct efi_object is our
> storage
> @@ -325,7 +330,7 @@ struct efi_loaded_image_obj {
> * @queue_link: Link to the list of queued events
> * @type:Type of event, see efi_create_event
> * @notify_tpl: Task priority level of notifications
> - * @nofify_function: Function to call when the event is triggered
> + * @notify_function: Function to call when the event is triggered
> * @notify_context: Data to be passed to the notify function
> * @group: Event group
> * @trigger_time:Period of the timer
> @@ -368,7 +373,8 @@ struct efi_protocol_notification {
> };
>
> /**
> - * efi_register_notify_event - event registered by RegisterProtocolNotify()
> + * struct efi_register_notify_event - event registered by
> + * RegisterProtocolNotify()
> *
> * The address of this structure serves as registration value.
> *
> @@ -747,7 +753,7 @@ efi_status_t efi_set_load_options(efi_handle_t handle,
> efi_status_t efi_bootmgr_load(efi_handle_t *handle, void **load_options);
>
> /**
> - * efi_image_regions - A list of memory regions
> + * struct efi_image_regions - A list of memory regions
> *
> * @max: Maximum number of regions
> * @num: Number of regions
> @@ -760,13 +766,13 @@ struct efi_image_regions {
> };
>
> /**
> - * efi_sig_data - A decoded data of struct efi_signature_data
> + * struct efi_sig_data - A decoded data of struct efi_signature_data
'data' is a plural or mass noun. "a data" must be grammatically
incorrect. Please fix it as well.
Thanks,
-Takahiro Akashi
> *
> * This structure represents an internal form of signature in
> * signature database. A listed list may represent a signature list.
> *
> * @next:Pointer to next entry
> - * @onwer: Signature owner
> + * @owner: Signature owner
> * @data:Pointer to signature data
> * @size:Size of signature data
> */
> @@ -778,7 +784,7 @@ struct efi_sig_data {
> };
>
> /**
> - * efi_signature_store - A decoded data of signature database
> + * struct efi_signature_store - A decoded data of signature database
> *
> * This structure represents an internal form of signature database.
> *
> --
> 2.30.0
>
Re: [PATCH v2 1/1] drivers: mmc: iproc_sdhci: enable HS200 mode
On 2/26/21 3:15 PM, Rayagonda Kokatanur wrote:
> From: Bharat Gooty
>
> Add tuning functionality which is needed for HS200 mode.
> For HS200, program the correct needed 1.8 voltage
>
> Signed-off-by: Bharat Gooty
> Signed-off-by: Rayagonda Kokatanur
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Changes from v1:
> --Address review comments from Jaehoon Chung,
>Add comment for udelay
>Move #define to top
>Remove udelay
>
> drivers/mmc/iproc_sdhci.c | 92 +++
> 1 file changed, 83 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/iproc_sdhci.c b/drivers/mmc/iproc_sdhci.c
> index 6e4f527e5d..11d86ad658 100644
> --- a/drivers/mmc/iproc_sdhci.c
> +++ b/drivers/mmc/iproc_sdhci.c
> @@ -10,8 +10,11 @@
> #include
> #include
> #include
> +#include "mmc_private.h"
> #include
>
> +#define MAX_TUNING_LOOP 40
> +
> DECLARE_GLOBAL_DATA_PTR;
>
> struct sdhci_iproc_host {
> @@ -140,17 +143,89 @@ static void sdhci_iproc_writeb(struct sdhci_host *host,
> u8 val, int reg)
>
> static int sdhci_iproc_set_ios_post(struct sdhci_host *host)
> {
> - u32 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + struct mmc *mmc = (struct mmc *)host->mmc;
> + u32 ctrl;
> +
> + if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + ctrl |= SDHCI_CTRL_VDD_180;
> + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> + }
>
> - /* Reset UHS mode bits */
> - ctrl &= ~SDHCI_CTRL_UHS_MASK;
> + sdhci_set_uhs_timing(host);
> + return 0;
> +}
>
> - if (host->mmc->ddr_mode)
> - ctrl |= UHS_DDR50_BUS_SPEED;
> +static void sdhci_start_tuning(struct sdhci_host *host)
> +{
> + u32 ctrl;
>
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + ctrl |= SDHCI_CTRL_EXEC_TUNING;
> sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
>
> - return 0;
> + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
> + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
> +}
> +
> +static void sdhci_end_tuning(struct sdhci_host *host)
> +{
> + /* Enable only interrupts served by the SD controller */
> + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
> + SDHCI_INT_ENABLE);
> + /* Mask all sdhci interrupt sources */
> + sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE);
> +}
> +
> +static int sdhci_iproc_execute_tuning(struct mmc *mmc, u8 opcode)
> +{
> + struct mmc_cmd cmd;
> + u32 ctrl;
> + u32 blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64);
> + struct sdhci_host *host = dev_get_priv(mmc->dev);
> + char tuning_loop_counter = MAX_TUNING_LOOP;
> + int ret = 0;
> +
> + sdhci_start_tuning(host);
> +
> + cmd.cmdidx = opcode;
> + cmd.resp_type = MMC_RSP_R1;
> + cmd.cmdarg = 0;
> +
> + if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && mmc->bus_width == 8)
> + blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128);
> +
> + sdhci_writew(host, blocksize, SDHCI_BLOCK_SIZE);
> + sdhci_writew(host, 1, SDHCI_BLOCK_COUNT);
> + sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
> +
> + do {
> + mmc_send_cmd(mmc, , NULL);
> + if (opcode == MMC_CMD_SEND_TUNING_BLOCK)
> + /*
> + * For tuning command, do not do busy loop. As tuning
> + * is happening (CLK-DATA latching for setup/hold time
> + * requirements), give time to complete
> + */
> + udelay(1);
> +
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> +
> + if (tuning_loop_counter-- == 0)
> + break;
> +
> + } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
> +
> + if (tuning_loop_counter < 0 || (!(ctrl & SDHCI_CTRL_TUNED_CLK))) {
> + ctrl &= ~(SDHCI_CTRL_TUNED_CLK | SDHCI_CTRL_EXEC_TUNING);
> + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2);
> + printf("%s:Tuning failed, opcode = 0x%02x\n", __func__, opcode);
> + ret = -EIO;
> + }
> +
> + sdhci_end_tuning(host);
> +
> + return ret;
> }
>
> static struct sdhci_ops sdhci_platform_ops = {
> @@ -163,6 +238,7 @@ static struct sdhci_ops sdhci_platform_ops = {
> .write_b = sdhci_iproc_writeb,
> #endif
> .set_ios_post = sdhci_iproc_set_ios_post,
> + .platform_execute_tuning = sdhci_iproc_execute_tuning,
> };
>
> struct iproc_sdhci_plat {
> @@ -190,9 +266,7 @@ static int iproc_sdhci_probe(struct udevice *dev)
>
> host->name = dev->name;
> host->ioaddr = dev_read_addr_ptr(dev);
> - host->voltages = MMC_VDD_165_195 |
> - MMC_VDD_32_33 | MMC_VDD_33_34;
> - host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B;
> + host->quirks =
[PATCH v2 1/1] drivers: mmc: iproc_sdhci: enable HS200 mode
From: Bharat Gooty
Add tuning functionality which is needed for HS200 mode.
For HS200, program the correct needed 1.8 voltage
Signed-off-by: Bharat Gooty
Signed-off-by: Rayagonda Kokatanur
---
Changes from v1:
--Address review comments from Jaehoon Chung,
Add comment for udelay
Move #define to top
Remove udelay
drivers/mmc/iproc_sdhci.c | 92 +++
1 file changed, 83 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/iproc_sdhci.c b/drivers/mmc/iproc_sdhci.c
index 6e4f527e5d..11d86ad658 100644
--- a/drivers/mmc/iproc_sdhci.c
+++ b/drivers/mmc/iproc_sdhci.c
@@ -10,8 +10,11 @@
#include
#include
#include
+#include "mmc_private.h"
#include
+#define MAX_TUNING_LOOP40
+
DECLARE_GLOBAL_DATA_PTR;
struct sdhci_iproc_host {
@@ -140,17 +143,89 @@ static void sdhci_iproc_writeb(struct sdhci_host *host,
u8 val, int reg)
static int sdhci_iproc_set_ios_post(struct sdhci_host *host)
{
- u32 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ struct mmc *mmc = (struct mmc *)host->mmc;
+ u32 ctrl;
+
+ if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ ctrl |= SDHCI_CTRL_VDD_180;
+ sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+ }
- /* Reset UHS mode bits */
- ctrl &= ~SDHCI_CTRL_UHS_MASK;
+ sdhci_set_uhs_timing(host);
+ return 0;
+}
- if (host->mmc->ddr_mode)
- ctrl |= UHS_DDR50_BUS_SPEED;
+static void sdhci_start_tuning(struct sdhci_host *host)
+{
+ u32 ctrl;
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ ctrl |= SDHCI_CTRL_EXEC_TUNING;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
- return 0;
+ sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
+ sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
+}
+
+static void sdhci_end_tuning(struct sdhci_host *host)
+{
+ /* Enable only interrupts served by the SD controller */
+ sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
+SDHCI_INT_ENABLE);
+ /* Mask all sdhci interrupt sources */
+ sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE);
+}
+
+static int sdhci_iproc_execute_tuning(struct mmc *mmc, u8 opcode)
+{
+ struct mmc_cmd cmd;
+ u32 ctrl;
+ u32 blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64);
+ struct sdhci_host *host = dev_get_priv(mmc->dev);
+ char tuning_loop_counter = MAX_TUNING_LOOP;
+ int ret = 0;
+
+ sdhci_start_tuning(host);
+
+ cmd.cmdidx = opcode;
+ cmd.resp_type = MMC_RSP_R1;
+ cmd.cmdarg = 0;
+
+ if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && mmc->bus_width == 8)
+ blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128);
+
+ sdhci_writew(host, blocksize, SDHCI_BLOCK_SIZE);
+ sdhci_writew(host, 1, SDHCI_BLOCK_COUNT);
+ sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
+
+ do {
+ mmc_send_cmd(mmc, , NULL);
+ if (opcode == MMC_CMD_SEND_TUNING_BLOCK)
+ /*
+* For tuning command, do not do busy loop. As tuning
+* is happening (CLK-DATA latching for setup/hold time
+* requirements), give time to complete
+*/
+ udelay(1);
+
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+
+ if (tuning_loop_counter-- == 0)
+ break;
+
+ } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
+
+ if (tuning_loop_counter < 0 || (!(ctrl & SDHCI_CTRL_TUNED_CLK))) {
+ ctrl &= ~(SDHCI_CTRL_TUNED_CLK | SDHCI_CTRL_EXEC_TUNING);
+ sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2);
+ printf("%s:Tuning failed, opcode = 0x%02x\n", __func__, opcode);
+ ret = -EIO;
+ }
+
+ sdhci_end_tuning(host);
+
+ return ret;
}
static struct sdhci_ops sdhci_platform_ops = {
@@ -163,6 +238,7 @@ static struct sdhci_ops sdhci_platform_ops = {
.write_b = sdhci_iproc_writeb,
#endif
.set_ios_post = sdhci_iproc_set_ios_post,
+ .platform_execute_tuning = sdhci_iproc_execute_tuning,
};
struct iproc_sdhci_plat {
@@ -190,9 +266,7 @@ static int iproc_sdhci_probe(struct udevice *dev)
host->name = dev->name;
host->ioaddr = dev_read_addr_ptr(dev);
- host->voltages = MMC_VDD_165_195 |
-MMC_VDD_32_33 | MMC_VDD_33_34;
- host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B;
+ host->quirks = SDHCI_QUIRK_BROKEN_R1B;
host->host_caps = MMC_MODE_DDR_52MHz;
host->index = fdtdec_get_uint(gd->fdt_blob, node, "index", 0);
host->ops = _platform_ops;
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH 1/6] samsung: goni: change maintainer
Hi, On Fri, 19 Feb 2021 at 18:02, Minkyu Kang wrote: > change maintainer to Jaehoon > > Signed-off-by: Minkyu Kang > Signed-off-by: Jaehoon Chung > --- > board/samsung/goni/MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board/samsung/goni/MAINTAINERS > b/board/samsung/goni/MAINTAINERS > index 248ec3c..7643f9c 100644 > --- a/board/samsung/goni/MAINTAINERS > +++ b/board/samsung/goni/MAINTAINERS > @@ -1,5 +1,5 @@ > GONI BOARD > -M: Robert Baldyga > +M: Jaehoon Chung > S: Maintained > F: board/samsung/goni/ > F: include/configs/s5p_goni.h > -- > 1.9.1 > > -- > Thanks, > Minkyu Kang. > applied this series to u-boot-samsung. -- Thanks, Minkyu Kang.
Re: [PATCH V2 0/2] power: remove non-DM max8997/8 files
Hi, On Tue, 23 Feb 2021 at 07:28, Jaehoon Chung wrote: > Remove non-DM files about max8997 and mx8998. > There are already max8997/8 pmic driver to support driver-model. > But it didn't remove them because there was one place to use them. > > Now it's time to rmoeve non-DM max8997/8 files after converting to DM > in samsung/common/misc.c > > Changelog on V2: > - Rebased on latest u-boot > - Add Simon's reviewed-tag > > Jaehoon Chung (2): > board: samsung: covert to driver model about power_key_pressed > power: pmic: remove pmic_max8997/8 files > > board/samsung/common/misc.c | 27 > drivers/power/pmic/Makefile | 2 - > drivers/power/pmic/pmic_max8997.c | 107 -- > drivers/power/pmic/pmic_max8998.c | 32 - > 4 files changed, 14 insertions(+), 154 deletions(-) > delete mode 100644 drivers/power/pmic/pmic_max8997.c > delete mode 100644 drivers/power/pmic/pmic_max8998.c > > -- > 2.29.0 > > applied to u-boot-samsung. -- Thanks, Minkyu Kang.
Re: [PATCH v2] serial: s5p: Allow independent selection
Hi, On Sun, 14 Feb 2021 at 19:30, Patrick Wildt wrote: > Am Fri, Feb 12, 2021 at 11:22:18PM +0100 schrieb Mark Kettenis: > > Currently support for the Samsung serial port driver is part > > of CONFIG_S5P which controls selection of several drivers for > > the S5P family. Give it its own config option such that we > > can use it on other SoCs as well. > > > > Signed-off-by: Mark Kettenis > > Reviewed-by: Patrick Wildt > > > --- > > > > v2: fix Kconfig > > > > drivers/serial/Kconfig | 7 +++ > > drivers/serial/Makefile | 2 +- > > 2 files changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > > index 9db4cae1df..2ada150526 100644 > > --- a/drivers/serial/Kconfig > > +++ b/drivers/serial/Kconfig > > @@ -722,6 +722,13 @@ config ROCKCHIP_SERIAL > > This uses the ns16550 driver, converting the platdata from > of-platdata > > to the ns16550 format. > > > > +config S5P_SERIAL > > + bool "Support for Samsung S5P UART" > > + depends on ARCH_EXYNOS || ARCH_S5PC1XX > > + default y > > + help > > + Select this to enable Samsung S5P UART support. > > + > > config SANDBOX_SERIAL > > bool "Sandbox UART support" > > depends on SANDBOX > > diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile > > index 0c3810f5d5..92bcb30b85 100644 > > --- a/drivers/serial/Makefile > > +++ b/drivers/serial/Makefile > > @@ -41,7 +41,7 @@ obj-$(CONFIG_EFI_APP) += serial_efi.o > > obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o > > obj-$(CONFIG_MCFUART) += serial_mcf.o > > obj-$(CONFIG_SYS_NS16550) += ns16550.o > > -obj-$(CONFIG_S5P) += serial_s5p.o > > +obj-$(CONFIG_S5P_SERIAL) += serial_s5p.o > > obj-$(CONFIG_MXC_UART) += serial_mxc.o > > obj-$(CONFIG_PXA_SERIAL) += serial_pxa.o > > obj-$(CONFIG_MESON_SERIAL) += serial_meson.o > > -- > > 2.30.0 > > > Applied to u-boot-samsung. -- Thanks, Minkyu Kang.
Re: [PATCH v1 1/1] drivers: mmc: iproc_sdhci: enable HS200 mode
On Wed, Feb 10, 2021 at 3:12 AM Jaehoon Chung wrote:
>
> Hi Rayagonda,
>
> On 2/9/21 1:34 PM, Rayagonda Kokatanur wrote:
> > From: Bharat Gooty
> >
> > Add tuning functionality which is needed for HS200 mode.
> > For HS200, program the correct needed 1.8 voltage
>
> I didn't test with this on target. But how did you use HS200 mode?
> In this patch, there is no set to HS200 mode. Is there any other patch.
It can be enabled from a config file (configs/bcm_ns3_defconfig) based
on requirement. Hence not added config file changes.
>
> >
> > Signed-off-by: Bharat Gooty
> > Signed-off-by: Rayagonda Kokatanur
> > ---
> > drivers/mmc/iproc_sdhci.c | 88 +++
> > 1 file changed, 79 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/mmc/iproc_sdhci.c b/drivers/mmc/iproc_sdhci.c
> > index f931e4b3c1..360ea01e21 100644
> > --- a/drivers/mmc/iproc_sdhci.c
> > +++ b/drivers/mmc/iproc_sdhci.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include "mmc_private.h"
> > #include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> > @@ -139,17 +140,87 @@ static void sdhci_iproc_writeb(struct sdhci_host
> > *host, u8 val, int reg)
> >
> > static int sdhci_iproc_set_ios_post(struct sdhci_host *host)
> > {
> > - u32 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> > + struct mmc *mmc = (struct mmc *)host->mmc;
> > + u32 ctrl;
> >
> > - /* Reset UHS mode bits */
> > - ctrl &= ~SDHCI_CTRL_UHS_MASK;
> > + if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
> > + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> > + ctrl |= SDHCI_CTRL_VDD_180;
> > + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> > + }
> >
> > - if (host->mmc->ddr_mode)
> > - ctrl |= UHS_DDR50_BUS_SPEED;
>
> Doesn't need to remove this? If someone want to use DDR mode, doesn't need to
> set this bit?
Supported speeds can come from the capabilities registers
>
> > + sdhci_set_uhs_timing(host);
> > + return 0;
> > +}
> >
> > +static void sdhci_start_tuning(struct sdhci_host *host)
> > +{
> > + u32 ctrl;
> > +
> > + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> > + ctrl |= SDHCI_CTRL_EXEC_TUNING;
> > sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> >
> > - return 0;
> > + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
> > + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
> > +}
> > +
> > +static void sdhci_end_tuning(struct sdhci_host *host)
> > +{
> > + /* Enable only interrupts served by the SD controller */
> > + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
> > + SDHCI_INT_ENABLE);
> > + /* Mask all sdhci interrupt sources */
> > + sdhci_writel(host, 0x0, SDHCI_SIGNAL_ENABLE);
> > +}
> > +
> > +static int sdhci_iproc_execute_tuning(struct mmc *mmc, u8 opcode)
> > +{
> > +#define MAX_TUNING_LOOP 40
>
> Move to top.
Thank you, will fix it.
>
> > + struct mmc_cmd cmd;
> > + u32 ctrl;
> > + u32 blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64);
> > + struct sdhci_host *host = dev_get_priv(mmc->dev);
> > + char tuning_loop_counter = MAX_TUNING_LOOP;
> > + int ret = 0;
> > +
> > + sdhci_start_tuning(host);
> > +
> > + cmd.cmdidx = opcode;
> > + cmd.resp_type = MMC_RSP_R1;
> > + cmd.cmdarg = 0;
> > +
> > + if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && mmc->bus_width == 8)
>
> According to spec, HS200 can be used with 4/8 bit buswidth.
Iproc SDHCI controller supports HS200 in 8bit mode only.
>
>
> > + blocksize = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128);
> > +
> > + sdhci_writew(host, blocksize, SDHCI_BLOCK_SIZE);
> > + sdhci_writew(host, 1, SDHCI_BLOCK_COUNT);
> > + sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
> > +
> > + do {
> > + mmc_send_cmd(mmc, , NULL);
> > + if (opcode == MMC_CMD_SEND_TUNING_BLOCK)
> > + udelay(1);
>
> Add the comment to add udelay(1).
Sure, thank you.
>
> > +
> > + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> > +
> > + if (tuning_loop_counter-- == 0)
> > + break;
> > +
> > + } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
> > +
> > + if (tuning_loop_counter < 0 || (!(ctrl & SDHCI_CTRL_TUNED_CLK))) {
> > + ctrl &= ~(SDHCI_CTRL_TUNED_CLK | SDHCI_CTRL_EXEC_TUNING);
> > + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2);
> > + printf("%s:Tuning failed, opcode = 0x%02x\n", __func__,
> > opcode);
> > + ret = -EIO;
> > + }
> > +
> > + udelay(1);
>
> Doesn't need to add udelay(1) at here?
okay, will remove it.
>
> Best Regards,
> Jaehoon Chung
>
> > +
> > + sdhci_end_tuning(host);
> > +
> > + return ret;
> > }
> >
> > static struct sdhci_ops sdhci_platform_ops = {
> > @@ -162,6 +233,7 @@ static struct sdhci_ops
Re: [PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
Hi Asherah,
On Wed, Feb 24, 2021 at 11:23 AM Asherah Connor wrote:
>
> Updates the QFW driver to use the driver model, splitting the driver
> into qfw_pio and qfw_mmio (for non-x86) in their own uclass.
>
> Signed-off-by: Asherah Connor
> ---
>
> Changes in v4:
> - PIO definitions are now #defines
> - qfw_*_plat structs are no longer in header files
> - Remove yield/pause in DMA wait loop
> - Change struct udevice *qfw_get_dev(void) to int qfw_get_dev(struct
> udevice **)
>
> arch/arm/Kconfig | 1 +
> arch/x86/cpu/qemu/cpu.c | 9 +-
> arch/x86/cpu/qemu/qemu.c | 47 +---
> arch/x86/cpu/qfw_cpu.c | 11 +-
> cmd/qfw.c| 52 -
> common/Makefile | 2 +
> common/qfw.c | 105 +
> drivers/misc/Makefile| 6 +-
> drivers/misc/qfw.c | 238 ++-
> drivers/misc/qfw_mmio.c | 119
> drivers/misc/qfw_pio.c | 69
> include/dm/uclass-id.h | 1 +
> include/qfw.h| 61 ++
> 13 files changed, 466 insertions(+), 255 deletions(-)
> create mode 100644 common/qfw.c
> create mode 100644 drivers/misc/qfw_mmio.c
> create mode 100644 drivers/misc/qfw_pio.c
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d51abbeaf0..cd01dc458a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -937,6 +937,7 @@ config ARCH_QEMU
> imply DM_RNG
> imply DM_RTC
> imply RTC_PL031
> + imply CMD_QFW
>
> config ARCH_RMOBILE
> bool "Renesas ARM SoCs"
> diff --git a/arch/x86/cpu/qemu/cpu.c b/arch/x86/cpu/qemu/cpu.c
> index 9ce86b379c..c78e374644 100644
> --- a/arch/x86/cpu/qemu/cpu.c
> +++ b/arch/x86/cpu/qemu/cpu.c
> @@ -22,7 +22,14 @@ int cpu_qemu_get_desc(const struct udevice *dev, char
> *buf, int size)
>
> static int cpu_qemu_get_count(const struct udevice *dev)
> {
> - return qemu_fwcfg_online_cpus();
> + int ret;
> + struct udevice *qfw_dev;
> +
> + ret = qfw_get_dev(_dev);
> + if (ret)
> + return ret;
> +
> + return qemu_fwcfg_online_cpus(qfw_dev);
> }
>
> static const struct cpu_ops cpu_qemu_ops = {
> diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
> index 044a429c13..605f51e1b8 100644
> --- a/arch/x86/cpu/qemu/qemu.c
> +++ b/arch/x86/cpu/qemu/qemu.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -18,46 +19,10 @@ static bool i440fx;
>
> #ifdef CONFIG_QFW
>
> -/* on x86, the qfw registers are all IO ports */
> -#define FW_CONTROL_PORT0x510
> -#define FW_DATA_PORT 0x511
> -#define FW_DMA_PORT_LOW0x514
> -#define FW_DMA_PORT_HIGH 0x518
> -
> -static void qemu_x86_fwcfg_read_entry_pio(uint16_t entry,
> - uint32_t size, void *address)
> -{
> - uint32_t i = 0;
> - uint8_t *data = address;
> -
> - /*
> -* writting FW_CFG_INVALID will cause read operation to resume at
> -* last offset, otherwise read will start at offset 0
> -*
> -* Note: on platform where the control register is IO port, the
> -* endianness is little endian.
> -*/
> - if (entry != FW_CFG_INVALID)
> - outw(cpu_to_le16(entry), FW_CONTROL_PORT);
> -
> - /* the endianness of data register is string-preserving */
> - while (size--)
> - data[i++] = inb(FW_DATA_PORT);
> -}
> -
> -static void qemu_x86_fwcfg_read_entry_dma(struct fw_cfg_dma_access *dma)
> -{
> - /* the DMA address register is big endian */
> - outl(cpu_to_be32((uintptr_t)dma), FW_DMA_PORT_HIGH);
> -
> - while (be32_to_cpu(dma->control) & ~FW_CFG_DMA_ERROR)
> - __asm__ __volatile__ ("pause");
> -}
> -
> -static struct fw_cfg_arch_ops fwcfg_x86_ops = {
> - .arch_read_pio = qemu_x86_fwcfg_read_entry_pio,
> - .arch_read_dma = qemu_x86_fwcfg_read_entry_dma
> +U_BOOT_DRVINFO(x86_qfw_pio) = {
> + .name = "qfw_pio",
> };
> +
> #endif
>
> static void enable_pm_piix(void)
> @@ -132,10 +97,6 @@ static void qemu_chipset_init(void)
>
> enable_pm_ich9();
> }
> -
> -#ifdef CONFIG_QFW
> - qemu_fwcfg_init(_x86_ops);
> -#endif
> }
>
> #if !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
> diff --git a/arch/x86/cpu/qfw_cpu.c b/arch/x86/cpu/qfw_cpu.c
> index b959eaddde..9700908064 100644
> --- a/arch/x86/cpu/qfw_cpu.c
> +++ b/arch/x86/cpu/qfw_cpu.c
> @@ -18,7 +18,7 @@ int qemu_cpu_fixup(void)
> int cpu_num;
> int cpu_online;
> struct uclass *uc;
> - struct udevice *dev, *pdev;
> + struct udevice *dev, *pdev, *qfwdev;
> struct cpu_plat *plat;
> char *cpu;
>
> @@ -39,6 +39,13 @@ int qemu_cpu_fixup(void)
> return -ENODEV;
> }
>
> + /* get qfw dev */
> + ret = qfw_get_dev();
> + if (ret) {
> + printf("unable to find qfw
Re: [PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
Hi Bin, On 21/02/26 10:02:p, Bin Meng wrote: > On Fri, Feb 26, 2021 at 10:14 AM Bin Meng wrote: > > This patch mixed two things together. The adding ARM support should > > not belong to this patch. > > So we need to split the patch like this: > > 1. Convert the existing QFW driver of x86 to QFW uclass driver > 2. Add a new QFW mmio driver > 3. Enable the driver on QEMU ARM Thanks for taking a look! I'll redo the series accordingly. Best, Asherah
Re: [PATCH v4 5/5] qemu: add documentation to qfw.h
On 21/02/25 09:02:p, Heinrich Schuchardt wrote: > > -void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void > > *address); > > +/** > > + * Read a QEMU firmware config entry > > This will not generate documentation for qfw_read_entry() with Sphinx. > > See > https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation Thank you! I am now testing documentation produced using scripts/kernel-doc -man include/qfw.h | man --local-file - If there's a better way, please let me know. > > + * @return 0 on success, -ENOMEM if unable to allocate. > > This is not valid Sphinx syntax. [...] > function name missing. [...] > invalid syntax. [...] > Please, describe each function individually in Sphinx style. I'll correct these in the next version. Thank you! Best, Asherah
Re: [PATCH v4 5/5] qemu: add documentation to qfw.h
On 21/02/25 02:02:p, Simon Glass wrote: > On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > > > Also rename a "length" to "size" for consistency with the rest of qfw. > > Here also you add comments so should mention that. I thought that may be considered redundant with the subject; will add to both. Best, Asherah
Re: [PATCH] cmd: gpt: Add option to write GPT partitions to environment variable
Hi Heinrich,
Thank you for your comments. I will add your recommendations and resubmit,
I just want to clarify the use case here:
-Right now we have commands to read the GPT table into an internal data
structure, and from then on we can only rename or swap partitions
-If a user wants to modify all aspects of the partition layout, they
currently dont have any way to do so from the uboot command line
-With this proposed change, users would be able to export the entire
partition table to a uboot environment variable and then edit all of it
enmasse
Regards, Farhan
On Thu, Feb 25, 2021 at 12:03 PM Heinrich Schuchardt
wrote:
> On 2/25/21 7:56 PM, Farhan Ali wrote:
> > This change would enhance the existing 'gpt read' command to allow
> > (optionally) writing of the read GPT partitions to an environment
> > variable. This would allow users to easily change the partition
> > settings and then simply reuse the variable in the 'gpt write' and
> > 'gpt verify' commands.
> >
> > Signed-off-by: Farhan Ali
>
> Hello Farhan,
>
> It is unclear what your use case is.
>
> 'gpt read' already reads the data into a data structure for
> manipulation. See doc/README.gpt.
>
> Please, provide an example showing how you will use the variable.
>
> > ---
> > Cc: Simon Glass
> > Cc: Heinrich Schuchardt
> > Cc: Corneliu Doban
> > Cc: Rayagonda Kokatanur
> >
> > cmd/gpt.c | 46 ++
> > 1 file changed, 38 insertions(+), 8 deletions(-)
> >
> > diff --git a/cmd/gpt.c b/cmd/gpt.c
> > index 76a95ad..12d0551 100644
> > --- a/cmd/gpt.c
> > +++ b/cmd/gpt.c
> > @@ -350,17 +350,46 @@ static int get_gpt_info(struct blk_desc *dev_desc)
> > }
> >
> > /* a wrapper to test get_gpt_info */
> > -static int do_get_gpt_info(struct blk_desc *dev_desc)
> > +static int do_get_gpt_info(struct blk_desc *dev_desc, char * const
> namestr)
> > {
> > - int ret;
> > + int numparts;
> > +
> > + numparts = get_gpt_info(dev_desc);
> > +
> > + if (numparts > 0) {
> > + if (namestr) {
>
> If the parameter is missing, the caller passes random bytes and not
> NULL. So this check does not work.
>
> > + char disk_guid[UUID_STR_LEN + 1];
> > + char *partitions_list;
> > + int partlistlen;
> > + int ret = -1;
> > +
> > + ret = get_disk_guid(dev_desc, disk_guid);
> > + if (ret < 0)
> > + return ret;
> > +
> > + partlistlen = calc_parts_list_len(numparts);
> > + partitions_list = malloc(partlistlen);
> > + if (!partitions_list) {
> > + del_gpt_info();
> > + return -ENOMEM;
> > + }
> > + memset(partitions_list, '\0', partlistlen);
> > +
> > + ret = create_gpt_partitions_list(numparts,
> disk_guid,
> > + partitions_list);
> > + if (ret < 0)
> > + printf("Error: Could not create partition
> list string!\n");
> > + else
> > + env_set(namestr, partitions_list);
> >
> > - ret = get_gpt_info(dev_desc);
> > - if (ret > 0) {
> > - print_gpt_info();
> > + free(partitions_list);
> > + } else {
> > + print_gpt_info();
> > + }
> > del_gpt_info();
> > return 0;
> > }
> > - return ret;
> > + return numparts;
> > }
> > #endif
> >
> > @@ -982,7 +1011,7 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag,
> int argc, char *const argv[])
> > ret = do_disk_guid(blk_dev_desc, argv[4]);
> > #ifdef CONFIG_CMD_GPT_RENAME
> > } else if (strcmp(argv[1], "read") == 0) {
> > - ret = do_get_gpt_info(blk_dev_desc);
> > + ret = do_get_gpt_info(blk_dev_desc, argv[4]);
>
> You have to check argc to know if argv[4] exists and pass argv[4] or
> NULL accordingly.
>
> > } else if ((strcmp(argv[1], "swap") == 0) ||
> > (strcmp(argv[1], "rename") == 0)) {
> > ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4],
> argv[5]);
> > @@ -1028,8 +1057,9 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
> > " gpt guid mmc 0 varname\n"
> > #ifdef CONFIG_CMD_GPT_RENAME
> > "gpt partition renaming commands:\n"
> > - " gpt read \n"
> > + " gpt read []\n"
> > "- read GPT into a data structure for manipulation\n"
> > + "- read GPT partitions into environment variable\n"
>
> Where is your update for doc/README.gpt?
>
> Best regards
>
> Heinrich
>
> > " gpt swap\n"
> > "- change all partitions named name1 to name2\n"
> > " and vice-versa\n"
> >
>
>
smime.p7s
Description: S/MIME
Re: [PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
Hi Asherah, On Fri, Feb 26, 2021 at 10:14 AM Bin Meng wrote: > > Hi Asherah, > > On Wed, Feb 24, 2021 at 11:23 AM Asherah Connor wrote: > > > > Updates the QFW driver to use the driver model, splitting the driver > > into qfw_pio and qfw_mmio (for non-x86) in their own uclass. > > > > Signed-off-by: Asherah Connor > > --- > > > > Changes in v4: > > - PIO definitions are now #defines > > - qfw_*_plat structs are no longer in header files > > - Remove yield/pause in DMA wait loop > > - Change struct udevice *qfw_get_dev(void) to int qfw_get_dev(struct > > udevice **) > > > > arch/arm/Kconfig | 1 + > > arch/x86/cpu/qemu/cpu.c | 9 +- > > arch/x86/cpu/qemu/qemu.c | 47 +--- > > arch/x86/cpu/qfw_cpu.c | 11 +- > > cmd/qfw.c| 52 - > > common/Makefile | 2 + > > common/qfw.c | 105 + > > drivers/misc/Makefile| 6 +- > > drivers/misc/qfw.c | 238 ++- > > drivers/misc/qfw_mmio.c | 119 > > drivers/misc/qfw_pio.c | 69 > > include/dm/uclass-id.h | 1 + > > include/qfw.h| 61 ++ > > 13 files changed, 466 insertions(+), 255 deletions(-) > > create mode 100644 common/qfw.c > > create mode 100644 drivers/misc/qfw_mmio.c > > create mode 100644 drivers/misc/qfw_pio.c > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index d51abbeaf0..cd01dc458a 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -937,6 +937,7 @@ config ARCH_QEMU > > imply DM_RNG > > imply DM_RTC > > imply RTC_PL031 > > + imply CMD_QFW > > This patch mixed two things together. The adding ARM support should > not belong to this patch. So we need to split the patch like this: 1. Convert the existing QFW driver of x86 to QFW uclass driver 2. Add a new QFW mmio driver 3. Enable the driver on QEMU ARM Regards, Bin
Re: [PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
Hi Asherah, On Wed, Feb 24, 2021 at 11:23 AM Asherah Connor wrote: > > Updates the QFW driver to use the driver model, splitting the driver > into qfw_pio and qfw_mmio (for non-x86) in their own uclass. > > Signed-off-by: Asherah Connor > --- > > Changes in v4: > - PIO definitions are now #defines > - qfw_*_plat structs are no longer in header files > - Remove yield/pause in DMA wait loop > - Change struct udevice *qfw_get_dev(void) to int qfw_get_dev(struct > udevice **) > > arch/arm/Kconfig | 1 + > arch/x86/cpu/qemu/cpu.c | 9 +- > arch/x86/cpu/qemu/qemu.c | 47 +--- > arch/x86/cpu/qfw_cpu.c | 11 +- > cmd/qfw.c| 52 - > common/Makefile | 2 + > common/qfw.c | 105 + > drivers/misc/Makefile| 6 +- > drivers/misc/qfw.c | 238 ++- > drivers/misc/qfw_mmio.c | 119 > drivers/misc/qfw_pio.c | 69 > include/dm/uclass-id.h | 1 + > include/qfw.h| 61 ++ > 13 files changed, 466 insertions(+), 255 deletions(-) > create mode 100644 common/qfw.c > create mode 100644 drivers/misc/qfw_mmio.c > create mode 100644 drivers/misc/qfw_pio.c > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index d51abbeaf0..cd01dc458a 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -937,6 +937,7 @@ config ARCH_QEMU > imply DM_RNG > imply DM_RTC > imply RTC_PL031 > + imply CMD_QFW This patch mixed two things together. The adding ARM support should not belong to this patch. > > config ARCH_RMOBILE > bool "Renesas ARM SoCs" > diff --git a/arch/x86/cpu/qemu/cpu.c b/arch/x86/cpu/qemu/cpu.c > index 9ce86b379c..c78e374644 100644 Regards, Bin
Re: [PATCH V2] spi: imx: Implement set_speed
On 2/4/21 1:23 AM, Bin Meng wrote: On Thu, Feb 4, 2021 at 12:54 AM Marek Vasut wrote: The set_speed() callback should configure the bus speed, make it so. Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Stefano Babic --- V2: Rename dev_get_platdata() to dev_get_plat() --- drivers/spi/mxc_spi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Bin Meng Jagan, any news on this patch ?
Re: [PATCH] spi: imx: Implement set_speed
On 2/26/21 2:28 AM, Bin Meng wrote: Hi Marek, Hello Bin, On Fri, Feb 26, 2021 at 8:14 AM Marek Vasut wrote: On 2/26/21 12:41 AM, Bin Meng wrote: Hi Marek, Hello Bin, On Fri, Feb 26, 2021 at 4:52 AM Marek Vasut wrote: The set_speed() callback should configure the bus speed, make it so. This patch is not flagged as v3 since previously there were 2 versions already on the ML. Did you mistakenly send this? No, I sent it yet again because I still do not see this patch upstream. Okay, but you ended up sending a wrong version :) Okay :) Better to tag the patch as [RESEND] to avoid misunderstanding. Thank you for your feedback.
[GIT PULL] u-boot-riscv/master
Hi Tom, Please pull some RISC-V updates. CI result: https://gitlab.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/6505 The following changes since commit cbe607b920bc0827d8fe379ed4f5ae4e2058513e: Merge tag 'xilinx-for-v2021.04-rc3' of https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze (2021-02-23 10:45:55 -0500) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git for you to fetch changes up to 5540294fa48598bf1aa8aa4d9084506a19bbd64c: riscv: k210: Enable QSPI for spi3 (2021-02-25 18:06:08 +0800) Heinrich Schuchardt (1): cmd/riscv/sbi: support System Reset Extension Sean Anderson (1): riscv: k210: Enable QSPI for spi3 arch/riscv/dts/k210-maix-bit.dts | 2 ++ cmd/riscv/sbi.c | 1 + 2 files changed, 3 insertions(+) Best regards, Leo
Re: [PATCH] spi: imx: Implement set_speed
Hi Marek, On Fri, Feb 26, 2021 at 8:14 AM Marek Vasut wrote: > > On 2/26/21 12:41 AM, Bin Meng wrote: > > Hi Marek, > > Hello Bin, > > > On Fri, Feb 26, 2021 at 4:52 AM Marek Vasut wrote: > >> > >> The set_speed() callback should configure the bus speed, make it so. > >> > > > > This patch is not flagged as v3 since previously there were 2 versions > > already on the ML. Did you mistakenly send this? > > No, I sent it yet again because I still do not see this patch upstream. > Okay, but you ended up sending a wrong version :) Better to tag the patch as [RESEND] to avoid misunderstanding. > [...] Regards, Bin
Re: [PATCH] spi: imx: Implement set_speed
On 2/26/21 12:41 AM, Bin Meng wrote: Hi Marek, Hello Bin, On Fri, Feb 26, 2021 at 4:52 AM Marek Vasut wrote: The set_speed() callback should configure the bus speed, make it so. This patch is not flagged as v3 since previously there were 2 versions already on the ML. Did you mistakenly send this? No, I sent it yet again because I still do not see this patch upstream. [...]
Re: [PATCH] spi: imx: Implement set_speed
Hi Marek,
On Fri, Feb 26, 2021 at 4:52 AM Marek Vasut wrote:
>
> The set_speed() callback should configure the bus speed, make it so.
>
This patch is not flagged as v3 since previously there were 2 versions
already on the ML. Did you mistakenly send this?
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Stefano Babic
> ---
> drivers/spi/mxc_spi.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
> index bb68eb90e91..bce5356b294 100644
> --- a/drivers/spi/mxc_spi.c
> +++ b/drivers/spi/mxc_spi.c
> @@ -662,7 +662,10 @@ static int mxc_spi_release_bus(struct udevice *dev)
>
> static int mxc_spi_set_speed(struct udevice *bus, uint speed)
> {
> - /* Nothing to do */
> + struct mxc_spi_slave *mxcs = dev_get_platdata(bus);
This patch is the same as the previous v1 patch here:
https://lists.denx.de/pipermail/u-boot/2021-February/439840.html
And you already sent a v2 that was reviewed.
https://lists.denx.de/pipermail/u-boot/2021-February/439863.html
> +
> + mxcs->max_hz = speed;
> +
> return 0;
> }
Regards,
Bin
Re: [PATCH][RESEND] ARM: imx: Add missing FEC ethernet quirk for MX8M
On 2/26/21 12:29 AM, Fabio Estevam wrote: On Thu, Feb 25, 2021 at 8:21 PM Marek Vasut wrote: There is similar fix for the other IMX8Q/X by Oleksandr too. It should be applied as well. Yes, I reviewed that one too. I think Stefano will apply it for the upcoming 2021.04 release. Yes
Re: [PATCH][RESEND] ARM: imx: Add missing FEC ethernet quirk for MX8M
On Thu, Feb 25, 2021 at 8:21 PM Marek Vasut wrote: > There is similar fix for the other IMX8Q/X by Oleksandr too. It should > be applied as well. Yes, I reviewed that one too. I think Stefano will apply it for the upcoming 2021.04 release. Thanks
Re: [PATCH] rk3399: Add basic support for helios64
Thanks for submitting, I have been meaning to do so myself, I have
been meaning to go through and try get the dts files in a decent
shape. I think that most of what is in
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi belongs in
arch/arm/dts/rk3399-kobol-helios64.dts I also wonder if we shouldn't
default to building an image for use in the SPI flash since the system
has it available.
Dennis
On Thu, Feb 25, 2021 at 3:14 PM Uwe Kleine-König wrote:
>
> This is a stripped down version of the vendor U-Boot patch by Aditya
> Prayoga found in the armbian repository. This patch is enough to have
> the 1G ethernet port, the micro SD card, eMMC and UART operational and
> let it boot a Debian netboot installer.
>
> The device tree is contained in Linux v5.11-rc1. During my work on
> U-Boot I noticed a wrong pull setting, the corresponding patch is still
> in linux-next and already applied in the copy that is added by this
> patch.
>
> Signed-off-by: Uwe Kleine-König
> ---
> Hello,
>
> @Aditya: I kept you as maintainer in MAINTAINERS, is this ok for you?
> I doubt that I'm qualified enough for that.
>
> So please wait for this question to be resolved before you apply this
> patch.
>
> Best regards
> Uwe
>
> arch/arm/dts/Makefile | 1 +
> .../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 266 +
> arch/arm/dts/rk3399-kobol-helios64.dts| 372 ++
> arch/arm/mach-rockchip/rk3399/Kconfig | 17 +
> board/kobol/helios64/Kconfig | 24 ++
> board/kobol/helios64/MAINTAINERS | 6 +
> board/kobol/helios64/Makefile | 5 +
> board/kobol/helios64/helios64.c | 262
> board/kobol/helios64/sys_otp.c| 248
> board/kobol/helios64/sys_otp.h| 10 +
> configs/helios64-rk3399_defconfig | 142 +++
> include/configs/helios64.h| 47 +++
> 12 files changed, 1400 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
> create mode 100644 board/kobol/helios64/Kconfig
> create mode 100644 board/kobol/helios64/MAINTAINERS
> create mode 100644 board/kobol/helios64/Makefile
> create mode 100644 board/kobol/helios64/helios64.c
> create mode 100644 board/kobol/helios64/sys_otp.c
> create mode 100644 board/kobol/helios64/sys_otp.h
> create mode 100644 configs/helios64-rk3399_defconfig
> create mode 100644 include/configs/helios64.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index fd47e408f826..752ba4fd8b35 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -125,6 +125,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-kobol-helios64.dtb \
> rk3399-khadas-edge.dtb \
> rk3399-khadas-edge-captain.dtb \
> rk3399-khadas-edge-v.dtb \
> diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> new file mode 100644
> index ..84a27548a08d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
> @@ -0,0 +1,266 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2020 Aditya Prayoga (adi...@kobol.io)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> + aliases {
> + spi0 =
> + ethernet0 =
> + };
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xff1a earlyprintk";
> + stdout-path = "serial2:150n8";
> + u-boot,spl-boot-order = "same-as-spl", , ,
>
> + };
> +
> + config {
> + u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
> + };
> +
> + leds {
> + led-1 {
> + linux,default-trigger = "panic";
> + };
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + startup-delay-us = <2>;
> + };
> +};
> +
> +_alert0 {
> + temperature = <8>;
> +};
> +
> +_alert1 {
> + temperature = <95000>;
> +};
> +
> +_crit {
> + temperature = <10>;
> +};
> +
> + {
> + rk808: pmic@1b {
> + rockchip,system-power-controller;
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-name = "vdd_center";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <95>;
> + regulator-max-microvolt = <95>;
> + regulator-init-microvolt = <95>;
> + regulator-ramp-delay = <6001>;
> +
Re: [PATCH][RESEND] ARM: imx: Add missing FEC ethernet quirk for MX8M
On 2/25/21 10:22 PM, Fabio Estevam wrote: Hi Marek, On Thu, Feb 25, 2021 at 6:02 PM Marek Vasut wrote: The MX8M also contains a gigabit MAC, so define FEC_QUIRK_ENET_MAC. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic Thanks for the fix: Reviewed-by: Fabio Estevam Sure, thanks for the RB. There is similar fix for the other IMX8Q/X by Oleksandr too. It should be applied as well.
Re: [PATCH][RESEND] ARM: imx: Add missing FEC ethernet quirk for MX8M
Hi Marek, On Thu, Feb 25, 2021 at 6:02 PM Marek Vasut wrote: > > The MX8M also contains a gigabit MAC, so define FEC_QUIRK_ENET_MAC. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Peng Fan > Cc: Stefano Babic Thanks for the fix: Reviewed-by: Fabio Estevam
[PATCH] rk3399: Add basic support for helios64
This is a stripped down version of the vendor U-Boot patch by Aditya
Prayoga found in the armbian repository. This patch is enough to have
the 1G ethernet port, the micro SD card, eMMC and UART operational and
let it boot a Debian netboot installer.
The device tree is contained in Linux v5.11-rc1. During my work on
U-Boot I noticed a wrong pull setting, the corresponding patch is still
in linux-next and already applied in the copy that is added by this
patch.
Signed-off-by: Uwe Kleine-König
---
Hello,
@Aditya: I kept you as maintainer in MAINTAINERS, is this ok for you?
I doubt that I'm qualified enough for that.
So please wait for this question to be resolved before you apply this
patch.
Best regards
Uwe
arch/arm/dts/Makefile | 1 +
.../arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 266 +
arch/arm/dts/rk3399-kobol-helios64.dts| 372 ++
arch/arm/mach-rockchip/rk3399/Kconfig | 17 +
board/kobol/helios64/Kconfig | 24 ++
board/kobol/helios64/MAINTAINERS | 6 +
board/kobol/helios64/Makefile | 5 +
board/kobol/helios64/helios64.c | 262
board/kobol/helios64/sys_otp.c| 248
board/kobol/helios64/sys_otp.h| 10 +
configs/helios64-rk3399_defconfig | 142 +++
include/configs/helios64.h| 47 +++
12 files changed, 1400 insertions(+)
create mode 100644 arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-kobol-helios64.dts
create mode 100644 board/kobol/helios64/Kconfig
create mode 100644 board/kobol/helios64/MAINTAINERS
create mode 100644 board/kobol/helios64/Makefile
create mode 100644 board/kobol/helios64/helios64.c
create mode 100644 board/kobol/helios64/sys_otp.c
create mode 100644 board/kobol/helios64/sys_otp.h
create mode 100644 configs/helios64-rk3399_defconfig
create mode 100644 include/configs/helios64.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fd47e408f826..752ba4fd8b35 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -125,6 +125,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+ rk3399-kobol-helios64.dtb \
rk3399-khadas-edge.dtb \
rk3399-khadas-edge-captain.dtb \
rk3399-khadas-edge-v.dtb \
diff --git a/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
new file mode 100644
index ..84a27548a08d
--- /dev/null
+++ b/arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Aditya Prayoga (adi...@kobol.io)
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+
+/ {
+ aliases {
+ spi0 =
+ ethernet0 =
+ };
+
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0xff1a earlyprintk";
+ stdout-path = "serial2:150n8";
+ u-boot,spl-boot-order = "same-as-spl", , ,
+ };
+
+ config {
+ u-boot,spl-payload-offset = <0x8>; /* @ 512KB */
+ };
+
+ leds {
+ led-1 {
+ linux,default-trigger = "panic";
+ };
+ };
+
+ vcc3v0_sd: vcc3v0-sd {
+ startup-delay-us = <2>;
+ };
+};
+
+_alert0 {
+ temperature = <8>;
+};
+
+_alert1 {
+ temperature = <95000>;
+};
+
+_crit {
+ temperature = <10>;
+};
+
+ {
+ rk808: pmic@1b {
+ rockchip,system-power-controller;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <95>;
+ regulator-max-microvolt = <95>;
+ regulator-init-microvolt = <95>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <95>;
+ };
+ };
+
+ vcc_ddr_s3: DCDC_REG3 {
+ regulator-name = "vcc_ddr_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ /* not used */
+ vcc1v8_dvp: LDO_REG1 {
+
[PATCH][RESEND] ARM: imx: Add missing FEC ethernet quirk for MX8M
The MX8M also contains a gigabit MAC, so define FEC_QUIRK_ENET_MAC. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Peng Fan Cc: Stefano Babic --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index f5711155b70..3f500146185 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -63,6 +63,7 @@ #define DDR_CSD1_BASE_ADDR 0x4000 #define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK 0x7 +#define FEC_QUIRK_ENET_MAC #if !defined(__ASSEMBLY__) #include -- 2.30.0
Re: [PATCH] ARM: imx: Add missing FEC ethernet quirk for MX8M
On 1/17/21 12:16 AM, Marek Vasut wrote: The MX8M also contains a gigabit MAC, so define FEC_QUIRK_ENET_MAC. This patch has been marked as "Changes requested" in patchwork and thus discarded, so FEC remains broken on MX8M. Zero feedback was given, so what changes are requested ?
Re: [PATCH 2/4] pinephone_defconfig: reduce boot delay
On Thu, Feb 25, 2021 at 05:02:40PM +, André Przywara wrote: > On 20/02/2021 12:14, Nicolas Boulenguez wrote: > > From: Arnaud Ferraris > > > > On a cellular phone, the vast majority of users can be expected to > > have no serial console connected and prefer a short boot. > > It's a bit tricky to break in with a delay of 0, but indeed most users > won't care, so looks fine to me. > > But it's missing a Signed-off-by: line. I'm not sure we should start accepting custom boards changes like it's done here, this will only lead to inconsistencies between boards in the long run. And a defconfig is really easy to change anyway, even when it's integrated in build systems Maxime signature.asc Description: PGP signature
[PATCH] ARM: imx: Add OCRAM_S into iMX8M MMU tables
The OCRAM_S is regular memory, just like the OCRAM, add it to the MMU
tables so it can be used and cached.
Signed-off-by: Marek Vasut
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
---
arch/arm/mach-imx/imx8m/soc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 5456c10fb17..225e4e12500 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -104,6 +104,13 @@ static struct mm_region imx8m_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* OCRAM_S */
+ .virt = 0x18UL,
+ .phys = 0x18UL,
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_OUTER_SHARE
}, {
/* TCM */
.virt = 0x7CUL,
--
2.30.0
[PATCH] spi: Update speed/mode on change
The spi_get_bus_and_cs() may be called on the same bus and chipselect
with different frequency or mode. This is valid usecase, but the code
fails to notify the controller of such a configuration change. Call
spi_set_speed_mode() in case bus frequency or bus mode changed to let
the controller update the configuration.
The problem can easily be triggered using the sspi command:
=> sspi 0:0@1000
=> sspi 0:0@2000
Without this patch, both transfers happen at 1000 Hz. With this patch,
the later transfer happens correctly at 2000 Hz.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Patrick Delaunay
---
drivers/spi/spi-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 7155d4aebd6..96c9a83e761 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -405,12 +405,22 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
mode,
goto err;
}
+ /* In case bus frequency or mode changed, update it. */
+ if ((speed && slave->speed && slave->speed != speed) ||
+ (plat->mode != mode)) {
+ ret = spi_set_speed_mode(bus, speed, mode);
+ if (ret)
+ goto err_speed_mode;
+ }
+
*busp = bus;
*devp = slave;
log_debug("%s: bus=%p, slave=%p\n", __func__, bus, *devp);
return 0;
+err_speed_mode:
+ spi_claim_bus(slave);
err:
log_debug("%s: Error path, created=%d, device '%s'\n", __func__,
created, dev->name);
--
2.30.0
[PATCH] spi: imx: Implement set_speed
The set_speed() callback should configure the bus speed, make it so.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Stefano Babic
---
drivers/spi/mxc_spi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index bb68eb90e91..bce5356b294 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -662,7 +662,10 @@ static int mxc_spi_release_bus(struct udevice *dev)
static int mxc_spi_set_speed(struct udevice *bus, uint speed)
{
- /* Nothing to do */
+ struct mxc_spi_slave *mxcs = dev_get_platdata(bus);
+
+ mxcs->max_hz = speed;
+
return 0;
}
--
2.30.0
[PATCH] Makefile: Fix generation of flash.bin u-boot.itb with binman
In case binman is enabled, the u-boot.itb is generated using this tool and there is no direct u-boot.itb target, but instead the binman tool must be invoked. Add support for this case. Signed-off-by: Marek Vasut Cc: Peng Fan Cc: Stefano Babic --- Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Makefile b/Makefile index 079881b62ab..a0456dd5859 100644 --- a/Makefile +++ b/Makefile @@ -1542,10 +1542,16 @@ u-boot.cnt: u-boot.bin FORCE flash.bin: spl/u-boot-spl.bin u-boot.cnt FORCE $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ else +ifeq ($(CONFIG_BINMAN),y) +flash.bin: spl/u-boot-spl.bin $(INPUTS-y) FORCE + $(call if_changed,binman) + $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ +else flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ endif endif +endif u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@ -- 2.30.0
Re: [PATCH u-boot-dm + u-boot-spi v3 10/11] mtd: compare also with OF path and device name in get_mtd_device_nm()
On Thu, Feb 25, 2021 at 09:35:13PM +0100, Marek Behun wrote: > On Thu, 25 Feb 2021 15:28:56 -0500 > Tom Rini wrote: > > > On Thu, Feb 25, 2021 at 09:07:40PM +0100, Marek Behun wrote: > > > On Thu, 25 Feb 2021 14:31:42 -0500 > > > Simon Glass wrote: > > > > > > > We should not need CONFIG_DM here...it should be enabled for all > > > > boards. You can always disable MTD for a board if not, or send a > > > > removable patch. > > > > > > > > If for some reason you do, please use if (IS_ENABLED() so that 'dev' > > > > can always be declared. > > > > > > Simon, it still isn't enabled for all boards. For example > > > tqma6s_wru4_mmc_defconfig does not compile with this. I actually wrote > > > this into commit message: > > > > > > Although CONFIG_DM is compulsory since v2020.01, there are still some > > > boards (for example tqma6s_wru4_mmc_defconfig) that don't enable it. > > > > > > But if breaking such boards is not a problem anymore, I will gladly > > > just remove the ifdefs :) Should I? > > > > So, I'm working hard at dropping boards that are well past migration > > deadlines. That specific one fails DM_MMC more importantly, and I will > > be dropping it if it's not migrated, after v2021.04 is out. What else > > fails? If you rebase your series on my > > WIP/remove-non-AHCI_LIBATA-drivers (as it has the most board removals in > > it), what fails to build if your series is just DM only? > > > > I haven't tried building all boards, just quickly found a defconfig > with disabled CONFIG_DM :) > With removing the CONFIG_DM ifdefs this series shouldn't break anything > that is already past migration deadline. Well, past migration deadline doesn't mean it can cause CI to fail. I'm just now throwing things out that are 2 years past the deadline, and we'll probably be doing that for a few releases. -- Tom signature.asc Description: PGP signature
Re: [PATCH u-boot-dm + u-boot-spi v3 10/11] mtd: compare also with OF path and device name in get_mtd_device_nm()
On Thu, 25 Feb 2021 15:28:56 -0500 Tom Rini wrote: > On Thu, Feb 25, 2021 at 09:07:40PM +0100, Marek Behun wrote: > > On Thu, 25 Feb 2021 14:31:42 -0500 > > Simon Glass wrote: > > > > > We should not need CONFIG_DM here...it should be enabled for all > > > boards. You can always disable MTD for a board if not, or send a > > > removable patch. > > > > > > If for some reason you do, please use if (IS_ENABLED() so that 'dev' > > > can always be declared. > > > > Simon, it still isn't enabled for all boards. For example > > tqma6s_wru4_mmc_defconfig does not compile with this. I actually wrote > > this into commit message: > > > > Although CONFIG_DM is compulsory since v2020.01, there are still some > > boards (for example tqma6s_wru4_mmc_defconfig) that don't enable it. > > > > But if breaking such boards is not a problem anymore, I will gladly > > just remove the ifdefs :) Should I? > > So, I'm working hard at dropping boards that are well past migration > deadlines. That specific one fails DM_MMC more importantly, and I will > be dropping it if it's not migrated, after v2021.04 is out. What else > fails? If you rebase your series on my > WIP/remove-non-AHCI_LIBATA-drivers (as it has the most board removals in > it), what fails to build if your series is just DM only? > I haven't tried building all boards, just quickly found a defconfig with disabled CONFIG_DM :) With removing the CONFIG_DM ifdefs this series shouldn't break anything that is already past migration deadline. Marek
Re: [PATCH u-boot-dm + u-boot-spi v3 10/11] mtd: compare also with OF path and device name in get_mtd_device_nm()
On Thu, Feb 25, 2021 at 09:07:40PM +0100, Marek Behun wrote: > On Thu, 25 Feb 2021 14:31:42 -0500 > Simon Glass wrote: > > > We should not need CONFIG_DM here...it should be enabled for all > > boards. You can always disable MTD for a board if not, or send a > > removable patch. > > > > If for some reason you do, please use if (IS_ENABLED() so that 'dev' > > can always be declared. > > Simon, it still isn't enabled for all boards. For example > tqma6s_wru4_mmc_defconfig does not compile with this. I actually wrote > this into commit message: > > Although CONFIG_DM is compulsory since v2020.01, there are still some > boards (for example tqma6s_wru4_mmc_defconfig) that don't enable it. > > But if breaking such boards is not a problem anymore, I will gladly > just remove the ifdefs :) Should I? So, I'm working hard at dropping boards that are well past migration deadlines. That specific one fails DM_MMC more importantly, and I will be dropping it if it's not migrated, after v2021.04 is out. What else fails? If you rebase your series on my WIP/remove-non-AHCI_LIBATA-drivers (as it has the most board removals in it), what fails to build if your series is just DM only? -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 5/5] qemu: add documentation to qfw.h
On 2/24/21 4:23 AM, Asherah Connor wrote:
Also rename a "length" to "size" for consistency with the rest of qfw.
Signed-off-by: Asherah Connor
---
(no changes since v1)
drivers/misc/qfw.c | 6 ++--
include/qfw.h | 86 +++---
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index b0c82e2098..3e8c1a9cda 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -283,14 +283,14 @@ static void qfw_read_entry_dma(struct qfw_dev *qdev, u16
entry, u32 size,
ops->read_entry_dma(qdev->dev, );
}
-void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void *address)
+void qfw_read_entry(struct udevice *dev, u16 entry, u32 size, void *address)
{
struct qfw_dev *qdev = dev_get_uclass_priv(dev);
if (qdev->dma_present)
- qfw_read_entry_dma(qdev, entry, length, address);
+ qfw_read_entry_dma(qdev, entry, size, address);
else
- qfw_read_entry_io(qdev, entry, length, address);
+ qfw_read_entry_io(qdev, entry, size, address);
}
int qfw_register(struct udevice *dev)
diff --git a/include/qfw.h b/include/qfw.h
index 41d4db08d6..d59c71a5dd 100644
--- a/include/qfw.h
+++ b/include/qfw.h
@@ -8,6 +8,11 @@
#include
+/*
+ * List of firmware configuration item selectors. The official source of truth
+ * for these is the QEMU source itself; see
+ * https://github.com/qemu/qemu/blob/master/hw/nvram/fw_cfg.c
+ */
enum {
FW_CFG_SIGNATURE= 0x00,
FW_CFG_ID = 0x01,
@@ -66,8 +71,10 @@ enum {
#define FW_CFG_DMA_SKIP (1 << 2)
#define FW_CFG_DMA_SELECT (1 << 3)
+/* Bit set in FW_CFG_ID response to indicate DMA interface availability. */
#define FW_CFG_DMA_ENABLED(1 << 1)
+/* Structs read from FW_CFG_FILE_DIR. */
struct fw_cfg_file {
__be32 size;
__be16 select;
@@ -134,27 +141,56 @@ struct bios_linker_entry {
};
} __packed;
+/* DMA transfer control data between UCLASS_QFW and QEMU. */
struct qfw_dma {
__be32 control;
__be32 length;
__be64 address;
};
+/* uclass per-device configuration information */
struct qfw_dev {
- struct udevice *dev;
- bool dma_present;
- struct list_head fw_list;
+ struct udevice *dev;/* Transport device */
+ bool dma_present; /* DMA interface usable? */
+ struct list_head fw_list; /* Cached firmware file list */
};
+/* Ops used internally between UCLASS_QFW and its driver implementations. */
struct dm_qfw_ops {
+ /**
+* read_entry_io() - Read a firmware config entry using the regular
+* IO interface for the platform (either PIO or MMIO)
+*
+* Supply FW_CFG_INVALID as the entry to continue a previous read. In
+* this case, no selector will be issued before reading.
+*
+* @dev: Device to use
+* @entry: Firmware config entry number (e.g. FW_CFG_SIGNATURE)
+* @size: Number of bytes to read
+* @address: Target location for read
+*/
void (*read_entry_io)(struct udevice *dev, u16 entry, u32 size,
void *address);
+
+ /**
+* read_entry_dma() - Read a firmware config entry using the DMA
+* interface
+*
+* Supply FW_CFG_INVALID as the entry to continue a previous read. In
+* this case, no selector will be issued before reading.
+*
+* This method assumes DMA availability has already been confirmed.
+*
+* @dev: Device to use
+* @dma: DMA transfer control struct
+*/
void (*read_entry_dma)(struct udevice *dev, struct qfw_dma *dma);
};
#define dm_qfw_get_ops(dev) \
((struct dm_qfw_ops *)(dev)->driver->ops)
+/* Used internally by driver implementations on successful probe. */
int qfw_register(struct udevice *dev);
struct udevice;
@@ -168,8 +204,37 @@ struct udevice;
*/
int qfw_get_dev(struct udevice **devp);
-void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void *address);
+/**
+ * Read a QEMU firmware config entry
This will not generate documentation for qfw_read_entry() with Sphinx.
See
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#function-documentation
+ *
+ * The appropriate transport and interface will be selected automatically.
+ *
+ * @dev: Device to use
+ * @entry: Firmware config entry number (e.g. FW_CFG_SIGNATURE)
+ * @size: Number of bytes to read
+ * @address: Target location for read
+ */
+void qfw_read_entry(struct udevice *dev, u16 entry, u32 size, void *address);
+
+/**
+ * Reads the QEMU firmware config file list, for later use with qfw_find_file.
+ *
+ * If the list has already been read, returns 0 (success).
+ *
+ * @dev: Device to use
+ *
+ * @return 0 on success, -ENOMEM if unable to allocate.
This
Re: [PATCH u-boot-dm + u-boot-spi v3 10/11] mtd: compare also with OF path and device name in get_mtd_device_nm()
On Thu, 25 Feb 2021 14:31:42 -0500 Simon Glass wrote: > We should not need CONFIG_DM here...it should be enabled for all > boards. You can always disable MTD for a board if not, or send a > removable patch. > > If for some reason you do, please use if (IS_ENABLED() so that 'dev' > can always be declared. Simon, it still isn't enabled for all boards. For example tqma6s_wru4_mmc_defconfig does not compile with this. I actually wrote this into commit message: Although CONFIG_DM is compulsory since v2020.01, there are still some boards (for example tqma6s_wru4_mmc_defconfig) that don't enable it. But if breaking such boards is not a problem anymore, I will gladly just remove the ifdefs :) Should I? Marek
Re: [PATCH] cmd: gpt: Add option to write GPT partitions to environment variable
On 2/25/21 7:56 PM, Farhan Ali wrote:
This change would enhance the existing 'gpt read' command to allow
(optionally) writing of the read GPT partitions to an environment
variable. This would allow users to easily change the partition
settings and then simply reuse the variable in the 'gpt write' and
'gpt verify' commands.
Signed-off-by: Farhan Ali
Hello Farhan,
It is unclear what your use case is.
'gpt read' already reads the data into a data structure for
manipulation. See doc/README.gpt.
Please, provide an example showing how you will use the variable.
---
Cc: Simon Glass
Cc: Heinrich Schuchardt
Cc: Corneliu Doban
Cc: Rayagonda Kokatanur
cmd/gpt.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/cmd/gpt.c b/cmd/gpt.c
index 76a95ad..12d0551 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -350,17 +350,46 @@ static int get_gpt_info(struct blk_desc *dev_desc)
}
/* a wrapper to test get_gpt_info */
-static int do_get_gpt_info(struct blk_desc *dev_desc)
+static int do_get_gpt_info(struct blk_desc *dev_desc, char * const namestr)
{
- int ret;
+ int numparts;
+
+ numparts = get_gpt_info(dev_desc);
+
+ if (numparts > 0) {
+ if (namestr) {
If the parameter is missing, the caller passes random bytes and not
NULL. So this check does not work.
+ char disk_guid[UUID_STR_LEN + 1];
+ char *partitions_list;
+ int partlistlen;
+ int ret = -1;
+
+ ret = get_disk_guid(dev_desc, disk_guid);
+ if (ret < 0)
+ return ret;
+
+ partlistlen = calc_parts_list_len(numparts);
+ partitions_list = malloc(partlistlen);
+ if (!partitions_list) {
+ del_gpt_info();
+ return -ENOMEM;
+ }
+ memset(partitions_list, '\0', partlistlen);
+
+ ret = create_gpt_partitions_list(numparts, disk_guid,
+partitions_list);
+ if (ret < 0)
+ printf("Error: Could not create partition list
string!\n");
+ else
+ env_set(namestr, partitions_list);
- ret = get_gpt_info(dev_desc);
- if (ret > 0) {
- print_gpt_info();
+ free(partitions_list);
+ } else {
+ print_gpt_info();
+ }
del_gpt_info();
return 0;
}
- return ret;
+ return numparts;
}
#endif
@@ -982,7 +1011,7 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
ret = do_disk_guid(blk_dev_desc, argv[4]);
#ifdef CONFIG_CMD_GPT_RENAME
} else if (strcmp(argv[1], "read") == 0) {
- ret = do_get_gpt_info(blk_dev_desc);
+ ret = do_get_gpt_info(blk_dev_desc, argv[4]);
You have to check argc to know if argv[4] exists and pass argv[4] or
NULL accordingly.
} else if ((strcmp(argv[1], "swap") == 0) ||
(strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4],
argv[5]);
@@ -1028,8 +1057,9 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt guid mmc 0 varname\n"
#ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
- " gpt read \n"
+ " gpt read []\n"
"- read GPT into a data structure for manipulation\n"
+ "- read GPT partitions into environment variable\n"
Where is your update for doc/README.gpt?
Best regards
Heinrich
" gpt swap\n"
"- change all partitions named name1 to name2\n"
" and vice-versa\n"
[PATCH] configs: stm32mp1: enable uefi related commands
The board can boot with UEFI. With the latest changes in U-Boot's EFI subsystem we also have support for EFI runtime variables, without SetVariable support. We can also store the EFI variables in a file on the ESP partition and preserve them across reboots. The env and efidebug commands are missing in order to configure EFI variables and the efibootmgr though. Since U-Boot's default config enables other EFI related commands (e.g bootefi), let's add the env related and efidebug commands and allow users to do that Signed-off-by: Ilias Apalodimas --- configs/stm32mp15_trusted_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/stm32mp15_trusted_defconfig b/configs/stm32mp15_trusted_defconfig index da31b74cdeb6..107041119f1d 100644 --- a/configs/stm32mp15_trusted_defconfig +++ b/configs/stm32mp15_trusted_defconfig @@ -17,6 +17,7 @@ CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" CONFIG_SYS_PROMPT="STM32MP> " CONFIG_CMD_ADTIMG=y CONFIG_CMD_ERASEENV=y +CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_MEMINFO=y CONFIG_CMD_MEMTEST=y CONFIG_CMD_ADC=y @@ -32,6 +33,7 @@ CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y +CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y CONFIG_CMD_TIMER=y CONFIG_CMD_PMIC=y @@ -144,4 +146,5 @@ CONFIG_BMP_32BPP=y CONFIG_WDT=y CONFIG_WDT_STM32MP=y CONFIG_ERRNO_STR=y +# CONFIG_HEXDUMP is not set CONFIG_FDT_FIXUP_PARTITIONS=y -- 2.30.1
Re: [PATCH] net: add MMIO Register MDIO MUX driver
On Wed, Feb 24, 2021 at 4:02 PM Neil Armstrong wrote:
>
> Add support for MMIO register MDIO muxes based on the Linux mdio-mux-mmioreg
> driver.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/net/Kconfig| 7 ++
> drivers/net/Makefile | 1 +
> drivers/net/mdio_mux_mmioreg.c | 129 +
> 3 files changed, 137 insertions(+)
> create mode 100644 drivers/net/mdio_mux_mmioreg.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 0e84c22b50..41fa2fe566 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -790,4 +790,11 @@ config FSL_LS_MDIO
> This driver supports the MDIO bus found on the Fman 10G Ethernet
> MACs and
> on the mEMAC (which supports both Clauses 22 and 45).
>
> +config MDIO_MUX_MMIOREG
> + bool "MDIO MUX accessed as a MMIO register access"
> + depends on DM_MDIO_MUX
> + help
> + This driver is used for MDIO muxes driven by writing to a register
> in
> + the MMIO physical memory.
> +
> endif # NETDEVICES
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index a19511aaa7..511c87c3a5 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_MACB) += macb.o
> obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
> obj-$(CONFIG_MDIO_IPQ4019) += mdio-ipq4019.o
> obj-$(CONFIG_MDIO_MUX_I2CREG) += mdio_mux_i2creg.o
> +obj-$(CONFIG_MDIO_MUX_MMIOREG) += mdio_mux_mmioreg.o
> obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o
> obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
> obj-$(CONFIG_MT7620_ETH) += mt7620-eth.o
> diff --git a/drivers/net/mdio_mux_mmioreg.c b/drivers/net/mdio_mux_mmioreg.c
> new file mode 100644
> index 00..e1a23e40a2
> --- /dev/null
> +++ b/drivers/net/mdio_mux_mmioreg.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2021 BayLibre, SAS
> + * Author: Neil Armstrong
> + *
> + * Based on linux/drivers/net/phy/mdio-mux-mmioreg.c :
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct mdio_mux_mmioreg_priv {
> + struct udevice *chip;
> + phys_addr_t phys;
> + unsigned int iosize;
> + unsigned int mask;
> +};
> +
> +static int mdio_mux_mmioreg_select(struct udevice *mux, int cur, int sel)
> +{
> + struct mdio_mux_mmioreg_priv *priv = dev_get_priv(mux);
> +
> + debug("%s: %x -> %x\n", __func__, (u32)cur, (u32)sel);
> +
> + /* if last selection didn't change we're good to go */
> + if (cur == sel)
> + return 0;
> +
> + switch (priv->iosize) {
> + case sizeof(u8): {
> + u8 x, y;
> +
> + x = ioread8((void *)priv->phys);
> + y = (x & ~priv->mask) | (u32)sel;
> + if (x != y) {
> + iowrite8((x & ~priv->mask) | sel, (void *)priv->phys);
> + debug("%s: %02x -> %02x\n", __func__, x, y);
> + }
> +
> + break;
> + }
> + case sizeof(u16): {
> + u16 x, y;
> +
> + x = ioread16((void *)priv->phys);
> + y = (x & ~priv->mask) | (u32)sel;
> + if (x != y) {
> + iowrite16((x & ~priv->mask) | sel, (void
> *)priv->phys);
> + debug("%s: %04x -> %04x\n", __func__, x, y);
> + }
> +
> + break;
> + }
> + case sizeof(u32): {
> + u32 x, y;
> +
> + x = ioread32((void *)priv->phys);
> + y = (x & ~priv->mask) | (u32)sel;
> + if (x != y) {
> + iowrite32((x & ~priv->mask) | sel, (void
> *)priv->phys);
> + debug("%s: %08x -> %08x\n", __func__, x, y);
> + }
> +
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static const struct mdio_mux_ops mdio_mux_mmioreg_ops = {
> + .select = mdio_mux_mmioreg_select,
> +};
> +
> +static int mdio_mux_mmioreg_probe(struct udevice *dev)
> +{
> + struct mdio_mux_mmioreg_priv *priv = dev_get_priv(dev);
> + phys_addr_t reg_base, reg_size;
> + u32 reg_mask;
> + int err;
> +
> + reg_base = ofnode_get_addr_size_index(dev_ofnode(dev), 0, _size);
> + if (reg_base == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + if (reg_size != sizeof(u8) &&
> + reg_size != sizeof(u16) &&
> + reg_size != sizeof(u32)) {
> + printf("%s: only 8/16/32-bit registers are supported\n",
> __func__);
> + return -EINVAL;
> + }
> +
> + err = dev_read_u32(dev, "mux-mask", _mask);
> + if (err) {
> + debug("%s: error reading mux-mask property\n", __func__);
> + return err;
> + }
> +
> + if (reg_mask >= BIT(reg_size * 8)) {
> + printf("%s:
Re: [PATCH v1] net: eth-uclass: Change uclass driver name to ethernet
On Thu, Feb 25, 2021 at 9:33 PM Simon Glass wrote:
>
> On Thu, 25 Feb 2021 at 10:55, Fabio Estevam wrote:
> >
> > On Thu, Feb 25, 2021 at 4:58 AM Michael Walle wrote:
> >
> > > This is how it looks in the linux tree:
> > >
> > > $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > > 633
> >
> > Yes, 'ethernet' is the recommended node name as per the Devicetree
> > Specification doc item "2.2.2 Generic Names Recommendation".
>
> OK.
>
>
> - Simon
Ack.
Re: [PATCH] net: designware: add DM_MDIO support
On Wed, Feb 24, 2021 at 4:02 PM Neil Armstrong wrote:
>
> Add support for DM_MDIO to connect to PHY and expose a MDIO device for the
> internal MDIO bus in order to dynamically connect to MDIO PHYs with DT
> with eventual MDIO muxes in between.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/net/designware.c | 93 +++-
> 1 file changed, 92 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 9dba55adaa..acf3a82828 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -21,7 +21,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -122,6 +124,55 @@ static int dw_mdio_reset(struct mii_dev *bus)
> }
> #endif
>
> +#if IS_ENABLED(CONFIG_DM_MDIO)
> +int designware_eth_mdio_read(struct udevice *mdio_dev, int addr, int devad,
> int reg)
> +{
> + struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
> +
> + return dw_mdio_read(pdata->mii_bus, addr, devad, reg);
> +}
> +
> +int designware_eth_mdio_write(struct udevice *mdio_dev, int addr, int devad,
> int reg, u16 val)
> +{
> + struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
> +
> + return dw_mdio_write(pdata->mii_bus, addr, devad, reg, val);
> +}
> +
> +#if CONFIG_IS_ENABLED(DM_GPIO)
> +int designware_eth_mdio_reset(struct udevice *mdio_dev)
> +{
> + struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
> +
> + return dw_mdio_reset(pdata->mii_bus);
> +}
> +#endif
> +
> +static const struct mdio_ops designware_eth_mdio_ops = {
> + .read = designware_eth_mdio_read,
> + .write = designware_eth_mdio_write,
> +#if CONFIG_IS_ENABLED(DM_GPIO)
> + .reset = designware_eth_mdio_reset,
> +#endif
> +};
> +
> +static int designware_eth_mdio_probe(struct udevice *dev)
> +{
> + /* Use the priv data of parent */
> + dev_set_priv(dev, dev_get_priv(dev->parent));
> +
> + return 0;
> +}
> +
> +U_BOOT_DRIVER(designware_eth_mdio) = {
> + .name = "eth_designware_mdio",
> + .id = UCLASS_MDIO,
> + .probe = designware_eth_mdio_probe,
> + .ops = _eth_mdio_ops,
> + .plat_auto = sizeof(struct mdio_perdev_priv),
> +};
> +#endif
> +
> static int dw_mdio_init(const char *name, void *priv)
> {
> struct mii_dev *bus = mdio_alloc();
> @@ -143,6 +194,34 @@ static int dw_mdio_init(const char *name, void *priv)
> return mdio_register(bus);
> }
>
> +#if IS_ENABLED(CONFIG_DM_MDIO)
> +static int dw_dm_mdio_init(const char *name, void *priv)
> +{
> + struct udevice *dev = priv;
> + ofnode node;
> + int ret;
> +
> + ofnode_for_each_subnode(node, dev_ofnode(dev)) {
> + const char *subnode_name = ofnode_get_name(node);
> + struct udevice *mdiodev;
> +
> + if (strcmp(subnode_name, "mdio"))
> + continue;
> +
> + ret = device_bind_driver_to_node(dev, "eth_designware_mdio",
> +subnode_name, node,
> );
> + if (ret)
> + debug("%s: not able to bind mdio device node\n",
> __func__);
> +
> + return 0;
> + }
> +
> + printf("%s: mdio node is missing, registering legacy mdio bus",
> __func__);
> +
> + return dw_mdio_init(name, priv);
> +}
> +#endif
> +
> static void tx_descs_init(struct dw_eth_dev *priv)
> {
> struct eth_dma_regs *dma_p = priv->dma_regs_p;
> @@ -487,7 +566,14 @@ static int _dw_free_pkt(struct dw_eth_dev *priv)
> static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
> {
> struct phy_device *phydev;
> - int phy_addr = -1, ret;
> + int ret;
> +
> +#if IS_ENABLED(CONFIG_DM_MDIO) && IS_ENABLED(CONFIG_DM_ETH)
> + phydev = dm_eth_phy_connect(dev);
> + if (!phydev)
> + return -ENODEV;
> +#else
> + int phy_addr = -1;
>
> #ifdef CONFIG_PHY_ADDR
> phy_addr = CONFIG_PHY_ADDR;
> @@ -496,6 +582,7 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
> phydev = phy_connect(priv->bus, phy_addr, dev, priv->interface);
> if (!phydev)
> return -ENODEV;
> +#endif
>
> phydev->supported &= PHY_GBIT_FEATURES;
> if (priv->max_speed) {
> @@ -759,7 +846,11 @@ int designware_eth_probe(struct udevice *dev)
> priv->interface = pdata->phy_interface;
> priv->max_speed = pdata->max_speed;
>
> +#if IS_ENABLED(CONFIG_DM_MDIO)
> + ret = dw_dm_mdio_init(dev->name, dev);
> +#else
> ret = dw_mdio_init(dev->name, dev);
> +#endif
> if (ret) {
> err = ret;
> goto mdio_err;
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH] net: add Amlogic Meson G12A MDIO MUX driver
On Wed, Feb 24, 2021 at 6:31 PM Neil Armstrong wrote:
>
> The Amlogic G12A & compatible SoCs embeds a mux to either communicate with
> the external PHY or the internal 10/100 PHY.
>
> This adds support for this mux as a MDIO MUX device.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/net/Kconfig | 7 ++
> drivers/net/Makefile | 1 +
> drivers/net/mdio_mux_meson_g12a.c | 149 ++
> 3 files changed, 157 insertions(+)
> create mode 100644 drivers/net/mdio_mux_meson_g12a.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 41fa2fe566..e1d3b26687 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -797,4 +797,11 @@ config MDIO_MUX_MMIOREG
> This driver is used for MDIO muxes driven by writing to a register
> in
> the MMIO physical memory.
>
> +config MDIO_MUX_MESON_G12A
> + bool "MDIO MUX for Amlogic Meson G12A SoCs"
> + depends on DM_MDIO_MUX
> + help
> + This driver is used for the MDIO mux found on the Amlogic G12A &
> compatible
> + SoCs.
> +
> endif # NETDEVICES
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 511c87c3a5..070ae7662c 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_MACB) += macb.o
> obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
> obj-$(CONFIG_MDIO_IPQ4019) += mdio-ipq4019.o
> obj-$(CONFIG_MDIO_MUX_I2CREG) += mdio_mux_i2creg.o
> +obj-$(CONFIG_MDIO_MUX_MESON_G12A) += mdio_mux_meson_g12a.o
> obj-$(CONFIG_MDIO_MUX_MMIOREG) += mdio_mux_mmioreg.o
> obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o
> obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
> diff --git a/drivers/net/mdio_mux_meson_g12a.c
> b/drivers/net/mdio_mux_meson_g12a.c
> new file mode 100644
> index 00..b520bf98f0
> --- /dev/null
> +++ b/drivers/net/mdio_mux_meson_g12a.c
> @@ -0,0 +1,149 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) Copyright 2021 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ETH_PLL_STS0x40
> +#define ETH_PLL_CTL0 0x44
> +#define PLL_CTL0_LOCK_DIG BIT(30)
> +#define PLL_CTL0_RST BIT(29)
> +#define PLL_CTL0_EN BIT(28)
> +#define PLL_CTL0_SEL BIT(23)
> +#define PLL_CTL0_NGENMASK(14, 10)
> +#define PLL_CTL0_MGENMASK(8, 0)
> +#define PLL_LOCK_TIMEOUT 100
> +#define PLL_MUX_NUM_PARENT2
> +#define ETH_PLL_CTL1 0x48
> +#define ETH_PLL_CTL2 0x4c
> +#define ETH_PLL_CTL3 0x50
> +#define ETH_PLL_CTL4 0x54
> +#define ETH_PLL_CTL5 0x58
> +#define ETH_PLL_CTL6 0x5c
> +#define ETH_PLL_CTL7 0x60
> +
> +#define ETH_PHY_CNTL0 0x80
> +#define EPHY_G12A_ID 0x33010180
> +#define ETH_PHY_CNTL1 0x84
> +#define PHY_CNTL1_ST_MODE GENMASK(2, 0)
> +#define PHY_CNTL1_ST_PHYADD GENMASK(7, 3)
> +#define EPHY_DFLT_ADD8
> +#define PHY_CNTL1_MII_MODEGENMASK(15, 14)
> +#define EPHY_MODE_RMII 0x1
> +#define PHY_CNTL1_CLK_EN BIT(16)
> +#define PHY_CNTL1_CLKFREQ BIT(17)
> +#define PHY_CNTL1_PHY_ENB BIT(18)
> +#define ETH_PHY_CNTL2 0x88
> +#define PHY_CNTL2_USE_INTERNALBIT(5)
> +#define PHY_CNTL2_SMI_SRC_MAC BIT(6)
> +#define PHY_CNTL2_RX_CLK_EPHY BIT(9)
> +
> +#define MESON_G12A_MDIO_EXTERNAL_ID 0
> +#define MESON_G12A_MDIO_INTERNAL_ID 1
> +
> +struct mdio_mux_meson_g12a_priv {
> + struct udevice *chip;
> + phys_addr_t phys;
> +};
> +
> +static int meson_g12a_ephy_pll_init(struct mdio_mux_meson_g12a_priv *priv)
> +{
> + /* Fire up the PHY PLL */
> + writel(0x29c0040a, priv->phys + ETH_PLL_CTL0);
> + writel(0x927e, priv->phys + ETH_PLL_CTL1);
> + writel(0xac5f49e5, priv->phys + ETH_PLL_CTL2);
> + writel(0x, priv->phys + ETH_PLL_CTL3);
> + writel(0x, priv->phys + ETH_PLL_CTL4);
> + writel(0x2020, priv->phys + ETH_PLL_CTL5);
> + writel(0xc002, priv->phys + ETH_PLL_CTL6);
> + writel(0x0023, priv->phys + ETH_PLL_CTL7);
> + writel(0x39c0040a, priv->phys + ETH_PLL_CTL0);
> + writel(0x19c0040a, priv->phys + ETH_PLL_CTL0);
> +
> + return 0;
> +}
> +
> +static int meson_g12a_enable_internal_mdio(struct mdio_mux_meson_g12a_priv
> *priv)
> +{
> + /* Initialize ephy control */
> + writel(EPHY_G12A_ID, priv->phys + ETH_PHY_CNTL0);
> + writel(FIELD_PREP(PHY_CNTL1_ST_MODE, 3) |
> + FIELD_PREP(PHY_CNTL1_ST_PHYADD, EPHY_DFLT_ADD) |
> + FIELD_PREP(PHY_CNTL1_MII_MODE, EPHY_MODE_RMII) |
> + PHY_CNTL1_CLK_EN |
> + PHY_CNTL1_CLKFREQ |
> + PHY_CNTL1_PHY_ENB,
> + priv->phys + ETH_PHY_CNTL1);
> + writel(PHY_CNTL2_USE_INTERNAL |
> +
Re: [PATCH u-boot-dm + u-boot-spi v3 09/11] cmd: mtd: print device OF path in listing
Hi Marek,
On Thu, 25 Feb 2021 at 09:14, Marek Behún wrote:
>
> Print MTD's device OF path in the output of `mtd list` command.
>
> Signed-off-by: Marek Behún
> Cc: Jagan Teki
> Cc: Priyanka Jain
> Cc: Simon Glass
> Cc: Heiko Schocher
> Cc: Jagan Teki
> Cc: Patrick Delaunay
> Cc: Patrice CHOTARD
> Cc: Miquel Raynal
> ---
> cmd/mtd.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/cmd/mtd.c b/cmd/mtd.c
> index 485a963bdd..446cbc1038 100644
> --- a/cmd/mtd.c
> +++ b/cmd/mtd.c
> @@ -126,6 +126,15 @@ static void mtd_show_device(struct mtd_info *mtd)
> printf(" - driver: %s\n", mtd->dev->driver->name);
> }
> #endif
> +#if defined(CONFIG_OF_CONTROL)
> + if (mtd->dev) {
Can you do:
if (IS_ENABLED(CONFIG_OF_CONTROL) && mtd->dev)
?
> + char buf[256];
> + int res;
> +
> + res = ofnode_get_path(mtd_get_ofnode(mtd), buf, 256);
> + printf(" - path: %s\n", res == 0 ? buf : "unavailable");
> + }
> +#endif
>
> /* MTD device information */
> printf(" - type: ");
> --
> 2.26.2
>
Regards,
Simon
Re: [PATCH v4 4/5] test: qemu: add simple test for cmd_qfw
On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > Signed-off-by: Asherah Connor > --- > > (no changes since v1) > > test/py/tests/test_qfw.py | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 test/py/tests/test_qfw.py Reviewed-by: Simon Glass
Re: [PATCH] net: use the same alias stem for ethernet as linux
On Thu, Feb 25, 2021 at 5:58 PM Fabio Estevam wrote:
>
> Hi Michael,
>
> On Thu, Feb 25, 2021 at 12:51 PM Michael Walle wrote:
> >
> > Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
> > the linux tree:
> >
> > $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > 0
> > $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > 633
> >
> > In u-boot device trees both prefixes are used. Until recently the only
> > user of the ethernet alias was the sandbox test device tree. This
> > changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
> > switches"). There, the MAC addresses are inherited based on the devices
> > sequence IDs which is in turn given by the device tree.
> >
> > Before there are more users in u-boot and both worlds will differ even
> > more, rename the alias prefix to "ethernet" to match the linux ones.
> > Also adapt the test cases and rename any old aliases in the u-boot
> > device trees.
> >
> > Cc: David Wu
> > Signed-off-by: Michael Walle
>
> Yes, this is the preferred node naming as per the Devicetree Specification:
>
> Reviewed-by: Fabio Estevam
Ack-by: Ramon Fried
Re: Broken build on OpenBSD
Hi Alex, On Tue, 23 Feb 2021 at 17:23, Alex G. wrote: > > On 2/23/21 3:18 PM, Simon Glass wrote: > > Hi Alex, > > > > On Tue, 23 Feb 2021 at 14:48, Alex G. wrote: > >> > >> On 2/23/21 1:07 PM, Mark Kettenis wrote: > >>> Hi Simon, > >>> > >>> Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on > >>> OpenBSD and probably other non-Linux systems. ENODATA, which is now > >>> used in fit_check_format(), isn't defined. It isn't part of POSIX[1] > >>> and generally not available on BSD-derived systems. Could you pick > >>> another error code for this case? > >> > >> Hi Mark, > >> > >> I looked at the commit you mentioned, and I think it's fundamentally > >> broken. The errors represent -EINVAL, and trying to assign different > >> error codes doesn't make sense. > >> > >> "Wrong FIT format: no images parent node": > >> -ENOENT "No such file or directory". > >> This just doesn't make sense. We obviously have the file data at this > >> point, and we know the data is wrong. This should be -EINVAL. > >> > >> "Wrong FIT format: no description": > >> -ENOMSG "No message of desired type". > >> Again, this doesn't make sense. We're not dealing with messaging APIs or > >> send()/recv(). I think this should be -EINVAL. > >> > >> "Wrong FIT format: not a flattened device tree": > >> -ENOEXEC "Exec format error" > >> This one is amusing, as it's comparing a flattened devicetree to an > >> executable. An FDT might have executable code, which is in the wrong > >> format, but this is not why we're failing here. > >> > >> Simon, > >> I'd suggest using the correct error code, which, for each case is > >> -EINVAL, as the log messages also confirm: "Wrong [input value] format". > >> We might have issues with the "configurations", an "@" in a signature > >> name, and so forth. There just aren't enough error codes to cover the > >> set of possible failures. And in any case, there likely can't be a > >> reasonable 1:1 mapping to _distinct_ errno codes. > >> > >> Does any user even check the error code beyond "less than zero"? Take > >> different decisions based on what the negative code indicates? If > >> information as to what is wrong with the input value (FIT) is needed, > >> then I'd suggest using a separate enum, and stick to -EINVAL. > > > > Actually I make an effort to use different codes where possible, so > > there is some indication what went wrong. Of course devs can whip out > > the JTAG debugger or start filling the code with printf()s but normal > > users cannot, so having an idea what is wrong is helpful. > > > > We don't have to cover every case, but years ago U-Boot used to return > > -1 for lots of failures and it was certainly frustrating to debug > > things. > > I agree with most of these arguments. And I agree with using errno codes > to represent errno codes. However, when we deviate from the agreed upon > convention, can we still apply the said convention? Each function > acquires its own set of rules. And when each function has its own set of > rules, the source code is needed to derive the meaning. +Tom Rini too I am not a fan of each function having its own rules, but the overall U-Boot rules are very broad. Something like: -EPERM - the old -1 -ENOENT - entry or object not found -EIO - failed to perform I/O -ENXIO - couldn't find device/address -EAGAIN - try later (e.g. dependencies not ready) -ENOMEM - out of memory -EINVAL - dev_read_...() failed -ENODEV - do not bind device -ENOSPC - ran out of space -EREMOTEIO - cannot talk to peripheral, e.g. i2c -EPFNOSUPPORT - missing uclass There are others. If we only used these it would not be much better than using -1 / -EPERM. > > You make the argument that these codes give normal users an idea of what > is wrong. I assume that normal users respond better to human-readable > strings than to negative integers -- for which they would have to go to > he source code anyway to decipher the meaning. Because, in order to be > useful, error codes require the, they cannot be useful for normal users. The problem is that we don't want to print strings willy nilly in drivers and library code. That makes it manageable for higher-level code that is actually in control. If an object is not found and an error is reported, but the caller knows it is optional and continues, the user sees the error and assumes something is wrong. Better to print errors just in the top-level code. At that point all we have is the error number. As things are today, top-level code can use that to print useful messages if it wants to, but if all the numbers returned are the same, it can't. > > I believe this rebukes your central point around the unconventional use > of errno codes. To the extent that it is unconventional, that reflects the decision to avoid adding U-Boot-specific error numbers and perhaps also to avoid having a different error number for each possible failure in U-Boot. > > So then the question is how to cover error cases without returning '-1', > and
Re: [PATCH v1] net: eth-uclass: Change uclass driver name to ethernet
On Thu, 25 Feb 2021 at 10:55, Fabio Estevam wrote:
>
> On Thu, Feb 25, 2021 at 4:58 AM Michael Walle wrote:
>
> > This is how it looks in the linux tree:
> >
> > $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> > 633
>
> Yes, 'ethernet' is the recommended node name as per the Devicetree
> Specification doc item "2.2.2 Generic Names Recommendation".
OK.
- Simon
Re: [PATCH u-boot-dm + u-boot-spi v3 10/11] mtd: compare also with OF path and device name in get_mtd_device_nm()
Hi Marek,
On Thu, 25 Feb 2021 at 09:14, Marek Behún wrote:
>
> The get_mtd_device_nm() function (code imported from Linux) simply
> iterates all registered MTD devices and compares the given name with
> all MTDs' names.
>
> With SPI_FLASH_MTD enabled U-Boot registers a SPI-NOR as a MTD device
> with name identical to the SPI flash chip name (from SPI ID table). Thus
> for a board with multiple same SPI-NORs it registers multiple MTDs, but
> all with the same name (such as "s25fl164k"). We do not want to change
> this behaviour, since such a change could break existing boot scripts,
> which can rely on a hardcoded name.
>
> In order to allow somehow to uniqely select a MTD device, change
> get_mtd_device_nm() function as such:
> - if first character of name is '/', interpret it as OF path
> - otherwise compare the name with MTDs name and MTDs device name.
>
> In the following example a board has two "s25fl164k" SPI-NORs. They both
> have name "s25fl164k", thus cannot be uniquely selected via this name.
> With this change, the user can select the second SPI-NOR either with
> "spi-nor@1" or "/soc/spi@10600/spi-nor@1".
>
> Example:
> => mtd list
> List of MTD devices:
> * s25fl164k
> - device: spi-nor@0
> - parent: spi@10600
> - driver: jedec_spi_nor
> - path: /soc/spi@10600/spi-nor@0
> - type: NOR flash
> - block size: 0x1000 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0080 : "s25fl164k"
> * s25fl164k
> - device: spi-nor@1
> - parent: spi@10600
> - driver: jedec_spi_nor
> - path: /soc/spi@10600/spi-nor@1
> - type: NOR flash
> - block size: 0x1000 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0080 : "s25fl164k"
>
> This change adds code that depends on CONFIG_DM. Although CONFIG_DM
> is compulsory since v2020.01, there are still some boards (for example
> tqma6s_wru4_mmc_defconfig) that don't enable it. Therefore the code
> guards this parts by #ifdefs.
>
> Signed-off-by: Marek Behún
> Cc: Jagan Teki
> Cc: Priyanka Jain
> Cc: Simon Glass
> Cc: Heiko Schocher
> Cc: Jagan Teki
> Cc: Patrick Delaunay
> Cc: Patrice CHOTARD
> Cc: Miquel Raynal
> ---
> drivers/mtd/mtdcore.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 0d1f94c6cb..7c894b2e41 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -780,13 +780,42 @@ struct mtd_info *get_mtd_device_nm(const char *name)
> {
> int err = -ENODEV;
> struct mtd_info *mtd = NULL, *other;
> +#ifdef CONFIG_DM
> + struct udevice *dev = NULL;
> +#endif
> +
> +#ifdef CONFIG_DM
We should not need CONFIG_DM here...it should be enabled for all
boards. You can always disable MTD for a board if not, or send a
removable patch.
If for some reason you do, please use if (IS_ENABLED() so that 'dev'
can always be declared.
> + /*
> +* If the first character of mtd name is '/', interpret it as OF path.
> +* Otherwise try comparing by mtd->name and mtd->dev->name.
> +*/
> + if (*name == '/') {
> + err = device_get_global_by_ofnode(ofnode_path(name), );
> + if (err)
> + return ERR_PTR(err);
> + }
> +#endif
>
> mutex_lock(_table_mutex);
>
> mtd_for_each_device(other) {
> +#ifdef CONFIG_DM
> + if ((dev && !mtd_is_partition(other) && other->dev == dev) ||
> + !strcmp(name, other->name) ||
> + (!mtd_is_partition(other) && other->dev &&
> +!strcmp(name, other->dev->name))) {
> +#else
> if (!strcmp(name, other->name)) {
> +#endif
> +#ifdef __UBOOT__
> + if (mtd)
> + printf("\nWarning: MTD name \"%s\" is not
> unique!\n\n",
> + name);
> + mtd = other;
> +#else /* !__UBOOT__ */
> mtd = other;
> break;
> +#endif /* !__UBOOT__ */
> }
> }
>
> --
> 2.26.2
>
Regards,
Simon
Re: [PATCH u-boot-dm + u-boot-spi v3 03/11] dm: core: add ofnode_get_path()
On Thu, 25 Feb 2021 at 09:14, Marek Behún wrote: > > Add function for retrieving full node path of a given ofnode. > This uses np->full_name if OF is live, otherwise a call to > fdt_get_path() is made. > > Signed-off-by: Marek Behún > Cc: Simon Glass > --- > drivers/core/ofnode.c | 25 + > include/dm/ofnode.h | 10 ++ > test/dm/ofnode.c | 21 + > 3 files changed, 56 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH 4/6] scmi: define LOG_CATEGORY
On Wed, 24 Feb 2021 at 05:20, Patrick Delaunay wrote: > > Define LOG_CATEGORY to allow filtering with log command. > > Signed-off-by: Patrick Delaunay > --- > > drivers/firmware/scmi/mailbox_agent.c| 2 ++ > drivers/firmware/scmi/sandbox-scmi_agent.c | 2 ++ > drivers/firmware/scmi/sandbox-scmi_devices.c | 2 ++ > drivers/firmware/scmi/scmi_agent-uclass.c| 2 ++ > drivers/firmware/scmi/smccc_agent.c | 2 ++ > drivers/firmware/scmi/smt.c | 2 ++ > 6 files changed, 12 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > Updates the QFW driver to use the driver model, splitting the driver > into qfw_pio and qfw_mmio (for non-x86) in their own uclass. > > Signed-off-by: Asherah Connor > --- > > Changes in v4: > - PIO definitions are now #defines > - qfw_*_plat structs are no longer in header files > - Remove yield/pause in DMA wait loop > - Change struct udevice *qfw_get_dev(void) to int qfw_get_dev(struct > udevice **) > > arch/arm/Kconfig | 1 + > arch/x86/cpu/qemu/cpu.c | 9 +- > arch/x86/cpu/qemu/qemu.c | 47 +--- > arch/x86/cpu/qfw_cpu.c | 11 +- > cmd/qfw.c| 52 - > common/Makefile | 2 + > common/qfw.c | 105 + > drivers/misc/Makefile| 6 +- > drivers/misc/qfw.c | 238 ++- > drivers/misc/qfw_mmio.c | 119 > drivers/misc/qfw_pio.c | 69 > include/dm/uclass-id.h | 1 + > include/qfw.h| 61 ++ > 13 files changed, 466 insertions(+), 255 deletions(-) > create mode 100644 common/qfw.c > create mode 100644 drivers/misc/qfw_mmio.c > create mode 100644 drivers/misc/qfw_pio.c Reviewed-by: Simon Glass
Re: [PATCH v4 5/5] qemu: add documentation to qfw.h
Hi Asherah, On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > Also rename a "length" to "size" for consistency with the rest of qfw. Here also you add comments so should mention that. > > Signed-off-by: Asherah Connor > --- > > (no changes since v1) > > drivers/misc/qfw.c | 6 ++-- > include/qfw.h | 86 +++--- > 2 files changed, 84 insertions(+), 8 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v4 3/5] qemu: add sandbox driver and tests
On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > We minimally exercise the sandbox driver. > > Signed-off-by: Asherah Connor > --- > > (no changes since v1) > > arch/sandbox/dts/sandbox.dtsi | 4 ++ > arch/sandbox/dts/test.dts | 4 ++ > drivers/misc/Makefile | 1 + > drivers/misc/qfw_sandbox.c| 129 ++ > test/dm/Makefile | 1 + > test/dm/qfw.c | 42 +++ > 6 files changed, 181 insertions(+) > create mode 100644 drivers/misc/qfw_sandbox.c > create mode 100644 test/dm/qfw.c > Reviewed-by: Simon Glass
Re: [PATCH v4 2/5] arm: x86: qemu: unify qfw driver functions as qfw_
On Tue, 23 Feb 2021 at 22:24, Asherah Connor wrote: > > There's a mixture of "qemu_fwcfg_"-prefixed functions and > "qfw_"-prefixed ones. Now that the qfw name is applied in multiple > places (i.e. the uclass itself, and each of its drivers), let's > consistently use the prefix "qfw_" for anything relating to the > drivers. > > Signed-off-by: Asherah Connor > --- > > (no changes since v1) > > arch/x86/cpu/qemu/cpu.c | 2 +- > arch/x86/cpu/qfw_cpu.c | 2 +- > cmd/qfw.c | 10 +- > common/qfw.c| 14 +++--- > drivers/misc/qfw.c | 20 ++-- > include/qfw.h | 16 > 6 files changed, 32 insertions(+), 32 deletions(-) Reviewed-by: Simon Glass
[PATCH] RFC: spl: fit: Use libfdt functions to read stringlist
At present the code here reimplements a few libfdt functions and does not
always respect the property length. The !str check is unlikely to fire
since 1 is added to the string address. If strchr() returns NULL then the
code produces (void*)1 instead. Also it might extend beyond the property
value since strchr() does not have a maximum length.
In any case it does not seem worthwhile to implement the libfdt functions
again, despite small code-size advantages. There is no function to return
the count after a failed get, but we can call two functions. We could add
one if code size is considered critical here.
Update the code to use libfdt directly.
For lion-rk3368 (aarch64) this adds 68 bytes of code.
For am57xx_hs_evm (arm) it adds 134 bytes.
Signed-off-by: Simon Glass
---
common/spl/spl_fit.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 75c8ff065bb..3b5307e4b2d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -83,33 +83,24 @@ static int spl_fit_get_image_name(const struct spl_fit_info
*ctx,
const char **outname)
{
struct udevice *sysinfo;
- const char *name, *str;
- __maybe_unused int node;
- int len, i;
- bool found = true;
-
- name = fdt_getprop(ctx->fit, ctx->conf_node, type, );
- if (!name) {
- debug("cannot find property '%s': %d\n", type, len);
- return -EINVAL;
- }
+ const char *str;
+ int count;
+ bool found;
- str = name;
- for (i = 0; i < index; i++) {
- str = strchr(str, '\0') + 1;
- if (!str || (str - name >= len)) {
- found = false;
- break;
- }
- }
+ count = fdt_stringlist_count(ctx->fit, ctx->conf_node, type);
+ str = fdt_stringlist_get(ctx->fit, ctx->conf_node, type, index, NULL);
+ found = str;
if (!found && CONFIG_IS_ENABLED(SYSINFO) && !sysinfo_get()) {
int rc;
/*
* no string in the property for this index. Check if the
-* sysinfo-level code can supply one.
+* sysinfo-level code can supply one. Subtract the number of
+* strings found in the devicetre node, so that @index numbers
+* the options in order from 0, starting with the devicetree
+* property and ending with sysinfo.
*/
- rc = sysinfo_get_fit_loadable(sysinfo, index - i - 1, type,
+ rc = sysinfo_get_fit_loadable(sysinfo, index - count, type,
);
if (rc && rc != -ENOENT)
return rc;
--
2.30.1.766.gb4fecdf3b7-goog
Re: [PATCH 3/4] net: dsa: remove NULL check for priv and platform data
On Thu, Feb 25, 2021 at 12:23 AM Vladimir Oltean wrote: > > On Wed, Feb 24, 2021 at 05:40:41PM +0100, Michael Walle wrote: > > Because the uclass has the "*_auto" properties set, the driver model > > will take care of allocating the private structures for us and they > > can't be NULL. Drop the checks. > > > > Signed-off-by: Michael Walle > > --- > > Reviewed-by: Vladimir Oltean Reviewed-By: Ramon Fried
Re: [PATCH 2/4] net: dsa: probe master device
On Wed, Feb 24, 2021 at 6:40 PM Michael Walle wrote:
>
> DSA needs to have the master device probed first for MAC inheritance.
> Until now, it only works by chance because the only user (LS1028A SoC)
> will probe the master device first. The probe order is given by the PCI
> device ordering, thus it works because the master device has a "smaller"
> BDF then the switch device.
>
> Explicitly probe the master device in dsa_port_probe().
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Michael Walle
> Reviewed-by: Vladimir Oltean
> ---
> net/dsa-uclass.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 88a8ea9352..7898f30e15 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -272,6 +272,7 @@ static int dsa_port_probe(struct udevice *pdev)
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> + int ret;
>
> port_pdata = dev_get_parent_plat(pdev);
> dsa_priv = dev_get_uclass_priv(dev);
> @@ -284,6 +285,14 @@ static int dsa_port_probe(struct udevice *pdev)
> if (!master)
> return -ENODEV;
>
> + /*
> +* Probe the master device. We depend on the master device for proper
> +* operation and we also need it for MAC inheritance below.
> +*/
> + ret = device_probe(master);
> + if (ret)
> + return ret;
> +
> /*
> * Inherit port's hwaddr from the DSA master, unless the port already
> * has a unique MAC address specified in the environment.
> --
> 2.20.1
>
Reviewed-By: Ramon Fried
Re: [PATCH 1/4] net: dsa: return early if there is no master
On Wed, Feb 24, 2021 at 6:40 PM Michael Walle wrote:
>
> It doesn't make sense to have DSA without a master port. Error out early
> if there is no master port.
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Michael Walle
> Reviewed-by: Vladimir Oltean
> ---
> net/dsa-uclass.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 2ce9ddb90d..88a8ea9352 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -280,6 +280,10 @@ static int dsa_port_probe(struct udevice *pdev)
> if (!port_pdata->phy)
> return -ENODEV;
>
> + master = dsa_get_master(dev);
> + if (!master)
> + return -ENODEV;
> +
> /*
> * Inherit port's hwaddr from the DSA master, unless the port already
> * has a unique MAC address specified in the environment.
> @@ -288,10 +292,6 @@ static int dsa_port_probe(struct udevice *pdev)
> if (!is_zero_ethaddr(env_enetaddr))
> return 0;
>
> - master = dsa_get_master(dev);
> - if (!master)
> - return 0;
> -
> master_pdata = dev_get_plat(master);
> eth_pdata = dev_get_plat(pdev);
> memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
> --
> 2.20.1
>
Reviewed-By: Ramon Fried
[PATCH] cmd: gpt: Add option to write GPT partitions to environment variable
This change would enhance the existing 'gpt read' command to allow
(optionally) writing of the read GPT partitions to an environment
variable. This would allow users to easily change the partition
settings and then simply reuse the variable in the 'gpt write' and
'gpt verify' commands.
Signed-off-by: Farhan Ali
---
Cc: Simon Glass
Cc: Heinrich Schuchardt
Cc: Corneliu Doban
Cc: Rayagonda Kokatanur
cmd/gpt.c | 46 ++
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/cmd/gpt.c b/cmd/gpt.c
index 76a95ad..12d0551 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -350,17 +350,46 @@ static int get_gpt_info(struct blk_desc *dev_desc)
}
/* a wrapper to test get_gpt_info */
-static int do_get_gpt_info(struct blk_desc *dev_desc)
+static int do_get_gpt_info(struct blk_desc *dev_desc, char * const namestr)
{
- int ret;
+ int numparts;
+
+ numparts = get_gpt_info(dev_desc);
+
+ if (numparts > 0) {
+ if (namestr) {
+ char disk_guid[UUID_STR_LEN + 1];
+ char *partitions_list;
+ int partlistlen;
+ int ret = -1;
+
+ ret = get_disk_guid(dev_desc, disk_guid);
+ if (ret < 0)
+ return ret;
+
+ partlistlen = calc_parts_list_len(numparts);
+ partitions_list = malloc(partlistlen);
+ if (!partitions_list) {
+ del_gpt_info();
+ return -ENOMEM;
+ }
+ memset(partitions_list, '\0', partlistlen);
+
+ ret = create_gpt_partitions_list(numparts, disk_guid,
+partitions_list);
+ if (ret < 0)
+ printf("Error: Could not create partition list
string!\n");
+ else
+ env_set(namestr, partitions_list);
- ret = get_gpt_info(dev_desc);
- if (ret > 0) {
- print_gpt_info();
+ free(partitions_list);
+ } else {
+ print_gpt_info();
+ }
del_gpt_info();
return 0;
}
- return ret;
+ return numparts;
}
#endif
@@ -982,7 +1011,7 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
ret = do_disk_guid(blk_dev_desc, argv[4]);
#ifdef CONFIG_CMD_GPT_RENAME
} else if (strcmp(argv[1], "read") == 0) {
- ret = do_get_gpt_info(blk_dev_desc);
+ ret = do_get_gpt_info(blk_dev_desc, argv[4]);
} else if ((strcmp(argv[1], "swap") == 0) ||
(strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4],
argv[5]);
@@ -1028,8 +1057,9 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt guid mmc 0 varname\n"
#ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
- " gpt read \n"
+ " gpt read []\n"
"- read GPT into a data structure for manipulation\n"
+ "- read GPT partitions into environment variable\n"
" gpt swap\n"
"- change all partitions named name1 to name2\n"
" and vice-versa\n"
--
1.8.3.1
Re: DM_MMC, BLK
On Thu, Feb 25, 2021 at 06:47:55PM +0100, Heinrich Schuchardt wrote: > On 2/24/21 10:32 PM, Tom Rini wrote: > > On Wed, Feb 24, 2021 at 10:28:31PM +0100, Heinrich Schuchardt wrote: > > > > > Hello Tom, > > > > > > migrating to CONFIG_DM_MMC was scheduled for release v2019.04. But some > > > board maintainers simply don't care. > > > > > > We have quite a lot of boards like cm_t335, draco, etamin, rastaban, > > > thuban, pxm2, vinco which compile when setting CONFIG_DM_MMC and > > > CONFIG_BLK. > > > > > > Shall we switch all boards that compile with these settings? > > > > Please see > > https://patchwork.ozlabs.org/project/uboot/list/?series=230325 > > There are other parts concerning block devices needing clean up. E.g the > usage of HAVE_BLOCK_DEVICE in disk/. > > Having all these changes collected in a next branch would be helpful. I've got various rebasing branches up with these removals (and some temporary merges) currently under WIP/make-DM_xxx-fatal. I will be opening next fairly soon. -- Tom signature.asc Description: PGP signature
Re: [PATCH 52/57] ppc: Remove MPC8569MDS board
On Sat, Feb 20, 2021 at 08:06:29PM -0500, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. As this is the last ARCH_MPC8569 board, remove that support > as well. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini > Reviewed-by: Priyanka Jain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 51/57] ppc: configs: Remove a few non-updated build configurations
On Sat, Feb 20, 2021 at 08:06:28PM -0500, Tom Rini wrote: > In the cases of T2080RDB_SECURE_BOOT, T2080RDB_SRIO_PCIE_BOOT, > P2041RDB_SECURE_BOOT, P2041RDB_SRIO_PCIE_BOOT, P3041DS_SRIO_PCIE_BOOT > and P4080DS_SRIO_PCIE_BOOT while some forms of the board have been > migrated more fully to current build standards, these have not. Remove > them. > > Cc: Priyanka Jain > Signed-off-by: Tom Rini > Reviewed-by: Priyanka Jain Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 40/57] arm: Remove sksimx6 board
On Sat, Feb 20, 2021 at 08:06:17PM -0500, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. > > Cc: Stefano Babic > Signed-off-by: Tom Rini > Acked-by: Stefano Babic Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 35/57] arm: Remove mx53smd board
On Sat, Feb 20, 2021 at 08:06:12PM -0500, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. > > Cc: Fabio Estevam > Signed-off-by: Tom Rini > Reviewed-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 33/57] arm: Remove mx53ard board
On Sat, Feb 20, 2021 at 08:06:10PM -0500, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. > > Cc: Fabio Estevam > Signed-off-by: Tom Rini > Reviewed-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 07/57] arm: Remove mx25pdk board
On Sat, Feb 20, 2021 at 08:05:44PM -0500, Tom Rini wrote: > This board has not been converted to CONFIG_DM_MMC by the deadline. > Remove it. > > Cc: Fabio Estevam > Signed-off-by: Tom Rini > Reviewed-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: DM_MMC, BLK
On 2/24/21 10:32 PM, Tom Rini wrote: On Wed, Feb 24, 2021 at 10:28:31PM +0100, Heinrich Schuchardt wrote: Hello Tom, migrating to CONFIG_DM_MMC was scheduled for release v2019.04. But some board maintainers simply don't care. We have quite a lot of boards like cm_t335, draco, etamin, rastaban, thuban, pxm2, vinco which compile when setting CONFIG_DM_MMC and CONFIG_BLK. Shall we switch all boards that compile with these settings? Please see https://patchwork.ozlabs.org/project/uboot/list/?series=230325 There are other parts concerning block devices needing clean up. E.g the usage of HAVE_BLOCK_DEVICE in disk/. Having all these changes collected in a next branch would be helpful. Best regards Heinrich And there's a follow-up for MVSATA/IDE stuff. I've started but haven't finished yet one for DM_PCI, but did post more removals on top of that.
Re: [PATCH 20/20] Enable led on boot to notify user of boot status
On Thu, Feb 25, 2021 at 3:17 PM André Przywara wrote:
>
> On 20/02/2021 12:14, Nicolas Boulenguez wrote:
> > From: Marius Gripsgard
>
> Hi,
>
> This is not really Pinephone specific, actually not even sunxi specific.
> I see two better ways of solving this:
>
> - We introduce some generic code to find "gpio-leds" subnodes in the DT,
> which have a default-state = "on" property. This could be either added
> to drivers/led/led_gpio.c, or in some higher level.
>
> - We introduce a generic boot LED GPIO config symbol. Maybe there is
> already something, that sounds like a generally useful feature? That
> would have the advantage of being already enabled in the SPL (admittedly
> a sunxi specific problem).
>
> Any opinions?
I believe there's already a way to use LEDs for status during the boot
process using the CONFIG_LED_STATUS selection of config options. A
grep of the defconfig already shows a number of boards using this. I
wonder why the already existing infrastructure isn't useful.
Peter
> Cheers,
> Andre
>
> > ---
> > arch/arm/mach-sunxi/Kconfig | 5 +
> > board/sunxi/board.c | 4 ++--
> > configs/pinephone_defconfig | 1 +
> > 3 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 8421f3b685..2bfdf7738b 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1,5 +1,10 @@
> > if ARCH_SUNXI
> >
> > +config PINEPHONE_LEDS
> > + bool "Notify boot status via LEDs on PinePhone"
> > + ---help---
> > + LED boot notification.
> > +
> > config SPL_LDSCRIPT
> > default "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds" if !ARM64
> >
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index abd7e390b2..a117b89ba2 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -637,6 +638,12 @@ void sunxi_board_init(void)
> > {
> > int power_failed = 0;
> >
> > +#ifdef CONFIG_PINEPHONE_LEDS
> > + /* PD18:G PD19:R PD20:B */
> > + gpio_request(SUNXI_GPD(18), "led:green");
> > + gpio_direction_output(SUNXI_GPD(18), 1);
> > +#endif
> > +
> > #ifdef CONFIG_SY8106A_POWER
> > power_failed = sy8106a_set_vout1(CONFIG_SY8106A_VOUT1_VOLT);
> > #endif
> > diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
> > index ff5da42ce0..9de6ab2316 100644
> > --- a/configs/pinephone_defconfig
> > +++ b/configs/pinephone_defconfig
> > @@ -1,6 +21,7 @@
> > CONFIG_ARM=y
> > CONFIG_ARCH_SUNXI=y
> > CONFIG_SPL=y
> > +CONFIG_PINEPHONE_LEDS=y
> > CONFIG_MACH_SUN50I=y
> > CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> > CONFIG_DRAM_CLK=552
> >
>
Re: [PATCH] sunxi: support asymmetric dual rank DRAM on A64/R40
On 20/02/2021 12:14, Nicolas Boulenguez wrote:
Hi,
> From: Icenowy Zheng
>
> Previously we have known that R40 has a configuration register for its
> rank 1, which allows different configuration than rank 0. Reverse
> engineering of newest libdram of A64 from Allwinner shows that A64 has
> this register too. It's bit 0 (which enables dual rank in rank 0
> configuration register) means a dedicated rank size setup is used for
> rank 1.
>
> Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
> rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
> DRAM support necessary.
>
> Add this support. As we have gained knowledge of asymmetric dual rank,
> we can now allow R40 dual rank memory setup to work too.
Icenowy just sent a new version, together with another patch. I will
review her version, so you can drop this one here.
Cheers,
Andre
>
> Signed-off-by: Icenowy Zheng
> ---
> .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +-
> arch/arm/mach-sunxi/dram_sunxi_dw.c | 100 +-
> 2 files changed, 84 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index a5a7ebde44..e843c14202 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
> #define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
> /* The eight data lines (DQn) plus DM, DQS and DQSN */
> #define LINES_PER_BYTE_LANE (BITS_PER_BYTE + 3)
> -struct dram_para {
> +
> +struct rank_para {
> u16 page_size;
> - u8 bus_full_width;
> - u8 dual_rank;
> u8 row_bits;
> u8 bank_bits;
> +};
> +
> +struct dram_para {
> + u8 dual_rank;
> + u8 bus_full_width;
> + struct rank_para ranks[2];
> const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> const u8 ac_delays[31];
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 85e7a1874e..b679f92e70 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -346,18 +346,24 @@ static void mctl_set_cr(uint16_t socid, struct
> dram_para *para)
> #else
> #error Unsupported DRAM type!
> #endif
> -(para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> +(para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> (para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
> -MCTL_CR_PAGE_SIZE(para->page_size) |
> -MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
> +MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
>
> - if (socid == SOCID_R40) {
> - if (para->dual_rank)
> - panic("Dual rank memory not supported\n");
> + if (socid == SOCID_A64 || socid == SOCID_R40) {
> + writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
> MCTL_CR_FOUR_BANKS) |
> +MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
> +(para->dual_rank ? MCTL_CR_DUAL_RANK :
> MCTL_CR_SINGLE_RANK) |
> +MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
> +MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
> _com->cr_r1);
> + }
>
> + if (socid == SOCID_R40) {
> /* Mux pin to A15 address line for single rank memory. */
> - setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> + if (!para->dual_rank)
> + setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
> }
> }
>
> @@ -581,35 +587,63 @@ static int mctl_channel_init(uint16_t socid, struct
> dram_para *para)
> return 0;
> }
>
> -static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para
> *para)
> +/*
> + * Test if memory at offset offset matches memory at a certain base
> + */
> +static bool mctl_mem_matches_base(u32 offset, ulong base)
> +{
> + /* Try to write different values to RAM at two addresses */
> + writel(0, base);
> + writel(0xaa55aa55, base + offset);
> + dsb();
> + /* Check if the same value is actually observed when reading back */
> + return readl(base) ==
> +readl(base + offset);
> +}
> +
> +static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para
> *para, ulong base, struct rank_para *rank)
> {
> /* detect row address bits */
> - para->page_size = 512;
> - para->row_bits = 16;
> - para->bank_bits = 2;
> + rank->page_size = 512;
> + rank->row_bits = 16;
> + rank->bank_bits = 2;
> mctl_set_cr(socid, para);
>
> - for (para->row_bits = 11; para->row_bits <
Re: [PATCH 2/4] pinephone_defconfig: reduce boot delay
On 20/02/2021 12:14, Nicolas Boulenguez wrote: > From: Arnaud Ferraris > > On a cellular phone, the vast majority of users can be expected to > have no serial console connected and prefer a short boot. It's a bit tricky to break in with a delay of 0, but indeed most users won't care, so looks fine to me. But it's missing a Signed-off-by: line. Cheers, Andre > --- > configs/pinephone_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig > index 9967cddab9..9b51a7a100 100644 > --- a/configs/pinephone_defconfig > +++ b/configs/pinephone_defconfig > @@ -10,4 +10,5 @@ > CONFIG_PINEPHONE_DT_SELECTION=y > CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2" > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_BOOTDELAY=0 > CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2" >
[PATCH] avb: Fix error when partition not found
part_get_info_by_name will return -1 on error, and >0 on success.
Signed-off-by: schspa
Cc: Igor Opaniuk
---
common/avb_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/avb_verify.c b/common/avb_verify.c
index db10d0f21f..0520a71455 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -369,7 +369,7 @@ static struct mmc_part *get_partition(AvbOps *ops, const
char *partition)
}
ret = part_get_info_by_name(mmc_blk, partition, >info);
- if (!ret) {
+ if (ret < 0) {
printf("Can't find partition '%s'\n", partition);
goto err;
}
--
2.24.3 (Apple Git-128)
[PATCH 2/2] sunxi: enable dual rank memory on R40
Previously we do not have proper dual rank memory detection on R40
(because we omitted PIR_QSGATE, which does not work on R40 with our
configuration), and dual rank memory is just simply disabled as early
R40 boards available (Banana Pi M2 Ultra and Berry) have single rank
memory.
As a board with dual rank memory (Forlinx OKA40i-C) is now known to us,
we need to have a way to do memory rank detection to support that board.
Add some routine to detect memory rank by trying to access the memory
in rank 1 and check for error status of the memory controller, and then
enable dual rank memory on R40.
Similar routine can be used to detect half DQ width (which is also
detected by PIR_QSGATE on other SoCs), but it's left unimplemented
because there's no known R40 board with half DQ width now.
Signed-off-by: Icenowy Zheng
---
arch/arm/mach-sunxi/dram_sunxi_dw.c | 55 +
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index 2b9d631d49..b86ae7cdf3 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -414,11 +414,9 @@ static void mctl_set_cr(uint16_t socid, struct dram_para
*para)
}
if (socid == SOCID_R40) {
- if (para->dual_rank)
- panic("Dual rank memory not supported\n");
-
/* Mux pin to A15 address line for single rank memory. */
- setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
+ if (!para->dual_rank)
+ setbits_le32(_com->cr_r1, MCTL_CR_R1_MUX_A15);
}
}
@@ -702,8 +700,55 @@ static unsigned long mctl_calc_rank_size(struct rank_para
*rank)
return (1UL << (rank->row_bits + rank->bank_bits)) * rank->page_size;
}
+/*
+ * Because we cannot do mctl_phy_init(PIR_QSGATE) on R40 now (which leads
+ * to failure), it's needed to detect the rank count of R40 in another way.
+ *
+ * The code here is modelled after time_out_detect() in BSP, which tries to
+ * access the memory and check for error code.
+ *
+ * TODO: auto detect half DQ width here
+ */
+static void mctl_r40_detect_rank_count(struct dram_para *para)
+{
+ ulong rank1_base = (ulong) CONFIG_SYS_SDRAM_BASE +
+ mctl_calc_rank_size(>ranks[0]);
+ struct sunxi_mctl_ctl_reg * const mctl_ctl =
+ (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
+
+ /* Enable read time out */
+ setbits_le32(_ctl->pgcr[0], 0x1 << 25);
+
+ (void) readl((void *) rank1_base);
+ udelay(10);
+
+ if (readl(_ctl->pgsr[0]) & (0x1 << 13)) {
+ clrsetbits_le32(_ctl->dtcr, 0xf << 24, 0x1 << 24);
+ para->dual_rank = 0;
+ }
+
+ /* Reset PHY FIFO to clear it */
+ clrbits_le32(_ctl->pgcr[0], 0x1 << 26);
+ udelay(100);
+ setbits_le32(_ctl->pgcr[0], 0x1 << 26);
+
+ /* Clear error status */
+ setbits_le32(_ctl->pgcr[0], 0x1 << 24);
+
+ /* Clear time out flag */
+ clrbits_le32(_ctl->pgsr[0], 0x1 << 13);
+
+ /* Disable read time out */
+ clrbits_le32(_ctl->pgcr[0], 0x1 << 25);
+}
+
static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para *para)
{
+ if (socid == SOCID_R40) {
+ mctl_r40_detect_rank_count(para);
+ mctl_set_cr(socid, para);
+ }
+
mctl_auto_detect_dram_size_rank(socid, para,
(ulong)CONFIG_SYS_SDRAM_BASE, >ranks[0]);
if ((socid == SOCID_A64 || socid == SOCID_R40) && para->dual_rank) {
@@ -854,8 +899,6 @@ unsigned long sunxi_dram_init(void)
uint16_t socid = SOCID_H3;
#elif defined(CONFIG_MACH_SUN8I_R40)
uint16_t socid = SOCID_R40;
- /* Currently we cannot support R40 with dual rank memory */
- para.dual_rank = 0;
#elif defined(CONFIG_MACH_SUN8I_V3S)
uint16_t socid = SOCID_V3S;
#elif defined(CONFIG_MACH_SUN50I)
--
2.30.0
[PATCH 1/2] sunxi: support asymmetric dual rank DRAM on A64/R40
Previously we have known that R40 has a configuration register for its
rank 1, which allows different configuration than rank 0. Reverse
engineering of newest libdram of A64 from Allwinner shows that A64 has
this register too. It's bit 0 (which enables dual rank in rank 0
configuration register) means a dedicated rank size setup is used for
rank 1.
Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB
rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank
DRAM support necessary.
Add this support. The code could support both A64 and R40, but because
dual rank detection is broken on R40 now, we cannot really use it on R40
currently.
Signed-off-by: Icenowy Zheng
---
.../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 ++-
arch/arm/mach-sunxi/dram_sunxi_dw.c | 94 +++
2 files changed, 82 insertions(+), 23 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
index a5a7ebde44..e843c14202 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
@@ -215,12 +215,17 @@ struct sunxi_mctl_ctl_reg {
#define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
/* The eight data lines (DQn) plus DM, DQS and DQSN */
#define LINES_PER_BYTE_LANE(BITS_PER_BYTE + 3)
-struct dram_para {
+
+struct rank_para {
u16 page_size;
- u8 bus_full_width;
- u8 dual_rank;
u8 row_bits;
u8 bank_bits;
+};
+
+struct dram_para {
+ u8 dual_rank;
+ u8 bus_full_width;
+ struct rank_para ranks[2];
const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
const u8 ac_delays[31];
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index d0600011ff..2b9d631d49 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -399,11 +399,19 @@ static void mctl_set_cr(uint16_t socid, struct dram_para
*para)
#else
#error Unsupported DRAM type!
#endif
- (para->bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
+ (para->ranks[0].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
(para->dual_rank ? MCTL_CR_DUAL_RANK : MCTL_CR_SINGLE_RANK) |
- MCTL_CR_PAGE_SIZE(para->page_size) |
- MCTL_CR_ROW_BITS(para->row_bits), _com->cr);
+ MCTL_CR_PAGE_SIZE(para->ranks[0].page_size) |
+ MCTL_CR_ROW_BITS(para->ranks[0].row_bits), _com->cr);
+
+ if (para->dual_rank && (socid == SOCID_A64 || socid == SOCID_R40)) {
+ writel((para->ranks[1].bank_bits == 3 ? MCTL_CR_EIGHT_BANKS :
MCTL_CR_FOUR_BANKS) |
+ MCTL_CR_BUS_FULL_WIDTH(para->bus_full_width) |
+ MCTL_CR_DUAL_RANK |
+ MCTL_CR_PAGE_SIZE(para->ranks[1].page_size) |
+ MCTL_CR_ROW_BITS(para->ranks[1].row_bits),
_com->cr_r1);
+ }
if (socid == SOCID_R40) {
if (para->dual_rank)
@@ -646,35 +654,63 @@ static int mctl_channel_init(uint16_t socid, struct
dram_para *para)
return 0;
}
-static void mctl_auto_detect_dram_size(uint16_t socid, struct dram_para *para)
+/*
+ * Test if memory at offset offset matches memory at a certain base
+ */
+static bool mctl_mem_matches_base(u32 offset, ulong base)
+{
+ /* Try to write different values to RAM at two addresses */
+ writel(0, base);
+ writel(0xaa55aa55, base + offset);
+ dsb();
+ /* Check if the same value is actually observed when reading back */
+ return readl(base) ==
+ readl(base + offset);
+}
+
+static void mctl_auto_detect_dram_size_rank(uint16_t socid, struct dram_para
*para, ulong base, struct rank_para *rank)
{
/* detect row address bits */
- para->page_size = 512;
- para->row_bits = 16;
- para->bank_bits = 2;
+ rank->page_size = 512;
+ rank->row_bits = 16;
+ rank->bank_bits = 2;
mctl_set_cr(socid, para);
- for (para->row_bits = 11; para->row_bits < 16; para->row_bits++)
- if (mctl_mem_matches((1 << (para->row_bits + para->bank_bits))
* para->page_size))
+ for (rank->row_bits = 11; rank->row_bits < 16; rank->row_bits++)
+ if (mctl_mem_matches_base((1 << (rank->row_bits +
rank->bank_bits)) * rank->page_size, base))
break;
/* detect bank address bits */
- para->bank_bits = 3;
+ rank->bank_bits = 3;
mctl_set_cr(socid, para);
- for (para->bank_bits = 2; para->bank_bits < 3; para->bank_bits++)
- if (mctl_mem_matches((1 << para->bank_bits) * para->page_size))
+ for (rank->bank_bits = 2; rank->bank_bits < 3; rank->bank_bits++)
+
[PATCH 0/2] A64/R40 DRAM controller dual-rank-related changes
This patchset contains two patches. The first one enables asymmetric dual rank DRAM on A64. This is needed for 3GiB PinePhone, which has 2GiB rank 0 and 1GiB rank 1. This patch is already used by the firmware flashed to PinePhone by factory. The second one enables dual rank (and asymmetric dual rank, although not tested because of lack of real board) on R40. In order to support single rank and dual rank at the same time, a new rank detection code is implemented (because PIR_QSGATE-based one does not work on R40). The code enables some error report facility of the DRAM controller, and then tries to access rank 1 and then check for error. It's placed at 2nd patch because it depends on the function that calculates rank 0 size (and rank 1 base address) introduced in PATCH 1. Icenowy Zheng (2): sunxi: support asymmetric dual rank DRAM on A64/R40 sunxi: enable dual rank memory on R40 .../include/asm/arch-sunxi/dram_sunxi_dw.h| 11 +- arch/arm/mach-sunxi/dram_sunxi_dw.c | 149 +++--- 2 files changed, 131 insertions(+), 29 deletions(-) -- 2.30.0
Re: [PATCH] fdt_support.c: Allow late kernel cmdline modification
On 2/24/21 3:51 PM, Tom Rini wrote:
On Tue, Feb 23, 2021 at 08:33:36AM +0200, Niko Mauno wrote:
On 2/22/21 10:21 PM, Tom Rini wrote:
On Mon, Feb 22, 2021 at 07:18:51PM +, Niko Mauno wrote:
By declaring board-specific board_fdt_chosen_bootargs() the kernel
command line arguments can be adjusted before injecting to flat dt
chosen node.
Signed-off-by: Niko Mauno
---
common/fdt_support.c | 12 +++-
include/fdt_support.h | 10 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 08d540bfc8..4379507e30 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -269,6 +269,15 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong
initrd_end)
return 0;
}
+/**
+ * board_fdt_chosen_bootargs - boards may override this function to use
+ * alternative kernel command line arguments
+ */
+__weak char *board_fdt_chosen_bootargs(void)
+{
+ return env_get("bootargs");
+}
+
int fdt_chosen(void *fdt)
{
int nodeoffset;
@@ -286,7 +295,8 @@ int fdt_chosen(void *fdt)
if (nodeoffset < 0)
return nodeoffset;
- str = env_get("bootargs");
+ str = board_fdt_chosen_bootargs();
+
if (str) {
err = fdt_setprop(fdt, nodeoffset, "bootargs", str,
strlen(str) + 1);
What's this look like in practice? I'm very wary about changing "set
bootargs to what you pass to the kernel" logic that's been there for
forever and a constant of every platform. Thanks!
Hi Tom,
Effectively this change as such should introduce no changes to prevalent
"bootargs" logic when an overriding board_fdt_chosen_bootargs() is not
defined. Our motivation for proposing this change is that it provides us
with a means to introduce an entry point where we can append rootfs specific
dm-verity kernel command line metrics (such as described in
https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html)
by reading a property from within a kernel tier FIT image header, in order
to facilitate secure boot process all the way to root filesystem.
Right. But what does that logic look like, and why must it be done in
C? People have used dm-verity with U-Boot for ages, for example.
Our build time implementation injects rootfs specific dm-verity metrics
in FIT conf node property, effectively coupling the particular (kernel
tier) FIT image and particular rootfs image containing trailing verity
hash tree.
Below is a sample of such conf node - please note also that the two
'${rootdev}' placeholder strings in the injected property are replaced
with device node path to 'active' rootfs (in a dual bank scheme where
the 'active' rootfs bank is resolved runtime).
configurations {
default = "conf-c";
conf-c {
description = "Linux kernel and FDT blob";
kernel = "kernel";
fdt = "fdt-c";
vaisala,dm-verity-args = "dm-mod.create="dm-verity,
ec077aa7-78e5-43b7-9605-0d7f72fc65b9, , ro, 0 136220 verity 1
${rootdev} ${rootdev} 1024 4096 68110 17028 sha256
2dcd25db0f5b94603843316e5a16ca7717585802bf9a3fbced1443d7f83ec5f6
fec6bf67513d044bc704c63e37508b223d75867842ac828ba0147c6080578698 1
restart_on_corruption" root=/dev/dm-0 ro";
signature {
...
};
};
In the boot flow the FIT needs to be signature verified and is processed
only after boot command has been issued. Resorting to u-boot scripting
means it would require parsing FIT twice and do all verifications twice.
Using C avoids this redundancy.
The command line approach is supported since Linux kernel version 5.1
onwards (CONFIG_DM_INIT), and it avoids us the need to bundle a
"trampoline" initramfs with Linux kernel for issuing veritysetup and
mount commands. The bundling approach struck as more time consuming and
also more cumbersome on Yocto to build for various different image types
in same build, and introduces additional booting overhead on target.
Related to existing dm-verity support in U-Boot, I observed there is
Android Verified Boot 2.0 code which seemed to resort to appending the
kernel command line, which lead us to propose this change which would
allow us to perform the picking of the property from the FIT image,
processing it and appending it to our default "bootargs" in a board
specific function.
-Niko
Re: [PATCH] net: use the same alias stem for ethernet as linux
Hi Michael,
On Thu, Feb 25, 2021 at 12:51 PM Michael Walle wrote:
>
> Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
> the linux tree:
>
> $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 0
> $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 633
>
> In u-boot device trees both prefixes are used. Until recently the only
> user of the ethernet alias was the sandbox test device tree. This
> changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
> switches"). There, the MAC addresses are inherited based on the devices
> sequence IDs which is in turn given by the device tree.
>
> Before there are more users in u-boot and both worlds will differ even
> more, rename the alias prefix to "ethernet" to match the linux ones.
> Also adapt the test cases and rename any old aliases in the u-boot
> device trees.
>
> Cc: David Wu
> Signed-off-by: Michael Walle
Yes, this is the preferred node naming as per the Devicetree Specification:
Reviewed-by: Fabio Estevam
Re: [PATCH u-boot-dm + u-boot-spi v3 00/11] Support SPI NORs and OF partitions in `mtd list`
Hi Marek, Marek Behún wrote on Thu, 25 Feb 2021 15:13:25 +0100: > Hello, > > this is v3 of patchset that adds support for U-Boot to parse MTD > partitions from device-tree, and also improves support for SPI NOR > access via the `mtd` command. Very nice contribution, I didn't reviewed in detail every change but for what I saw: Reviewed-by: Miquel Raynal for the whole series. Thanks, Miquèl
Re: [PATCH v1] net: eth-uclass: Change uclass driver name to ethernet
On Thu, Feb 25, 2021 at 4:58 AM Michael Walle wrote:
> This is how it looks in the linux tree:
>
> $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 633
Yes, 'ethernet' is the recommended node name as per the Devicetree
Specification doc item "2.2.2 Generic Names Recommendation".
Re: [PATCH] board: sl28: add DSA support for variant 2
Am 2021-02-16 23:25, schrieb Michael Walle: Now that u-boot gained DSA support, and it is already enabled for the kontron_sl28 board, add the last missing piece and enable the corresponding devices it in the device tree. Signed-off-by: Michael Walle --- Please don't apply this patch. The ethernet aliases will change with the following patch: https://patchwork.ozlabs.org/project/uboot/list/?series=231056 I'll post a new version once the patch above is accepted/merged. -michael
Re: [PATCH u-boot-dm + u-boot-spi v3 05/11] mtd: spi-nor: allow registering multiple MTDs when DM is enabled
Hi Marek,
Marek Behún wrote on Thu, 25 Feb 2021 15:13:30
+0100:
> Currently when the SPI_FLASH_MTD config option is enabled, only one SPI
> can be registered as MTD at any time - it is the last one probed (since
> with old non-DM model only one SPI NOR could be probed at any time).
>
> When DM is enabled, allow for registering multiple SPI NORs as MTDs by
> utilizing the nor->mtd structure, which is filled in by spi_nor_scan
> anyway, instead of filling a separate struct mtd_info.
>
> Signed-off-by: Marek Behún
> Reviewed-by: Pali Rohár
> Cc: Jagan Teki
> Cc: Priyanka Jain
> Cc: Simon Glass
> Cc: Heiko Schocher
> Cc: Jagan Teki
> Cc: Patrick Delaunay
> Cc: Patrice CHOTARD
> Cc: Miquel Raynal
> ---
> drivers/mtd/spi/sf_internal.h | 4 ++--
> drivers/mtd/spi/sf_mtd.c | 18 +-
> drivers/mtd/spi/sf_probe.c| 6 --
> 3 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 9ceff0e7c1..865955124c 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -77,14 +77,14 @@ extern const struct flash_info spi_nor_ids[];
>
> #if CONFIG_IS_ENABLED(SPI_FLASH_MTD)
> int spi_flash_mtd_register(struct spi_flash *flash);
> -void spi_flash_mtd_unregister(void);
> +void spi_flash_mtd_unregister(struct spi_flash *flash);
> #else
> static inline int spi_flash_mtd_register(struct spi_flash *flash)
> {
> return 0;
> }
>
> -static inline void spi_flash_mtd_unregister(void)
> +static inline void spi_flash_mtd_unregister(struct spi_flash *flash)
> {
> }
> #endif
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index 987fac2501..94854fbfc4 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -10,6 +10,20 @@
> #include
> #include
>
> +#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
> +
> +int spi_flash_mtd_register(struct spi_flash *flash)
> +{
> + return add_mtd_device(>mtd);
> +}
> +
> +void spi_flash_mtd_unregister(struct spi_flash *flash)
> +{
> + del_mtd_device(>mtd);
> +}
> +
> +#else /* !CONFIG_IS_ENABLED(DM_SPI_FLASH) */
> +
I actually started something to overcome the same issue but left it
aside waiting for more inspiration. Your approach is neat, thanks for
pushing this!
Thanks,
Miquèl
[PATCH] net: use the same alias stem for ethernet as linux
Linux uses the prefix "ethernet" whereas u-boot uses "eth". This is from
the linux tree:
$ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
0
$ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
633
In u-boot device trees both prefixes are used. Until recently the only
user of the ethernet alias was the sandbox test device tree. This
changed with commit fc054d563bfb ("net: Introduce DSA class for Ethernet
switches"). There, the MAC addresses are inherited based on the devices
sequence IDs which is in turn given by the device tree.
Before there are more users in u-boot and both worlds will differ even
more, rename the alias prefix to "ethernet" to match the linux ones.
Also adapt the test cases and rename any old aliases in the u-boot
device trees.
Cc: David Wu
Signed-off-by: Michael Walle
---
Vladimir, I didn't do another patch to rename any ethernet aliases to
"eth". Though kontron boards contain "ethernetN" aliases, all in tree
variants don't make use of it. So there is nothing to be fixed.
arch/arm/dts/fsl-ls1028a-rdb.dts | 12 ++--
arch/sandbox/dts/test.dts| 10 +-
net/eth-uclass.c | 4 ++--
test/dm/ofnode.c | 2 +-
test/dm/test-fdt.c | 2 +-
5 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 3432fca352..82a8c0a0cd 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -15,12 +15,12 @@
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
aliases {
spi0 =
- eth0 =
- eth1 =
- eth2 = _felix_port0;
- eth3 = _felix_port1;
- eth4 = _felix_port2;
- eth5 = _felix_port3;
+ ethernet0 =
+ ethernet1 =
+ ethernet2 = _felix_port0;
+ ethernet3 = _felix_port1;
+ ethernet4 = _felix_port2;
+ ethernet5 = _felix_port3;
};
};
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 3ef3ba0b17..7a5d4aa71d 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -14,11 +14,11 @@
aliases {
console =
- eth0 = "/eth@10002000";
- eth2 = _0;
- eth3 = _3;
- eth4 = _eth0;
- eth5 = _5;
+ ethernet0 = "/eth@10002000";
+ ethernet2 = _0;
+ ethernet3 = _3;
+ ethernet4 = _eth0;
+ ethernet5 = _5;
gpio1 = _a;
gpio2 = _b;
gpio3 = _c;
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 0b4260dc5b..5146bd 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -605,8 +605,8 @@ static int eth_pre_remove(struct udevice *dev)
return 0;
}
-UCLASS_DRIVER(eth) = {
- .name = "eth",
+UCLASS_DRIVER(ethernet) = {
+ .name = "ethernet",
.id = UCLASS_ETH,
.post_bind = eth_post_bind,
.pre_unbind = eth_pre_unbind,
diff --git a/test/dm/ofnode.c b/test/dm/ofnode.c
index c539134296..3b708b63eb 100644
--- a/test/dm/ofnode.c
+++ b/test/dm/ofnode.c
@@ -213,7 +213,7 @@ static int dm_test_ofnode_read_aliases(struct
unit_test_state *uts)
ofnode node;
int size;
- node = ofnode_get_aliases_node("eth3");
+ node = ofnode_get_aliases_node("ethernet3");
ut_assert(ofnode_valid(node));
ut_asserteq_str("sbe5", ofnode_get_name(node));
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 6e83aeecd9..98972665f2 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -183,7 +183,7 @@ static int dm_test_alias_highest_id(struct unit_test_state
*uts)
{
int ret;
- ret = dev_read_alias_highest_id("eth");
+ ret = dev_read_alias_highest_id("ethernet");
ut_asserteq(5, ret);
ret = dev_read_alias_highest_id("gpio");
--
2.20.1
Re: [PATCH v1] net: eth-uclass: Change uclass driver name to ethernet
On Thu, Feb 25, 2021 at 08:57:37AM +0100, Michael Walle wrote:
> Hi Simon,
>
> Am 2021-02-25 03:31, schrieb Simon Glass:
> > On Wed, 24 Feb 2021 at 17:51, Michael Walle wrote:
> > > Am 2021-02-24 22:34, schrieb Vladimir Oltean:
> > > > On Wed, Feb 24, 2021 at 08:26:14PM +0100, Michael Walle wrote:
> > > >> > Wasn't the intention of David's patch, in fact, to have the new
> > > >> > uclass
> > > >> > name also match on "eth" aliases? If I'm correct, doesn't this mean
> > > >> > we'll have to replace the strcmp with an actual stem check?
> > > >>
> > > >> I guess it was intended the other way around, to rename the "ethN"
> > > >> aliases to "ethernetN". The latter are used way more in u-boot's
> > > >> device
> > > >> trees and linux' device trees just use ethernetN aliases, though I'm
> > > >> not sure where they are used (can't find any
> > > >> of_alias_get_id("ethernet")
> > > >> in linux). So this makes sense, no?
> > > >
> > > > Bad phrasing, I meant to ask if it was intended to _still_ match on
> > > > "eth" aliases.
> > > >
> > > > By the way, Linux drivers use a combination of "ethernet" and "eth":
> > > > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c#L43
> > > > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/broadcom/genet/bcmmii.c#L441
> > > > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c#L436
> > > >
> > > >> > I would not, under any circumstance, break compatibility with "eth"
> > > >> > alias names.
> > > >>
> > > >> Assuming that ethN is not used expect in u-boot device trees, how
> > > >> would
> > > >> we break backwards compatibility? Also it seems that the only users of
> > > >> the ethN aliases are the sandbox and u-boot's DSA.
> > > >
> > > > I took another look, I was under the impression that
> > > > fdtdec_set_ethernet_mac_address searches by "eth" in the /aliases node
> > > > of the linux device tree, but it searches by "ethernet". Fair then.
> > >
> > > fdtdec_set_ethernet_mac_address() seems to be "only" used by tegra?
> > >
> > > > Tough luck in that case for those who got it right, ugh I mean wrong,
> > > > by
> > > > actually looking at the code to see what it searches for?
> > > >
> > > > So yeah, this patch is waiting for someone to update the existing
> > > > aliases, and you seem to be a valid candidate. Although it's low
> > > > impact,
> > > > and it's all in-tree so it isn't breaking any interface, it is up to
> > > > you
> > > > if you value consistency more than correctness. I would probably fix
> > > > just the device tree you care about to use "eth" instead of "ethernet",
> > > > that seems the most localized solution to a concrete problem, then you
> > > > could convert the uclass name to "ethernet" and therefore fix all the
> > > > other users at once (and at the same time update the kontron boards).
> > > > The reason why I would leave that at the end is because when you 'fix'
> > > > stuff that isn't broken, nice surprises are always bound to happen, and
> > > > I don't think you want your board to still remain broken at the end of
> > > > some bug-canceling-another-bug-on-board-you-don't-have debugging
> > > > headaches.
> > >
> > > Fair enough. And I might fix em, the only user is the kontron board
> > > with the DSA support which wasn't picked up yet. But then yeah, I
> > > can't stand it that one sl28 variant has ethernetN aliases and the
> > > other as ethN aliases *g*
> > >
> > > Btw another user might be
> > > https://patchwork.ozlabs.org/project/uboot/patch/20210224163044.17017-1-mich...@walle.cc/
> > >
> > > Thats actually why I noticed the inconsistency and found this patch.
> >
> > If we have the choice, 'eth' is shorter = better.
>
> This is how it looks in the linux tree:
>
> $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 633
> $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 0
>
> This is in the u-boot tree:
> $ grep "ethernet[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 261
> $ grep "eth[0-9].*=.*&" arch/**/*dts{,i}|wc -l
> 13
So "ethernet" it is.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] usb: dfu: Migrate CONFIG_SYS_DFU_DATA_BUF_SIZE and CONFIG_SYS_DFU_MAX_FILE_SIZE to Kconfig
Hi Oleksandr, Thank you for pointing these errors out. I used the tools/moveconfig.py script and I think this is error in the script while moving the configs. As you suggested, I will check all direct settings of CONFIG_SYS_DFU_MAX_FILE_SIZE and remove if it was not set previously. Thanks, Aswath On 25/02/21 6:39 pm, Oleksandr Suvorov wrote: >Hi Aswath, > > The original behavior was the CONFIG_SYS_DFU_MAX_FILE_SIZE got its value > from the CONFIG_SYS_DFU_DATA_BUF_SIZE by default. > This patch introduces changing previous default values of > CONFIG_SYS_DFU_MAX_FILE_SIZE > for a set of boards, especially for colibri-imx6ull and colibri_vf. > > Is there a reason to do it? > > Moreover, for colibri-imx6ull this patch sets CONFIG_SYS_DFU_MAX_FILE_SIZE > to the value lesser, than CONFIG_SYS_DFU_DATA_BUF_SIZE. > Let's look into drivers/dfu/dfu.c: > if (dfu->max_buf_size && dfu_buf_size > dfu->max_buf_size) > dfu_buf_size = dfu->max_buf_size; > After this patch, the CONFIG_SYS_DFU_DATA_BUF_SIZE ends up equal to the lesser > CONFIG_SYS_DFU_MAX_FILE_SIZE, which is not good. > > Could you please check all direct settings of > CONFIG_SYS_DFU_MAX_FILE_SIZE in defconfigs, > keeping the assigns only for boards that had such an assignment before > and using the original values? > > On Tue, Feb 23, 2021 at 2:14 PM Aswath Govindraju wrote: >> >> Currently the config options CONFIG_SYS_DFU_DATA_BUF_SIZE and >> CONFIG_SYS_DFU_MAX_FILE_SIZE are being set in include/configs/.h >> files and also in _defconfig files without a Kconfig option. It >> is easier for users to set these configs in defconfig files than in config >> header files as they are a part of the source code. >> >> Add Kconfig symbols, and update the defconfigs by using tools/moveconfig.py >> script. >> >> Suggested-by: Pratyush Yadav >> Signed-off-by: Aswath Govindraju >> --- >> configs/am65x_evm_a53_defconfig | 2 ++ >> configs/am65x_evm_r5_usbdfu_defconfig | 2 ++ >> configs/am65x_hs_evm_a53_defconfig| 2 ++ >> configs/beaver_defconfig | 2 ++ >> configs/cei-tk1-som_defconfig | 2 ++ >> configs/colibri-imx6ull_defconfig | 2 ++ >> configs/colibri_vf_defconfig | 2 ++ >> configs/corvus_defconfig | 2 ++ >> configs/dalmore_defconfig | 2 ++ >> configs/dh_imx6_defconfig | 2 ++ >> configs/draco_defconfig | 2 ++ >> configs/e2220-1170_defconfig | 2 ++ >> configs/etamin_defconfig | 2 ++ >> configs/jetson-tk1_defconfig | 2 ++ >> configs/nyan-big_defconfig| 2 ++ >> configs/odroid-xu3_defconfig | 2 ++ >> configs/odroid_defconfig | 2 ++ >> configs/origen_defconfig | 2 ++ >> configs/p2371-_defconfig | 2 ++ >> configs/p2371-2180_defconfig | 2 ++ >> configs/p2571_defconfig | 2 ++ >> configs/p3450-_defconfig | 2 ++ >> configs/pico-dwarf-imx6ul_defconfig | 2 ++ >> configs/pico-hobbit-imx6ul_defconfig | 2 ++ >> configs/pico-imx6_defconfig | 2 ++ >> configs/pico-imx6ul_defconfig | 2 ++ >> configs/pico-pi-imx6ul_defconfig | 2 ++ >> configs/pxm2_defconfig| 2 ++ >> configs/rastaban_defconfig| 2 ++ >> configs/rpi_4_32b_defconfig | 2 ++ >> configs/rpi_4_defconfig | 2 ++ >> configs/rut_defconfig | 2 ++ >> configs/s5p_goni_defconfig| 2 ++ >> configs/s5pc210_universal_defconfig | 2 ++ >> configs/smartweb_defconfig| 2 ++ >> configs/socfpga_arria5_defconfig | 2 ++ >> configs/socfpga_cyclone5_defconfig| 2 ++ >> configs/socfpga_dbm_soc1_defconfig| 2 ++ >> configs/socfpga_de0_nano_soc_defconfig| 2 ++ >> configs/socfpga_de10_nano_defconfig | 2 ++ >> configs/socfpga_mcvevk_defconfig | 2 ++ >> configs/socfpga_sockit_defconfig | 2 ++ >> configs/socfpga_socrates_defconfig| 2 ++ >> configs/socfpga_vining_fpga_defconfig | 2 ++ >> configs/taurus_defconfig | 2 ++ >> configs/thuban_defconfig | 2 ++ >> configs/topic_miami_defconfig | 2 ++ >> configs/topic_miamilite_defconfig | 2 ++ >> configs/topic_miamiplus_defconfig | 2 ++ >> configs/trats2_defconfig | 2 ++ >> configs/trats_defconfig | 2 ++ >> configs/venice2_defconfig | 2 ++ >> configs/warp7_bl33_defconfig | 2 ++ >> configs/warp7_defconfig | 2 ++ >> configs/warp_defconfig| 2 ++ >> configs/xilinx_versal_virt_defconfig | 2 ++ >> configs/xilinx_zynq_virt_defconfig| 2 ++ >>
Re: [PATCH] tools: Remove #include
On Thu, Feb 25, 2021 at 02:05:54AM +0100, Pali Rohár wrote:
> On Wednesday 03 February 2021 12:10:13 Pali Rohár wrote:
> > On Monday 01 February 2021 16:20:18 Tom Rini wrote:
> > > On Wed, Jan 27, 2021 at 04:34:24PM +0100, Pali Rohár wrote:
> > >
> > > > Header file version.h includes also autogenerated file timestamp.h which
> > > > is recompiled on every time when SOURCE_DATE_EPOCH change.
> > > >
> > > > Tools do not use build time therefore they do not have to include
> > > > timestamp.h file.
> > > >
> > > > This change prevents recompiling tools every time when SOURCE_DATE_EPOCH
> > > > changes.
> > > >
> > > > Signed-off-by: Pali Rohár
> > > > ---
> > > > tools/dumpimage.c | 2 +-
> > > > tools/mkenvimage.c | 2 +-
> > > > tools/mkimage.c| 2 +-
> > > > 3 files changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/tools/dumpimage.c b/tools/dumpimage.c
> > > > index e5481435a7..54c2517c9e 100644
> > > > --- a/tools/dumpimage.c
> > > > +++ b/tools/dumpimage.c
> > > > @@ -7,7 +7,7 @@
> > > >
> > > > #include "dumpimage.h"
> > > > #include
> > > > -#include
> > > > +#include "generated/version_autogenerated.h"
> > > >
> > > > static void usage(void);
> > > >
> > >
> > > I don't know if I really like this approach. It also seems inconsistent
> > > as we have for example tools/fit-image.c that has content from
> > > generated/version_autogenerated.h but wasn't changed by this patch (nor
> > > the rest of the series).
> > >
> > > I think a bit more invasive approach is required here. I like the
> > > approach you used elsewhere, and as best I can see,
> > > the only place U_BOOT_VERSION_STRING, which is where we have the
> > > timestamp itself, is used is cmd/version.c (and defined in version.h).
> > > We should isolate the file that has the date such that it's only
> > > in one file and referenced in one file. This means probably removing
> > > the version_string global from arch/{powerpc,m68k} and dropping __weak
> > > from cmd/version.c and seeing what happens, as well.
> >
> > Hello! I have looked at dropping this weak property from version_string
> > but seem it is not so easy... powerpc platforms have following code:
> >
> > file arch/powerpc/cpu/mpc85xx/start.S:
> >
> >.globl _start
> > _start:
> >.long 0x27051956 /* U-BOOT Magic Number */
> >.globl version_string
> > version_string:
> >.ascii U_BOOT_VERSION_STRING, "\0"
> >
> > I do not know how it is used, but for me it looks like that on these
> > platforms is somehow null-term U-Boot version string important to be put
> > after some magic number at specific location (start of the binary?).
> >
> > How could we handle this situation? I do not have any of those powerpc
> > platforms and I do not know any details about them.
> >
> > If we cannot remove version string from this location, it is possible to
> > tweak linker to put at this location version string from compiled
> > cmd/version.o object file (at the time when building final u-boot
> > binary)?
> >
> > CCing powerpc maintainers.
>
> Hello! Do you have any details? Can be version_string at beginning
> dropped? Or it is required?
Should probably just go with trying linker games at this point, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: make O=directory parameter
On Thu, Feb 25, 2021 at 12:50:47PM +1100, Fred 1 wrote: > like in the linux kernel build > > make O=builds/arm > > builds the result to the specified output directory > > > is this supposed to work for uboot also ? > > doesn't seem to work for me, i've fetched older tar files and same problem > > maybe my environment? > > fedora32 > > 5.10.13-100.fc32.x86_64 > > GNU Make 4.2.1 > > the O= does mostly work on older uboot like from ~2010 though > > > thought i'd ask as debugging the make process is,well umm...horrible, > > (i've inserted some extra debug print codes in gnu make (it self no code to > be praised about! > > esp when so much open source depends on it!!) > > so atm, a bit of a rabbit holeshould I persist? Can you provide a sample failure? The last "make O=... fails" I saw was because they were passing ARCH= which isn't valid for U-Boot and specifically breaks if you're say building for an aarch64 platform as in the linux kernel you would do ARCH=arm64 but it's all "arm" here. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sunxi-common: support loading compressed kernel images on ARMv8
On 20/02/2021 12:14, Nicolas Boulenguez wrote: Hi, > From: Arnaud Ferraris This looks OK on the first glance, but is missing a commit message and a Signed-off-by: Cheers, Andre > > --- > include/configs/sunxi-common.h | 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 5b0bec0561..227284cd29 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -291,6 +291,8 @@ extern int soft_i2c_gpio_scl; > */ > #define BOOTM_SIZE __stringify(0xa00) > #define KERNEL_ADDR_R__stringify(SDRAM_OFFSET(008)) > +#define KERNEL_COMP_ADDR_R __stringify(SDRAM_OFFSET(400)) > +#define KERNEL_COMP_SIZE __stringify(0x400) > #define FDT_ADDR_R __stringify(SDRAM_OFFSET(FA0)) > #define SCRIPT_ADDR_R__stringify(SDRAM_OFFSET(FC0)) > #define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(FD0)) > @@ -332,6 +334,18 @@ extern int soft_i2c_gpio_scl; > "pxefile_addr_r=" PXEFILE_ADDR_R "\0" \ > "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" > > +#ifdef CONFIG_ARM64 > + > +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS \ > + "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \ > + "kernel_comp_size=" KERNEL_COMP_SIZE "\0" > + > +#else > + > +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS "" > + > +#endif > + > #define DFU_ALT_INFO_RAM \ > "dfu_alt_info_ram=" \ > "kernel ram " KERNEL_ADDR_R " 0x100;" \ > @@ -487,6 +501,7 @@ extern int soft_i2c_gpio_scl; > #define CONFIG_EXTRA_ENV_SETTINGS \ > CONSOLE_ENV_SETTINGS \ > MEM_LAYOUT_ENV_SETTINGS \ > + MEM_LAYOUT_ENV_EXTRA_SETTINGS \ > DFU_ALT_INFO_RAM \ > "fdtfile=" FDTFILE "\0" \ > "console=ttyS0,115200\0" \ >
