Some high level questions from a senior software engineer

I’ve been doing software in many different areas for over 20 years (server, client, mobile, gaming, etc), but never at the level of processors and firmware a lot of this is new to me.

I have some probably really obvious and stupid sounding questions, but I’d be really happy if someone could help me wrap my head around a few things.

I am now researching how to create our own OEM tablet because my company is in development mode, and has had trouble with sourcing various commercial white label Android tablets because their Android OS’s are often lacking or buggy. We have to rely on the manufacturer to make fixes, which isn’t working out for various reasons.

So I found Rock960

Question 1:
Is Rock960 meant to be a development board and not for production, similar to Raspberry Pi?

Question 2:
If Rock960 is meant to be a development board, what is the process to move it to production? Design a PCB, find someone to manufacture the other components and assemble?

Question 3:
I see Android images are provided for Rock960. Is there a way to access the source code? For example if in production we want to change the background wallpaper to our brand or pre-install our app?

I’d suggest contacting the vendor to find out if and how they would handle a bulk purchase of the boards: https://vamrs.com/contact/

That will depend entirely on your requirements, the size of your production run and your budget!

Rough set of options are:

  1. Adopt a development board that meets or nearly meets your needs and arrange a bulk purchase with the vendor. This is typically smallest NRE but greatest per-unit cost and the form-factor of the existing board will influence your industrial design.
  2. Adopt a SoM with a software eco-system that meets your needs and design a carrier board that fits well with your intended product. This is a mid-point in terms of NRE versus unit cost. The baseboard will likely be bigger than the adapter boards you might end up with if you adopt an existing board but it still doesn’t require sophisticated board design capabilities.
  3. Adopt a chip with a software eco-system that meets your needs and design (or outsource the design of) a full board.

BTW 96Boards does have a SoM edition although there are not a huge number of vendors right now.

Check out the Build from Source section in the documentation: https://www.96boards.org/documentation/consumer/rock/rock960/

Hi!. Thanks for your help.

We have a lot of space on our product so that won’t be an issue. If I take a Rock960, actually it has everything I need and maybe too much. I don’t need that many USB ports or HDMI ports. I am not sure what type of display it supports but we want to use a display between 13" and 22" so I think that would either be edp or lvds? Not sure if Rock960 supports that but that might be the only change.

This is a dumb question I’m sure, but to help me understand of what a SoM is after Googling, is SoM the same as a “motherboard”? Sounds like it has the connectivity options for various components (WiFI, Bluetooth, etc.), but doesn’t have them integrated onto the board like an SoC?

Lastly, I have some important questions about AOSP to help me wrap my head around this, as I haven’t found an answer through Google search.

Is the Android 9 build for Rock960 provided by Rockchip (makers of rk3399) or did they get a generic release from AOSP?

What type of modifications did Rock960 have to make to get things to work on Rock960? I guess I am asking how much coupling there is between the board and the OS. Is it just about the instruction set or is the OS conscious about each hardware component and has to be customized accordingly for each type of component, for example using Bluetooth 4.0 vs Bluetooth 5.0

SoM is an abbreviation of System-on-Module. The combine the main chip with RAM, power supplies and (sometimes) storage but then provide lots of I/O signals via high density connectors to be routed by a carrier board to real connectors. This hugely reduced the complexity of the carrier board since the most timing and power sensitive signals are designed for you and if may also the carrier board to use fewer layers.

Hi Daniel,

Thanks for helping. If I get the Android 9 source for this chipset from AOSP, what modifications would I have to make for it to work on rock960?

To figure that out you will need to compare the repo manifest at https://github.com/96rocks/manifests.git (as discussing in the Build from Source documents) with the raw AOSP one. Personally I would expect the differences to be relatively substantial.

So this is a general question, just for my knowledge.

Given the source provided on AOSP, what type of things need to be added or modified to make it work for a specific board? How deep is the coupling between hardware and OS?

A large quantity of code is likely to be needed adapt AOSP to a new board. As already mentioned, you can compare the manifests to see exactly what is needed because that is what the rock960 source code actually is: AOSP… with board support added.

Regarding the level of coupling see https://source.android.com/devices/architecture .

AOSP source is not strongly coupled to the hardware, and it is fairly EASY to adapt it to a new board, PROVIDED that the new board is strongly supported in mainline linux and mesa in general.

Look at the aosp device tree for hikey 960 (device/linaro/hikey) and dragonboard 845c (device/linaro/dragonboard), which are both supported directly in AOSP. They use all open source hardware support in the form of kernel and mesa, and are a good starting point for ANY board that is able to run linux competently.

hikey960 isn’t a good choice since the hardware vendor never offered the components for purchase, and its both discontinued and subject to international trade sanctions. The 845c might be a good place to start, especially since it actually utilizes an SoM that can be purchased separately for use in custom products. https://www.thundercomm.com/app_en/product/1529761023999618

Hi doitright, thanks for responding. After Googling some of the things you mentioned, I’ve learned some new things but I am still trying to wrap my head around the whole process.

Two questions. First, “PROVIDED that the new board is strongly supported in mainline linux and mesa in general”. Can you expand on what you mean by this? And how would I know if a board is strongly supported?

Second, let me start with a specific example question. Let’s say I go on Alibaba and I search for “rk3399 board”, and I find a bunch of manufacturers offering such things such as this one:

https://www.alibaba.com/product-detail/Rockchip-RK3399-PCBA-Development-board-6_60678596622.html?spm=a2700.galleryofferlist.normal_offer.d_title.586d9453D09OQg

So they say it comes with Android 7.1. But let’s say I want my own custom version of Android 7.1 or maybe I want to move to Android 9.

Can you tell me the steps to take in loading a version of AOSP onto the board and making it work with all the pieces of hardware, in as much detail as you are comfortable in providing?

Can you build mainline kernel from kernel.org without adding any patches from who knows where and have the hardware sufficiently functional? Can you similarly do the same with upstream mesa for 3d accel?

I already gave you all the details for building aosp, just read and understand the dragonboard and hikey build trees. It will look very similar for anything else.

Hi doitright, I actually have no idea, since I have never done anything like this before. For example, I have no idea what mesa or 3d accel is; or what is available at kernel.org. But from your tone, I assume the answer is no.

Thanks for your help thus far.

Well if you’re talking about building stuff from the CAD/PCB level, then these are questions that you MUST be able to answer before you can even begin. In fact, you really need to be an EXPERT on the hardware/software support for the hardware you’re using before you can consider working with it from that level.

kernel.org is the upper most “upstream” for Linux. If your hardware isn’t supported there, then it means you’re depending on vendor code, which may or may not be supported in the NEAR future, and may be of questionable quality – if it isn’t supported upstream, then you have to assume that you’re going to have to maintain the code YOURSELF. Mesa is the userspace component for graphics drivers (i.e. 3d accel) that work with the upstream kernel.