Bananian Linux

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000126Bananian Linux[All Projects] Generalpublic2015-04-21 16:032015-04-22 15:19
ReporterOmega 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusnewResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000126: Provide a way to inspect what hardware Bananian is running on
DescriptionCurrently 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.
Steps To Reproduce(feature request)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000216)
Nico (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
2015-04-21 16:35

Haha, sounds like we need an upstream fix! ;)
(0000222)
Thomas Kaiser (reporter)
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 (manager)
2015-04-21 21:21

And what about the R1?
(0000224)
Omega (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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)

- Issue History
Date Modified Username Field Change
2015-04-21 16:03 Omega New Issue
2015-04-21 16:05 Nico Note Added: 0000216
2015-04-21 16:07 Omega Note Added: 0000217
2015-04-21 16:08 Omega Note Edited: 0000217 View Revisions
2015-04-21 16:10 Nico Note Added: 0000218
2015-04-21 16:11 Nico Note Edited: 0000218 View Revisions
2015-04-21 16:11 Nico Note Edited: 0000218 View Revisions
2015-04-21 16:11 Nico Note Edited: 0000218 View Revisions
2015-04-21 16:25 Omega Note Added: 0000219
2015-04-21 16:33 Nico Note Added: 0000220
2015-04-21 16:35 Omega Note Added: 0000221
2015-04-21 21:01 Thomas Kaiser Note Added: 0000222
2015-04-21 21:21 Nico Note Added: 0000223
2015-04-21 21:35 Omega Note Added: 0000224
2015-04-21 21:36 Omega Note Edited: 0000224 View Revisions
2015-04-21 21:37 Omega Note Edited: 0000224 View Revisions
2015-04-22 07:46 Thomas Kaiser Note Added: 0000225
2015-04-22 13:41 Omega Note Added: 0000226
2015-04-22 13:44 Omega Note Added: 0000227
2015-04-22 13:45 Omega Note Edited: 0000227 View Revisions
2015-04-22 14:35 Thomas Kaiser Note Added: 0000228
2015-04-22 14:39 Omega Note Added: 0000229
2015-04-22 14:40 Omega Note Edited: 0000229 View Revisions
2015-04-22 15:19 Thomas Kaiser Note Added: 0000230


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker