switch
-
Posts
17 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Community Map
Posts posted by switch
-
-
The Libre Computer Renegade RK3328 has hardware AES support. Should it not be listed by `lsmod` if the module is activated?
$ grep aes /proc/cpuinfo Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid $ lsmod | grep aes $
How can one verify that the AES chip is being utilized?
I'm on the Armbian 22.11 Jammy release (Kernel 5.15.y, Release date: Nov 30, 2022).
-
On 10/2/2019 at 3:57 AM, Igor said:
This feature was a work from someone that was not a part of the core group. I said: do it and if it doesn't break anything we will accept it. We are unable to support it so functionality will be either removed or if someone takes a look what is wrong. I saw other people reporting, so its indeed broken.This is unfortunate because building an image with cryptroot pre-installed is a very useful feature to have, doing it manually later is hell.
I'll create a Github issue and ping the author of the pull to see if he or anyone else is able to fix it.
-
I'm attempting to build an image for the ROC-RK3328-CC (Renegade) with cryptroot encryption (and SSH unlock) enabled, but I run into weird behavior.
The board will start and I can SSH in and reach the BusyBox prompt. So far so good but from what I've gathered I should enter the command "unlock" there to display the cryptroot password prompt. However it only results in the message -sh: unlock: not found. I read somewhere else the command might be "cryptroot-unlock" but that instead gives nothing, not even the error message.
Furthermore, regardless whether I enter any commands, around 10 seconds into the SSH session it will freeze and I eventually get kicked off with a broken pipe error. I suspect the board is restarting by itself but it is difficult to verify because it is running headless. After a few seconds I'm able to SSH in again for another ~10 sec session.
Building it without cryptroot works just fine and the board starts normally and I can SSH in. I have not tested building it with cryptroot only (without the SSH-unlock ability), because again it is difficult to verify due to the headless setup.
Has anyone run into these kind of behavior when building Armbian images with cryptroot setup or have any idea what's gone wrong? Is it a bug in the build cryptroot feature?
Below is my config-default.conf
KERNEL_ONLY="no" KERNEL_CONFIGURE="no" CLEAN_LEVEL="make,debs,oldcache" DEST_LANG="en_US.UTF-8" EXTERNAL_NEW="prebuilt" INSTALL_HEADERS="yes" LIB_TAG="master" USE_TORRENT="yes" CARD_DEVICE="/dev/sdb" BOARD="renegade" RELEASE="buster" BUILD_MINIMAL="yes" CRYPTROOT_ENABLE="yes" CRYPTROOT_PASSPHRASE="password" CRYPTROOT_SSH_UNLOCK="yes" CRYPTROOT_SSH_UNLOCK_PORT="2222"
-
I'm trying to do the same thing on a RK3328 Renegade but receiving some error messages during the process.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete.
I received this message three times during the process. The message may have been different, probably similar, but they flashed by so quickly I didn't have time to read them.
After a reboot the eMMC does seem to be working fine and the device boots but I'm just curious to what is causing these messages and if it could potentially have caused some data to be corrupted on the system installed on the eMMC. Could anyone provide some insight?
-
On 7/18/2018 at 10:22 AM, tkaiser said:
Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato).
Is there anything I can do to assist in this, e.g. reach out to Firefly and ask them for certain settings? I would need to know exactly what to ask them.
To everyone: besides the SD issues, do all other functions seem to be running smoothly on the Renegade with this image, in your testing? or is there anything else I should ask Firefly when I contact them.
Thx guys
-
Thanks for the explanation, @tkaiser. I'm assuming manufacturers do not provide data about the random IO performance of their cards, hence why we're left to test them ourselves..
It looks like the Extreme card that I tested even outperforms the Extreme Pro in your tests. but I suppose it also depends on the device used for testing. Perhaps a positive data point if we're trying to determine the Renegade's sd card read/write capabilities?
-
1 hour ago, tkaiser said:
Random IO performance of the rootfs is usually the problem. I would use the iozone call from here, test SD card performance and report back.
I ran 'iostat 5' in a separate ssh sesh but I don't know how to identify anomalies. I also don't know how to interpret if there are any issues with the iozone results but here's the output:
SanDisk Ultra 8gb
SpoilerInclude fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 2132 2224 7632 7648 6723 803
102400 16 7335 6989 15353 15359 14942 98
102400 512 10399 8716 23070 23060 20331 2336
102400 1024 11002 11727 23244 23237 23062 4767
102400 16384 11045 10120 23407 23405 21016 9174iozone test complete.
SanDisk Extreme 32gb
SpoilerInclude fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 3232 3316 10065 9965 9276 4512
102400 16 8299 8482 17180 17186 17069 10857
102400 512 21183 21135 23120 23130 23141 20726
102400 1024 22535 22556 23286 23298 23292 21853
102400 16384 22243 22289 23462 23451 23451 22479iozone test complete.
-
@JMCC I'm not sure I understand the issue you're experiencing but I had an instance when I was unable to write (to /boot/ iirc), despite using sudo. Solved it by using the root account instead.
Also, I am experiencing some speed hiccups (temporary freezing) but I cannot recreate it at will. I do suspect things run snappier on my Raspberry Pi (e.g. during apt install) and I find myself a bit disappointed with the speed of the Renegade. Also in xfce. I do not know if this is due to the card itself (slow r/w which causes temporary freezing), or bugs in the Armbian image, or whatever else.
-
Thanks but I've seen that pull request. The post-install script posted in the thread is kind of a mess because of the author's special use case (sata drive with dedicated root and data dirs) which further complicates an already-confusing process. At least I was having difficulty making sense of it when I was trying to get it to work and eventually gave up, I'm not as experienced with these things as some of you guys.
I suppose my only option would be to try building an image of my own with the cryptsetup build options configured. I'll be following the instructions in the Armbian docs but is there anything in particular I should be doing when building for the Renegade? (I'm not clear on if the board is officially supported or not)
-
Just wanna check if anyone has successfully gotten full disk encryption to work for the Renegade? I've been following a couple different tutorials but mostly this tutorial in the forum:
which is for Armbian on Orange Pi (was hoping the process would be same or similar for the Renegade). Nonetheless I've been unsuccessful in my attempts, the board won't boot with the SD card with the encrypted partition. Does anyone have any ideas?
-
-
On 7/7/2018 at 9:17 PM, JMCC said:
Can you please do somethings that performs intensive SD card I/O,
Here you go:
For reference the card is a SanDisk Ultra 8gb HC I class 10 (at least that's what's printed on it).PS I previously stated that my board shows 4GB but I'd just like to confirm.. 'free -m' shows 3924, which is normal for 4GB right?
-
The new image boots successfully! Great job guys, thanks for your work.
PS: It shows 4gb RAM for my board, as it should. Let me know if there's anything else you'd like me to check or test and I'll do my best to help.
-
The image isn't booting for me, is there anything that I've missed doing? Tried flashing using both dd and etcher
-
No sun for me this summer! Huge thanks to everyone involved for making this available
-
I'd love an Armbian image for this board
Renegade hardware AES support not activated under Armbian?
in Libre Renegade
Posted
Hi @TonyMac32,
Thanks for that information. Looking forward to the kernel update.