Hi,
I’m having difficulties booting from the arm64 image on my helios64. I followed the download instructions, replacing of=/dev/sdX with of=/dev/mmcblk0 because it’s a SD-card.
After sticking the SD-card into the machine lights go on but the machine does not seem to register on the network and I can’t ping it.
Seen as it’s a headless NAS, I’m not sure how to debug further. Without a boot/webui/ssh-connection shell I can’t get a log, can I?
@RlndVt Hi and welcome to Rockstor
The initial install needs to be done with a display and keyboard attached to the device, as there are some setup activities that need user input. Once this is all completed and Rockstor is running then you can go to headless operation.
I’ve not used the hardware you mention, but I have successfully installed the arm image to a Pi4 device.
Hello Geoff,
So it doesn’t work like say OMV where the first boot provides a web-ui from where the initialization can be done? Development in that direction would be great!
Does the Pi image also require a display and keyboard for first configuration?
I’ll try connecting a display over usb-c, see if that gives me a display when I have time.
Thanks!
@RlndVt I can chip in on this one. And welcome to the Rockstor community from me also.
Re:
Yes, all our images have a first boot config. But the ARM64EFI images expect a serial console and can be setup from that.
That may work but if your device has a serial console capability, likely, then go for that. You can then use an appropriate adaptor to see the console on a pc. It’s a one off thing so there after it’s Web-UI all the way. See the following for what is to be done on first boot:
https://rockstor.com/docs/installation/installer-howto.html
Bar the drive selection, as for our Arm installers we use a self expanding image hence no transfer needed from installer to target system disk as the sd-card (say) is the target system disk.
Our ARM64EFI images assume your hardware’s firmware implements the required ‘Embedded Boot’ or ‘Server boot’ standard, if so then you should be good. See the following readme section in our installer:
If not then a contribution to an alternative profile may be your way to getting a compatible Rockstor install. That last Readme is in the repo that builds, via kiwi-ng, our installers. And since openSUSE use this same technology (it’s theirs) to make quite a few specific arm compatible boards you may well be able to copy the config from there. But you may, as @GeoffA indicates, simply need to get a console on that hardware to do the initial setup.
And what you probably need is a serial to usb adapter so that you can run minicom say on your desktop/laptop. Just be sure to get the voltage correct. There images are targeted as ARM servers which do implement Embedded Boot/Server boot, and our Pi4 has special Pi4 adjustments. Again the latter is taken from our upstream openSUSE images also made by kiwi-ng.
A display over usb-c doesn’t sound right. And will likly not work. Just look up how to get a serial console hookup from your board. Then you have full access and will see the full bootup. You can also test this installer to know what it does by setting up an ARM64 emulated KVM for instance. That is how we test these images. Other than on an actual Ten64 that is.
Hope that helps.
Hello Phill, thank you for your detailed response!
Oh that should work out. Thanks! The makers advertise a serial connection capabilities, haven’t tested but that should work!
@RlndVt Hello again.
Re:
Yes that’s the one. I’ve used that sort of thing a number of times on all sorts of devices. It’s quite interesting to see it in action actually. Also gives you boot level access which is nice. Most ARM stuff is this way as they often don’t have a graphics card / chip in at all. The Pi4 is not typical that way. The Ten64 has a nice system where they have a serial to usb build in so you only need a usb cable. But most required a special adapter. Take great care to wire up correctly and more importantly to select an adaptor that is the correct voltage. Very important as you can break stuff hardware wise if you connect the wrong voltage device to some devices.
Hope that helps and let us know how you get on with this. You may be the first to try our a Helios64 and they are a great looking machine. It may be that our image doesn’t work but either way you will need a serial console to know and to check any custom installer profile you may end up creating. I’m not familiar with the specific needs of this device and me and @Flox were actually super interested in this device ourselves but alas they seem to folded before we even got going on that one.
Hope that helps and as always let us know how this goes. As they state, they are open source so it will be possible to develop a kiwi-ng profile for this system. But I’m not familiar with the requirements. Fingers crossed they support the above mentioned standards and you will be sorted. Do send some pics of your connecting this machine up to serial and any progress you make.
The Helios64 offers the same! It does have a manufacturing ‘defect’ where the backplane doesn’t allow a USB-C cable to insert far enough. The ‘fix’ is to remove/shaveback the plastic covering of the cable.
I just removed the covering of a cheapish cable, and could create a serial connection easily!
I’ll be sure to report any issue’s! (And possibly my solutions.) No news will be good news though.
I’ll take pictures when I start my RockStor installation!
Okay poor start.
I had the opportunity to try booting with the serial connection, but I got no output what so ever. I’ll have a go with no SD-card, and try and re-image the SD-card. Sadly the armbian build of helios64 seems to have been taken offline (
), so can’t check if it is the SD-card itself. I’ll try copying the serial dump info when booting from my armbian install.
It will have to wait a bit, till a scrub has been finished.
As a side note, why is the image ~16GB? From what I see there is quite some free space, can’t that be decreased and expanded on first install/setup? (FWIW, it seems like the image now is (a bit) too big for my 16GB card, had to find a 32GB one.)
I just tried without a SD-card and with OpenSUSE arm64 JeOS, both gave me no output whatsoever on trying to boot. This is the output I get when booting armbian:
DDR Version 1.24 20191016
In
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 928MHZ
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 928 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 254
SdmmcInit=2 0
BootCapSize=100000
UserCapSize=14910MB
FwPartOffset=2000 , 100000
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=60906MB
FwPartOffset=2000 , 0
StorageInit ok = 78884
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt…
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xe5ba8
RunBL31 0x40000
NOTICE: BL31: v1.3(debug):42583b6
NOTICE: BL31: Built : 07:55:13, Oct 15 2019
NOTICE: BL31: Rockchip release version: v1.1
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: plat_rockchip_pmu_init(1190): pd status 3e
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x200000
INFO: SPSR = 0x3c9U-Boot 2020.10-armbian (Sep 08 2021 - 10:55:50 +0000) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 4!? 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 8 ms (388.7 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 166 bytes read in 4 ms (40 KiB/s) 13855157 bytes read in 595 ms (22.2 MiB/s) 28580352 bytes read in 1210 ms (22.5 MiB/s) 81924 bytes read in 11 ms (7.1 MiB/s) 2698 bytes read in 8 ms (329.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Moving Image from 0x2080000 to 0x2200000, end=3de0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 13855093 Bytes = 13.2 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f51b9000, end f5eef975 ... OK Loading Device Tree to 00000000f513c000, end 00000000f51b8fff ... OK Starting kernel ...
For me this feels like a dead end, would love input.
@RlndVt That’s a shame but:
Not really. I’ve not got the required knowledge to ‘fix’ this but you may end up aquiriing it with some more reading and it may then most likely be possible to craft a Rockstor installer that is tailored to this hardware. It would seem from your experience that the hardware is looking for an arrangement we don’t have. The Pi4 also has ‘special’ requirements but they are well known so we simply copied those requirements from our upstream (openSUSE Leap) wiki-ng configurations. OpenSUSE offer a lot of hardware specific images which is nice but not one for the Helios64 by the looks of it.
If/when you do find what is required to boot these systems you should be able to fashion it in kiwi-ng. Take a look at the ‘special’ arrangements used in our Pi4 build:
and the partition messing about that is also required for Pi4s which is all held in a script of it’s own that is invoked for our Pi4 related profiles from this line:
and the script itself to edit partitions to be ‘special’ for the Pi4 so that it will boot is here:
Likely you will need to establish the exact nature required on a system disk for the Helios64 to boot successfully. They released all this info I believe, or at least hope, so it should be possible. And our installer builder kiwi-ng is super capable so you are very likely to be able to fashion a custom installer once you know the magic required to make it happy to boot.
The good news is that your example successful boot uses U-Boot as does our ARM64 image so that’s promising. I’m afraid my knowledge in this area (ARM BOOTING) is rather lacking however. Although our Ten64 partner @mcbridematt may well be able to step in here with expert guidance but their platform is standards compatible and so just works out-of-the-box as it were. And as stated our Pi4 target is now very well understood in upstream where we just copied out config from.
I’d definitely not give up hope just yet, as all you need is the requirement it expects of it’s boot drive. Then implement those via kiwi-ng and you should be home and dry with being able to build your own installer. If you manage this it would be great to have it submitted to our config as there are likely quite a few other Helios64 owners who would like at least the option to try our offering, or a plain openSUSE for that matter. We are ourselves pretty much a JeOS openSUSE bar the ‘rockstor’ bit that is.
Thanks for the dump and do keep an eye on this thread as you may well get some input from folks more knowledgeable than me in this area.
As a basic start it would be good to know the partition layout of the working boot? The Parted program should be able to ‘print’ this for your.
We have 16 GB, akin to upstream, as a recommended minimum and indeed our Pi4 image does start out much smaller. But our ARM64EFI image was contributed primarily for the Ten64 by @mcbridematt and there was a requirement to use qcow2 as the image in this case. And when using this format the self expansion ‘bit’ failed. So we played safe and set it to a workable minimum of 16 GB to allow for snapshots over time which can end up taking quite a lot of space. These snapshots then allow boot-to-snapshot recovery which is nice and so the room they take is worth it. If you want to reduce this size then just change the following line in the DIY installer config:
And the consequent installer, once built, will be the size you designate. But I wouldn’t go much below 16 GB if you can help it. With some snapshot config options and care you could go down to say 8 GB however and still have some breathing room.
Hope that helps and let us know how your research goes on this front. Do you know how many Helios64’s were actually released into the wild by chance. They are super nice and it’s a shame they didn’t manage to pull off at least this manufacturing run.
Thank you again for the detailed response!
My first instinct is that this is too much for me to solve. However, it does seem like you have broken down the problem into more bit-size chunks. I’ll see if can find the necessary information to get started!
The partition layout doesn’t seem to be very exciting:
(parted) print
Model: SD SR64G (sd/mmc)
Disk /dev/mmcblk1: 63.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 16.8MB 63.2GB 63.2GB primary ext4
Could the problem be so simple as MBR boot and GPT/EFI boot?
Sadly I don’t know. I agree it’s a shame, a.o. they were victims of the great chip-shortage.
Not sure whether this can/could help to get closer to at least run a flavor of OpenSUSE on the Helios, but I found this Reddit post where the poster used the rootfs from OpenSUSE and used the boot files from an armbian image available for the Helios: https://www.reddit.com/r/openSUSE/comments/jjze7j/porting_opensuse_to_helios64/
Good find; thanks! I contacted the poster to ask if they had any luck or tips, but it sounds like they abandoned the idea. They did give me the same advice as Philip, do research:
Yes and no… In a strange turn of events, I have ended up porting opensuse to custom hardware as part of my job! So I’m extremely familiar with the process now. But I never sat down to do it at home for the helios64.
I can tell you how to get going. Step 1 is research. Look at armbian and try to find the device trees and kernel patches that are being applied.
Then you will have to consult the rockstor build system to work out how to build an image. Alternatively (given that this is an openSUSE subreddit) you could build a rockstor distro using kiwi and obs
I honestly have a lot of difficulty making heads or tails of relevant armbian kernel patches. But we push on.
Researching SOC compatibility, I found that OpenSUSE has some (testing) JeOS images for a couple of machines also using RK3399, which seems like a good place to start! [1-3] (With the Pinebook seeming the most tested/promising.) Does anyone know where I can find the related (wiki-ng) configurations?
I found a mirror holding newer armbian builds, so I should be able to extract a few files from that if necessary. [4]
[1] https://en.opensuse.org/HCL:ROCKPro64-RK3399
[2] https://en.opensuse.org/HCL:Pinebook-Pro-RK3399
[3] https://en.opensuse.org/HCL:Firefly-RK3399
[4] https://mirrors.netix.net/armbian/dl/helios64/archive/
Hi everyone, some new questions:
I’ve been testing the kiwi-ng, but I can’t get the Arm64 image to build. Does kiwi-ng support building for different architectures (arm64 on x86)? Or must I use arm64 device to build a arm64 image?
E:
x86 host:
[ ERROR ]: 12:38:08 | KiwiProfileNotFound: profile Leap15.3.ARM64EFI not found for host arch x86_64
ARM64 host:
[ ERROR ]: 13:33:31 | KiwiBoxPluginArchNotFoundError: No box configuration found for architecture: aarch64
So how do I build a image?
I believe I have gathered all the relevant kernel patches used for the armbian rockchip kernel. What would be the best way to ‘package’ the custom kernel? I think I’m looking for something equivalant to Arch’s PKGBUILD. Or would the OBS allow for a more automated process?
@RlndVt Sounds like some progress.
Re kernel patches, they have to be compatible for the openSUSE kernel. The main/first issue is to build an installer that the system recognises as a bootable device. Hence the parted info etc. Kiwi-ng should be able to do that via a custom profile. You may find that un-commenting our kernel backport will give all the patches required, but maybe not. But you have to have the thing see your installer as a boot device first.
The boxbuild method documented in the Readme should do it. But if not then you may have to setup a KVM that emulates ARM64 on an x86_64. This is super slow but doable. By way of example it too way longer for me to build early installers for ARM64 on a 4.2 GHz Haswell than it did to do the same on a Pi4. We now build all our ARM64 installers on a Pi4 actually, with openSUSE installed on it via one of their JeOS images. Although now we have our own installers I’ll likely move to using a Rockstor install when I get to re-do this setup.
So in short you need to emulate ARM64 on an x86_64 via a KVM machine say (if on a linux host), or use a donor ARM64 machine such as a Pi4.
Hope that helps.
@RlndVt We just posted at the same time, I’ll add a comment on this:
Re:
If you are on an ARM64 (say a Pi4 or an emulated machine) and it’s running the required host OS (openSUSE Leap 15.3) then you can use the non boxbuild method as your errors suggest they don’t have a ‘box’ for aarch64/ARM64.
We don’t yet use the boxbuild method ourselves as the Pi4 that builds our ARM64 installers runs openSUSE natively.
Hope that helps.
Hello Phillip.
For clarity, this is the command I tried to use:
./kiwi-env/bin/kiwi-ng --profile=Leap15.3.ARM64EFI --type oem --temp-dir=/mnt/volatile/kiwi-temp system boxbuild --box leap --box-memory 4G --box-smp-cpus=7 -- --description ./ --target-dir ./images.
This should be the ‘super-slow but doable’ build right?
Does it matter what specific image it is? Can it be tumbleweed, or must it match the Leap version? I was thinking of going with MicroOS.
Hello again @RlndVt,
Just a very brief input here as I believe I’ve seen something about it last time I check using boxbuild for cross arch building…
It does. I think I remember the universal box being recommended for cross-arch, especially if the target is aarch64. If you look at OBS, it does have an aarch64 build, whereas leap or tumbleweed do not, for instance:
universal:
leap:
Sorry for the very brief message but I hope it still helps,
Hello all
@Flox, thanks for the info. Sadly I couldn’t use the universal box to build a image.
Good news is I got a working build image with Leap JeOS on RaspberryPi4. I created my own config (draft Pull Request here [1]). All I really did was change my partition table to MBR, because that’s what I see on my armbian drive. Sadly that didn’t boot; no serial output again. I think the next step is testing a non-EFI image.
However I saw a comment [2] that seems to imply firmware=efi is required for ARM64. Is that true? Would removing that line be sufficient for disabling efi-boot?
[1] https://github.com/rockstor/rockstor-installer/pull/98
[2] <!--firmware="efi" See https://github.com/OSInside/kiwi/issues/1428 re AArch64 -->
Edit:
I’ve removed the efi flags I could find, and recreated a image. Sadly I got no output again. Little stuck again 
@RlndVt So it looks like your almost there.
Another shot in the dark is to try:
firmware=uefi
It’s slightly different. The relevance of this to ARM64 is specific currently for us in that our existing profiles require this. But that doesn’t mean it’s required for your profile.
Thanks for the update and see if uefi works.
Incidentally, if the following:
means you were able to achieve a bootable image on the Helios64 with a JeOS Pi4 image then why not replicate that in your new profile. Or are your saying that you were able to build your own image for the Pi4?
Hope that helps and apologies for loosing the thread a little on this one. I.e. does your current pr modifications result in a bootable image but you just don’t have a serial output? in which case look to the kernel parameters for our Pi4 profile:
Also note that the ARM64EFI profile (as that machine also has no graphics card) and it’s serial port setting requirement thus:
I.e. @mcbridematt used the “earlycon” option. It may be you also require this.
Just a thought. Apologies for not being able to offer anything more informed on this front.
Super exiting for you to be at least be creeping up on this one 
.
Hi Phillip
Oh! For me it feels like I’m still at square zero :).
Sure I’ll try that soon!
Just that I was able to boot on the Pi4. I will try the JeOS pi image on helios, haven’t tested to see what that does.
To be honest, I haven’t checked for booting beyond getting serial output. I imagine that if the system has any sign of life it should be in the form of serial output. Would any of those kernel parameters hide serial output?
Good tip, I’ll give it a try!
FWIW, these are the kernel parameters the armbian image uses:
cat /proc/cmdline
root=UUID=08a42967-5c72-4a18-b476-9a8e0ccc5d14 rootwait rootfstype=ext4 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=ccc514b5-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1