Bananian Linux - Bananian Linux
View Issue Details
0000126Bananian Linux[All Projects] Generalpublic2015-04-21 16:032015-04-22 15:19
Omega 
 
normalfeaturealways
newopen 
 
 
 
0000126: Provide a way to inspect what hardware Bananian is running on
Currently there's no hard & fast way to find out what type of hardware bananian is currently running on.

It would be nice if there was an entry in /proc or /sys that I could cat to get the current hardware.  Ideally these names would line up with fex names.
(feature request)
No tags attached.
Issue History
2015-04-21 16:03OmegaNew Issue
2015-04-21 16:05NicoNote Added: 0000216
2015-04-21 16:07OmegaNote Added: 0000217
2015-04-21 16:08OmegaNote Edited: 0000217bug_revision_view_page.php?bugnote_id=217#r98
2015-04-21 16:10NicoNote Added: 0000218
2015-04-21 16:11NicoNote Edited: 0000218bug_revision_view_page.php?bugnote_id=218#r100
2015-04-21 16:11NicoNote Edited: 0000218bug_revision_view_page.php?bugnote_id=218#r101
2015-04-21 16:11NicoNote Edited: 0000218bug_revision_view_page.php?bugnote_id=218#r102
2015-04-21 16:25OmegaNote Added: 0000219
2015-04-21 16:33NicoNote Added: 0000220
2015-04-21 16:35OmegaNote Added: 0000221
2015-04-21 21:01Thomas KaiserNote Added: 0000222
2015-04-21 21:21NicoNote Added: 0000223
2015-04-21 21:35OmegaNote Added: 0000224
2015-04-21 21:36OmegaNote Edited: 0000224bug_revision_view_page.php?bugnote_id=224#r104
2015-04-21 21:37OmegaNote Edited: 0000224bug_revision_view_page.php?bugnote_id=224#r105
2015-04-22 07:46Thomas KaiserNote Added: 0000225
2015-04-22 13:41OmegaNote Added: 0000226
2015-04-22 13:44OmegaNote Added: 0000227
2015-04-22 13:45OmegaNote Edited: 0000227bug_revision_view_page.php?bugnote_id=227#r107
2015-04-22 14:35Thomas KaiserNote Added: 0000228
2015-04-22 14:39OmegaNote Added: 0000229
2015-04-22 14:40OmegaNote Edited: 0000229bug_revision_view_page.php?bugnote_id=229#r109
2015-04-22 15:19Thomas KaiserNote Added: 0000230

Notes
(0000216)
Nico   
2015-04-21 16:05   
Hey,
that was our first idea behind "bananian-hardware" but we did not find any reliable method to determine the board Bananian is running on.

Any ideas?
(0000217)
Omega   
2015-04-21 16:07   
(edited on: 2015-04-21 16:08)
Well, the issue is that bananian-hardware is interactive, so I can't automate the setup.

I would hope the device itself should have some kind of metadata available (set during manufacturing/production) that we can inspect non-interactively.

(0000218)
Nico   
2015-04-21 16:10   
(edited on: 2015-04-21 16:11)
Sorry, I did not tell the whole story.
Because we were not able to find a automatic solution we decided to build bananian-hardware interactively.

It would be really nice to have a non-interactive tool determining then hardware and then setting the corresponding fex configuration.

(0000219)
Omega   
2015-04-21 16:25   
Are you able to talk to lemaker etc.. to see if they populate anything in the device that can be exposed by the kernel?
(0000220)
Nico   
2015-04-21 16:33   
We already talked with them about that topic (before the 15.01 release) and they had no idea what could be used for this.
(0000221)
Omega   
2015-04-21 16:35   
Haha, sounds like we need an upstream fix! ;)
(0000222)
Thomas Kaiser   
2015-04-21 21:01   
There's something that is 'populated in the device'. Simply ship a script.bin with AP6181 enabled, issue modprobe on the first run, exchange script.bin, modify /etc/bananian_platform and you're done. :-)
(0000223)
Nico   
2015-04-21 21:21   
And what about the R1?
(0000224)
Omega   
2015-04-21 21:35   
(edited on: 2015-04-21 21:37)
Thomas: I don't think you understand, I need to identify the hardware specifically, not via an assumption based on behaviour.

Outside of what you're saying not really seeming like a solution to my concern here, it also seems like a hack...

(0000225)
Thomas Kaiser   
2015-04-22 07:46   
@Nico: The R1 has a totally different Ethernet PHY (BCM53125). And all the boards Bananian supports feature none or different Wi-Fi chips. Enable USB, ship with lsusb and you can have a look for RTL8192CU or RTL8188ETV to get a clue whether it's R1 or Orange Pi.

