Process for adding CSC boards?

[legogris]

I'm having some success installing Debian on Raspberry Pi 3B+ and thought I'd proceed with making an Armbian build in order to have equivalent environments with other boards in my cluster.

Is there any process/channel for this or should I just make a PR on the repo? What are some particular prerequisites I should be aware of that might block it from merging?

 

I am very aware of armbian's stance on Raspberry Pi, and I understand you do not want to support it officially (if nothing else because you'd have difficulty handling the incoming clueless users), but I think there are a lot in the intended armbian audience who have Raspis lying around who would be happy about an armbian build. Also it could act as a gateway to bring people to educate themselves more on Linux in general.

 

[JMCC]

2 hours ago, legogris said:

armbian's stance on Raspberry Pi

Ha ha, I don't think there is an "official" stance on RPi. It is true that, in general, the devs and members of the community tend to think that RPi is already well supported and does not need our additional work. Also, from the technical point of view we don't like some of the RPi engineering choices, but it is also true that we support some other boards that also have similar flaws (e.g. microusb powering).

 

I'm not totally against the idea. The main problem I can think is if we started getting tons of support requests and forum posts about things not working on the RPi, while it would actually not be a supported board. @Igor What do you think?

[TRS-80]

The (well deserved) negative stance towards the RPi is one of the things that attracted me to this community initially.

 

Meanwhile, everyone else keeps drinking the kool-aid.

 

There are plenty of other places for them to go do that, IMO. I agree that it would only raise the clueless level, and stretch thin already too thin resources.

 

And I even own one RPi. It would be handy as you say to have similar environment across. But I dread the flood of clueless users it would bring to Armbian.

[Igor]

43 minutes ago, JMCC said:

What do you think?

I share concerns which @TRS-80 pointed out while on the other hand we shall not prohibit anyone to maintain any hardware as CSC target if he wishes. Until he does not bother for implementation, maintenance and if this does not break the build system or other images. Anyway we can't really assist on implementation of boards and RPi is not any exception. It also has to be generally approved, but it seems its not. So @legogris IMO you are without "official" support, but if you get it working ... I guess we shell merge it. I think I already told this to few people and nobody take it serious enough.

 

Leaving CSC target in the dark should not change anything, or?

[TRS-80]

There is also the issue that RPi has a locked down bootloader / RTOS / GPU blob running underneath the OS, which is totally unacceptable from a Freedom standpoint.

 

Debian (which Armbian is at least partially named after) to me (and I am sure many, many others) stands for some other things besides the technical bits of the package manager and software repository. Debian takes a strong political stance in favor of Free Software.

 

Now this is not something that Armbian (as far as I know) officially adopts. And in fact I think there are some other blobs in certain places that are required to get certain boards to run, etc. I am actually still trying to figure all of this out but in the meantime, just something I wanted to bring to your attention for consideration.

[Igor]

11 minutes ago, TRS-80 said:

There is also the issue that RPi has a locked down bootloader / RTOS / GPU blob running underneath the OS, which is totally unacceptable from a Freedom standpoint.

Yeah, this is the main issue.

[legogris]

1 hour ago, Igor said:

Yeah, this is the main issue.

Well guess what, somebody ported a working UEFI firmware over: https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3

 

Only non-free part at this point is WiFi-drivers, which users can totally skip. As for non-free firmware etc, I'm just assuming this goes for several of even officially supported boards?

 

Just to be clear, I'm not asking for help to get this working, just thinking it would be nice to have an upstream where others who are doing a similar setup can collaborate without having to make a fork. That is, if I end up finishing something I feel comfortable doing a PR with - I'm actually new to armbian so don't hold your breath, just created this thread to see if it's worth making an attempt in the first place and if there is any contributor/maintainer guidelines I missed

Edited January 30, 2020 by legogris

[TRS-80]

1 hour ago, legogris said:

Well guess what, somebody ported a working UEFI firmware over: https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3

 

I was not aware of that, and have not looked in detail, but definitely as they say, big if true!

 

1 hour ago, legogris said:

As for non-free firmware etc, I'm just assuming this goes for several of even officially supported boards?

 

I don't know for certain, but I also suspect this to be the case, as I alluded to in my post above already, and which I have been trying to get to the bottom of for a long time now (see my post I linked above, which by the way, is the date I decided to ask, after already spending a lot of time researching it independently)...

Edited January 30, 2020 by TRS-80
typo

[chwe]

blobs:

https://github.com/armbian/build/tree/master/packages/blobs/mt7623n

https://github.com/armbian/build/blob/909be0239d8f3a9d6e2dae9da94d18b65e350320/config/sources/families/meson-gxl.conf#L18-L27

ends then in: https://github.com/armbian/odroidc2-blobs

 

so we even already dealt with bootblobs we've no clue what they're doing.. especially meson-glx

 

1 hour ago, legogris said:

2 hours ago, Igor said:

 

