LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > slarm64
User Name
Password
slarm64 This forum is for the discussion of slarm64.

Notices


Reply
  Search this Thread
Old 01-25-2022, 03:48 PM   #1
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,865

Rep: Reputation: Disabled
Rock64 RK3328 (aarch64)


previous discussion Rock64
 
Old 01-26-2022, 12:06 PM   #3
Hannes Worst
Member
 
Registered: Jul 2008
Location: Tilburg, The Netherlands
Distribution: Void Linux, Slackware, Nixos
Posts: 179

Rep: Reputation: 122Reputation: 122
Thanks! Should I comment out the mirror in /etc/slackpkg/mirrors and update? Is that safe to do?
 
Old 01-26-2022, 07:38 PM   #4
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Rep: Reputation: Disabled
Quote:
Originally Posted by Hannes Worst View Post
Thanks! Should I comment out the mirror in /etc/slackpkg/mirrors and update? Is that safe to do?
UNcomment your mirror of choice and upgrade to your heart's content. Yes, totally safe to do, I have a Rock64 running slarm64 24/7 as a torrent box and LAN server / update mirror, I keep it upgraded regularly. No problems, highly stable.
 
1 members found this post helpful.
Old 03-12-2022, 01:01 AM   #6
JWSmythe
LQ Newbie
 
Registered: Oct 2012
Location: Various
Distribution: Slackware64-current
Posts: 8

Rep: Reputation: Disabled
Just a quick FYI/bug report. I'm writing up some nice instructions for getting Octoprint up on the Rock64. In doing that, I'm trying to do everything "right". If you do the recommended slackpkg commands, it will brick it. Well, just not boot to that SD again, until you reimage or fix it.

Code:
slackpkg update 
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system
It's the slackpkg clean-system that's doing it.

The image I'm installing with is: slarm64-current-aarch64-xfce-rock64-5.16.9-build-20220214.img
I was doing it on Mar-10-2022 and Mar-11-2022.

It did it using both slarm64-15.0 and slarm64-current from

Code:
http://dl.slarm64.org/slarm64/slarm64-15.0/
http://dl.slarm64.org/slarm64/slarm64-current/
At the beginning of 'slackpkg clean-system', it says that it's going to remove these packages. They're all listed, even though it's obvious that some are totally unrelated. Just trying to be complete.

Code:
ffmpeg-rockchip-4.4.1-aarch64-2
kernel-firmware-rk3328-5.16.9-aarch64-1mara
kernel-headers-rk3328-5.16.9-aarch64-1mara
kernel-modules-rk3328-5.16.9-aarch64-1mara
kernel-rk3328-5.16.9-aarch64-1mara
kernel-source-rk3328-5.16.9-noarch-1mara
libass-20210619_4779444-aarch64-1mara
libdrm-rockchip-2.4.109-aarch64-1mara
libgl-rk3328-r7p0-aarch64-6mara
lightdm-1.30.0-aarch64-7mara
lightdm-gtk-greeter-2.0.8-aarch64-1mara
mpv-rockchip-0.34.0-aarch64-1mara
transmission-20220102_a5c6168-aarch64-1mara
xfce4-alsa-plugin-20200607_7192d34-aarch64-2mara
xfce4-xkb-plugin-0.8.1-aarch64-1mara
I'm guessing that some part of the installation for the kernel isn't happening, so removing the files breaks it. There is also nothing in the default /etc/slackpkg/blacklist . I tried to get a serial console up to my board, but that didn't work with either a CP2102 or FTDI FT232RL, at 1500000 8N1N, so I can't give any more useful feedback there. I've done it several times now, and I haven't done anything extra before updating. I'm trying to go through my instructions to make sure they're easy for a layman, so it's by the numbers simple.

Also, there's something wrong with the osdn.net mirrors. Some files on some mirrors are showing 404, and slackpkg is saving a 0 byte file for each. That upsets it when it's trying to install them. It was also throwing md5sum and gpg errors, but I think they were all caused by the 404 thing. Switching to dl.slarm64.org links fixed that. Sorry for sucking up your bandwidth.
Code:
https://osdn.net/projects/slarm64/storage/slarm64-15.0/
https://osdn.net/projects/slarm64/storage/slarm64-current/
If you need any more info, feel free to ask. I don't mind doing stuff to this board for a little while to test. Once it's managing it's printer, I'd like to leave it there.
 
Old 03-12-2022, 02:02 AM   #7
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,865

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JWSmythe View Post
Just a quick FYI/bug report. I'm writing up some nice instructions for getting Octoprint up on the Rock64. In doing that, I'm trying to do everything "right". If you do the recommended slackpkg commands, it will brick it. Well, just not boot to that SD again, until you reimage or fix it.

Code:
slackpkg update 
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system
It's the slackpkg clean-system that's doing it.

The image I'm installing with is: slarm64-current-aarch64-xfce-rock64-5.16.9-build-20220214.img
I was doing it on Mar-10-2022 and Mar-11-2022.

It did it using both slarm64-15.0 and slarm64-current from

Code:
http://dl.slarm64.org/slarm64/slarm64-15.0/
http://dl.slarm64.org/slarm64/slarm64-current/
At the beginning of 'slackpkg clean-system', it says that it's going to remove these packages. They're all listed, even though it's obvious that some are totally unrelated. Just trying to be complete.

Code:
ffmpeg-rockchip-4.4.1-aarch64-2
kernel-firmware-rk3328-5.16.9-aarch64-1mara
kernel-headers-rk3328-5.16.9-aarch64-1mara
kernel-modules-rk3328-5.16.9-aarch64-1mara
kernel-rk3328-5.16.9-aarch64-1mara
kernel-source-rk3328-5.16.9-noarch-1mara
libass-20210619_4779444-aarch64-1mara
libdrm-rockchip-2.4.109-aarch64-1mara
libgl-rk3328-r7p0-aarch64-6mara
lightdm-1.30.0-aarch64-7mara
lightdm-gtk-greeter-2.0.8-aarch64-1mara
mpv-rockchip-0.34.0-aarch64-1mara
transmission-20220102_a5c6168-aarch64-1mara
xfce4-alsa-plugin-20200607_7192d34-aarch64-2mara
xfce4-xkb-plugin-0.8.1-aarch64-1mara
I'm guessing that some part of the installation for the kernel isn't happening, so removing the files breaks it. There is also nothing in the default /etc/slackpkg/blacklist . I tried to get a serial console up to my board, but that didn't work with either a CP2102 or FTDI FT232RL, at 1500000 8N1N, so I can't give any more useful feedback there. I've done it several times now, and I haven't done anything extra before updating. I'm trying to go through my instructions to make sure they're easy for a layman, so it's by the numbers simple.
That's right, the kernel used for rock64 is not vanilla (a number of patches have been applied), so when you purge, you remove the kernel.
Some packages are also removed that are not included in the slarm64 distribution (which repeats the slackware64 package base).

Quote:
Originally Posted by JWSmythe View Post
Also, there's something wrong with the osdn.net mirrors. Some files on some mirrors are showing 404, and slackpkg is saving a 0 byte file for each. That upsets it when it's trying to install them. It was also throwing md5sum and gpg errors, but I think they were all caused by the 404 thing. Switching to dl.slarm64.org links fixed that. Sorry for sucking up your bandwidth.
Code:
https://osdn.net/projects/slarm64/storage/slarm64-15.0/
https://osdn.net/projects/slarm64/storage/slarm64-current/
If you need any more info, feel free to ask. I don't mind doing stuff to this board for a little while to test. Once it's managing it's printer, I'd like to leave it there.
Уes, there is something strange with osdn.net.
 
Old 03-12-2022, 12:07 PM   #8
JWSmythe
LQ Newbie
 
Registered: Oct 2012
Location: Various
Distribution: Slackware64-current
Posts: 8

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
That's right, the kernel used for rock64 is not vanilla (a number of patches have been applied), so when you purge, you remove the kernel.
Some packages are also removed that are not included in the slarm64 distribution (which repeats the slackware64 package base).
Shouldn't kernel-* be added to /etc/slackpkg/blacklist by default? So normal users don't accidentally blow away their kernels? When I saw it, I assumed that it had been upgraded by another kernel-* package, and those were leftovers.

I have updated my instructions to warn about this. Just to not do clean-system, not update the blacklist.
 
