Posts by SpookyHands

  • Dreambox/Dreambox2 S922X device-tree experiments

    Thank you, yeah I should have mentioned I'm currently working with CE. The SCPI error comes from send_scpi_cmd in scpi_protocol.c. Their scpi_protocol.c file appears to be a mashup of g12b/a, and SM1/2, T7 files. Those warnings aren't present in the g12b/a scpi_protocol.c.

    I'll keep working at it for another day or two and if I can't make any progress, I'll take that advise and try the Amlogic kernel mailing list. I'll also try the CE team again, never got a response the couple times I asked about it before.

  • Dreambox/Dreambox2 S922X device-tree experiments

    Thank you so much, this was EXACTLY the problem! The DTB I was building my DTB off of wasn't covering the BL32 memory range in the reserved memory. Expanding secmon's range to include BL32 fixed the crashes.

    Can I get your input on one other DTB issue that I suspect is BL31/BL32 related. I get SCPI timeouts during boot (4 x 10sec).

    Code
    [ 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

    I can eliminate these by removing the Meson MHU/Mailbox node. Reading about the node, it seems like it's probably an important one. Do you have any idea what might lead to SCPI timeouts?

    Or more simply, what might be the consequence of deleting the node? At the moment I'm not observing any consequences.

  • Dreambox/Dreambox2 S922X device-tree experiments

    Quote from chewitt

    The Beelink G12B devices I have all experience some kind of kernel lockup when using vendor u-boot, with or without chainload of any recent newer u-boot as second stage; although in that case LE boots and generally runs fine until you attempt any large file transfer and then it locks up. Nobody has been able to put their finger on the issue.

    Hi I'm working with a G12B device (s922x), and I had noticed that when reading or writing > ~500MB I would get a kernel crash related to the dmc_monitor node. Do you remember if this was the same cause of the kernel lockups that you observed?

    Was anymore information ever found to the root cause of the kernel lockups with large file transfers?

  • How to decompress LZ4 compressed u-boot

    Yes the signing tool has an LZ4 compression option

    Code
    aml_encrypt_g12a --bl3sig --input u-boot.bin --compress lz4 --output u-boot.enc --level v3 --type bl33

    But it uses a custom frame header that's not recognized by the standard LZ4 program. I was just wondering if there is an easy solution for decompression.

    This isn't really specific to any box, I have seen the LZ4C magic in a number of bootloaders from different boxes indicating uboot is compressed.