alt Hacker NewsI'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse.
I'm in the process of optimizing a bootolader for my various SoC/SBCs and even the cheapest, oldest least powerful SoC from 15 years ago can manage AES-CBC via crypto accelerator at 50 MiB/s. There's no excuse.
You can achieve 50MiB/s if that's all that you're doing. I've worked with some DSPs (TI's DaVinci line) where some operations would abort if DDR was overwhelmed.
For example, passing a frame of video (YUV) into the peripheral which can resize the overall image, would fail if the system was busy with other DMA transfers. You could attempt to resize again, but there were no guarantee that it would complete successfully. Your options are to reduce overall DDR utilization or drop frames. In an application like Flock's, dropping frames is likely something they need to avoid.
The system in question is doing similar tasks, and I don't think that what I'm suggesting is out of the question.