Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Pine A64 detection #96

Closed
wants to merge 1 commit into from
Closed

Conversation

ThomDietrich
Copy link
Member

@ThomDietrich ThomDietrich commented Feb 9, 2018

Fixes #35
@EliasGabrielsson could you please confirm this is working correctly?
With the logic as implemented in the previous PR, it shouldn't have worked. Maybe my numbers are wrong?
Additionally just as discussed in openhab/openhabian#333 we should improve board detection.

@willemdh
Copy link
Member

@ThomDietrich Could u please recommit on latest master?

@EliasGabrielsson
Copy link

I think this pull request shall be rewritten according to leonsio advice in thread above before getting merged. Cited below:

the best way to detect SoC is to use the information from device-tree/model or ( if not present ) to
detect Soc based on some hardware specification.

for example CPU architecture or hardware string in /proc/cpuinfo

the biggest problem is to identify the correct board, if many boards uses the same chipset. for example Allwinner A64 is used on this boards

Azpen hybrx
FriendlyARM NanoPi A64
Olimex A64-OLinuXino
Pine64
Sinovoip Banana Pi M64
Xunlong Orange Pi Win
in this case you need some more unique specifications to detect the right hardware like RAM/ethernet/soundchips or other

The kernel string can be set to anything

@ThomDietrich
Copy link
Member Author

@EliasGabrielsson while you are completely right, this PR is just here to fix the memory differentiation part. Can you verify that the memory of your Pine falls into one (the correct) of the three ranges?

@leonsio
Copy link

leonsio commented Feb 21, 2018

another tip, don't use dmesg to detect any system information.
the buffer size of dmesg is mostly limited to 32k. this means that older entries=boot logs will be deleted/overwritten

here a example from my system running 18 days

[12:56:15][root@rock64:~]
# date
Mi 21. Feb 12:56:20 UTC 2018
[12:56:20][root@rock64:~]
# uptime
 12:56:22 up 18 days, 17:25,  1 user,  load average: 0,04, 0,01, 0,00
[12:56:22][root@rock64:~]
# dmesg -H | head -n1
[Feb12 15:51] "java" (1965) uses deprecated CP15 Barrier instruction at 0xf58b0a30

I can only find information from last 9 days in dmesg, older entries are deleted

@ThomDietrich
Copy link
Member Author

ThomDietrich commented Mar 18, 2018

@leonsio I'm not able to contribute anything these months. Would you like to add a PR to replace this one and to improve the detection of all three Pine A64 boards? I'd do it myself but as I currently do not have a system running I would be unable to test.

@willemdh willemdh closed this Jul 16, 2018
@willemdh willemdh deleted the ThomDietrich-patch-2 branch July 16, 2018 14:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants