Could AMD A6-9220C be an SoC candidate?


spud42 said:
apart from the thermal restraints there are physical space restraints. here is a link to a post from hns detailing the space that is available. https://pyra-handheld.com/boards/th...-rk3399-sounds-good.83004/page-2#post-1438378
If you are expecting to run some form of x86 windows on this then there is an additional requirement that ED also brought up in one of the many threads on a windows SOC.... windows requires a BIOS. someone would have to write it . would it need another chip for it? if so how big is the chip and where does it go?
whatever new SOC is used the CPU board has to fit in the space available. the 2 connectors to the main PCB are in fixed position.
A new CPU board will not be a trivial thing to design.
Click to expand...

To be completely honest I didn't even consider booting Windows natively. I guess native Windows mentally became a corner case after I moved my last performance critical Windows installation to a hardware accelerated VM in January of 2012.

Sorry about that.
[doublepost=1548428313,1548427136][/doublepost]
Askarus said:
We need an SoC that needs less power and produces less heat than the OMAP. Not more.
OMAP 5 is at the limit.
Click to expand...

I can agree with (average) power, but didn't ED say we had some margins on the thermals (which is more about peak power)? Correct me if I'm wrong but isnt the OMAP5432 a 6W part with a 3W programmable limit as well?

In theory then if we limit the clocks of an A6-9220C we could reach well below the 6W spec. The net gain we'd be aiming for lies in the GCN based GPU anyway so we should be able to have the user pick between high CPU or GPU clocks.

Or we could hypothetically go the Apple route and rely on permanent thermal throttling... -_-
 
Wouldn't something from the AMD Zen "simi-custom" team be better for a future Pyra than anything Excavator based?
 
We'd need something off the shelves, requesting an own semi-custom design is way too expensive and others are likely bound to exclusive contracts.

Originally AMD did plan to scale Zen down to ultra low power embedded SoCs, but these ended up having a similar fate like their ARM64 SoC - hardly available, very specialized peripherals and still too beefy for our purpose. I do hope these will get more attention once Zen2 is out of the door. the architecture does have potential for these kind of things.
 
I won't consider buying any Intel or AMD CPU. AMD has PSP and intel ME, and both prevent a owner controlled computer. I don't know about this specific part, but I highly doubt they didn't include the PSP. This implies signed blobs and I don't care how fast it works if I can't trust it works for me.
 
Unlike ME, the PSP can be entirely disabled once the x86 cores are released from reset, though. It's a common misconception that PSP is "just another ME", because there are very large differences in their functionality. It's supposed to be used as a local monitoring device, unlike ME it has no remote functionality nor is it essential for the operation of the CPU past the initialization phase.

If you're both in control how the CPU is being integrated into the board and what firmware is being used for it (BIOS/UEFI), you still have many options to limit its capabilities.

pyrat said:
This implies signed blobs and I don't care how fast it works if I can't trust it works for me.
Click to expand...
You know, large chips like the OMAP that don't have an own flash memory and are able to directly boot from external media more complex than a simple SPI flash IC commonly contain blobs, because at a certain point you need software to initialize certain hardware components before you can just start execution of whatever is on the component connected to it. I'm not sure how the OMAP implements this, but on Renesas' 3rd gen RCar series this blob is provided as immutable mask ROM, which means it is directly burned into the silicon and not reflashable. Don't expect it to be explicitly mentioned in the HW manual, though, the manufacturer might limit this information to how the data header of your own bootloader has to look like so the internal blob can correctly process and execute it.

If you feel like having a fit, take a look at the boot procedure of the Xilinx Zynq UltraScale+ SoCs (full HW documentation is publicly available without having to create an account), they are really doing some serious shit to achieve a "secure booting process" - and I've got the feeling that there's even more to it than the HW manual describes, because having a MicroBlaze-based co-processor directly on that chip sounds kind of weird...
 
Last edited:
Non flash-able ROM is actually a good thing, mainly for 2 reasons:

- It means no malicious software can be installed on it after the chip leaves the factory.

- The manufacturer will write the simplest software possible for it as it will not be able to fix it latter with an update, this means that said software is extremely unlikely to do any more than the absolutely necessary to boot the device.
 
Kuro said:
- The manufacturer will write the simplest software possible for it as it will not be able to fix it latter with an update
Click to expand...
You're really naive if you think they would care enough to do so. Chip engineers are not security-aware programmers - and even if they were, screw-ups and imbeciles can be found everywhere.
 
Letalis Sonus said:
You're really naive if you think they would care enough to do so. Chip engineers are not security-aware programmers - and even if they were, screw-ups and imbeciles can be found everywhere.
Click to expand...

That is true, but it is also true that a bad enough bug would require a recall instead of a software update, such a recall would imply huge losses for the company.
And if there is one thing these companies truly care about, it's money.
 
Kuro said:
That is true, but it is also true that a bad enough bug would require a recall instead of a software update, such a recall would imply huge losses for the company.
Click to expand...
Have you ever heard about a hardware manufacturer doing a recall because of security issues? Even car manufacturers only do that if the device itself may cause personal harm. The ECU is hackable? Who cares?

In a world where companies pay a shit-ton of money to license software components with the highest grade safety certification just to literally workaround and disable every single protection mechanism that are actually required by said certification because they "make development too difficult", such simple logical conclusions just do not reflect reality. If you get the chance to get a glance at the crap people are actually passing into mass-production you'll never want to be near a car again.
 
Letalis Sonus said:
Have you ever heard about a hardware manufacturer doing a recall because of security issues? Even car manufacturers only do that if the device itself may cause personal harm. The ECU is hackable? Who cares?

In a world where companies pay a shit-ton of money to license software components with the highest grade safety certification just to literally workaround and disable every single protection mechanism that are actually required by said certification because they "make development too difficult", such simple logical conclusions just do not reflect reality. If you get the chance to get a glance at the crap people are actually passing into mass-production you'll never want to be near a car again.
Click to expand...

Let me start by clarifying that I agree with what you say, i just argue that if the software is not flash-able it probably will not implement superfluous features that add no real value apart from a bigger spec list. If it wore flash-able, doing such a thing would not be a problem as you could just fix the bugs latter.

Nowadays ECU's are not only updated during the car maintenance but also over the air through the gsm network (most cars nowadays have a gsm module just for updates), which allows them to go crazy on the software, because if there is a problem you can just send an update to fix it.

PS: I drive a non Turing complete car for a reason :)
 
Letalis Sonus said:
Unlike ME, the PSP can be entirely disabled once the x86 cores are released from reset, though.
Click to expand...
I don't quite believe. If you don't install the signed blob the PSP won't release the CPU from reset. If you do there is no way to know what it does,
since it can access the system RAM, and is privileged. In fact it's either you can't escape from the PSP or the PSP is useless for DRM, so without
being an expert, I don't think you can escape. How bad it is I don't know, but I fear enough how bad it can be.

It's a common misconception that PSP is "just another ME", because there are very large differences in their functionality. It's supposed to be used as a local monitoring device, unlike ME it has no remote functionality nor is it essential for the operation of the CPU past the initialization phase.
Click to expand...

I know the implementation is different, but the business requirements are about the same, so it needs to be similarly powerful.

If you're both in control how the CPU is being integrated into the board and what firmware is being used for it (BIOS/UEFI), you still have many options to limit its capabilities.
Click to expand...