Old 03-12-2022, 02:42 PM   #9
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,865

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JWSmythe View Post
Shouldn't kernel-* be added to /etc/slackpkg/blacklist by default? So normal users don't accidentally blow away their kernels? When I saw it, I assumed that it had been upgraded by another kernel-* package, and those were leftovers.

I have updated my instructions to warn about this. Just to not do clean-system, not update the blacklist.
To be honest, I would not like to remove the ability for the user to control his system (this happened for the first time).

osdn.net loading fixed.
 
1 members found this post helpful.
Old 03-12-2022, 05:24 PM   #10
JWSmythe
LQ Newbie
 
Registered: Oct 2012
Location: Various
Distribution: Slackware64-current
Posts: 8

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
To be honest, I would not like to remove the ability for the user to control his system (this happened for the first time).

osdn.net loading fixed.
Fair enough. I put it in my writeup, with an explanation. I hope someone might use it, but there's a good chance this whole thing will only ever be read by 3 people.

BTW, did you notice that wget doesn't work on https://dl.slarm64.org? It's something with the ZeroSSL CA. I guess it isn't in our cert bundle.

My site (also tested below) was failing with the ca-certificates included on the installation image, but it was fixed after updating ca-certificates to current. That was because of a recent problem with Let's Encrypt, which was fixed recently.

I checked it with wget on the Rock64, and on my Slackware64 14.2 server. Those are both broken It also fails under the Kali WSL on Windows, with the "certificate ... doesn't have a known issuer". I also updated the ca-certificates on the Rock64 with the mainstream Slackware-current package (20220309), and it still fails.

It does work fine with current Chrome on Win11. I know the Chrome folks are more attentive to keeping all the certs updated. It doesn't matter to me, and just using the http:// link works perfectly, but some people may not know or bother to look. I will try building my own updated ca-certificates package with the Slackware-current build scripts, and see if it fixes anything, but that looks like it last gathered the cert data 3 days ago. So it's a problem with ZeroSSL's trust, not slarm64, other than making life difficult for people.

Code:
root@rock64:~# slackpkg search ca-certificates

Looking for ca-certificates in package list. Please wait... DONE

The list below shows all packages with name matching "ca-certificates".

[ installed ] - ca-certificates-20220309-noarch-1

You can search specific files using "slackpkg file-search file".

root@rock64:~# wget https://dl.slarm64.org
--2022-03-12 22:02:18--  https://dl.slarm64.org/
Resolving dl.slarm64.org (dl.slarm64.org)... 193.151.15.132
Connecting to dl.slarm64.org (dl.slarm64.org)|193.151.15.132|:443... connected.
ERROR: cannot verify dl.slarm64.org's certificate, issued by ‘CN=ZeroSSL RSA Domain Secure Site CA,O=ZeroSSL,C=AT’:
  Unable to locally verify the issuer's authority. 
To connect to dl.slarm64.org insecurely, use `--no-check-certificate'.

root@rock64:~# wget https://jwsmythe.com
--2022-03-12 22:02:27--  https://jwsmythe.com/
Resolving jwsmythe.com (jwsmythe.com)... 47.206.58.201
Connecting to jwsmythe.com (jwsmythe.com)|47.206.58.201|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5281 (5.2K) [text/html]
Saving to: ‘index.html.2’

index.html.2                      100%[============================================================>]   5.16K  --.-KB/s    in 0s

2022-03-12 22:02:27 (18.5 MB/s) - ‘index.html.2’ saved [5281/5281]

root@rock64:~#
 
Old 03-12-2022, 07:43 PM   #11
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,865

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by JWSmythe View Post
BTW, did you notice that wget doesn't work on https://dl.slarm64.org? It's something with the ZeroSSL CA. I guess it isn't in our cert bundle.

My site (also tested below) was failing with the ca-certificates included on the installation image, but it was fixed after updating ca-certificates to current. That was because of a recent problem with Let's Encrypt, which was fixed recently.

I checked it with wget on the Rock64, and on my Slackware64 14.2 server. Those are both broken It also fails under the Kali WSL on Windows, with the "certificate ... doesn't have a known issuer". I also updated the ca-certificates on the Rock64 with the mainstream Slackware-current package (20220309), and it still fails.

It does work fine with current Chrome on Win11. I know the Chrome folks are more attentive to keeping all the certs updated. It doesn't matter to me, and just using the http:// link works perfectly, but some people may not know or bother to look. I will try building my own updated ca-certificates package with the Slackware-current build scripts, and see if it fixes anything, but that looks like it last gathered the cert data 3 days ago. So it's a problem with ZeroSSL's trust, not slarm64, other than making life difficult for people.

Code:
root@rock64:~# slackpkg search ca-certificates

Looking for ca-certificates in package list. Please wait... DONE

The list below shows all packages with name matching "ca-certificates".

[ installed ] - ca-certificates-20220309-noarch-1

You can search specific files using "slackpkg file-search file".

root@rock64:~# wget https://dl.slarm64.org
--2022-03-12 22:02:18--  https://dl.slarm64.org/
Resolving dl.slarm64.org (dl.slarm64.org)... 193.151.15.132
Connecting to dl.slarm64.org (dl.slarm64.org)|193.151.15.132|:443... connected.
ERROR: cannot verify dl.slarm64.org's certificate, issued by ‘CN=ZeroSSL RSA Domain Secure Site CA,O=ZeroSSL,C=AT’:
  Unable to locally verify the issuer's authority. 
To connect to dl.slarm64.org insecurely, use `--no-check-certificate'.

