wdtz
-
Posts
49 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by wdtz
-
-
and, BTW, this will probably work on any SBC that has pwm and working port of wiringPi
(wiringOP is much simpler than the dtbo method, IMO)
WHY: I don't like fans that run full speed ALL the time
pwm fans are a bit limited on the ground in small size, and expensive
The SBC has pwm pins, so why not use them
none of the examples I have found are adequate, either gpio off/full
or excessive python scripts, 40 lines or more,, the bash script is ~ 10 lines
Some of the wiringOP/gpio packages don't work (ubuntu-full desktop)
try the commands in rc.local, if they don't work, then,,, dpkg -l |grep wiring; apt remove .....
git clone https://github.com/orangepi-xunlong/wiringOP.git,, also install lm-sensors
(you may have to make link, this puts gpio in /usr/local/bin, this is branch next)
in rc.local: gpio mode 0 pwm #using wPi pin #'s, from gpio readall
sleep 500e-3 #pause needed
gpio pwm 0 900 #starts for sure
gpio pwm 0 380 #slow to MIN until cron adjusts
-----
gpio pwm <pin> NNN ,,,, NNN is what I will call PWR, to get range give a PWR too large, the error will give range
If the PWR is too low the the fan won't start, even 800 is only 90% start
The fan turns all the time, but not at full speed, at MIN you can almost count the turns (maybe 150 rpm)
You have to find the PWR number for MIN for your fan, start at 300, it should run for hours, if not add 20, retest
When you get some #, then add 10%. With this number, fan should run forever
the script that cron calls every minute or 2
#!/usr/bin/bash
TEMP=`sensors|grep bigcore0 -A3 |grep temp1 |tr -s ' '| cut -d ' ' -f 2|cut -c 2-3` #adjust grep as suitable, fails >99
echo $TEMP
#TEMP=$1 #for testing, will error if $1 is blank
PWR=$(("$TEMP" * 11)) #or any other number you choose
echo $PWR
if [ "$PWR" -gt 999 ]; then #check to see if PWR is in 'correct' range
PWR=999
elif [ "$PWR" -lt 380 ] ; then #if this number is suitable for YOUR fan
PWR=380
fi
gpio pwm 0 $PWR
-----
obviously comment out echo lines when debugging finished
And now the wiring, it is stupid simple (arrows are both connections AND current flow)
(-ve) <-- E
pwm --> R --> B
(+ve) --> Fan --> C
if R is 1k, not enough drive to turn on transistor, 330 is 'iffy', 220 is OK, I have 180, depends on transistor
Oh, BTW, scope told me pulses are +, so transistor is NPN, if you couldn't follow circuit logic (TO92 OK, unless fan huge)
----
and now pwmTone,,, absolutely nothing on web
gpio pwmTone <pin> <frequency> ,, sounds good, right. well range likely changes, neutral as long as you know
plus: fan starts MUCH better, even 1/2 PWR
minus: fan barely slows down even with very low PWR
If anyone knows more, please reply..... maybe there should be 5-10k pwm --> (-ve) to ensure pwm turn-off???
---- I guess if you don't have a scope you could feed a LED + R, see if it dims (? R=100?) as you change PWRPS I would suggest this be pinned, if it is considered suitable
---------
And a better debugged script, better than off the top (of my head)
paying more attention to the hw side and not forgetting anything
-----
#!/usr/bin/bash
TEMP=`sensors|grep bigcore0 -A3 |grep temp1 |tr -s ' '| cut -d ' ' -f 2|cut -c 2-3` #adjust grep as suitable, fails >9
echo $TEMP
if [ $# -gt 0 ]; then
TEMP=$1 #for testing
fi
PWR=$(($TEMP * 11)) #or any other number you choose
if [ "$TEMP" -lt 50 ]; then
PWR=$(($TEMP * 8))
elif [ "$TEMP" -lt 60 ]; then
PWR=$(($TEMP * 9))
elif [ "$TEMP" -lt 70 ]; then
PWR=$(($TEMP * 10))
fi
echo $PWR
if [ "$PWR" -gt 999 ]; then #check to see if PWR is in 'correct' range
PWR=999
elif [ "$PWR" -lt 380 ]; then #if this number is suitable for YOUR fan
PWR=380
fi
echo $PWR
gpio pwm 0 $PWR -
err unless this is specificly different ,, max-link-speed = <01> is pcie gen1 ,, = <02> is pcie gen2 ,, = <03> is pcie gen3
I doubt that rk3399 can do gen3
But if it works ......
------more----
What you probably have happening is 2 lanes at pcie2 ... to find out..
lspci -nn (to get the bus #, somethiing like 00:00.0,,, then)
lspci -s <bus#> -vvv|grep -i speed
-
>I'm willing to try any builds, configs, and pretty much anything else anyone can think of, short of soldering,
Do some dtb hacking? All the memory timing is in this, maybe the mem is pushed too far, too hard?
But, it is plenty complicated, looking at 5x, much of the detail is gone, so applies to 4x mostly
-
OK, a bit more update, I did try a nightly, mostly works OK
one boot(early) needed a vt, black screen and
oddly, caps,num were not active so I didn't think it had booted, well, give it a try,, whoa!! whats this!
One did a hard lock, the first IIRR
Since it has been booting without problem
(This is using its own uboot)
Sleep, so far is only s2idle, deep fails to wake
Despite ACPI and a change to legacy uboot, have not gotten S3 sleep
S3 on manjaro, elementary, fedora,, sleep is 7%/d, fast too,,
so makes running off SD feasible (if you're not a reboot addict)
Any suggestions for S3?
Anything besides sleep.conf?
-
I have to wonder if you have a uboot (&equally important, idbloader) on your emmc
If you run fdisk on emmc is there room,,1st part start at 32768 (or >)?
What the boot rom is looking for is idblaoder, well, a raw read for the signature bytes
3B 8C DC FC BE 9F 9D 51 (so far, all idbloaders are same here)
I guess it is assumed that if idbloader is there (on that media), then so will uboot
So, something like..... dd if=/dev/emmc of=test skip=64 count=1
then,,,,, hexedit test
-
No, this is a perhaps week old download, updated
Armbian_20.08.4_Pinebook-pro_focal_current_5.8.11_desktop.img.xz
-
https://forum.pine64.org/showthread.php?tid=10694&page=6 ,, post 58 & on
Oddly I had a great deal of trouble getting anything but black screen, probably booted 'cause capslock toggle worked (leds)
The bsp uboots gave 'hard locks' (mrfix, pcm), now using samueldr, 1 in 5 boots
My pbp is a bit unusual, emmc uboot area blanked, so forced to use SD uboot
If sleep to mem works, doesn't matter if SD is slow, resume to desktop is 10-12 s, another 10 for wifi
But I have not found how to resume armbian, so no idea how well it does
-
Well, if you have serial terminal....
>the device loads first the uboot from the emmc
I doubt that there is one (on the emmc)
So then it looks at SD, loads 1st idbloader, then uboot, then ATF (arm trusted firmware),,
all from uSD
I would say that either your emmc/controller are bad or dtb is not right
copy boot.* as backup, try other dtbs,, since it is a H96+ also write image to a usb stick,,
many dtb have a wrong regulator setting for SD power, uboot is OK, then SD is dead with kernel
usb stick will still work, see if fdisk works with different dtb (writes without error, a rerun shows correct data)
--theoretical--If idbloader from emmc and then uboot (emmc), and there is a bootable SD card,
what comes next??.. Clearly the version of uboot must prioritize SD or only android would boot
I know, for rk3299 order baked into chip is spi, emmc, SD, usb for program load
I don't remember for rk3328
--edit--
only 2 dtb are right for H96max+ easyb and ?hexdump?
All others have no power to SD after uboot
uboot can read SD OK, load dtb, then load kernel, then card is dead
So, only change SD card, easiest is to copy good dtb to *.gd
then copy, in turn, dtb to name of dtb you are using, make a note of which,
or do in alphabetical order, don't bother with anything with android in the name
-
>Buffer I/O error on dev mmcblk1, logical block 0, lost async page write
>/dev/mmcblk1: close device failed: Input/output error
I think something is wrong with hardware, perhaps try a different (but compatible) dtb
OR try dd if=/dev/zero of=emmc bs=1M count=20 (change emmc as appropriate)
Do be sure to run fdisk again, command p ,, q,, just to see if error msg was correct
And, PLEASE start first partition at 32768 sectors (16M).
Most distros expect unpartitioned space for idbloader(start 64 sec), uboot (8M, 32384)
and ATF (not sure). sometimes you see them as mmcblkXboot0, boot1, rpmb in dmesg,,
(uboot in boot0, ATF in rpmb,, idbloader just raw)
NOT accessible with fdisk at all,, will NOT show up,
if it wasn't for dmesg | grep mmcblk you wouldn't know they exist
And some distros have different offsets, but if you leave 16M blank it usually works out
-
Why would you not use fdisk on the emmc to define and format partitions?
Do start at 16M, 32768 sectors for the first, 2-300M,, fat, type c
and the rest linux, type 83,, mkdosfs -F32 /dev/mmcblk1p1,, mkfs.ext4 .......p2
All as root (16M = 16*1024*2 sectors,,, space for idbloader, uboot, tfm)
If the emmc is bad, you will get lots of errors
-
That's the error for a misconfigured dtb, the voltage supply to mmc, @500000 and 5100000
A non-standard regulator setup, like t9 or h96max+
-
OK, i'll make an attempt, please correct me where wrong
dtc is kind of stupid, and device trees could definitely be improved
I'll bet you don't have a compiler environment and that's the problem
an example line, still symbolic,,, gpios = <&gpio2 RK_PA2 GPIO_ACTIVE_HIGH>;
The <&something,,> is an internal (only?) pointer in the dtb
The next 2 elements are probably populated from an appropriate .h (header) file
(specific to that hardware)
So it becomes,,, gpios = < 0x3e 0x02 0x01 >; ( a random example)
The dtc compiler can only deal with numbers
There is also an include at the top, has to be merged in
It would be a REAL improvement if the pointers, wherever possible
had the same numbers as linux devices they represent
(Probably that would be half, to differentiate the "made up"
ones, add F0 00 00 00, so f0000001,f0000002, ...
There could be a standard..... a device tree number standard)
The &numbers seem to be somewhat random, 1st come I think
All source dts are not written is same order and have different numbers of stanza's
so, in 6 dts's for example for 3328, only 2 will almost match (&numbers)
most confusing, pages of notes, a real pain
-
So, Digit97 , you never 'got back' to us to say how it worked out and what you found
-
understand, uboot and kernel have different dtb, that is why h96max+ starts, with uboot as seen
by serial cable, but then when hands over to kernel dtb does not power uSD slot, something non-standard
with regulators. So, it can't find its root filesystem, because slot is dead, no power
You see no hdmi display until quite late in the boot, so it seems dead, just can't read uSD slot
It there is a usb stick ALSO plugged in, will find root fs on usb stick.. uSD slot continues dead, unpowered
easyb and hexdump have made dtb for h96max+/T9 that make regulators work.
I don't know about other models
----edit----
For my h96max+ there is a problem with usb2 port, in dmesg late in boot and periodically
(with hexdumps' dtb, not with easyb's)
genirq: Flags mismatch irq 13. 00000080 (serial) vs. 00004000 (debug)
Quickly, the usb2 port 'locks up' there is no easy way to revive,,
I am sure a suitable unbind,bind would make it work for a bit, a bit esoteric
But now, I am using easyb's dtb, a 5hr power out forced a shutdown (47d uptime)
No problem with usb2 port
-
I hope you don't expect me to do it for you?
I am going to assume that you have broken that image up into the partition images
I don't know if you are using win or linux, no matter
There are hexeditors for both, a gui vesion is my recommendation,
wxHex or okteta or ghex, I tend to use okteta
load kernel.img into hexeditor, control f , make sure the hex button is selected,
enter the signature above. It will be a good sign if it is found at the begining of the line,
make a note of the address, keep searching. Then, in calculator, set decimal , address/1024, should be even, no remainder
If so,, try dd if=kernel.img of=test bs=1024 skip=(above number) count=70 (Input file, output file, block size)
Check test, load into hexeditor, should begin with signature, if not, you screwed up
Then try to decompile, as usual
If you don't find it appended to kernel, search in other images
-
Are you saying that there is no resource.img? You do know that the dtb is 2K into resource.img (IIRR)? use dd to strip
Sometimes the dtb is appended to the kernel,,, anyway search, with a hexeditor for D0 0D FE ED 00, at an even K boundry
d00dfeed00 it the "signature" for dtb's. Most dtbs are about 60-65K in size
Most of the resource.img is an (graphic) image file (or 2) for the splash screen
I haven't found android dtbs to be very useful
And, BTW how well does easyb's dtb work for you,, does everything work, both usb, ethernet?
I have 46d uptime, I seldom reboot
-
Digit: with a working and non-working situation,, compare
lsusb ,,, lsusb | wc -l ,,, dmesg | tail -15 (just after dongle inserted,, ie unplug, replug)
as root/sudo,,, lsmod | grep ath ,,, ifconfig
If it doesn't show with lsusb, check the other port,
for me, hexdump's dtb conflicts usb2 and debug, doesn't work,,
and usb3 locks hub on a daily basis, needs a replug, 3 different hubs
Haven't tried easyb's dtb yet
-
I am wondering what version of linux is this running under?
I am not familiar with libre-elect
-
>I have tried the conversion from dts to dtb but i not have success.
Try again,,, dtc -h,, must be dtb,,, dts is only for editing/altering,,, kernel wants dtb
Let us know how it goes
Because of the symbolic names, if you don't have a compile environment it
probably won't work
-
I guess you have not read much of this thread, last5-6 pages would be good
t9.dtb for 4.4.x kernel seems OK, I have not tried any 5.x, slightly different dtb (guess)
Not on ups, 10d uptime,, H96max+, wifi dongle a bit unstable, needs powered hub, x11vnc
Oh, and if hub back-feeds (many do) must unplug for reboot or power off
For example, a 2 second power "blink", you will think box is dead, until you unplug hub power too
-
@hexdump
Thanks for your t9.dtb,, works fine with H96 max+ for me
I could never figure out how the regulators worked, somehow you did
Only thing lacking is module for SSV6051
I guess I should try to put patch in right place and make a kernel
-
On 2/15/2019 at 7:49 PM, rmoriz said:
They are not the same, as my 64GB version has another radio chipset. There are at least two hardware versions out there, and there are different android firmware releases. One is "SSV6051_RTL8189" the other one is "HS2734".
Board is labeled RK3328_8D4_V1.1, same as yours, wifi chip is indeed different, SV6051P
Serial connection as shown in your photo
I think the problem with sd card is power to socket,
if you read this thread I have a few posts previous
-
17 hours ago, rmoriz said:
1. PCB is labelled as "RK3328_8D4_V1.1" with date "20180703"
2 .Wifi/BT chip seems to be:
I have H96 max+,32gb, board is same, wifi is sv6051, no bluetooth
Like you, most of the dtb give root fs not found, no /dev/block/mmc.... ,, or
for the android versions a black screen, serial shows only a few lines of kernel load (<5)
--edit--
you can make it work by writing image to both a uSD card and a usb stick,
it will probably find the stick and run from it. The uSd can be small and slow
Not so good with only 2 usb sockets
-
17 hours ago, CarlosPiles said:
Be carefull with changing /system/xbin/su as i've read sometimes it blocks Android boot.
Can you quote some specific models?
My H96max+, android8.1 seemed OK,, SuperSU installed OK, root checker said all was well
PinebookPro all armbian versions broken
in Pinebook Pro
Posted · Edited by wdtz
mor info
I'm not sure why you would do anything so complex or convoluted
The bootrom search order is SPI, eMMC, SD,,, it nothing is on the medium it goes to next one, applys to ALL rk3399
Really, it is looking for signature of idbloader, at correct location, and assumes uboot will be on same media
So, using dd, save emmc mbr(34 sectors if GPT) , save 1st 16M, blank 1st 16M (/dev/zero), restore emmc mbr, and then the only uboot is on SD
to boot emmc,, a small sd with ONLY uboot installed, some uboot 'choke' if there is no fs on media, so make a fat fs on rest of card
My pbp is a 'virgin',,, back has never been off, but I do know about "extra long press" (pwr button, 20+s) which acts as a hard reset (& have done > 10 times)
( a "long press" = hard power off = ~ 7s,,, this is NOT a hard reset,,, always try this 1st (7s)