You are using a methodology on a product that is not compatible IMHO.
In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able, or replaceable.
In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.
The tasks you list above seem very waterfall to me. They have to be in a certain order, and they are not negotiable.
I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.
If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and development boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).
Scrum, Kanban or any other Agile methodology is primarily a methodology focused on software development projects. In other words, it is a project management practice by its very nature.
As much as you desperately want you and your team to be doing project work, you will find that Agile will just simply not work in your organization because of the fact that you really are not doing "project" work or devoting yourselves as a team to a "project commitment".
You may organize a mini project around a complex feature, but in reality you have no connection to business analysts or the end users so how can you verify that you are delivering on User Stories when you have no way of really knowing what it is the user wants?
Your only stakeholder is your boss, and he basically ensures that your team doesn't exist to serve the other stakeholders of the project, you exist as a team to serve him and his needs regardless how this affects the other stakeholders.
On top of all of that, he is giving individual tasks to individuals and probably reprioritizing things immediately as he decides that they should go. You can't function in an Agile project methodology if individual project resources are going to reprioritized at a moments notice, or if the sprint will be put on hold.
It is not supposed to work like that
A sprint is a commitment by the entire team to deliver a subset of user stories by a specified date. Once started, a sprint should be gone through to completion before any reprioritization or changes are to occur. How is a project supposed to be managed when run in such a chaotic ad-hoc environment?
You don't work in an environment that is conducive to Agile project management methodologies. You don't even work in an environment conducive to Waterfall methodologies. You work in a monarchy and you are merely the kings pawns doing his bidding and putting out fires.
This is not the makings of a software development project team.
So in a very obscure way I am answering your question in saying that in your situation that it really doesn't matter if individuals are playing multiple roles. You have much bigger problems on your hands. You are asking how to get water stains out of carpet on a house without a roof.
Best Answer
Since you will be the scrummaster then I believe the answer to "is it possible to organize..." is really one best answered by you; you know your personality, management and organizational skills better than we do. Any methodology is do-able given sufficient understanding and commitment from all parties (that's often the hard part - does everyone in this startup understand what "Agile" and Scrum mean; short iterations with partial functionality added at each and lots of customer feedback?).
Also to be considered is this - is everyone involved already experienced with Scrum? If not, and especially if there is an appreciable amount of skepticism or animosity toward Agile/Scrum, perhaps a 3-month project is too short a window to be a)gelling as a team, b)getting the "real work" done, and c)learning a new methodology.
No matter what methodology you choose, Team relationships are an excellent place to start, btw.