root@rock64:~# wget https://jwsmythe.com
--2022-03-12 22:02:27--  https://jwsmythe.com/
Resolving jwsmythe.com (jwsmythe.com)... 47.206.58.201
Connecting to jwsmythe.com (jwsmythe.com)|47.206.58.201|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5281 (5.2K) [text/html]
Saving to: ‘index.html.2’

index.html.2                      100%[============================================================>]   5.16K  --.-KB/s    in 0s

2022-03-12 22:02:27 (18.5 MB/s) - ‘index.html.2’ saved [5281/5281]

root@rock64:~#
try
Code:
update-ca-certificates
after that should work.
 
Old 03-13-2022, 04:08 PM   #12
JWSmythe
LQ Newbie
 
Registered: Oct 2012
Location: Various
Distribution: Slackware64-current
Posts: 8

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
try
Code:
update-ca-certificates
after that should work.
Looks like someone fixed something. It works now, without running update-ca-certificate. The timestamp on ca-certificates.crt is a few minutes before the tests I commented with.
 
Old 03-13-2022, 11:20 PM   #13
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Rep: Reputation: Disabled
On a slightly different note, I am running into an issue with u-boot when trying to build a post-"dirty pipe" image for this board. (bold emphasis added)

Code:
  UPD     include/generated/timestamp_autogenerated.h
  CC      cmd/version.o
  AR      cmd/built-in.o
  LD      u-boot
  OBJCOPY u-boot-nodtb.bin
./"arch/arm/mach-rockchip/make_fit_atf.py" \
arch/arm/dts/rk3328-rock64.dtb > u-boot.its
  RELOC   u-boot-nodtb.bin
  MKIMAGE u-boot.itb
/hdd/slarm64/images_build_kit/build/source/u-boot /hdd/slarm64/images_build_kit/build/source/u-boot
tools/mkimage: Can't open /hdd/slarm64/images_build_kit/build/source/rkbin/bin/rk33/rk3328_ddr_333MHz_v1.19.bin: No such file or directory
Error: Bad parameters for image type
Usage: tools/mkimage -l image
          -l ==> list image header information
       tools/mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
          -A ==> set architecture to 'arch'
          -O ==> set operating system to 'os'
          -T ==> set image type to 'type'
          -C ==> set compression type 'comp'
          -a ==> set load address to 'addr' (hex)
          -e ==> set entry point to 'ep' (hex)
          -n ==> set image name to 'name'
          -d ==> use image data from 'datafile'
          -x ==> set XIP (execute in place)
       tools/mkimage [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
           <dtb> file is used with -f auto, it may occur multiple times.
          -D => set all options for device tree compiler
          -f => input filename for FIT source
          -i => input filename for ramdisk file
          -E => place data outside of the FIT structure
          -B => align size in hex for FIT structure and header
Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-p addr] [-r] [-N engine]
          -k => set directory containing private keys
          -K => write public keys to this .dtb file
          -G => use this signing key (in lieu of -k)
          -c => add comment in signature node
          -F => re-sign existing FIT image
          -p => place external data at a static position
          -r => mark keys used as 'required' in dtb
          -N => openssl engine to use for signing
       tools/mkimage -V ==> print version information and exit
Use '-T list' to see a list of available image types
A quick look in the directory with the missing file shows that a version bump is needed in the mentioned binary:

Code:
root@quartz:/hdd/slarm64/images_build_kit# ls /hdd/slarm64/images_build_kit/build/source/rkbin/bin/rk33/
px30_bl31_v1.22.elf                    rk3308_ddr_451MHz_uart4_m0_v1.31.bin*    rk3366_miniloader_v1.02.bin   rk3399_miniloader_spinor_v1.14.bin*
px30_bl32_v1.15.bin                    rk3308_ddr_589MHz_uart2_m1_v1.31.bin     rk3366_usbplug_v1.02.bin      rk3399_miniloader_v1.26.bin*
px30_ddr_333MHz_v1.16.bin*             rk3308_ddr_589MHz_uart4_m0_v1.31.bin*    rk3368_bl30_v2.13.bin         rk3399_usbplug_spinor_v1.14.bin*
px30_miniloader_slc_v1.31.bin*         rk3308_miniloader_v1.27.bin              rk3368_bl30_v2.16.bin*        rk3399_usbplug_v1.26.bin*
px30_miniloader_v1.31.bin*             rk3308_miniloader_wo_ftl_v1.27.bin       rk3368_bl31_v1.91.bin*        rk3399pro_bl31_v1.35.elf
px30_usbplug_slc_v1.31.bin*            rk3308_usbplug_v1.27.bin                 rk3368_bl32_v0.10.bin         rk3399pro_bl32_v2.01.bin
px30_usbplug_v1.31.bin*                rk3308_usbplug_wo_ftl_v1.27.bin          rk3368_ddr_600MHz_v2.06.bin*  rk3399pro_ddr_666MHz_v1.25.bin*
rk322xh_bl31_v1.46.elf*                rk3326_bl31_v1.22.elf                    rk3368_miniloader_v2.58.bin*  rk3399pro_ddr_800MHz_v1.25.bin*
rk322xh_bl32_v2.01.bin                 rk3326_bl32_v1.15.bin                    rk3368_miniloader_v2.68.bin*  rk3399pro_ddr_933MHz_v1.25.bin*
rk322xh_ddr_333MHz_v1.17.bin           rk3326_ddr_333MHz_v1.16.bin*             rk3368_usbplug_v2.58.bin*     rk3399pro_miniloader_v1.26.bin*
rk322xh_ddr_400MHz_v1.17.bin           rk3326_miniloader_aarch32_slc_v1.29.bin  rk3368_usbplug_v2.62.bin*     rk3399pro_usbplug_v1.26.bin*
rk322xh_miniloader_v2.50.bin*          rk3326_miniloader_aarch32_v1.16.bin      rk3368_usbplug_v2.68.bin*     rknpu_lion_bl31_v1.12.elf*
rk322xh_usbplug_v2.50.bin*             rk3326_miniloader_slc_v1.31.bin*         rk3368h_bl31_v2.28.elf*       rknpu_lion_bl32_v1.13.bin
rk3308_bl31_aarch32_v2.22.elf*         rk3326_miniloader_v1.28.bin*             rk3368h_bl32_v2.01.bin        rknpu_lion_ddr_933MHz_v1.04.bin
rk3308_bl31_v2.22.elf*                 rk3326_usbplug_slc_v1.31.bin*            rk3399_bl31_v1.35.elf         rknpu_lion_miniloader_usb_v1.03.bin*
rk3308_bl32_v1.16.bin                  rk3326_usbplug_v1.28.bin*                rk3399_bl32_v2.01.bin         rkpx5_miniloader_v2.62.bin*
rk3308_ddr_393MHz_uart2_m1_v1.31.bin*  rk3328_ddr_333MHz_v1.17.bin              rk3399_ddr_666MHz_v1.25.bin*
rk3308_ddr_393MHz_uart4_m0_v1.31.bin*  rk3328_ddr_400MHz_v1.17.bin              rk3399_ddr_800MHz_v1.25.bin*
rk3308_ddr_451MHz_uart2_m1_v1.31.bin*  rk3366_ddr_800MHz_v1.00.bin              rk3399_ddr_933MHz_v1.25.bin*