Well guess what, somebody ported a working UEFI firmware over

still needs the blobs to chainload UEFI (https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3):

 

Quote

3. Download and copy the following files from https://github.com/raspberrypi/firmware/tree/master/boot

• bootcode.bin
• fixup.dat
• start.elf

 

the only serious attempt to avoid this was done by christinaa (https://github.com/christinaa/rpi-open-firmware) but more or less dead since months/years. So no there's no change that the RPi relies on bootblobs to get up and running

 

Cause the bootloader (bootcode.bin) only understands FAT you also need some tweaks here and there in the buildscript.. But most of the needed features are there cause we support(ed?) having /boot on FAT. According to jamesh from the RPi forum their engineers don't see a reason that a bootloader should understand something like ext4 (I would have to search in my posts in their forum to get you a quote for that).. But safest bet for a more or less "sane" implementation would be bootcode chainloads u-boot and u-boot then properly loads a kernel sitting in a ext4 partition.

 

32 minutes ago, legogris said:

high CPU/IO performance and preferably high RAM?

IMO that doesn't fit to the 3b+ at all.. Maybe partly to the 4. In most when not all parts a rk3399 based on will outperform even the RP4 and for sure the RPi3

 

32 minutes ago, legogris said:

Active PoE is obviously a huge boon but unless I've missed some hidden gem I've abandoned those hopes after ROCK's abandonment of bringing that into their V3)

what do you mean with ROCK? means RockPi? then there you go:https://www.seeedstudio.com/PoE-HAT-for-ROCK-Pi-4-p-4143.html currently out of stock but allnet has it:

https://shop.allnetchina.cn/products/rock-pi-4b-poe-hat

 

I guess something like this will do the trick: https://www.aliexpress.com/item/33057941535.html?spm=a2g0o.productlist.0.0.38d222ebEfaAc9&algo_pvid=ebc883c9-19fd-4f58-ae77-add76220ba26&algo_expid=ebc883c9-19fd-4f58-ae77-add76220ba26-3&btsid=1071dcd7-b020-4d15-ab51-f383395eff93&ws_ab_test=searchweb0_0,searchweb201602_9,searchweb201603_53

obviously untested I don't deal with POE atm. Just make sure that you don't run into:

RK3399 tends to be power-hungry..

 

but back to topic:

7 hours ago, legogris said:

Is there any process/channel for this or should I just make a PR on the repo? What are some particular prerequisites I should be aware of that might block it from merging?

• have a sane implementation dealing with the bootstuff
• when possible don't add additional kernel sources (means build your kernel on top of mainline)
• Make sure that basic functionality even when you're not interested in works (e.g. USB/HDMI/UART or it's clearly that it doesn't work - well UART must work otherwise it's a pain to debug)

 

[legogris]

@chwe Good points in general.

8 minutes ago, chwe said:

what do you mean with ROCK? means RockPi? then there you go:https://www.seeedstudio.com/PoE-HAT-for-ROCK-Pi-4-p-4143.html currently out of stock but allnet has it:

https://shop.allnetchina.cn/products/rock-pi-4b-poe-hat

 

I guess something like this will do the trick: https://www.aliexpress.com/item/33057941535.html?spm=a2g0o.productlist.0.0.38d222ebEfaAc9&algo_pvid=ebc883c9-19fd-4f58-ae77-add76220ba26&algo_expid=ebc883c9-19fd-4f58-ae77-add76220ba26-3&btsid=1071dcd7-b020-4d15-ab51-f383395eff93&ws_ab_test=searchweb0_0,searchweb201602_9,searchweb201603_53

Sorry being unclear, I was referring to Rock64. They were announcing for a long time that PoE would be coming in the Rev3 of that board but it was eventually dropped. I ended up buying one anyway due to availability in my country, so now I'm here with a Rock64, a couple of Pis and thinking what the next board would be when I inevitably grow out of that. In general I'm wary of getting power supplies from untrusted vendors on places like Ali but it seems like it's either than or DIY for most boards, sadly. Thanks for the link either way; I'm thinking that should actually work fine with most SBCs rated at 5V/3-4A including Rock64 and Pi3B/4 but yeah, I'm wary of power especially if connecting external disks.

 

And good that you pointed out UART, I wouldn't have considered that otherwise.

[TRS-80]

13 minutes ago, legogris said:

power

 

I shun almost all these (usually crappy, IMO) included power supplies. I was actually glad when I learned the ODROID-XU4s I bought didn't come with one.

 

So far, I have been ordering Mean Well units from (IIRC) Mouser. But after collecting more and more of those (plus various devices, & etc...) I start to think about doing some kind of power rail(s) running up and down my workbench / computer / server area with one single larger PSU, and perhaps with connectors like what HAMs use (I think they are called Anderson Powerpole)...

Edited January 30, 2020 by TRS-80
add descriptive adjective (crappy)