On Sat, 2020-06-27 at 20:57 +0800, Kever Yang wrote:
> Hi Kurt,
>
>
> On 2020/6/4 上午5:17, Peter Geis wrote:
>
> >
> > On Tue, Jun 2, 2020 at 11:12 AM Kurt Miller
> > wrote:
> > >
> > > On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wro
On Tue, 2020-06-02 at 10:23 +0800, Shawn Lin wrote:
>
> 在 2020/6/2 9:59, Kever Yang 写道:
> >
> > Hi Kurt,
> >
> > On 2020/6/2 上午4:30, Kurt Miller wrote:
> > >
> > > On at least the RockPro64, many cards will trip a
> > > synchronous abor
On Tue, 2020-06-02 at 02:16 +0530, Jagan Teki wrote:
> On Tue, Jun 2, 2020 at 2:00 AM Kurt Miller wrote:
> >
> >
> > On at least the RockPro64, many cards will trip a
> > synchronous abort when first accessing PCIe config space
> > during bus scanning. A
On at least the RockPro64, many cards will trip a
synchronous abort when first accessing PCIe config space
during bus scanning. A delay after link training allows
some of these cards to function.
Signed-off-by: Kurt Miller
---
On the RockPro64, some pci cards trip a synchronous abort when
On Fri, 2020-05-29 at 13:00 -0600, Simon Glass wrote:
> Hi Kurt,
>
> On Fri, 29 May 2020 at 06:42, Kurt Miller wrote:
> >
> >
> > On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
> > >
> > > On Thu, May
On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
> On Thu, May 28, 2020 at 8:32 PM Kurt Miller
> wrote:
> >
> >
> > The cooling levels are tuned to the fan that comes with the rockpro64 NAS
> > case. A gpu_thermal zone was not added because having two a
The cooling levels are tuned to the fan that comes with the rockpro64 NAS
case. A gpu_thermal zone was not added because having two active cooling
maps control one physical fan causes them to compete for the fan speed
which results in erratic fan behavior.
Signed-off-by: Kurt Miller
---
arch
ors optional and properly check their
> presence before attempting to enable them.
>
> Makes PCIe work on un U-Boot on the boards mentioned above.
>
> Signed-off-by: Mark Kettenis
Tested by: Kurt Miller
Model: Pine64 RockPro64 v2.1
=> pci
Scanning PCI devices on bus 0
On Mon, 2020-05-25 at 11:00 +0200, Mark Kettenis wrote:
> Enable CONFIG_PCI and CONFIG_NVME and related configs for the
> ROCKPro64 board.
>
> Signed-off-by: Mark Kettenis
Tested by: Kurt Miller
Model: Pine64 RockPro64 v2.1
=> pci
Scanning PCI devices on bus 0
BusDevFun Vend
On Wed, 2020-05-20 at 16:30 +0800, Chen-Yu Tsai wrote:
> On Wed, May 20, 2020 at 4:05 PM Matwey V. Kornilov
> wrote:
> >
> >
> > вт, 19 мая 2020 г. в 17:30, Kurt Miller :
> > >
> > >
> > > On Tue, 2020-05-19 at 12:48 +0300, Matwey V. Kornilov
On Tue, 2020-05-19 at 12:48 +0300, Matwey V. Kornilov wrote:
> вт, 19 мая 2020 г. в 01:06, Kurt Miller :
> >
> >
> > On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote:
> > >
> > > On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> > &
On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote:
> On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> >
> > Thanks. Have you already checked it on gen2? I think I have gen2 board to
> > test.
> Yes, I have both gen3 and gen2 boards. gen2 continues to w
On Thu, 2020-05-14 at 12:10 +0800, Chen-Yu Tsai wrote:
> Hi Kurt
>
> On Tue, May 12, 2020 at 3:00 AM Kurt Miller
> wrote:
> >
> >
> > On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> > >
> > > From: Chen-Yu Tsai
> > >
> &
On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> Thanks. Have you already checked it on gen2? I think I have gen2 board to
> test.
Yes, I have both gen3 and gen2 boards. gen2 continues to work
with this patch as well.
>
> ср, 13 мая 2020 г. в 22:55,
Use the same approach as ROC-RK3328-CC which enables SPL GPIO,
pinctl and regulator support. This allows the gen3 board to
boot through SPL and does not break gen2 in the process.
Signed-off-by: Kurt Miller
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 21 +
configs/rock64
On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> This syncs rk3328 device tree files from the Linux kernel next-20200324.
> The last commit to touch these files is:
>
> b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
>
> Additional changes not
On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Hi everyone,
>
> This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> dropping the custom board target, and dealing with the pinmuxing
> through proper use of DM regulators / GPIO / pinctrl in SPL.
>
On Wed, 2020-04-01 at 18:09 +0800, Chen-Yu Tsai wrote:
> On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki wrote:
> >
> >
> > On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai wrote:
> > >
> > >
> > > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki
> > > wrote:
> > > >
> > > >
> > > > On Mon, Mar 30, 2020
On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Hi everyone,
>
> This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
> single board computer.
>
> The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> card size development
On Sat, 2020-03-28 at 01:44 +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller
> wrote:
> >
> >
> > On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> > >
> > > From: Chen-Yu Tsai
> > >
> >
dd dt-binding header for rk3328
Signed-off-by: Kurt Miller
---
include/dt-bindings/clock/rk3328-cru.h | 212 -
1 file changed, 106 insertions(+), 106 deletions(-)
diff --git a/include/dt-bindings/clock/rk3328-cru.h
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed88
I noted that the u-boot clock bindings differ from upstream
Linux for rk3328. Which values are correct and how does u-boot
plan on addressing this discrepancy?
https://github.com/u-boot/u-boot/blob/master/include/dt-bindings/clock/rk3328-cru.h
vs
https://github.com/torvalds/linux/blob/master/inclu
Hi Kever,
On Mon, 2019-11-18 at 11:05 +0800, Kever Yang wrote:
> Hi Kurt,
>
> On 2019/11/14 上午2:44, Kurt Miller wrote:
> >
> > On Tue, 2019-09-17 at 12:02 -0400, Kurt Miller wrote:
> > >
> > > On Tue, 2019-09-17 at 10:57 +0800, Kev
On Tue, 2019-09-17 at 12:02 -0400, Kurt Miller wrote:
> On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote:
> >
> > Hi Kurt,
> >
> > Could you try with below update:
> >
> >
> > diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
&g
On Sun, 2019-10-06 at 12:28 -0400, Simon South wrote:
> These two patches fix small issues with the Rockchip RK3328 SDRAM
> driver that prevented my PINE64 ROCK64 from booting and running
> normally using U-Boot's TPL [1].
>
> The first patch updates the phy_dll_bypass_set() function to use the
>
On Thu, 2019-09-19 at 11:03 +0530, Jagan Teki wrote:
> Hi Kever,
>
> On Wed, Sep 18, 2019 at 10:31 AM Jagan Teki
> wrote:
> >
> >
> > On Wed, Sep 18, 2019 at 9:09 AM Kever Yang
> > wrote:
> > >
> > >
> > > Hi Jagan,
> > >
> > > Seems like your and Kurt's board have different DRAM typ
On Tue, 2019-09-17 at 10:57 +0800, Kever Yang wrote:
> Hi Kurt,
>
> Could you try with below update:
>
>
> diff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
> b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi
> index 4a4414a960..dc9db047cb 100644
> --- a/arch/arm/dts/rk3399-sdram-lpddr4-100
size detection on this board.
On Wed, 2019-08-28 at 17:45 -0400, Kurt Miller wrote:
> The board has 4G memory but only 2G is detected by TPL. Please
> let me know if additional information is needed.
>
> With u-boot master TPL output:
>
> U-Boot TPL 2019.10-rc3-00020-ge4b8dd9b34-
The board has 4G memory but only 2G is detected by TPL. Please
let me know if additional information is needed.
With u-boot master TPL output:
U-Boot TPL 2019.10-rc3-00020-ge4b8dd9b34-dirty (Aug 28 2019 - 17:26:44)
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
LPDDR4, 50MH
Hi Kever,
On Tue, 2019-08-20 at 10:46 +0800, Kever Yang wrote:
> Hi Kurt,
>
>
> Does this patch fix your issue?
>
> https://patchwork.ozlabs.org/patch/1147457/
>
Yes! It fixes my boot issue. Thank you for working on it.
However there is a second issue. Only 2G of memory was recognized
instea
Hi Jagan,
On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote:
> Is your board running at 50MHz? (look like No).
No it is running at 800Mhz or 856MHz (see rkbin TPL output below).
> As I said please
> explore step-by-step
> 00: First boot the board rkbin => SPL => U-Boot proper
This step was co
On Mon, 2019-08-19 at 22:08 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller
> wrote:
> >
> >
> > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > >
> > > >
> > > >
> > >
On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller
> wrote:
> >
> >
> > Hi Michael,
> >
> > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > >
> > > It's pos
Hi Michael,
On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> It's possible to dump the register after training in mainline uboot?
I'm working on getting master to build now. How would I
go about dumping the register after training?
Regards,
-Kurt
__
On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> >
> > From: Jagan Teki
> > Date: Mon, 19 Aug 2019 00:21:40 +0530
> >
> > + Kever
> >
> > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller
> > wrote:
> > >
> > >
> &g
Hello,
The Rockpro64_V2.1 2018-07-02 using master code base freezes
with only the following output:
U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
Whereas another board dated 2018-06-06 works and outputs the following:
U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug
36 matches
Mail list logo
