Various rockchip u-boot 2019.10rc4 aarch64 improvements:
* u-boot.itb is included in the all target for rockpro64 and
firefly-rk3399 so remove duplicate make for it.
* Build rock64-rk3328, except exclude idbloader.img which is broken.
* Install u-boot-spl-dtb.bin and mkimage for rock64, rockpro64
Improve devel/gdb aarch64 support:
* Enable debugging on running threaded programs
* Provide sigtramp routine unwinding (support modeled after ppc)
okay?
Example of unwinding through signal trap page on running target:
(gdb) bt
#0 handler (sig=11, sip=0x16517e9238, ctx=0x16517e9118) at
pthread
I've been trying to get the rock64 to work with u-boot 2019.10rc4
with the help of solene@ and a motivated user with this board.
(I don't have one to test with). The Rock64 is close to fully
working with 2019.10rc4 u-boot but is experiencing a similar issue
to what NetBSD has reported on the u-boot
On Fri, 2019-09-27 at 10:12 +1000, Jonathan Gray wrote:
> On Thu, Sep 26, 2019 at 12:28:56PM -0400, Kurt Miller wrote:
> >
> > I've been trying to get the rock64 to work with u-boot 2019.10rc4
> > with the help of solene@ and a motivated user with this board.
> >
On Fri, 2019-09-27 at 11:50 +1000, Jonathan Gray wrote:
> On Thu, Sep 26, 2019 at 09:38:43PM -0400, Kurt Miller wrote:
> >
> > On Fri, 2019-09-27 at 10:12 +1000, Jonathan Gray wrote:
> > >
> > > On Thu, Sep 26, 2019 at 12:28:56PM -0400, Kurt Miller wrote:
&g
to see if the Rock64
will work with u-boot's TPL layer. Please see the attached diff
for review.
Rock64 users can test the firmware by jumping gpio pins
20 and 21 to disable the SPI firmware and booting off a
uSD prepared as follows:
dd if=miniroot66.fs of=/dev/ bs=1m
dd if=idbloader.img of=
On Sun, 2019-10-06 at 21:51 -0400, Kurt Miller wrote:
> The /usr/local/share/u-boot/rockpro64-rk3399 directory
Typo above. It should have said:
The /usr/local/share/u-boot/rock64-rk3328 directory
> built from this diff can be downloaded here to save Rock64
> users some time:
On Mon, 2019-10-07 at 13:35 +1100, Jonathan Gray wrote:
> On Sun, Oct 06, 2019 at 09:51:20PM -0400, Kurt Miller wrote:
> >
> > On Sun, 2019-10-06 at 18:47 +0200, Mark Kettenis wrote:
> > >
> > > >
> > > >
> > > > Date
On Tue, 2019-10-08 at 02:25 +1100, Jonathan Gray wrote:
> On Mon, Oct 07, 2019 at 10:33:27AM -0400, Kurt Miller wrote:
> >
> > On Mon, 2019-10-07 at 13:35 +1100, Jonathan Gray wrote:
> > >
> > > On Sun, Oct 06, 2019 at 09:51:20PM -0400, Kurt Miller wrote:
>
be in 2020.01-rc3 when its
tagged.
-Kurt
> On Thu, Nov 14, 2019 at 07:12:13PM +0100, Klaus Küchemann wrote:
> >
> > The worldwide only U-Boot 2019.10-version for RockPro64 I have ever seen
> > fully working
> > is the one which is made by OpenBSD-magic-hardcore-prog
de to work by adding an arbitrary delay into the
rkpci driver after link training but this is a hack without a root
cause known so it is unlikely to be committed.
The current driver does not support cards that have PCI bridge's on
them as well.
-Kurt
> Thank you,
>
> Olivier.
On Thu, 2019-11-28 at 23:29 +0100, burelli.fr wrote:
> Hello,
>
> I tried to install current on RockPro64 to eMMC.
>
> _ I used the firmware provided by Marc (on microSD):
> https://marc.info/?l=openbsd-arm&m=156114869709200&w=2
> _ I used an usb stick for miniroot
>
> Once arrived to choose th
$x.0+0x6c
> $x.0() at ppb_alloc_resources+0xb4
> ppb_alloc_resources() at ppbattach+0x2c4
> ppbattach() at config_attach+0x220
> config_attach() at pci_probe_device+0x3f0
> pci_probe_device() at pci_enumerate_bus+0x11c
> pci_enumerate_bus() at config_attach+0x220
> config_attach() at rkpcie_attach+0x6e0
> rkpcie_attach() at config_attach+0x220
> config_attach() at mainbus_attach_node+0x2c4
> mainbus_attach_node() at mainbus_attach+0x298
> mainbus_attach() at config_attach+0x220
> config_attach() at cpu_configure+0x2c
> cpu_configure() at main+0x308
> main() at $x.2+0x70
>
> ddb{0}> show panic
> uvm_fault failed: ff8000213870
>
> Have a nice evening :)
>
This is the panic I was referring to previously here:
https://marc.info/?l=openbsd-arm&m=157426949805676&w=2
For reference:
> Cards that don't work panic when first accessing the PCIe configuration
> memory during boot. The reason for this is unknown and appears to be an
> issue with Linux as well: https://github.com/rockchip-linux/kernel/issues/116
> Some cards can be made to work by adding an arbitrary delay into the
> rkpci driver after link training but this is a hack without a root
> cause known so it is unlikely to be committed.
>
> The current driver does not support cards that have PCI bridge's on
> them as well.
Regards,
-Kurt
t the default one is, but firefox tells me
> the default is not firefox.
>
> 2) Haas anyone else encountered this same issue? and if so, do you know of
> a fix?
>
> Thanks :-)
>
>
> *Michael G. Workman*
> (321) 432-9295
> michael.g.work...@gmail.com
Please send a dmesg. Also are you using ssh X11 forwarding?
-Kurt
020.01p2.rock64-rk3328.tar.gz
Could you test idbloader.img and u-boot.itb from it on both of your
boards to see if it corrects the TPL memory training error you
are seeing?
-Kurt
> U-Boot TPL 2020.01 (Jan 12 2020 - 02:16:54)
> data training error
> col error
> data training error
> LP
On Mon, 2020-02-03 at 21:24 +0100, Sebastian Reitenbach wrote:
> Hi,
>
>
> Am Montag, Februar 03, 2020 20:41 CET, schrieb Kurt Miller
> :
>
> >
> > On Sun, 2020-02-02 at 23:01 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> > >
On Mon, 2020-02-03 at 21:39 +0100, Sebastian Reitenbach wrote:
> Seems the latest arm64 snapshot miniroot66.fs doesn't go into single user,
> first kernel that seem to broke is from:
> Sun Feb 2 02:14:44 MST 2020, last working from: Fri Jan 31 21:54:51 MST 2020
>
> every second it writes:
> init
On Mon, 2020-02-03 at 23:29 +0100, Sebastian Reitenbach wrote:
> Hi,
>
> Am Montag, Februar 03, 2020 21:43 CET, schrieb Kurt Miller
> :
>
> >
> > On Mon, 2020-02-03 at 21:24 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> > &g
On Tue, 2020-02-04 at 20:29 +0100, Sebastian Reitenbach wrote:
> Hi,
>
> Am Dienstag, Februar 04, 2020 00:56 CET, schrieb Kurt Miller
> :
>
> >
> > On Mon, 2020-02-03 at 23:29 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> > >
On Mon, 2020-02-03 at 00:28 +0100, Sebastian Reitenbach wrote:
> Hi,
>
> I've two rock64 1 with 2GB memory, the other with 1GB memory.
> Both with NetBSD-evbarm-aarch64-202001141930Z-rock64.img
> as well as the one with 2GB on OpenBSD -current, have super
> lousy network performance. Both are Roc
ve
modified the board to correct the problem and posted instructions
on how to do that. However, I tested Arbian's and ayufan's linux
on my board and the ethernet works fine so a software solution is
possible as well.
-Kurt
On Tue, 2020-03-24 at 15:53 +0100, Mark Kettenis wrote:
> >
> > From: Kurt Miller
> > Date: Tue, 24 Mar 2020 09:48:01 -0400
> >
> > On Fri, 2020-03-20 at 16:24 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> > >
> &
the NanoPi R2S in u-boot master so there's
a decent amount of work to add support for it. It may be a fun
mini-project for someone who has a NanoPi R2S to add support to
u-boot though.
-Kurt
On Tue, 2020-03-24 at 23:01 +0100, Mark Kettenis wrote:
> >
> > From: Kurt Miller
> > Date: Tue, 24 Mar 2020 17:54:13 -0400
> >
> > On Sat, 2020-03-14 at 21:19 -0700, Lear Zhou wrote:
> > >
> > > Hi,
> > >
> > > I ha
On Tue, 2020-03-24 at 15:53 +0100, Mark Kettenis wrote:
> >
> > From: Kurt Miller
> > Date: Tue, 24 Mar 2020 09:48:01 -0400
> >
> > On Fri, 2020-03-20 at 16:24 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> > >
> &
On Wed, 2020-03-25 at 15:28 -0400, Kurt Miller wrote:
> On Tue, 2020-03-24 at 15:53 +0100, Mark Kettenis wrote:
> >
> > >
> > >
> > > From: Kurt Miller
> > > Date: Tue, 24 Mar 2020 09:48:01 -0400
> > >
> > >
On Mon, 2020-03-23 at 20:41 +0100, Marcus MERIGHI wrote:
> o...@drijf.net (Otto Moerbeek), 2020.03.22 (Sun) 20:21 (CET):
> >
> > On Sun, Mar 22, 2020 at 08:07:05PM +0100, Otto Moerbeek wrote:
> >
> > >
> > > On Sun, Mar 22, 2020 at 07:30:49PM +0100, Marcus MERIGHI wrote:
> > >
> > > >
> > > >
On Wed, 2020-04-08 at 10:17 +0200, Sebastian Reitenbach wrote:
> Hi,
>
>
> Am Dienstag, Februar 04, 2020 23:10 CET, schrieb Kurt Miller
> :
>
> >
> > On Mon, 2020-02-03 at 00:28 +0100, Sebastian Reitenbach wrote:
> > >
> > > Hi,
> >
ed a V2 board when I
was intending on purchasing a V3 board. Their customer
service follows a 'customer is always wrong' approach
to problems, so buyer beware.
> Lear Zhou
>
> On Thu, May 28, 2020 at 11:58 AM Kurt Miller
> wrote:
>
> >
> > On W
I purchased one of the rev c boards with 8GB ram with the
hopes that it could build the full ports tree. Good news
it installs and boots fairly easily. Bad news is that I
missed that the 8GB ram is split between the CPU and the
NPU (4GB for CPU/GPU, 4GB for NPU) so only 4GB is usable
for building p
On Mon, 2020-11-23 at 17:36 +, Joseph Mayer wrote:
> Hi arm@!
>
> Should the RK3399Pro work out of the box?
Yes it does. See my 'Radxa ROCK Pi N10 Works' email.
> Its specs look equivalent
> with the RK3399's but it has 8GB RAM.
I was excited about this board too but note that only
4GB of t
On Tue, 2021-01-12 at 20:42 +0100, Mark Kettenis wrote:
> >
> > Date: Tue, 12 Jan 2021 20:40:05 +0100 (CET)
> > From: Mark Kettenis
> >
> > >
> > > From: Kurt Miller
> > > Date: Tue, 12 Jan 2021 12:29:34 -0500
> > >
> > >
On Thu, 2021-03-04 at 08:48 +0100, Sylvain S wrote:
> Hello,
>
> I am still attempting to obtain a working server
> out of my Firefly-RK3399, or at least boot obsd
> from it.
>
> I have more or less configured a multimedia station
> out of Android right now, tinkering a bit with the
> card, but t
ound 60 deg for most loads.
With these settings its pretty hard to get the cpu temp to 65 deg.
Of course these settings are only tuned to the fan that comes with
the NAS case but that seem like a reasonable place to work from.
We should probably sync the dtb port to match these settings,
including the PCIe gen2 setting.
-Kurt
34 matches
Mail list logo
