[PATCH] sunxi: Enable ethernet on newer Olimex OLinuXino-A20-Lime2-eMMC
Olimex OLinuXino LIME2 rev. H through L uses Micrel KSZ9031 PHY. This enables the Micrel PHY for A20-OLinuXino-Lime2-eMMC_defconfig. Signed-off-by: Jonas Smedegaard --- configs/A20-OLinuXino-Lime2-eMMC_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig b/configs/A20-OLinuXino-Lime2-eMMC_defconfig index b1a38d7a4d..f9f8f14151 100644 --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig @@ -19,6 +19,8 @@ CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_SCSI_AHCI=y CONFIG_DFU_RAM=y CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_PHY_REALTEK=y CONFIG_ETH_DESIGNWARE=y CONFIG_RGMII=y -- 2.28.0
Re: OpenBSI and U-Boot
On 8/9/20 12:23 AM, Heinrich Schuchardt wrote: > Am 9. August 2020 03:48:19 MESZ schrieb Sean Anderson : >> On 8/8/20 2:56 PM, Heinrich Schuchardt wrote: >>> On 8/8/20 7:22 PM, Sean Anderson wrote: On 8/8/20 12:17 PM, Heinrich Schuchardt wrote: > On 8/8/20 5:32 PM, Sean Anderson wrote: >> On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: >>> Hello Anup, >>> >>> I have looking at you OpenSBI code firmware/payloads/test_head.S. >> Here >> >> I think the real start is in firmware/fw_base.S. From there, >> secondary >> harts loop first in _wait_relocate_copy_done, and then in >> _wait_for_boot_hart, and then they execute the next stage via >> _start_warm and sbi_init. >> >>> like in U-Boot's common/spl/spl_opensbi.c you put all but one >> hart in to >>> an enless loop (hang). >> >> As far as I can tell, U-Boot has all harts execute the next stage >> when >> SMP is enabled. smp_call_function has all harts execute that >> function. > > U-Boot can only run on one hart. Are the other harts trapped in > secondary_hart_loop()? Yes. They also need handle_ipi, and by extension riscv_clear_ipi. >> This latter function currently requires that gd_t be valid, and may >> require other structures (e.g. a struct udevice) to be valid in the future. > How do we ensure that an UEFI payload does not overwrite this >> memory location? The most foolproof is probably to wait for all harts to start >> running UEFI code before making any modifications to ram outside the binary. >> One easy way to do this is to use amoadd instead of amoswap (e.g. a >> semaphor and not a mutex) in the standard boot lottery code. Whichever hart >> gets to it first then waits for the value of hart_lottery to reach the expected number of harts. >>> >>> There is no such requirement in the UEFI specification. >> >> Hm, well perhaps there should be a shim (or patch to U-Boot) which >> implements such a requirement. AFAIK (and please correct me if there is >> another option) there is no way to communicate between harts except by >> interrupt or shared memory. Interrupts may require substantial code to >> handle properly (which could be difficult to trace the requirements >> of). >> However, shared memory only requires one or two functions to be valid, >> plus the memory location itself. I think that solution has been mostly >> avoided by U-Boot since the rest of U-Boot is not designed for SMP, so >> there is not much infrastructure for atomics, etc. >> >>> The way to tell which memory should not be overwritten by the UEFI >>> payload is an entry in the memory map that the payload can read via >>> GetMemoryMap(). So we have to make reservations in the memory map, by >>> calling efi_add_memory_map() or by putting the code into the >>> __efi_runtime section. >>> >>> Do I understand it correctly that the secondary harts stay in the >>> unrelocated secondary_hart_loop()? In this case __efi_runtime would >> not >>> be the right section, because that memory section is also relocated >> and >>> only the relocated code is reserved in the memory map. >> >> The other harts get relocated in relocate_secondary_harts. >> >>> >>> We would also have to consider the location of secondary_hart_loop() >>> when defining the load address of any payload be it UEFI or not. >> >> Yes. I was looking at your patch to add load addresses [1], and I'm >> concerned that 8040 may be too high for the average kernel. Since >> U-Boot relocates to just below 8060, that leaves only 1.5M or so >> for >> the kernel to be loaded into. > > The patch has: > > kernel_addr_r=0x8004 > > You somehow missed the position of "4". Ah, so I did. That looks fine then. --Sean
[PATCH] git-mailrc: Update email address of Maxime Ripard
Update email address of Maxime Ripard in git-mailrc to match more
recently updated entry in MAINTAINERS.
commit 9bd9b2bcbee1 ("MAINTAINERS: Update my email address")
commit bf8f4c4400e3 ("MAINTAINERS: Update email address for Maxime Ripard")
Signed-off-by: Jonas Smedegaard
---
doc/git-mailrc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/git-mailrc b/doc/git-mailrc
index 31595a71c9..bbca3a9a37 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -36,7 +36,7 @@ alias marex Marek Vasut
alias mariosix Mario Six
alias masahiro Masahiro Yamada
alias mateuszMateusz Kulikowski
-alias maxime Maxime Ripard
+alias maxime Maxime Ripard
alias mbrugger Matthias Brugger
alias monstr Michal Simek
alias prom Minkyu Kang
--
2.28.0
[PATCH] serial: sh: Improve FIFO empty check on RX
If the SCIF is receiving data quickly enough, it may happen that the SCxSR_RDxF flag is cleared in sh_serial_getc_generic(), while the FIFO still contains data. If that happens, the serial_getc_check() reports no data in the FIFO as the flag is no longer set. Add one more check, if the SCxSR_RDxF is not set, read out the FIFO level and if there are still characters in the FIFO, permit reading them out. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- drivers/serial/serial_sh.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c index 13b179f03d..e27d256574 100644 --- a/drivers/serial/serial_sh.c +++ b/drivers/serial/serial_sh.c @@ -116,7 +116,10 @@ static int serial_getc_check(struct uart_port *port) handle_error(port); if (sci_in(port, SCLSR) & SCxSR_ORER(port)) handle_error(port); - return status & (SCIF_DR | SCxSR_RDxF(port)); + status &= (SCIF_DR | SCxSR_RDxF(port)); + if (status) + return status; + return scif_rxfill(port); } static int sh_serial_getc_generic(struct uart_port *port) -- 2.28.0
Re: OpenBSI and U-Boot
On 8/9/20 3:48 AM, Sean Anderson wrote: > On 8/8/20 2:56 PM, Heinrich Schuchardt wrote: >> On 8/8/20 7:22 PM, Sean Anderson wrote: >>> On 8/8/20 12:17 PM, Heinrich Schuchardt wrote: On 8/8/20 5:32 PM, Sean Anderson wrote: > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: >> Hello Anup, >> >> I have looking at you OpenSBI code firmware/payloads/test_head.S. Here > > I think the real start is in firmware/fw_base.S. From there, secondary > harts loop first in _wait_relocate_copy_done, and then in > _wait_for_boot_hart, and then they execute the next stage via > _start_warm and sbi_init. > >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart in to >> an enless loop (hang). > > As far as I can tell, U-Boot has all harts execute the next stage when > SMP is enabled. smp_call_function has all harts execute that function. U-Boot can only run on one hart. Are the other harts trapped in secondary_hart_loop()? >>> >>> Yes. They also need handle_ipi, and by extension riscv_clear_ipi. This >>> latter function currently requires that gd_t be valid, and may require >>> other structures (e.g. a struct udevice) to be valid in the future. >>> How do we ensure that an UEFI payload does not overwrite this memory location? >>> >>> The most foolproof is probably to wait for all harts to start running >>> UEFI code before making any modifications to ram outside the binary. One >>> easy way to do this is to use amoadd instead of amoswap (e.g. a semaphor >>> and not a mutex) in the standard boot lottery code. Whichever hart gets >>> to it first then waits for the value of hart_lottery to reach the >>> expected number of harts. >> >> There is no such requirement in the UEFI specification. > > Hm, well perhaps there should be a shim (or patch to U-Boot) which > implements such a requirement. AFAIK (and please correct me if there is > another option) there is no way to communicate between harts except by > interrupt or shared memory. Interrupts may require substantial code to > handle properly (which could be difficult to trace the requirements of). > However, shared memory only requires one or two functions to be valid, > plus the memory location itself. I think that solution has been mostly > avoided by U-Boot since the rest of U-Boot is not designed for SMP, so > there is not much infrastructure for atomics, etc. > >> The way to tell which memory should not be overwritten by the UEFI >> payload is an entry in the memory map that the payload can read via >> GetMemoryMap(). So we have to make reservations in the memory map, by >> calling efi_add_memory_map() or by putting the code into the >> __efi_runtime section. >> >> Do I understand it correctly that the secondary harts stay in the >> unrelocated secondary_hart_loop()? In this case __efi_runtime would not >> be the right section, because that memory section is also relocated and >> only the relocated code is reserved in the memory map. > > The other harts get relocated in relocate_secondary_harts. I added the following: secondary_hart_loop: + + lui a5,0x20040 + addia5,a5,0x48c + sllia5,a5,0x2 + /* a5 = 80101230 */ + auipc a4, 0 + sw a4,0(a5) + lw a4,8(a5) + addwa4,a4,1 + sw a4,8(a5) + With the mm.w command I can see what is stored at 0x80101230 - 0x8010123f. On the MaixDuino secondary_hart_loop() is executed 1 to 2 times. Shouldn't it be running all the time? relocate_secondary_harts() is called once. hang() is never executed. Any idea what the secondary hart is executing after relocate_secondary_harts()? Best regards Heinrich > >> >> We would also have to consider the location of secondary_hart_loop() >> when defining the load address of any payload be it UEFI or not. > > Yes. I was looking at your patch to add load addresses [1], and I'm > concerned that 8040 may be too high for the average kernel. Since > U-Boot relocates to just below 8060, that leaves only 1.5M or so for > the kernel to be loaded into. > > --Sean > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20200729154235.90766-4-xypron.g...@gmx.de/ >
[PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off"
This reverts commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355.
That commit is causing reboot loops on Nokia N900 and basically make U-Boot
on Nokia N900 unusable. Revert it for now until problem is solved.
After reverting that commit U-Boot on Nokia N900 is working again.
Signed-off-by: Pali Rohár
---
drivers/mmc/mmc.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d79cdef62e..48c1629a19 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2800,18 +2800,7 @@ int mmc_get_op_cond(struct mmc *mmc)
MMC_QUIRK_RETRY_APP_CMD;
#endif
- err = mmc_power_cycle(mmc);
- if (err) {
- /*
-* if power cycling is not supported, we should not try
-* to use the UHS modes, because we wouldn't be able to
-* recover from an error during the UHS initialization.
-*/
- pr_debug("Unable to do a full power cycle. Disabling the UHS
modes for safety\n");
- uhs_en = false;
- mmc->host_caps &= ~UHS_CAPS;
- err = mmc_power_on(mmc);
- }
+ err = mmc_power_on(mmc);
if (err)
return err;
--
2.20.1
MAIX: CONFIG_SYS_INIT_SP_ADDR
Hello Sean,
while trying to understand the handling of SMP I stumbled of this question:
Why did you define CONFIG_SYS_INIT_SP_ADDR as an odd number on the MAIX
in commit a7c81fc85326 ("riscv: Add Sipeed Maix support") while the
other RISC-V boards use an even number:
include/configs/sifive-fu540.h:29:
29 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)
include/configs/qemu-riscv.h:22:
22 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)
include/configs/sipeed-maix.h:13:
13 | #define CONFIG_SYS_INIT_SP_ADDR 0x803F
I always thought that RISC-V stack pointers must be 16 byte aligned:
Cf. https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
"In the standard RISC-V calling convention, the stack grows downward and
the stack pointer is always kept 16-byte aligned."
Best regards
Heinrich
Re: MAIX: CONFIG_SYS_INIT_SP_ADDR
On 8/9/20 12:14 PM, Heinrich Schuchardt wrote:
> Hello Sean,
>
> while trying to understand the handling of SMP I stumbled of this question:
>
> Why did you define CONFIG_SYS_INIT_SP_ADDR as an odd number on the MAIX
> in commit a7c81fc85326 ("riscv: Add Sipeed Maix support") while the
> other RISC-V boards use an even number:
>
> include/configs/sifive-fu540.h:29:
>29 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)
>
> include/configs/qemu-riscv.h:22:
>22 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + SZ_2M)
>
> include/configs/sipeed-maix.h:13:
>13 | #define CONFIG_SYS_INIT_SP_ADDR 0x803F
>
> I always thought that RISC-V stack pointers must be 16 byte aligned:
>
> Cf. https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
>
> "In the standard RISC-V calling convention, the stack grows downward and
> the stack pointer is always kept 16-byte aligned."
Because that is the top of (non-ai) ram. And it gets 16-byte aligned by
call_board_init_f anyway.
--Sean
Re: MAIX: CONFIG_SYS_INIT_SP_ADDR
Am 9. August 2020 18:35:45 MESZ schrieb Sean Anderson :
>On 8/9/20 12:14 PM, Heinrich Schuchardt wrote:
>> Hello Sean,
>>
>> while trying to understand the handling of SMP I stumbled of this
>question:
>>
>> Why did you define CONFIG_SYS_INIT_SP_ADDR as an odd number on the
>MAIX
>> in commit a7c81fc85326 ("riscv: Add Sipeed Maix support") while the
>> other RISC-V boards use an even number:
>>
>> include/configs/sifive-fu540.h:29:
>>29 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
>SZ_2M)
>>
>> include/configs/qemu-riscv.h:22:
>>22 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
>SZ_2M)
>>
>> include/configs/sipeed-maix.h:13:
>>13 | #define CONFIG_SYS_INIT_SP_ADDR 0x803F
>>
>> I always thought that RISC-V stack pointers must be 16 byte aligned:
>>
>> Cf. https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
>>
>> "In the standard RISC-V calling convention, the stack grows downward
>and
>> the stack pointer is always kept 16-byte aligned."
>
>Because that is the top of (non-ai) ram. And it gets 16-byte aligned by
>call_board_init_f anyway.
>
>--Sean
Top of RAM is the place to which we want to relocate U-Boot. But furthermore
this value minus a multiple of16KiB is also used for the stack lication of the
secondary CPU.
Shouldn't we better use the same definition as the other boards?
Re: MAIX: CONFIG_SYS_INIT_SP_ADDR
On 8/9/20 3:16 PM, Heinrich Schuchardt wrote:
> Am 9. August 2020 18:35:45 MESZ schrieb Sean Anderson :
>> On 8/9/20 12:14 PM, Heinrich Schuchardt wrote:
>>> Hello Sean,
>>>
>>> while trying to understand the handling of SMP I stumbled of this
>> question:
>>>
>>> Why did you define CONFIG_SYS_INIT_SP_ADDR as an odd number on the
>> MAIX
>>> in commit a7c81fc85326 ("riscv: Add Sipeed Maix support") while the
>>> other RISC-V boards use an even number:
>>>
>>> include/configs/sifive-fu540.h:29:
>>>29 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
>> SZ_2M)
>>>
>>> include/configs/qemu-riscv.h:22:
>>>22 | #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE +
>> SZ_2M)
>>>
>>> include/configs/sipeed-maix.h:13:
>>>13 | #define CONFIG_SYS_INIT_SP_ADDR 0x803F
>>>
>>> I always thought that RISC-V stack pointers must be 16 byte aligned:
>>>
>>> Cf. https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf
>>>
>>> "In the standard RISC-V calling convention, the stack grows downward
>> and
>>> the stack pointer is always kept 16-byte aligned."
>>
>> Because that is the top of (non-ai) ram. And it gets 16-byte aligned by
>> call_board_init_f anyway.
>>
>> --Sean
>
> Top of RAM is the place to which we want to relocate U-Boot. But furthermore
> this value minus a multiple of16KiB is also used for the stack lication of
> the secondary CPU.
>
> Shouldn't we better use the same definition as the other boards?
>
Sorry, I misspoke earlier, it's actually the top of ram minus 2M. If you
would like to use a different value, it's fine to me, but I don't think
it changes much.
--Sean
Re: OpenBSI and U-Boot
On Sat, Aug 8, 2020 at 7:59 AM Heinrich Schuchardt wrote: > > Hello Anup, > > I have looking at you OpenSBI code firmware/payloads/test_head.S. Here > like in U-Boot's common/spl/spl_opensbi.c you put all but one hart in to > an enless loop (hang). > > When Linux boots via UEFI it will wake up the extra harts after > ExitBootServices(). So I assume we should define function hang() in > lib/hang.c as __efi_runtime to avoid seeing it overwritten by the EFI > payload. > Proper Linux will wake up non-boot harts through SBI HSM APIs. Until then all other harts are held on OpenSBI in sbi_hsm_wait() [1]. [1] https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_hsm.c#L133 Here are the details on SBI HSM extension if you are interested. https://fosdem.org/2020/schedule/event/riscv_bootflow/ > @Ard: > Does Linux take care of the hanging harts and redirect them to its own > routine before SetVirtualAddressMap()? Otherwise anything could happen. > Linux doesn't need to as SetVirtualAddressMap is part of efistub which is only executed in the booting hart. > On the Kendryte K210 we don't have SPL. So we will not boot in the > sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply that > we have to implement the hart lottery at the entry point of main U-Boot > in this case? > Do you want OpenSBI->U-Boot or OpenSBI->U-Boot->Linux for kendryte ? Is this related to testing U-Boot EFI on Kendryte right ? > Best regards > > Heinrich -- Regards, Atish
Re: OpenBSI and U-Boot
On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt wrote: > > On 8/8/20 5:32 PM, Sean Anderson wrote: > > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: > >> Hello Anup, > >> > >> I have looking at you OpenSBI code firmware/payloads/test_head.S. Here > > > > I think the real start is in firmware/fw_base.S. From there, secondary > > harts loop first in _wait_relocate_copy_done, and then in > > _wait_for_boot_hart, and then they execute the next stage via > > _start_warm and sbi_init. > > > >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart in to > >> an enless loop (hang). > > > > As far as I can tell, U-Boot has all harts execute the next stage when > > SMP is enabled. smp_call_function has all harts execute that function. > > U-Boot can only run on one hart. Are the other harts trapped in > secondary_hart_loop()? How do we ensure that an UEFI payload does not > overwrite this memory location? > If you are booting Linux, U-Boot runs in S-mode and SMP is disabled. All memory regions containing OpenSBI code are reserved. Thus, U-Boot won't touch that. U-Boot also marks the run time services memory region as reserved as well. Thus, Linux kernel won't touch any of those memory regions either. > spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to > secondary_hart_relocate() fails. > > > > >> > >> When Linux boots via UEFI it will wake up the extra harts after > >> ExitBootServices(). So I assume we should define function hang() in > >> lib/hang.c as __efi_runtime to avoid seeing it overwritten by the EFI > >> payload. > >> > >> @Ard: > >> Does Linux take care of the hanging harts and redirect them to its own > >> routine before SetVirtualAddressMap()? Otherwise anything could happen. > >> > >> On the Kendryte K210 we don't have SPL. So we will not boot in the > >> sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply that > >> we have to implement the hart lottery at the entry point of main U-Boot > >> in this case? > > > > Isn't the hart lottery already implemented for U-Boot? E.g. around line > > 100 of arch/riscv/cpu/start.S. > > Thanks for the hint. > > > > > On another note, does Linux support S-Mode NOMMU? I was under the > > impression that NOMMU implied M-Mode (or the other way around). > > Have a look at > > https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf > > Best regards > > Heinrich -- Regards, Atish
Re: master u-boot broken for HiFive Unleashed
On Tue, Aug 4, 2020 at 7:33 AM Pragnesh Patel wrote:
>
> Hi Atish,
>
> >-Original Message-
> >From: U-Boot On Behalf Of Pragnesh Patel
> >Sent: 04 August 2020 19:55
> >To: Atish Patra ; Bin Meng ;
> >Rick Chen
> >Cc: Anup Patel ; Lukas Auer
> >; U-Boot Mailing List
> >Subject: RE: master u-boot broken for HiFive Unleashed
> >
> >Hi Atish,
> >
> >I tried to debug this and find something interesting.
> >
> >With FSBL,
> >I am able to reproduce the same and found that if I will disable
> >CONFIG_OF_BOARD_FIXUP and then print the bdinfo shows expected result.
> >
> >=> bdinfo
> >boot_params = 0x
> >DRAM bank = 0x
> >-> start= 0x8000
> >-> size = 0x0002
> >memstart= 0x
> >memsize = 0x
> >flashstart = 0x
> >flashsize = 0x
> >flashoffset = 0x
> >baudrate= 115200 bps
> >relocaddr = 0xfff83000
> >reloc off = 0x7fd83000
> >Build = 64-bit
> >current eth = ethernet@1009
> >ethaddr = (not set)
> >IP addr =
> >fdt_blob= 0xff75e680
> >new_fdt = 0xff75e680
> >fdt_size= 0x47a0
> >=>
> >
> >With CONFIG_OF_BOARD_FIXUP, following functions gets called
> >fix_fdt() ("common/board_f.c") -> board_fix_fdt()
> >("arch/riscv/lib/fdt_fixup.c")
> >and in this we will increase the fdt_blob size for PMP regions
> >
> >/*
> > * Extend the FDT by the following estimated size:
> > *
> > * Each PMP memory region entry occupies 64 bytes.
> > * With 16 PMP memory regions we need 64 * 16 = 1024 bytes.
> > */
> >err = fdt_open_into(dst, dst, fdt_totalsize(dst) + 1024);
> >
> >I suspect this will overwrite the global data (gd) and that creates the
> >problem.
> >
> >
> >Surprisingly With U-Boot SPL,
> >Latest U-Boot master branch works fine and shows expected results.
>
> With U-Boot SPL it works because in riscv_board_reserved_mem_fixup()
> ("arch/riscv/lib/fdt_fixup.c")
>
> riscv_board_reserved_mem_fixup() {
> /* avoid the copy if we are using the same device tree */
> if (src_fdt_addr == fdt)
> return 0;
>
> riscv_fdt_copy_resv_mem_node();
> }
>
> OpenSBI and U-Boot both are using the same device tree (U-Boot SPL sends
> U-Boot device tree address in a1 register to OpenSBI), so
> riscv_fdt_copy_resv_mem_node() never gets called.
>
>
> With FSBL, OpenSBI and U-Boot uses different device tree so
> riscv_board_reserved_mem_fixup() ("arch/riscv/lib/fdt_fixup.c"), so
> riscv_fdt_copy_resv_mem_node() getting called and tried to increase the
> fdt_blob size which will overwrite the global data (gd).
>
Thanks for root causing the issue. Apologies for not replying earlier.
>
>
> >
> >>-Original Message-
> >>From: Atish Patra
> >>Sent: 30 July 2020 03:13
> >>To: U-Boot Mailing List ; Bin Meng
> >>; Rick Chen
> >>Cc: Anup Patel ; Lukas Auer
> >>; Pragnesh Patel
> >>
> >>Subject: master u-boot broken for HiFive Unleashed
> >>
> >>[External Email] Do not click links or attachments unless you recognize
> >>the sender and know the content is safe
> >>
> >>Hi,
> >>The latest master (423e08cb7701 (origin/master, origin/HEAD) Merge
> >>branch
> >>'2020-07-28-misc-soc-improvements') seems to be broken for HiFive
> >Unleashed.
> >>
> >>It already has Bin's fix for unleashed.
> >>
> >>a0018fc8209c riscv: Make SiFive HiFive Unleashed board boot again
> >>
> >>dram start and size is corrupted for some reason. I have verified that
> >>it was initialized properly during DT parsing. However, it shows random
> >>values in the U- Boot console.
> >>
> >>=> bdinfo
> >>boot_params = 0x
> >>memstart= 0x
> >>memsize = 0x
> >>flashstart = 0x
> >>flashsize = 0x
> >>flashoffset = 0x
> >>baudrate= 115200 bps
> >>relocaddr = 0xfff84000
> >>reloc off = 0x7fd84000
> >>Build = 64-bit
> >>
> >>=> bdinfo
> >>boot_params = 0x9a26a361c16aa601
> >>DRAM bank = 0x
> >>-> start= 0x974515c3bda965ef
> >>-> size = 0x79b6f0fb37923036
> >>memstart= 0x574587c7f00570f9
> >>memsize = 0xCFD8C0F4D42668AB
> >>flashstart = 0x67f9fbb06586658b
> >>flashsize = 0xf91aed913c99b9e1
> >>flashoffset = 0x9ddbf00d69e870fa
> >>baudrate= 115200 bps
> >>
> >>v2020.07 seems to work fine. I couldn't bisect between those two as the
> >>number of commits didn't compile.
> >>
> >>--
> >>Regards,
> >>Atish
--
Regards,
Atish
Re: [PATCH] common/board_f: make sure to call fix_fdt() before reserve_fdt()
On Wed, Aug 5, 2020 at 2:01 AM Pragnesh Patel wrote:
>
> There may be a chance that board specific fix_fdt() will change the
> size of FDT blob so it's safe to call reserve_fdt() after fix_fdt()
> otherwise global data (gd) will overwrite with FDT blob values.
>
> Signed-off-by: Pragnesh Patel
> ---
> common/board_f.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 88ff0424a7..7ae01e9fff 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -956,6 +956,9 @@ static const init_fnc_t init_sequence_f[] = {
> * - board info struct
> */
> setup_dest_addr,
> +#ifdef CONFIG_OF_BOARD_FIXUP
> + fix_fdt,
> +#endif
> #ifdef CONFIG_PRAM
> reserve_pram,
> #endif
> @@ -984,9 +987,6 @@ static const init_fnc_t init_sequence_f[] = {
> setup_board_part2,
> #endif
> display_new_sp,
> -#ifdef CONFIG_OF_BOARD_FIXUP
> - fix_fdt,
> -#endif
> INIT_FUNC_WATCHDOG_RESET
> reloc_fdt,
> reloc_bootstage,
> --
> 2.17.1
>
Reviewed-by: Atish Patra
--
Regards,
Atish
Re: OpenBSI and U-Boot
Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra : >On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt >wrote: >> >> On 8/8/20 5:32 PM, Sean Anderson wrote: >> > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: >> >> Hello Anup, >> >> >> >> I have looking at you OpenSBI code firmware/payloads/test_head.S. >Here >> > >> > I think the real start is in firmware/fw_base.S. From there, >secondary >> > harts loop first in _wait_relocate_copy_done, and then in >> > _wait_for_boot_hart, and then they execute the next stage via >> > _start_warm and sbi_init. >> > >> >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart >in to >> >> an enless loop (hang). >> > >> > As far as I can tell, U-Boot has all harts execute the next stage >when >> > SMP is enabled. smp_call_function has all harts execute that >function. >> >> U-Boot can only run on one hart. Are the other harts trapped in >> secondary_hart_loop()? How do we ensure that an UEFI payload does not >> overwrite this memory location? >> > >If you are booting Linux, U-Boot runs in S-mode and SMP is disabled. Would that also hold true on the Kendryte K210? For all what can see the secondary hart enters U-Boot and is only restrained by WFI and otherwise kept in an endless loop. I am wondering if that endless loop needs to be marked as reserved memory for Linux. >All memory regions containing OpenSBI code are reserved. Thus, U-Boot >won't touch that. >U-Boot also marks the run time services memory region as reserved as >well. >Thus, Linux kernel won't touch any of those memory regions either. > >> spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to >> secondary_hart_relocate() fails. >> >> > >> >> >> >> When Linux boots via UEFI it will wake up the extra harts after >> >> ExitBootServices(). So I assume we should define function hang() >in >> >> lib/hang.c as __efi_runtime to avoid seeing it overwritten by the >EFI >> >> payload. >> >> >> >> @Ard: >> >> Does Linux take care of the hanging harts and redirect them to its >own >> >> routine before SetVirtualAddressMap()? Otherwise anything could >happen. >> >> >> >> On the Kendryte K210 we don't have SPL. So we will not boot in the >> >> sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply >that >> >> we have to implement the hart lottery at the entry point of main >U-Boot >> >> in this case? >> > >> > Isn't the hart lottery already implemented for U-Boot? E.g. around >line >> > 100 of arch/riscv/cpu/start.S. >> >> Thanks for the hint. >> >> > >> > On another note, does Linux support S-Mode NOMMU? I was under the >> > impression that NOMMU implied M-Mode (or the other way around). >> >> Have a look at >> >> >https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf >> >> Best regards >> >> Heinrich
Re: OpenBSI and U-Boot
On Sun, Aug 9, 2020 at 1:28 PM Heinrich Schuchardt wrote: > > Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra : > >On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt > >wrote: > >> > >> On 8/8/20 5:32 PM, Sean Anderson wrote: > >> > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: > >> >> Hello Anup, > >> >> > >> >> I have looking at you OpenSBI code firmware/payloads/test_head.S. > >Here > >> > > >> > I think the real start is in firmware/fw_base.S. From there, > >secondary > >> > harts loop first in _wait_relocate_copy_done, and then in > >> > _wait_for_boot_hart, and then they execute the next stage via > >> > _start_warm and sbi_init. > >> > > >> >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart > >in to > >> >> an enless loop (hang). > >> > > >> > As far as I can tell, U-Boot has all harts execute the next stage > >when > >> > SMP is enabled. smp_call_function has all harts execute that > >function. > >> > >> U-Boot can only run on one hart. Are the other harts trapped in > >> secondary_hart_loop()? How do we ensure that an UEFI payload does not > >> overwrite this memory location? > >> > > > >If you are booting Linux, U-Boot runs in S-mode and SMP is disabled. > > Would that also hold true on the Kendryte K210? For all what can see the > secondary hart enters U-Boot and is only restrained by WFI and otherwise kept > in an endless loop. > > I am wondering if that endless loop needs to be marked as reserved memory for > Linux. > Is U-boot running in S-mode or M-mode ? Are you trying to boot Linux on a Kendryte board using OpenSBI ->U-Boot -> Linux? (all in M-mode ?) > >All memory regions containing OpenSBI code are reserved. Thus, U-Boot > >won't touch that. > >U-Boot also marks the run time services memory region as reserved as > >well. > >Thus, Linux kernel won't touch any of those memory regions either. > > > >> spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to > >> secondary_hart_relocate() fails. > >> > >> > > >> >> > >> >> When Linux boots via UEFI it will wake up the extra harts after > >> >> ExitBootServices(). So I assume we should define function hang() > >in > >> >> lib/hang.c as __efi_runtime to avoid seeing it overwritten by the > >EFI > >> >> payload. > >> >> > >> >> @Ard: > >> >> Does Linux take care of the hanging harts and redirect them to its > >own > >> >> routine before SetVirtualAddressMap()? Otherwise anything could > >happen. > >> >> > >> >> On the Kendryte K210 we don't have SPL. So we will not boot in the > >> >> sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply > >that > >> >> we have to implement the hart lottery at the entry point of main > >U-Boot > >> >> in this case? > >> > > >> > Isn't the hart lottery already implemented for U-Boot? E.g. around > >line > >> > 100 of arch/riscv/cpu/start.S. > >> > >> Thanks for the hint. > >> > >> > > >> > On another note, does Linux support S-Mode NOMMU? I was under the > >> > impression that NOMMU implied M-Mode (or the other way around). > >> > >> Have a look at > >> > >> > >https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf > >> > >> Best regards > >> > >> Heinrich > -- Regards, Atish
RE: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off"
Faiz, Jean
> Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched
> on and off"
Got time to take a look?
Thanks,
Peng.
>
> This reverts commit 04a2ea248f58b3b6216d0cd0a6b8698df8b14355.
>
> That commit is causing reboot loops on Nokia N900 and basically make
> U-Boot on Nokia N900 unusable. Revert it for now until problem is solved.
>
> After reverting that commit U-Boot on Nokia N900 is working again.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/mmc/mmc.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> d79cdef62e..48c1629a19 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2800,18 +2800,7 @@ int mmc_get_op_cond(struct mmc *mmc)
> MMC_QUIRK_RETRY_APP_CMD;
> #endif
>
> - err = mmc_power_cycle(mmc);
> - if (err) {
> - /*
> - * if power cycling is not supported, we should not try
> - * to use the UHS modes, because we wouldn't be able to
> - * recover from an error during the UHS initialization.
> - */
> - pr_debug("Unable to do a full power cycle. Disabling the UHS
> modes for safety\n");
> - uhs_en = false;
> - mmc->host_caps &= ~UHS_CAPS;
> - err = mmc_power_on(mmc);
> - }
> + err = mmc_power_on(mmc);
> if (err)
> return err;
>
> --
> 2.20.1
[PATCH v4 00/10] Add support MediaTek USB3 DRD driver
These patches introduce the MediaTek USB3 Dual-Role Controller driver. The driver can be configured as Peripheral only and Host only(xHCI) modes, and it's ported from Linux Kernel 5.8-rc1 v4 changes: 1. [4/10], [9/10] and [10/10] are new patches 2. add a glue driver 3. add host driver and rebuild host flow 4. support force_vbus mode for device 5. update bindings to support glue driver v3 changes: 1. add patch [5/7] 2. add udc_set_speed() 3. simplify some code flow v2 changes: 1. simplify QMU operations Chunfeng Yun (10): dt-binding: usb: add bindings for some common properties dt-bindings: usb: mtu3: add bindings for MediaTek USB3 DRD usb: add USB_SPEED_SUPER_PLUS usb: common: add define of usb_speed_string() usb: add MediaTek USB3 DRD driver usb: gadget: Add bcdDevice for the MTU3 USB Gadget Controller arm: dts: mt8512: add usb related nodes configs: mt8512: enable fastboot configs: mt8512: add USB host related configs MAINTAINERS: add mtu3 driver to ARM MEDIATEK MAINTAINERS| 1 + Makefile | 1 + arch/arm/dts/mt8512-bm1-emmc.dts | 34 + arch/arm/dts/mt8512.dtsi | 49 +- configs/mt8512_bm1_emmc_defconfig | 26 + doc/device-tree-bindings/usb/generic.txt | 31 + doc/device-tree-bindings/usb/mediatek,mtu3.txt | 79 +++ drivers/usb/Kconfig| 2 + drivers/usb/common/common.c| 8 + drivers/usb/gadget/gadget_chips.h | 8 + drivers/usb/mtu3/Kconfig | 45 ++ drivers/usb/mtu3/Makefile | 11 + drivers/usb/mtu3/mtu3.h| 423 +++ drivers/usb/mtu3/mtu3_core.c | 838 ++ drivers/usb/mtu3/mtu3_dr.h | 52 ++ drivers/usb/mtu3/mtu3_gadget.c | 686 ++ drivers/usb/mtu3/mtu3_gadget_ep0.c | 933 + drivers/usb/mtu3/mtu3_host.c | 141 drivers/usb/mtu3/mtu3_hw_regs.h| 515 ++ drivers/usb/mtu3/mtu3_plat.c | 367 ++ drivers/usb/mtu3/mtu3_qmu.c| 504 + drivers/usb/mtu3/mtu3_qmu.h| 37 + include/linux/usb/ch9.h| 5 +- 23 files changed, 4791 insertions(+), 5 deletions(-) create mode 100644 doc/device-tree-bindings/usb/generic.txt create mode 100644 doc/device-tree-bindings/usb/mediatek,mtu3.txt create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h -- 1.9.1
[PATCH v4 06/10] usb: gadget: Add bcdDevice for the MTU3 USB Gadget Controller
Add an entry in usb_gadget_controller_number() for the MTU3
gadget controller. It is used to bind the USB Ethernet driver.
Signed-off-by: Chunfeng Yun
---
v4: no changes
v3: new patch
---
drivers/usb/gadget/gadget_chips.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index 91b0285..2dc4c47 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -155,6 +155,12 @@
#define gadget_is_cdns3(g)0
#endif
+#ifdef CONFIG_USB_MTU3_GADGET
+#define gadget_is_mtu3(g)(!strcmp("mtu3-gadget", (g)->name))
+#else
+#define gadget_is_mtu3(g)0
+#endif
+
/**
* usb_gadget_controller_number - support bcdDevice id convention
* @gadget: the controller being driven
@@ -216,5 +222,7 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x23;
else if (gadget_is_cdns3(gadget))
return 0x24;
+ else if (gadget_is_mtu3(gadget))
+ return 0x25;
return -ENOENT;
}
--
1.9.1
[PATCH v4 01/10] dt-binding: usb: add bindings for some common properties
Add bindings for common properties, include maximum-speed,
dr_mode and phy_type
Signed-off-by: Chunfeng Yun
---
v2~v4: no changes
---
doc/device-tree-bindings/usb/generic.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 doc/device-tree-bindings/usb/generic.txt
diff --git a/doc/device-tree-bindings/usb/generic.txt
b/doc/device-tree-bindings/usb/generic.txt
new file mode 100644
index 000..a02a198
--- /dev/null
+++ b/doc/device-tree-bindings/usb/generic.txt
@@ -0,0 +1,31 @@
+Generic USB Properties
+
+Optional properties:
+ - maximum-speed: tells USB controllers we want to work up to a certain
+ speed. Valid arguments are "super-speed-plus",
+ "super-speed", "high-speed", "full-speed" and
+ "low-speed". In case this isn't passed via DT, USB
+ controllers should default to their maximum HW
+ capability.
+ - dr_mode: tells Dual-Role USB controllers that we want to work on a
+ particular mode. Valid arguments are "host",
+ "peripheral" and "otg". In case this attribute isn't
+ passed via DT, USB DRD controllers should default to
+ OTG.
+ - phy_type: tells USB controllers that we want to configure the core to
support
+ a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
+ selected. Valid arguments are "utmi" and "utmi_wide".
+ In case this isn't passed via DT, USB controllers should
+ default to HW capability.
+
+This is an attribute to a USB controller such as:
+
+dwc3@4a03 {
+ compatible = "synopsys,dwc3";
+ reg = <0x4a03 0xcfff>;
+ interrupts = <0 92 4>
+ usb-phy = <&usb2_phy>, <&usb3,phy>;
+ maximum-speed = "super-speed";
+ dr_mode = "otg";
+ phy_type = "utmi_wide";
+};
--
1.9.1
[PATCH v4 08/10] configs: mt8512: enable fastboot
Enable fastboot to support download image from usb, also enable usb related drivers, such as usb phy etc. Signed-off-by: Chunfeng Yun --- v2~v4: no changes --- configs/mt8512_bm1_emmc_defconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/configs/mt8512_bm1_emmc_defconfig b/configs/mt8512_bm1_emmc_defconfig index 10a2083..4b94bff 100644 --- a/configs/mt8512_bm1_emmc_defconfig +++ b/configs/mt8512_bm1_emmc_defconfig @@ -9,6 +9,7 @@ CONFIG_TARGET_MT8512=y CONFIG_NR_DRAM_BANKS=1 CONFIG_DEFAULT_DEVICE_TREE="mt8512-bm1-emmc" CONFIG_FIT=y +CONFIG_EFI_PARTITION=y CONFIG_FIT_SIGNATURE=y CONFIG_DEFAULT_FDT_FILE="mt8512-bm1-emmc.dtb" CONFIG_SYS_PROMPT="MT8512> " @@ -26,6 +27,15 @@ CONFIG_PINCONF=y CONFIG_PINCTRL_MT8512=y CONFIG_RAM=y CONFIG_BAUDRATE=921600 +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0x5600 +CONFIG_FASTBOOT_BUF_SIZE=0x1e0 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 +CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT=y +CONFIG_PHY=y +CONFIG_PHY_MTK_TPHY=y +CONFIG_DM_REGULATOR=y CONFIG_DM_SERIAL=y CONFIG_MTK_SERIAL=y CONFIG_TIMER=y @@ -33,3 +43,12 @@ CONFIG_MTK_TIMER=y CONFIG_WDT=y CONFIG_WDT_MTK=y CONFIG_LZO=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_MTU3=y +CONFIG_USB_MTU3_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="MediaTek" +CONFIG_USB_GADGET_VENDOR_NUM=0x0e8d +CONFIG_USB_GADGET_PRODUCT_NUM=0x201c -- 1.9.1
[PATCH v4 09/10] configs: mt8512: add USB host related configs
Add USB, FAT commands, and fixed regulator, mass storage drivers. Due to device mode is enabled by default, comment out the host mode config here. Signed-off-by: Chunfeng Yun --- v4: new patch --- configs/mt8512_bm1_emmc_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configs/mt8512_bm1_emmc_defconfig b/configs/mt8512_bm1_emmc_defconfig index 4b94bff..1ed3dd2 100644 --- a/configs/mt8512_bm1_emmc_defconfig +++ b/configs/mt8512_bm1_emmc_defconfig @@ -15,6 +15,10 @@ CONFIG_DEFAULT_FDT_FILE="mt8512-bm1-emmc.dtb" CONFIG_SYS_PROMPT="MT8512> " CONFIG_CMD_BOOTMENU=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +# CONFIG_DOS_PARTITION is not set CONFIG_ENV_OVERWRITE=y CONFIG_REGMAP=y CONFIG_SYSCON=y @@ -36,6 +40,7 @@ CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT=y CONFIG_PHY=y CONFIG_PHY_MTK_TPHY=y CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_SERIAL=y CONFIG_MTK_SERIAL=y CONFIG_TIMER=y @@ -48,6 +53,8 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_MTU3=y CONFIG_USB_MTU3_GADGET=y +#CONFIG_USB_MTU3_HOST=y +CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="MediaTek" CONFIG_USB_GADGET_VENDOR_NUM=0x0e8d -- 1.9.1
[PATCH v4 02/10] dt-bindings: usb: mtu3: add bindings for MediaTek USB3 DRD
Add dt-binding for MediaTek USB3 DRD Driver
Signed-off-by: Chunfeng Yun
---
v4:
Add support host mode, introduce some new properties and subnode
v2~v3: no changes
---
doc/device-tree-bindings/usb/mediatek,mtu3.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 doc/device-tree-bindings/usb/mediatek,mtu3.txt
diff --git a/doc/device-tree-bindings/usb/mediatek,mtu3.txt
b/doc/device-tree-bindings/usb/mediatek,mtu3.txt
new file mode 100644
index 000..ab877bf
--- /dev/null
+++ b/doc/device-tree-bindings/usb/mediatek,mtu3.txt
@@ -0,0 +1,79 @@
+The device node for Mediatek USB3 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
+ soc-model is the name of SoC, such as mt8512 etc,
+ when using "mediatek,mtu3" compatible string, you need SoC specific
+ ones in addition, one of:
+ - "mediatek,mt8512-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be
+ - "ippc" : IP Port Control
+ - power-domains : a phandle to USB power domain node to control USB's MTCMOS
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller,
+ the following clocks are optional:
+ "ref_ck", "mcu_ck", "dma_ck" and "xhci_ck";
+ - phys : list of all the USB PHYs on this HCD
+ - #address-cells, #size-cells : used for sub-nodes with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+
+Optional properties:
+ - vusb33-supply : regulator of USB AVDD3.3v
+ - vbus-supply : regulator of VBUS 5v, needed when supports host mode.
+
+Sub-nodes:
+Required properties:
+ - compatible : should be "mediatek,ssusb"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be
+ - "mac" : SSUSB MAC, include xHCI and device
+ - interrupts : interrupt used by xHCI or device
+ - dr_mode : should be one of "host" or "peripheral",
+ see : usb/generic.txt
+
+Optional properties:
+ - pinctrl-names : a pinctrl state named "default" is optional
+ - pinctrl-0 : pin control group
+ See: pinctrl/pinctrl-bindings.txt
+
+ - device mode:
+ - maximum-speed : valid arguments are "full-speed", "high-speed",
+ "super-speed" and "super-speed-plus",
+ see: usb/generic.txt
+ - mediatek,force-vbus : force vbus as valid by SW
+
+ - host mode (dr_mode is "host"):
+ - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
+ bit1 for u3port1, ... etc;
+
+Example:
+usb3: usb@11213e00 {
+ compatible = "mediatek,mt8512-mtu3", "mediatek,mtu3";
+ reg = <0x11213e00 0x0100>;
+ reg-names = "ippc";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u2port1 PHY_TYPE_USB2>;
+ power-domains = <&scpsys MT8512_POWER_DOMAIN_USB>;
+ clocks = <&infracfg CLK_INFRA_USB_SYS>,
+<&topckgen CLK_TOP_SSUSB_TOP_CK_EN>,
+<&infracfg CLK_INFRA_ICUSB>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck";
+ vusb33-supply = ;
+ vbus-supply = <&usb_p0_vbus>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ ssusb: usb@1121 {
+ compatible = "mediatek,ssusb";
+ reg = <0x1121 0x3e00>;
+ interrupts = ;
+ reg-names = "mac";
+ dr_mode = "peripheral";
+ maximum-speed = "high-speed";
+ status = "disabled";
+ };
+};
--
1.9.1
[PATCH v4 07/10] arm: dts: mt8512: add usb related nodes
Add usb, usb phy, and fixed regulators nodes
Signed-off-by: Chunfeng Yun
---
v4: add host related properties, add subnode.
v3: remove unused property mediatek,discth
v2: no changes
arch/arm/dts/mt8512-bm1-emmc.dts | 34
arch/arm/dts/mt8512.dtsi | 49 +++-
2 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/mt8512-bm1-emmc.dts b/arch/arm/dts/mt8512-bm1-emmc.dts
index 296ed93..12511b5 100644
--- a/arch/arm/dts/mt8512-bm1-emmc.dts
+++ b/arch/arm/dts/mt8512-bm1-emmc.dts
@@ -43,6 +43,25 @@
regulator-boot-on;
regulator-always-on;
};
+
+ usb_p0_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "p0_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio 27 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usb_p1_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "p1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio 32 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
};
&mmc0 {
@@ -95,6 +114,21 @@
};
};
+&ssusb {
+ dr_mode = "peripheral";
+ maximum-speed = "high-speed";
+ status = "okay";
+};
+
+&usb3 {
+ vbus-supply = <&usb_p0_vbus>;
+ status = "okay";
+};
+
+&u3phy {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins>;
diff --git a/arch/arm/dts/mt8512.dtsi b/arch/arm/dts/mt8512.dtsi
index 01a02a7..bdb84f8 100644
--- a/arch/arm/dts/mt8512.dtsi
+++ b/arch/arm/dts/mt8512.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8512";
@@ -100,6 +101,52 @@
status = "disabled";
};
+ usb3: usb@11213e00 {
+ compatible = "mediatek,mt8512-mtu3", "mediatek,mtu3";
+ reg = <0x11213e00 0x0100>;
+ reg-names = "ippc";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u2port1 PHY_TYPE_USB2>;
+ clocks = <&infracfg CLK_INFRA_USB_SYS>,
+<&topckgen CLK_TOP_SSUSB_TOP_CK_EN>,
+<&infracfg CLK_INFRA_ICUSB>;
+ clock-names = "sys_ck", "ref_ck", "mcu_ck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ ssusb: usb@1121 {
+ compatible = "mediatek,ssusb";
+ reg = <0x1121 0x3e00>;
+ interrupts = ;
+ reg-names = "mac";
+ status = "disabled";
+ };
+ };
+
+ u3phy: usb-phy@11cc {
+ compatible = "mediatek,mt8512-tphy",
+"mediatek,generic-tphy-v2";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ u2port0: usb-phy@11cc {
+ reg = <0x11cc 0x400>;
+ clocks = <&topckgen CLK_TOP_USB20_48M_EN>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: usb-phy@11c4 {
+ reg = <0x11c4 0x400>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
mmc0: mmc@1123 {
compatible = "mediatek,mt8512-mmc";
reg = <0x1123 0x1000>,
@@ -112,4 +159,4 @@
status = "disabled";
};
-};
\ No newline at end of file
+};
--
1.9.1
[PATCH v4 03/10] usb: add USB_SPEED_SUPER_PLUS
Add enum USB_SPEED_SUPER_PLUS for USB3.1
Signed-off-by: Chunfeng Yun
---
v4: also add it into speed_names array
v2~v3: no changes
---
include/linux/usb/ch9.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index d4ae186..76f5a9c 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -46,6 +46,7 @@ static const char *const speed_names[] = {
[USB_SPEED_HIGH] = "high-speed",
[USB_SPEED_WIRELESS] = "wireless",
[USB_SPEED_SUPER] = "super-speed",
+ [USB_SPEED_SUPER_PLUS] = "super-speed-plus",
};
enum usb_device_speed usb_get_maximum_speed(ofnode node)
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 989a5fc..7d225ee 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -956,6 +956,7 @@ enum usb_device_speed {
USB_SPEED_HIGH, /* usb 2.0 */
USB_SPEED_WIRELESS, /* wireless (usb 2.5) */
USB_SPEED_SUPER,/* usb 3.0 */
+ USB_SPEED_SUPER_PLUS, /* usb 3.1 */
};
#ifdef __KERNEL__
--
1.9.1
[PATCH v4 04/10] usb: common: add define of usb_speed_string()
There is only declear of usb_speed_string(), but not define it.
Signed-off-by: Chunfeng Yun
---
v4: new patch
---
drivers/usb/common/common.c | 7 +++
include/linux/usb/ch9.h | 4
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 76f5a9c..5e5c3c3 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -49,6 +49,13 @@ static const char *const speed_names[] = {
[USB_SPEED_SUPER_PLUS] = "super-speed-plus",
};
+const char *usb_speed_string(enum usb_device_speed speed)
+{
+ if (speed < 0 || speed >= ARRAY_SIZE(speed_names))
+ speed = USB_SPEED_UNKNOWN;
+ return speed_names[speed];
+}
+
enum usb_device_speed usb_get_maximum_speed(ofnode node)
{
const char *max_speed;
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index 7d225ee..a8fa5d7 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -959,8 +959,6 @@ enum usb_device_speed {
USB_SPEED_SUPER_PLUS, /* usb 3.1 */
};
-#ifdef __KERNEL__
-
/**
* usb_speed_string() - Returns human readable-name of the speed.
* @speed: The speed to return human-readable name for. If it's not
@@ -969,8 +967,6 @@ enum usb_device_speed {
*/
extern const char *usb_speed_string(enum usb_device_speed speed);
-#endif
-
enum usb_device_state {
/* NOTATTACHED isn't in the USB spec, and this state acts
* the same as ATTACHED ... but it's clearer this way.
--
1.9.1
[PATCH] arm: socfpga: soc64: Document down boot_scratch_cold register usage
From: Chin Liang See Document down the usage of boot_scratch_cold register to avoid overlapping of usage in the code for S10 & Agilex. The boot_scratch_cold register is generally used for passing critical system info between SPL, U-Boot and Linux. Signed-off-by: Chin Liang See Signed-off-by: Siew Chin Lim --- arch/arm/mach-socfpga/include/mach/system_manager_soc64.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h index c90f63a754..0b0eb7a259 100644 --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h @@ -46,13 +46,20 @@ void sysmgr_pinmux_table_delay(const u32 **table, unsigned int *table_len); #define SYSMGR_SOC64_GPO 0xe4 #define SYSMGR_SOC64_GPI 0xe8 #define SYSMGR_SOC64_MPU 0xf0 +/* store qspi ref clock */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD00x200 +/* store osc1 clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD10x204 +/* store fpga clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD20x208 #define SYSMGR_SOC64_BOOT_SCRATCH_COLD30x20c +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD40x210 +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD50x214 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD60x218 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD70x21c #define SYSMGR_SOC64_BOOT_SCRATCH_COLD80x220 #define SYSMGR_SOC64_BOOT_SCRATCH_COLD90x224 -- 2.19.0
[PATCH v2] arm: socfpga: soc64: Document down boot_scratch_cold register usage
From: Chin Liang See Document down the usage of boot_scratch_cold register to avoid overlapping of usage in the code for S10 & Agilex. The boot_scratch_cold register is generally used for passing critical system info between SPL, U-Boot and Linux. Signed-off-by: Chin Liang See Signed-off-by: Siew Chin Lim --- v2: Mark boot_scratch_cold3 as reserved for customer use. --- arch/arm/mach-socfpga/include/mach/system_manager_soc64.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h index c90f63a754..e5bb81a7a2 100644 --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h @@ -46,13 +46,21 @@ void sysmgr_pinmux_table_delay(const u32 **table, unsigned int *table_len); #define SYSMGR_SOC64_GPO 0xe4 #define SYSMGR_SOC64_GPI 0xe8 #define SYSMGR_SOC64_MPU 0xf0 +/* store qspi ref clock */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD00x200 +/* store osc1 clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD10x204 +/* store fpga clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD20x208 +/* reserved for customer use */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD30x20c +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD40x210 +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD50x214 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD60x218 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD70x21c #define SYSMGR_SOC64_BOOT_SCRATCH_COLD80x220 #define SYSMGR_SOC64_BOOT_SCRATCH_COLD90x224 -- 2.19.0
RE: [PATCH] arm: socfpga: soc64: Document down boot_scratch_cold register usage
Kindly ignore this patch review request. There is one more comment need to be added for SYSMGR_SOC64_BOOT_SCRATCH_COLD3 register. I will send "PATCH v2" for review. Thanks a lot, Siew Chin -Original Message- From: Lim, Elly Siew Chin Sent: Monday, August 10, 2020 10:05 AM To: u-boot@lists.denx.de Cc: Marek Vasut ; Ley Foon Tan ; See, Chin Liang ; Simon Goldschmidt ; Ang, Chee Hong ; Chee, Tien Fong ; Lim, Elly Siew Chin Subject: [PATCH] arm: socfpga: soc64: Document down boot_scratch_cold register usage From: Chin Liang See Document down the usage of boot_scratch_cold register to avoid overlapping of usage in the code for S10 & Agilex. The boot_scratch_cold register is generally used for passing critical system info between SPL, U-Boot and Linux. Signed-off-by: Chin Liang See Signed-off-by: Siew Chin Lim --- arch/arm/mach-socfpga/include/mach/system_manager_soc64.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h index c90f63a754..0b0eb7a259 100644 --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h @@ -46,13 +46,20 @@ void sysmgr_pinmux_table_delay(const u32 **table, unsigned int *table_len); #define SYSMGR_SOC64_GPO 0xe4 #define SYSMGR_SOC64_GPI 0xe8 #define SYSMGR_SOC64_MPU 0xf0 +/* store qspi ref clock */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD00x200 +/* store osc1 clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD10x204 +/* store fpga clock freq */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD20x208 #define SYSMGR_SOC64_BOOT_SCRATCH_COLD30x20c +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD40x210 +/* store PSCI_CPU_ON value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD50x214 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD60x218 +/* store VBAR_EL3 value */ #define SYSMGR_SOC64_BOOT_SCRATCH_COLD70x21c #define SYSMGR_SOC64_BOOT_SCRATCH_COLD80x220 #define SYSMGR_SOC64_BOOT_SCRATCH_COLD90x224 -- 2.19.0
[PATCH v4 10/10] MAINTAINERS: add mtu3 driver to ARM MEDIATEK
Add MediaTek USB3 Dual-Role controller driver to ARM MEDIATEK Signed-off-by: Chunfeng Yun --- v4: new patch --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 889a73f..e3fe859 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -265,6 +265,7 @@ F: drivers/power/domain/mtk-power-domain.c F: drivers/ram/mediatek/ F: drivers/spi/mtk_snfi_spi.c F: drivers/timer/mtk_timer.c +F: drivers/usb/mtu3/ F: drivers/watchdog/mtk_wdt.c F: drivers/net/mtk_eth.c F: drivers/reset/reset-mediatek.c -- 1.9.1
[U-Boot] requesting a custodian tree for Aspeed SoCs maintenance
Hi, We are Aspeed SW team and would like to request the creation of a u-boot-aspeed.git custodian tree for the u-boot support related to Aspeed SoCs. Attached is the SSH key generated for this purpose. By the way, the Aspeed SoCs are based on ARM architecture. However, we are not sure if the Aspeed custodian tree should be a downstream of u-boot-arm.git tree or not. As there is no update to u-boot-arm since 4 years ago. If anything is further needed, please let us know. Thanks, Chiawei ASPEED Technology Inc. Tel: 886-3-5751185 ext:8637 E-mail: chiawei_w...@aspeedtech.com * Email Confidentiality Notice DISCLAIMER: This message (and any attachments) may contain legally privileged and/or other confidential information. If you have received it in error, please notify the sender by reply e-mail and immediately delete the e-mail and any attachments without copying or disclosing the contents. Thank you. id_rsa.pub Description: id_rsa.pub
RE: [PATCH] common/board_f: make sure to call fix_fdt() before reserve_fdt()
Hi Atish,
>-Original Message-
>From: Atish Patra
>Sent: 10 August 2020 01:51
>To: Pragnesh Patel
>Cc: Atish Patra ; Bin Meng ; U-
>Boot Mailing List ; Anup Patel ;
>Sagar Kadam ; Rick Chen ;
>Paul Walmsley ( Sifive) ; Simon Glass
>; Ovidiu Panait ; Stephen Warren
>; Patrick Delaunay ; Vikas
>Manocha ; Masahiro Yamada
>; Ye Li
>Subject: Re: [PATCH] common/board_f: make sure to call fix_fdt() before
>reserve_fdt()
>
>[External Email] Do not click links or attachments unless you recognize the
>sender and know the content is safe
>
>On Wed, Aug 5, 2020 at 2:01 AM Pragnesh Patel
>wrote:
>>
>> There may be a chance that board specific fix_fdt() will change the
>> size of FDT blob so it's safe to call reserve_fdt() after fix_fdt()
>> otherwise global data (gd) will overwrite with FDT blob values.
>>
>> Signed-off-by: Pragnesh Patel
>> ---
>> common/board_f.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/common/board_f.c b/common/board_f.c index
>> 88ff0424a7..7ae01e9fff 100644
>> --- a/common/board_f.c
>> +++ b/common/board_f.c
>> @@ -956,6 +956,9 @@ static const init_fnc_t init_sequence_f[] = {
>> * - board info struct
>> */
>> setup_dest_addr,
>> +#ifdef CONFIG_OF_BOARD_FIXUP
>> + fix_fdt,
>> +#endif
>> #ifdef CONFIG_PRAM
>> reserve_pram,
>> #endif
>> @@ -984,9 +987,6 @@ static const init_fnc_t init_sequence_f[] = {
>> setup_board_part2,
>> #endif
>> display_new_sp,
>> -#ifdef CONFIG_OF_BOARD_FIXUP
>> - fix_fdt,
>> -#endif
>> INIT_FUNC_WATCHDOG_RESET
>> reloc_fdt,
>> reloc_bootstage,
>> --
>> 2.17.1
>>
>
>
>Reviewed-by: Atish Patra
Thanks for the review, can you please send your Reviewed-by tag in the v2
version of this patch.
>--
>Regards,
>Atish
Re: [PATCH] ram: rockchip: Disable debug output of RAM init by default
Hi Kever, Am 2020-08-08 11:40, schrieb Kever Yang: Hi Michael, I think there do have some information are really help people identify what's happen for TPL fail, that's why rockchip's dram binary always keep some DRAM info print for all the boards. I would like to keep it as is for now, before we are can split the 'debug' and 'info' msg. So shouldn't we work on splitting the messages into debug() and info() then? Like I said, it really clutters the console in the normal case (for DDR4 at least, I don't know about DDR3)and IMHO you don't want that many debug information _by default_. -michael
RE: [PATCH v2] arm: socfpga: soc64: Document down boot_scratch_cold register usage
> -Original Message- > From: Lim, Elly Siew Chin > Sent: Monday, August 10, 2020 10:56 AM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Tan, Ley Foon > ; See, Chin Liang ; > Simon Goldschmidt ; Ang, Chee Hong > ; Chee, Tien Fong ; > Lim, Elly Siew Chin > Subject: [PATCH v2] arm: socfpga: soc64: Document down > boot_scratch_cold register usage > > From: Chin Liang See > > Document down the usage of boot_scratch_cold register to avoid > overlapping of usage in the code for S10 & Agilex. > The boot_scratch_cold register is generally used for passing critical system > info between SPL, U-Boot and Linux. > > Signed-off-by: Chin Liang See > Signed-off-by: Siew Chin Lim > > --- > v2: Mark boot_scratch_cold3 as reserved for customer use. > --- > arch/arm/mach-socfpga/include/mach/system_manager_soc64.h | 8 > > 1 file changed, 8 insertions(+) Reviewed-by: Ley Foon Tan Regards Ley Foon
