Specs:
Uses an S922Z SOC (variant of S922X reb b - Dolby Vision/Audio licensed)
1 x microUSB2 port
1 x IR extenter (+6 internal IR blasters)
1 x IR receiver
1 x HDMI port
16GB eMMC
2GB DDR4-2400
No SDcard, USB3, SPDIF out, 3.5mm audio out
Currently Working:
HDR10, HDR10+, HLG
Dolby Vision profiles 4, 5, 7, 8 (same playback capabilities as AM6+/U22XJ)
DV FEL, TV & Player-led DV, CMV2.9/4.0
Dolby TrueHD and DD+ w/Atmos, DTS-HD/X
WiFi
CEC control
Bluetooth BR/EDR
**Widevine L1 & Playready support unaffected by unlock or CE
Not Working:
Bluetooth LE
IR (untested)
Unlocked Bootloader Required
USB booting requires an unlocked bootloader (read here for instructions). Any new/sealed 2nd gen Cube can be unlocked, follow the XDA thread, or this guide, to avoid updating the FireTV when powering on for the first time.
Download DTB
Get the latest DTB for the 2nd gen Cube here. The DTB is packed into the kernel.img, so just replace kernel.img on the CoreELEC partition of your USB drive with the provided one in the link, and boot.
The crash log indicates a problem with the dmc_monitor. The Cube also has problems with the MHU/mailbox node which results in timeouts during boot
[ 11.281127@0]- Warning: scpi wait ack time out 0
[ 21.521118@0]- Warning: scpi wait ack time out 0
[ 31.761129@0]- Warning: scpi wait ack time out 0
[ 42.001122@0]- Warning: scpi wait ack time out 0
For the moment, I have removed this node. These two issues together make me wonder if there is an issue with communication with the SMC/BL31?
Do you know if there are any differences as far as the SMC that need to be accounted for with Amlogic devices that use secure boot? @Portisch@vpeter
The default s922x DTB doesn’t cover the BL32 memory range in the reserved memory. I’m not sure how this isn’t an issue for other s922x devices? For now I’m using the native vendor dtb values below to fix the crashing. Alternatively, linux,secos could be enabled in reserved memory.
Makes sense. Let me know if there are any other DTB properties that require modification for secure boot.
Regarding the Mailbox/SCPI timeouts
[ 11.278713] Warning: scpi wait ack time out 0
[ 21.518713] Warning: scpi wait ack time out 0
[ 31.758718] Warning: scpi wait ack time out 0
[ 41.998712] Warning: scpi wait ack time out 0
[ 41.999168] usbcore: registered new interface driver snd-usb-audi
These always occur immediately before loading the snd-usb-audi driver. Deleting the MHU node, I can see that the usb driver is always loaded immediately after the bl301_manager driver
[ 1.103597] bl301_manager: driver init
[ 1.103638] bl301_manager: IR remote wake-up code: 0xffffffff
[ 1.104163] bl301_manager: IR remote wake-up code mask: 0xffffffff
[ 1.104964] bl301_manager: IR remote wake-up code protocol: 0x0
[ 1.105733] bl301_manager: enable 5V system power on suspend/power off state: 0
[ 1.107228] usbcore: registered new interface driver snd-usb-audio
I think the 4 (10sec each) SCPI timeouts are because the 4 bl301_manager commands are failing. I understand that the bl301_manager driver is not for all devices, and apparently not the Cube either. Is there a way to disable this driver from loading? the 40sec delay results in frequent system hangs / incomplete boots.
That sounds like good idea, I’d like to check that SCPI sends are working at all. Do you suggest adding one print command to send_scpi_cmd in scpi_protocol.c? Or something more elaborate than that?
example
static int send_scpi_cmd(struct scpi_data_buf *scpi_buf,
bool high_priority, int c_chan)
{
/* print log message */
pr_info("send_scpi_cmd called\n");
...
If it’s informative at all, I can upload the decrypted bootloader from the Cube.
Including the bl301_manager there are 8 send_scpi_cmd calls. 1 occurs after bl301_manager driver is initialized, then 3 more before each SCPI time out.
Maybe it’s specifically the enable 5V system power command that is attempting and failing send_scpi_cmd 4x? bl301_manager: enable 5V system power on suspend/power off state: 0
I was reviewing the operating points node for my DTB, and it’s organized a little differently than the w400-b.dtsi. I noticed an oddity in the w400-b.dtsi that looks like a potential error? I may just be misunderstanding how the node should be arranged.
With the native DTB the voltage is incrementally stepped up with each frequency, but with w400-b there is a drop in the voltage between opp07 &opp08?
Also, in cpu_opp_table0 why does w400-b max out at 1800Mhz and not 1900Mhz? Isn’t the maximum frequency of the small cores 1900Mhz? My native DTB goes up to 1900Mhz.
Lastly, the threshold values for Bifrost don’t increase incrementally throughout all the frequencies with w400-b:
high/low threshold values are sometimes higher and some times lower than the previous dvfs threshold values. With the native Cube values, there is a steady increase in the low/high threashold at every dvfs step
This is a copy of the native Cube DTS for comparison if you want a more detailed look 7224-3337_g12brevb-raven-2g.dts (100.5 KB)
The only way to find the correct values is to run performance tests in every case and find our the minimum required voltage.
We use by default performance as it gives best result with media playback handling.
So only highest case is used anyway and the steps between are mostly ignored.
Progress update on CoreELEC booting on the 2nd gen Cube. CE 20.2 has been booting stably the last few months. Updating to CE 20.3.
The 2nd gen Cube’s DTB is included in the kernel.img that can be downloaded here and placed on your CE flashed USB drive.
An unlocked bootloader is required to boot CoreELEC. Any new/sealed 2nd gen Cubes can be unlocked, by skipping the ‘mandatory’ setup OTA update with this guide.
There’s also a fair chance that any certified refurbished 2nd Cubes will be on FireOS P7292, and unlockable. So far a number of people have reported success with those.