I recall that the last time this happened I worked around it with a symlink. I just wanted to bring it up here in case you wanted to add a more elegant solution.

Thank you, as always.
 
Old 03-14-2022, 02:05 AM   #14
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,865

Original Poster
Rep: Reputation: Disabled
This is due to the fact that at some time the rkbin repository was not available at https://github.com/rockchip-linux/rkbin and I switched to https://github.com/caesar-github/rkbin.git

Let us turn on https://github.com/caesar-github/rkbin.git
 
1 members found this post helpful.
Old 03-17-2022, 01:00 AM   #15
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
This is due to the fact that at some time the rkbin repository was not available at https://github.com/rockchip-linux/rkbin and I switched to https://github.com/caesar-github/rkbin.git

Let us turn on https://github.com/caesar-github/rkbin.git
Hmmm... alright. Now I am getting a different error in roughly the same spot:

Code:
  MKIMAGE tpl/u-boot-tpl-rockchip.bin
  CAT     idbloader.img
  CAT     u-boot-rockchip.bin
  UPD     include/generated/timestamp_autogenerated.h
  CC      cmd/version.o
  AR      cmd/built-in.o
  LD      u-boot
  OBJCOPY u-boot-nodtb.bin
./"arch/arm/mach-rockchip/make_fit_atf.py" \
arch/arm/dts/rk3328-rock64.dtb > u-boot.its
  RELOC   u-boot-nodtb.bin
  MKIMAGE u-boot.itb
/hdd/slarm64/images_build_kit/build/source/u-boot /hdd/slarm64/images_build_kit/build/source/u-boot
Error: SPL image is too large (size 0x7800 than 0x7000)
Error: Bad parameters for image type
Usage: tools/mkimage -l image
          -l ==> list image header information
       tools/mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
          -A ==> set architecture to 'arch'
          -O ==> set operating system to 'os'
          -T ==> set image type to 'type'
          -C ==> set compression type 'comp'
          -a ==> set load address to 'addr' (hex)
          -e ==> set entry point to 'ep' (hex)
          -n ==> set image name to 'name'
          -d ==> use image data from 'datafile'
          -x ==> set XIP (execute in place)
       tools/mkimage [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
           <dtb> file is used with -f auto, it may occur multiple times.
          -D => set all options for device tree compiler
          -f => input filename for FIT source
          -i => input filename for ramdisk file
          -E => place data outside of the FIT structure
          -B => align size in hex for FIT structure and header
Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-p addr] [-r] [-N engine]
          -k => set directory containing private keys
          -K => write public keys to this .dtb file
          -G => use this signing key (in lieu of -k)
          -c => add comment in signature node
          -F => re-sign existing FIT image
          -p => place external data at a static position
          -r => mark keys used as 'required' in dtb
          -N => openssl engine to use for signing
       tools/mkimage -V ==> print version information and exit
Use '-T list' to see a list of available image types

I have tried switching between the two sources for rkbin as well as u-boot-tools in config/sources/rockchip.inc, but nothing lets me get past the u-boot compilation stage above.

FWIW, I am getting something similar when I try to build images for Quartz64 also. So, maybe something is going on with the rockchip boot sources and I just need to be more patient.

Just for your info, nothing critical. Thanks much.
 
  


Reply

Tags
pine64 team, rk3328, rockchip, slackware, slarm64


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Slackware for Rock64 RK3328 sndwvs Slackware - ARM 83 01-25-2022 03:49 PM
[SOLVED] Station M1(RK3328)/P1(RK3399) (slarm64, aarch64) sndwvs Slackware - ARM 10 12-07-2021 10:34 AM
[SOLVED] Rock Pi E RK3328 (aarch64) sndwvs Slackware - ARM 10 12-07-2021 10:23 AM
LXer: Meet ROCK64, a 4K-Capable Single-Board Computer That Can Run Android 7.1, Debian LXer Syndicated Linux News 0 07-07-2017 09:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > slarm64

All times are GMT -5. The time now is 06:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration