Hi,

 

I am working on enabling crust support in Armbian. A draft version of pull request is here. I have made the changes for the same. With my changes, crust compiles as part of building the image and gets bundled in u-boot. I can also see the following message from U-boot

 

U-Boot 2022.10-armbian (Jun 14 2023 - 13:49:59 +0000) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: FriendlyARM NanoPi NEO
DRAM:  512 MiB
Core:  61 devices, 18 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20ca0
MMC:   mmc@1c0f000: 0
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial
Out:   serial
Err:   serial
Starting SCP...
Net:   SCP/INF: Crust v0.5.10000
eth0: ethernet@1c30000
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1d000: USB EHCI 1.00
Bus usb@1c1d400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1d000 for devices... 1 USB Device(s) found
scanning bus usb@1c1d400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop

 

and the following message is present in dmesg output

 

[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.0

 

So I know that crust is getting loaded. I am not sure how I can test if its working as its supposed to be. I can use some guidance for the same.

 

Thanks in advanced

@jernej @ALIGMSTEN Could you please help me with this?

Is Crust even all that useful on ARM? It is a requirement now `last I checked?` with v2023.04 / ARM64. But on ARM, according to the Github it is still BETA.

 

I can say on the PineA64+, that when using Crust the board actually powers down and resets properly. It still has issues of course, but that has more to do with the revision of the board.

@c0rnelius How can I check that the board actually powers down and resets properly?

1 hour ago, Gunjan Gupta said:

 @ALIGMSTEN Could you please help me with this?

 

Hi Gunjan,  focused on H616  right now. Sorry, although very interested, cant add, don't have any experience! 

@ALIGMSTEN No problem. Thanks for the replying anyways

 

All well.

 

Obvious, though might be best here.

 

Interested users and contributors are encouraged to join #linux-sunxi on OFTC to discuss the firmware and its integration with other software.

 

 

 

Crust is successfully integrated on A64, H3, H5 and H6 in LibreELEC. R40 and H616 don't have co-processor, so they can't have it. I don't know A83T state. H3 needs additional U-Boot patches which are in conflict with other SoCs (including R40), so it's best to have them separated.

 

Easiest test is to use board with power button. Put board in sleep with "systemctl suspend" or power it down via command line (poweroff, shutdown now, etc.). Once it's in sleep or in stand by mode, press power button. If everything works as it should, board should come to life. Serial console is highly recommended during testing and a must for debugging any kind of issues.

@jernejThanks for replying back. Tried with systemctl suspend and power button connected to ap_reset, the board just reboots both with and without crust. I will try compiling and flashing LibreELEC and will see how that behaves.

Which board do you use for testing?

I am using nanopi duo2. I only have this single allwinner board at the moment.

I don't know this board, but it seems button is directly wired to reset pin, so reset is expected response. This board isn't the best choice for testing this. Maybe you can try with RTC wakeup. Or maybe even HDMI-CEC wakeup, but you need to change config for this one.

4 часа назад, jernej сказал:

Crust is successfully integrated on A64, H3, H5 and H6 in LibreELEC. R40 and H616 don't have co-processor, so they can't have it. I don't know A83T state. H3 needs additional U-Boot patches which are in conflict with other SoCs (including R40), so it's best to have them separated.

I agree with this statement

 

@Gunjan Gupta

You should not make changes to these files:

config/sources/arm64.conf

config/sources/armhf.conf

This is only needed by sunxi \ sunxi64.

@going

 

Thanks for the review. I will move the changes you have mentioned to sunxi_common and sunxi64_common. The PR is still wip and I would be making more changes as the testing proceeds.

10 часов назад, Gunjan Gupta сказал:

The PR is still wip and I would be making more changes as the testing proceeds.

The built-in ARISK controller can control the power supply and its own frequency independently.
If, for the debugging period, you manage to get it to report its status regularly to the UART, for example, this line:

AR1000: F=50 Mhz U=0.9 CPU0: F= 0 Mhz U=0 V T0=28 C

then I can check the performance on A64 and A83T processors.
When the system goes to sleep or shuts down as a result of system services or pressing a button,

the built-in controller must lower its own frequency to the minimum and turn off the power to the CPU.

When you press the PWR button, it should increase its frequency and supply voltage to the CPU and something else to resume the system.

 

Why do I pay attention to this?

A few years ago, a very bad effect was observed. When the "poweroff" command was given, the system turned off,

the LED on the board went out, but the processor chip housing began to warm up intensely.

The temperature rose from 35 C to 50 C.

Alright. some progress on testing.

 

Tried rtcwake command, that gave me a write error I will see what caused this later. My board doesn't have hdmi, so hdmi-cec is out of picture. That leaves me with IR, but the board doesn't have inbuilt IR receiver, but has some gpio pin to interface one. I didn't had an IR receiver so have ordered it and it will likely arrive by Monday.

 

Meanwhile, I enabled DEBUG_MONITOR in the crust config and used that for testing. This gave me access to debug terminal for crust when linux is suspended or powered off.

• I ran systemctl suspend that stopped linux and dropped me to crust debug console. I pressed w on the crust debug console and it brought back linux from suspended state.
• I powered off Linux and that too dropped me off to crust debug console. I pressed w and it rebooted the board.

So I guess its working the way it was expected.

 

I will also test if the system resumes on IR once that arrives and will try to debug why rtcwake command is not working.

16 hours ago, going said:

You should not make changes to these files:

config/sources/arm64.conf

config/sources/armhf.conf

This is only needed by sunxi \ sunxi64.

Moved the code as requested.

 

4 hours ago, going said:

The built-in ARISK controller can control the power supply and its own frequency independently.
If, for the debugging period, you manage to get it to report its status regularly to the UART, for example, this line:

AR1000: F=50 Mhz U=0.9 CPU0: F= 0 Mhz U=0 V T0=28 C

then I can check the performance on A64 and A83T processors.

I went through various config options, not sure I was able to locate a config that enables that kind of output. Does this require code changes in crust or is it already a builtin feature that needs to be enabled?

 

34 минуты назад, Gunjan Gupta сказал:

Does this require code changes in crust or is it already a builtin feature that needs to be enabled?

To be honest, I don't know much about this controller. Then a long time ago I tried to figure out this incorrect behavior and got stuck.

There wasn't enough free time. Today, when you implemented this, I assumed that you are a greater specialist and I want to ask you

about how you can check the frequency of the controller. Maybe it is possible in the "crust" debugging console?

Anyway, thanks for your work.

1 hour ago, Gunjan Gupta said:

I will also test if the system resumes on IR once that arrives

Note that crust is very board specific. If it doesn't have IR by default, you have to enable it in config. Apart from that, you have also select correct IR protocol and key code. On some boards you also have to select proper clock for IR.

Bought a usb multimeter.

 

Powered my board with the power cable connected to usb multimeter and usb multimeter connected to power adapter. Following are my observations

 

Current Armbian image with 6.1.30 kernel. This image doesn't have crust

Idle current usage - 0.15 Amps

current usage during sleep - 0.09 Amps

current usage after poweroff - 0.13 Amps

 

Armbian image with 6.1.33 kernel and Crust.

Idle current usage - 0.15 Amps

current usage during sleep - 0.00 Amps

current usage after poweroff - 0.00 Amps

 

Sleep state was triggered with

 

rtcwake -m mem -s 30

 

Now I can confirm this is working and reducing the power draw as expected. 

 

Thanks everyone for helping on the same.

3 часа назад, Gunjan Gupta сказал:

Now I can confirm this is working and reducing the power draw as expected. 

Are these your final changes?
I saw them in the pull request.

 

@Gunjan Gupta
You have removed the patches for the kernel that were previously.
Are they bringing in bad things?

10 minutes ago, going said:

Are these your final changes?
I saw them in the pull request.

yes, now the pull request is finalised. Unless someone reports any issue, I am not going to make more changes

 

10 minutes ago, going said:

You have removed the patches for the kernel that were previously.
Are they bringing in bad things?

They were not bringing any bad things. But I was trying to reduce changes to minimum and noticed that crust was working fine even without kernel changes. So I just removed them as we don't have to worry about maintaining those changes in the future

Gunjan, thank you for your work!

 

I have a Pine A64+ and want to use crust. In which images are the changes already integrated? I'm using a bookworm image which is some months old (but with all updates installed):

"Welcome to Armbian 23.8.1 Bookworm with Linux 6.1.53-current-sunxi64"

 

Do I have to re-flash? Or can I just re-install u-boot? Thank you

 

dmesg | grep -i scp
[    2.180921] scpi_protocol scpi: incorrect or no SCP firmware found
[    2.180937] scpi_protocol: probe of scpi failed with error -62

 

dmesg | grep -i psci

# no match

@mrfusionIf you have flashed Armbian 23.8 or later than you most likely will already be having crust support built in. On Pine64 however the crust configuration in use is a generic one and is not taking AXP chip in account. So power consumption might stay on bit higher side. But otherwise everything should work fine.

 

If you are unsure about crust is already enabled on your board, use sudo armbian-config > system > install option to flash latest u-boot

Thank you, I see it now:

dmesg | grep -i scp
[    2.150967] scpi_protocol scpi: SCP Protocol 1.2 Firmware 0.5.10000 version

 

But there's no PSCI. Should it?