@Omega: Seems you fail to understand that there's nothing else than the Wi-Fi chip you can rely on when you have a look at the hardware. Since hardware requires software (drivers and board inilialisation) all you can do is to try to detect them. If you (or Nico) assures that prerequisits are appropriate (enabled wifi/SDIO in script.bin and the necessary kernel module built) you're able to detect whether you're running on Banana Pro/M1+ -- otherwise not.

BTW. Igor's hardware script is also a nice attempt to get a clue on which board you're running: https://github.com/igorpecovnik/lib/blob/next/scripts/armhwinfo [^] (but I haven't checked whether relying on the presence of eg. LEDs using sysfs doesn't depend on script.bin/dtb)
(0000226)
Omega   
2015-04-22 13:41   
Thomas, I don't fail to understand that, it just isn't a suitable option.  What would be ideal is if this detection was offered as part of bananian instead of requiring user space workarounds.

Forcing people to implement various detections will result in a custom solution every time.  If the OS facilitated it (without requiring someone to explicitly choose what device they're running on, which is basically manual), then the community would have a consistent baseline and source for inferring the hardware their code is running on.

This is definitely something that belongs in the Bananian project and not replicated hundreds of times (and possibly wrong) across every project or repository as a workaround.
(0000227)
Omega   
2015-04-22 13:44   
(edited on: 2015-04-22 13:45)
Your example of Igor's script proves my point perfectly.

There is no "Banana Pro" in Igor's list.  Even though the OS supports it, this is just another maintenance nightmare dumped onto users/implementers because the OS doesn't offer a facility.

Ultimately the OS is the *only* trustable authority because only it will know which devices it has shipped with support for and will maintain the correct (and consistent!) detections and string names for such.

(0000228)
Thomas Kaiser   
2015-04-22 14:35   
That's the exact reason I suggested a feature request here. And maybe Nico will accept the RfE and implement it sometimes in the future. Or not.

If you want to deal with the problem in the meantime it's still as easy as outlined many times before: Only use a recent Bananian version and ship with a fex/script.bin that has support for wifi/SDIO as required for Pro/M1+ and test the exit code of 'modprobe ap6210' and act upon that.

And BTW: All Nico/Bananian can do is to implement the exact same 'hack' as outlined above and adjust the contents of /etc/bananian_platform as a simple hint and script.bin to fully activate all hardware features present on the specific boards.

Due to the way hardware initialisation works on sunxi you always depend on a few blocks on the SD-card interpreted by u-boot (the contents of fex/script.bin or dts/dtb stuff) and if these change for whatever reason then both hardware detection as well as useage will fail. 
(0000229)
Omega   
2015-04-22 14:39   
(edited on: 2015-04-22 14:40)
Yeah and it's definitely less of (or not at all) a hack if it's maintained by Bananian.  If ever there is an update to the OS that adds support for a new platform, that is the first and best opportunity to update the device database and come up with a new string for it.

It will also have the benefit of unifying the community on the platform names before everyone gets some crazy idea of what they should be.


Note: I do however have a crazy idea to suggest, which is that the device names should-look-like-this, no spaces.  If that's a potential risk in scripting (subtraction operator), underscores are fine.

(0000230)
Thomas Kaiser   
2015-04-22 15:19   
Regarding 'unifying the community on the platform names before everyone gets some crazy idea of what they should be': You should keep in mind that there is something like a sunxi community covering all Allwinner devices. You can get an idea how many devices these are by looking at the appropriate fex files: https://github.com/linux-sunxi/sunxi-boards/tree/master/sys_config [^] or dts/dtb support in mainline kernel (see below)

Bananian runs on a very small number of A20 based boards and can't even be considered _the_ OS of Bananas. I for example switched to Igor's image (or to be more precise his 'build system') months ago since for my use cases mainline kernel makes much more sense and utilising his build system (completely creating a useable OS distribution including u-boot and all stuff necessary) I've been able to get a fully blown Wheezy image for my LinkSprite pcDuino3 nano by simply extending his build scripts and patching two source files months before official integration into mainline.

If you want to consolidate names you would've to address this at the sunxi community level. So please have a look at the names of the fex files (rather inconsistent) or better the dts/dtb names (since kernel 3.4 used by Bananian won't support the more recent boards): https://github.com/mripard/linux/blob/sunxi-next/arch/arm/boot/dts/Makefile [^] (section CONFIG_MACH_SUN7I if you're just interested in sunxi/A20)