On Fri, 15 Nov 2024 09:34:54 +0100
Heinrich Schuchardt wrote:
> Rasmus Villemoes schrieb am Fr., 15. Nov. 2024,
> 08:18:
[...]
> > Or use getrandom(), which according to the man page has been
+1
> > exposed via glibc since glibc 2.25. Or just read from /dev/urandom
> > which should work everyw
The JH7110 has the arhitectural CPU timer on all 5 rv64 cores.
Note that in the device tree.
Signed-off-by: Torsten Duwe
---
arch/riscv/dts/jh7110.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index 081b81
,timer.yaml
Signed-off-by: Torsten Duwe
---
drivers/timer/riscv_timer.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 3627ed79b8..28a6a6870b 100644
--- a/drivers/timer/riscv_timer.c
patches fix the visionfive2, for a start. Others may follow and
the CPU driver calls can be removed later when they are not needed any
longer.
Torsten
Fixes: 55171aedda8 ("dm: Emit the arch_cpu_init_dm() even only before
relocation")
---
Torsten Duwe (2):
riscv: allow riscv tim
affect other
targets.
I'm also wondering whether the symbolic clock number constants should be
synced, too. But that's also a minor issue, as long as they expand to yield
the same numbers.
For the series:
Reviewed-by: Torsten Duwe
Torsten
Hi,
following the existing device tree binding[1], here is a draft to use it
in drivers/timer/riscv_timer.c. This would also fix the regression we see
with commit 55171aedda8 ("dm: Emit the arch_cpu_init_dm() even only
before relocation"), at least on the VisionFive2, as sketched out below.
The de
> On 2023/5/31 2:11, Simon Glass wrote:
> > Hi Yanhong,
> >
> > Please can you send this to the mailing list and cc me?
> >
Yes, that would have prevented some grief.
[...]
> >> DRAM: 8 GiB
> >> initcall sequence fffe08b0 failed at call 4021611e
> >> (err=-19)
> >> ### ERROR #
On Thu, 25 May 2023 17:36:26 +0800
Yanhong Wang wrote:
[...]
>
> base-commit: 62df7a39442902a71259568c13a4d496d5a514f4
Have you tested this?
I get
| U-Boot SPL 2023.07-rc2-00170-g62df7a3944 (Jun 01 2023 - 18:58:50 +0200)
| DDR version: dc2e84f0.
| Trying to boot from MMC2
|
|
| U-Boot 2023.
On Thu, 25 May 2023 17:36:26 +0800
Yanhong Wang wrote:
[...]
> The main difference between StarFive VisionFive 2 1.2A and 1.3B is
> gmac, but the difference in gmac is not defined in DT, but reads the
> PCB version from EEPROM, and then dynamically configures the
> difference of gmac according t
On Wed, 24 May 2023 11:19:48 +0100
Conor Dooley wrote:
> On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > On 2023/5/23 19:28, Conor Dooley wrote:
> > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> > >> On Tue, 23 May 2023 09:28:39 +0
Hi Leo, thanks for the quick reply!
On Thu, 20 Apr 2023 06:33:57 +
Leo Liang wrote:
> Hi, Torsten, Matthias,
>
> On Wed, Apr 19, 2023 at 02:34:03PM +0200, Matthias Brugger wrote:
> >
> >
> > On 19/04/2023 13:28, Torsten Duwe wrote:
> > > This is onl
ionFive2 config proves it. Use this quick hack for now.
Signed-off-by: Torsten Duwe
---
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index ff9df56ec2..fd3a1d057a 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
++
On Thu, 13 Apr 2023 10:05:28 +0800
yanhong wang wrote:
> the definition of DT refers to Linux and is consistent with the definition
> framework of Linux.
This is one of the desired goals, to avoid confusion, usually. But note there
are already the
-u-boot.dtsi files; in this case it would be v
On Wed, 29 Mar 2023 18:16:20 +0800
yanhong wang wrote:
>
>
> On 2023/3/29 17:41, Torsten Duwe wrote:
> > On Wed, 29 Mar 2023 11:42:07 +0800
> > Yanhong Wang wrote:
> >
> >> v5:
> > [...]
> >> - Splitted starfive_visionfive2_defconfig into
On Wed, 29 Mar 2023 18:16:20 +0800
yanhong wang wrote:
>
>
> On 2023/3/29 17:41, Torsten Duwe wrote:
> > On Wed, 29 Mar 2023 11:42:07 +0800
> > Yanhong Wang wrote:
> >
> >> v5:
> > [...]
> >> - Splitted starfive_visionfive2_defconfig into
On Wed, 29 Mar 2023 11:42:07 +0800
Yanhong Wang wrote:
> v5:
[...]
> - Splitted starfive_visionfive2_defconfig into
> starfive_visionfive2_12a_defconfig
> and starfive_visionfive2_13b_defconfig.
Is this really necessary? It puts another burden on people building U-Boot,
distribution networks,
On Mon, 27 Mar 2023 10:22:37 +0800
yanhong wang wrote:
> On 2023/3/24 20:53, Torsten Duwe wrote:
> > What's missing to read the correct MACs from the EEPROM?
>
> The minimum system of u-boot supporting JH7110 does not contain EEPROM
[...]
Thanks for the info!
Torsten
On Fri, 17 Mar 2023 09:05:31 +0800
Yanhong Wang wrote:
> This series adds ethernet support for the StarFive JH7110 RISC-V SoC.
> The series includes PHY and MAC drivers. The PHY model is
> YT8531 (from Motorcomm Inc), and the MAC version is dwmac-5.20
> (from Synopsys DesignWare).
>
> The imple
On Sun, 20 Dec 2020 11:17:50 -0700
Simon Glass wrote:
> Hi Torsten,
>
> On Sun, 20 Dec 2020 at 10:00, Torsten Duwe wrote:
> >
> > On Fri, 18 Dec 2020 19:29:12 -0700
> > Simon Glass wrote:
> >
> > > > - int i;
> > > > -
> >
On Fri, 18 Dec 2020 19:29:12 -0700
Simon Glass wrote:
> > - int i;
> > -
> > - srand(get_ticks() + rand());
> > + int i, ret;
> > + struct udevice *devp;
> > + u8 randv = 0;
> > +
> > +#if defined(CONFIG_DM_RNG)
>
> This seems a little backwards to me. The caller sh
On Sun, 20 Dec 2020 02:43:25 +0300
Anton Gorlov wrote:
> Thank you!
You're welcome, sorry for the inconvenience.
> > https://build.opensuse.org/package/show/home:duwe:Teres-I/u-boot
> >
> > Should get you to "0103-Add-AXP803-PMIC-support.patch"
> >> It needs some more clean-up and maybe separ
On Sat, 19 Dec 2020 17:15:21 +0100
Torsten Duwe wrote:
> On Fri, 18 Dec 2020 21:41:28 +0300
> Anton Gorlov wrote:
>
> > Hi all.
> >
> > Are there any plans to support AXP803 power regulator in u-boot?
>
> Well, I already wrote some generic AXP driver, in
On Fri, 18 Dec 2020 21:41:28 +0300
Anton Gorlov wrote:
> Hi all.
>
> Are there any plans to support AXP803 power regulator in u-boot?
Well, I already wrote some generic AXP driver, inspired by the code in
the Linux kernel:
https://build.opensuse.org/source/home:duwe:Teres-I/u-boot/0103-Add-AXP
On Fri, 18 Dec 2020 10:28:04 +0100
matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When calling srand_mac we use a weak seed dependent on the
> mac address. If present, use a RNG device instead to incerase entropy.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Torsten Duwe
On Fri, 18 Dec 2020 10:28:03 +0100
matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When calculating a random UUID we use a weak seed.
> Use a RNG device if present to increase entropy.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Torsten Duwe
On Wed, 16 Dec 2020 17:28:06 +0100
matthias@kernel.org wrote:
> @@ -249,9 +251,22 @@ void gen_rand_uuid(unsigned char *uuid_bin)
> {
> u32 ptr[4];
> struct uuid *uuid = (struct uuid *)ptr;
> - int i;
> -
> - srand(get_ticks() + rand());
> + int i, ret;
> + struct u
On Wed, 16 Dec 2020 17:28:05 +0100
matthias@kernel.org wrote:
> From: Matthias Brugger
>
>
> For now bootp and uuid code use a weak seed for generating random
> data. U-Boot as support for RNG devices now, so we should change to
> code to use them if they are present. This will help mitigat
On Wed, 16 Dec 2020 11:41:16 +0100
matthias@kernel.org wrote:
> @@ -249,9 +250,22 @@ void gen_rand_uuid(unsigned char *uuid_bin)
> {
> u32 ptr[4];
> struct uuid *uuid = (struct uuid *)ptr;
> - int i;
> -
> - srand(get_ticks() + rand());
> + int i, ret;
> + struct u
On Wed, 16 Dec 2020 11:41:17 +0100
matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When calling srand_mac we use a weak seed dependent on the
> mac address. If present, use a RNG device instead to incerase entropy.
>
> Signed-off-by: Matthias Brugger
>
> ---
>
> net/net_rand.h |
On Wed, 16 Dec 2020 11:41:15 +0100
matthias@kernel.org wrote:
> From: Matthias Brugger
>
>
> For now bootp and uuid code use a weak seed for generating random
> data. U-Boot as support for RNG devices now, so we should change to
> code to use them if they are present. This will help mitigat
On Sat, Feb 16, 2019 at 10:45:45AM +0100, Krzysztof Kozlowski wrote:
> Changing voltage and enabling regulator might require delays so the
> regulator stabilizes at expected level.
>
> Add support for "regulator-ramp-delay" binding which can introduce
> required time to both enabling the regulator
On Mon, Feb 18, 2019 at 03:28:46PM +0100, Krzysztof Kozlowski wrote:
> On Mon, 18 Feb 2019 at 15:03, Torsten Duwe wrote:
> >
> > > --- a/doc/device-tree-bindings/regulator/regulator.txt
> > > +++ b/doc/device-tree-bindings/regulator/regulator.txt
> > > @
32 matches
Mail list logo