I guess by being in control you mean you could for instance write your BIOS/UEFI, with the AMD signed blob in it and store it in a ROM or some EPROM with a jumper for write enable or whatever.
But since you can't still change that blob I stil don't think this is being in control (it's more control than just buying a ready made motherboard, but not enough).

You know, large chips like the OMAP that don't have an own flash memory and are able to directly boot from external media more complex than a simple SPI flash IC commonly contain blobs, because at a certain point you need software to initialize certain hardware components before you can just start execution of whatever is on the component connected to it. I'm not sure how the OMAP implements this,
Click to expand...

I'm not sure either, but for OMAP I'm not aware of required blobs in writeable memory.
 
pyrat said:
If you do there is no way to know what it does, since it can access the system RAM, and is privileged.
Click to expand...
Signed does not equal encrypted. You're free to disassemble the blob and look at what exactly it does. It's a common ARM CPU architecture, nothing exotic. The signed part just prevents you from feeding it with your own code. Usually the same applies for stuff in mask ROM, but it would be really easy for the manufacturer to prevent you from accessing the contained blob if they wanted to.

BTW: The PSP interfaces to the rest of the system through PCIe like any other peripheral device and uses standard PCI BARs for MMIO claims. You could just let the IOMMU wreak havok onto its externally mapped address space, no more DDR RAM access whatsoever.

pyrat said:
I know the implementation is different, but the business requirements are about the same, so it needs to be similarly powerful
Click to expand...
"Similarly powerful" - care to elaborate? You know, the lack of remote functionality is a big point, it means that you don't need to include a whole network stack. This is seriously the largest pain point part of the ME, because you can't get through to it without direct access to the system.

pyrat said:
I'm not sure either, but for OMAP I'm not aware of required blobs in writeable memory.
Click to expand...
It's still a closed source blob of software. Is it really that different for you?

FWIW, the mask ROM blob may still implement hidden ME-like remote features. It's a great place to hook up hidden processing units, just like the undocumented ARM9 core in the Pandora's OMAP that is supposed to support the closed source DSP blobs with decoding videos. In fact, the aforementioned Xilinx SoC is a great example for this, its CSU is one of the biggest black boxes I've ever seen, I actually assume that the CSU itself is a giant closed source bitstream blob being loaded into a dedicated FPGA - why else would they use a MicroBlaze architecture for it?
 
levi said:
Maybe, but I'm always suspicious of x64 TDPs. I have an atom in the netbook that's supposedly rated at 2.5W, but the little fan in this machine I can hear whining away trying to keep the thing cool just browsing these forums. I guess Intel didn't include a graphics core in their stats, or it's some other part of the chipset actually producing all of the heat it's trying to dissipate at present, which should be less of an issue with these AMD parts if they include graphics in the dies, but still, once bitten twice shy.
Click to expand...
That is because the chipset/southbridge is shit.
 
Forget SoC's anyways! It's time for SIP! xD I would call it "Compressed Hardware" that keeps your PCB cleaner compared to SOC's. ^^

Qualcomm_SIP_vs_SoC.jpg


https://paidfreedroid.com/2019/03/snapdragon-sip-1-explained.html
 
Djhg2000 said:
the A4-9120C and the A6-9220C. Both are 6W TDP parts and have full fledged x86 cores with GCN graphics.
Click to expand...

Really I don't like modern x86 CPU as both from Intel and AMD have secret/hidden internal CPU plus secret/hidden internal OS with access to all systems without you can avoid it. And it doesn't matter if you use Windows, Linux or other OS in those x86 CPU.

https://en.wikipedia.org/wiki/Intel_Management_Engine

https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor


I think having a hardware you paid for but you CAN'T TOTALLY CONTROL is really bad, at least if you know it or you want control/security. If someone is unaware of it he can be happy in ignorance.

I am bored from spy OS (Android/Windows...) and spy or uncontrollable hard, and I like Pyra being different almost as free from those spy plagues as possible. In that sense I even would love to see a future open RISC-V [1] SOC in Pyra even if it doesn't deliver more power, as it will deliver more freedom.

[1]: Of course RISC-V SOC, capable of running full Linux and with GPU/etc, are not available today, and it will take time. Meanwhile I prefer for example an i.MX8 series SOC much more than a x86 SOC.
 
Does the iMX range not have the trustzone extensions? I think it's theoretically possible for a malicious bootloader to put something in there that a reflash that doesn't include the bootloader won't touch, but to be honest the last time I tried to read up on that my eyes glazed over very quickly.
 
levi said:
Does the iMX range not have the trustzone extensions?
Click to expand...
Don't forget the dedicated SECO Hardware Security Module, whose signed binary-only firmware is needed before booting the main cores to keep kicking an essential watchdog timer.
 
Last edited:
You must log in or register to reply here.
Back
Top