Jump to content

hexdump

Members
  • Posts

    457
  • Joined

  • Last visited

Everything posted by hexdump

  1. hi @jernej - this is the tree i'm currently using as a base as it has most of the h6 patches in already (orange-pi-5.2 branch): https://github.com/megous/linux for completeness: this is the boot log of your latest libreelec image (LibreELEC-H6.arm-9.80-devel-20190711234608-e076031-tanix-tx6.img.gz) booting on this box - https://pastebin.com/raw/iVySMHL - again no hdmi working and even with mem=2048M it crashes at some point a lot of thanks in advance and best wishes - hexdump
  2. hi @jernej - here is the legacy u-boot and android boot log: https://pastebin.com/raw/K89ce83x - there only 2gb get discovered. you got me convinced about the 4bit now btw. regarding hdmi out (which is working fine on android) i tried: "ddc-en-gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; " from the orange pi 3 in the connector section of the dtb - it did not help. then i tried https://github.com/linux-sunxi/linux-sunxi/issues/291#issuecomment-372909917 but it did not help neither. i played with things like "disp.screen0_output_mode=1280x720p60" or "drm.edid_firmware=edid/1280x1024.bin" on the kernel cmdline but it all did not help - always no response on the monitor (one is 1280x1024, another is 1920x1080 and then i have a hdmi to vga adapter which usually works very well and reliable). is there anything around /sys or /proc which might help debugging this? update: for completeness - this is the boot log of megous 5.2.1 - https://pastebin.com/raw/tqWPwbfY
  3. @jernej - i just opened the eachlink h6 mini box once more and it really has 4x4gbit (K4B4G0446Q) and 4x2Gbit (K4B2G0446C) chips in it, which makes absolutely no sense following your 8x 4bit theory - this can at max only give 2gb of useable memory then and would explain the crashes beyond 2gb. i checked the web a bit for the datasheet of the memory and ran across https://www.datasheet.directory/index.php?title=Special:PdfViewer&url=https%3A%2F%2Fdatasheet.iiic.cc%2Fdatasheets-0%2Fsamsung%2FK4B2G0446C-HCH9.pdf which to me looks a bit like those chips can run in 4bit and 8bit width, but i might be wrong as i'm not at all an expert on this. in case the chips could run 8bit wide, then there might be two memory banks with 1x1gb and 1x2gb giving a total of 3gb and the setup of the box would make sense. the reason for my 2gb+ crashes might maybe be some broken ram or a timing problem still (timing only works well for one bank of the two)? but it is not that important - running it with 2gb is fine too. hdmi output is not working, but this is an open topic on h6 still anyway i think. i tried 3 different monitors and different cables - none worked (on the qplus and the mx10 pro 6k hdmi output did work well). otherwise it is running fine and stable now (limited to 2gb) with ethernet, thermal sensor and frequency scaling up to 1.8ghz. best wishes - hexdump
  4. funny anecdote: i got my hands on a used eachlink h6 mini box (the one the u-boot port for the h6 tv boxes started with) and to my surprise this box has 3gb ram builtin, but only 2g of them seem to be useable and inteded to be used - you can find the details here: https://github.com/apritzel/u-boot/issues/4#issuecomment-513580655 those tv boxes are always good for an unexpected surprise (just like most h6 tv boxes are sold as having 4gb although the h6 can only address 3gb of them ...) best wishes - hexdump
  5. i finally made some pictures of my cooling solution - this time on a mx10 pro 6k, which works fine with the above patch and dtb as well (except the usb 3 port was not working, but i guess this can be solved with some dtb magic) including ethernet, frequency scaling and thermal sensor. in case someone else has this box too, i would be interested to know if anyone got a serial console working as there are no obvious connectors visible. it looks like under the heat sink there are some contact points, which might be accessible with the heat sink removed, but i'm not sure if those are really serial console contact points (at least on a rockchip 3328 mx10 the serial console connection was right there). while i had the box cooled well like this i ran sbc-bench and the results can be seem here: http://ix.io/1OQb - to me they are not really looking that bad - for instance the 7zip performance is just about 15-20% below that of the new and powerful raspberry pi 4b! so looks like those h6 boxes are a good choice if you want some cheap (i got both the qplus and the mx10 pro 6k for 33 and 31 euro including relatively fast shipping here from germany) and well performing little linux systems - at least when the h6 support in mainline has martured a bit. best wishes - hexdump
  6. for that price its fine, but for the 117+ euro from the link above the advantage of the tv box for linux use slowly goes away
  7. i think for rk3399 maybe simply using a rock-pi 4 or nanopi m4 can sometimes be even cheaper than those $100+ rk3399 tv boxes i guess and they will most probably less troublesome ...
  8. it does not work out of the box with the magicsee dtb - it boots, but can't find the sd card, so some dtb adaption is most probably required - but it at least seems to have connection points for a serial console, so it should be possible to get it working with some effort ... i did just a simple boot test - its not my box
  9. @jernej - i guess active cooling would be best - @balbes150 has some good notes here: i did attach this passive heat sink: https://www.ebay.de/itm/CPU-BGA-Chipsatz-Kühlkörper-passiv-Aluminium-50-x-55-mm-z-B-INTEL/312685159616 to the original heat sink (just clamped it upside down to it) - this way i could run with 4 cores, but it throttled down to about half speed after a while - no overheating though - active cooling (with fan) should be much better - the seller of the above heat sink has a cheap one of similar size with fan as well ...
  10. a little update: @jernej - with the changes from your latest tree (after the force push) now it also works well if applied to the megous tree - i assume, that maybe beforehand the tree was not pushed completely (?) ... this way i now have it running on my qplus h6 tv box with ethernet, frequency scaling up to 1.8 ghz and thermal sensor values in /sys/class/thermal @balbes150 - maybe its time to start your armbian image build machinery to spin a test image ... in case you are interested: i used the orange-pi-5.2 branch of this tree: https://github.com/megous/linux containing a lot of h6 patches already and applied the below attached patch to add the ethernet support from jernej and some dummy regulator to get the frequency scaling working. there are two dtb's included: sun50i-h6-qplus.dts - it has everything required for ethernet and frequency scaling and sun50i-h6-tanix-tx6.dts - it is the dtb from jernej and does not have frequency scaling enabled (no cpu voltage defined - not sure if it even works with the below patched tree). it looks like all h6 tv box hardware is very similar, so the qplus dtb should work fine on the tanix tx6 and other boxes as well. it is important to add some proper active cooling when more load is put onto the cpu (running it in the tv box without additional cooling will result in overheating and a hanging system after some time with medium to high load). an alternative is to disable cpu cores via "echo 0 > /sys/devices/system/cpu/cpuX/online" - this way it should be possible to run it with 2 cores in the box and thermal throttling will handle the warming, with more cores throttling might not be strong enough to really cool down the cpu on high load as there is no voltage scaling. properly actively cooled it will run well with full load on all 4 cores at 1.8 ghz without throttling. h6-tv-box-eth-qplus-tanix.patch config.ah6-5.2.0-meg-ah6+
  11. @jernej - with that it works fine ... i just compared the ac200.* files from my patched megous tree with the ones from your tree and there were slight differences - can it be that you force pushed a new version a bit later than i took the patch from you? retrying the megous tree with the ac200.* files from your current trree now ...
  12. @jernej - this is what i get when i compile the ac200 branch of your linux-1 tree with my config: dmesg.txt dot-config.txt
  13. @jernej - your libreelec image works with ethernet - i'm right now checking out your kernel tree and will build a kernel from this and if this works can look at the differences to the tree i used ...
  14. @jernej - your libreelec image works with ethernet - i'm right now checking out your kernel tree and will build a kernel from this and if this works can look at the differences to the tree i used ...
  15. @jernej - yes i had mdio and emac in my dtb. i'll just try to compile a kernel from your tree then tomorrow and will let you know then. have to leave now ...
  16. @jernej - i did give it a try today, but it did not work - most probably there is still some patch missing or some config option. i'm using the above mentioned megous tree as base, as it already contains a lot of orangepi-3 stuff, h6 themal sensors, devfs etc. - i was able to add your patch and adjust my .config accordingly but maybe i'll retry it the next days with a bit more time. or maybe you can push your working kernel tree somewhere on github and i'll build from that. or i'll just wait a few more days until things are cleaned up a bit more. once more a lof of thanks for your efforts and best wishes - hexdump
  17. @jernej - this is an amazing news! i'll try it either tomorrow or on friday - did not have any time today and i'm not sure about tomorrow ... emmc is not working on my qplus box neither, i actually have to disable it in the dtb as otherwise the kernel hangs on boot ... maybe this is worth a try? - https://github.com/apritzel/u-boot/issues/4#issuecomment-502304665 best wishes and keep up your cool work! - hexdump
  18. @jernej - thanks a lot for the update a little update from my end: i have meanwhile removed the board from the case and added a larger passive heat sink to avoid overheating problems. with this and a 5.2 kernel built from the orange-pi-5.2 branch of https://github.com/megous/linux the thermal sensor is now working and with it the cpu cooling via d[v]fs. as a result the reboot problems due to overheating are gone: when the cpu gets too hot it will now get throttled down and that works perfectly fine even with a fixed cpu voltage only by just lowering the frequency. i can now run a make -j 4 kernel compile on the board and it is running absolutely stable - just after a while the cpu frequency will throttle down to around 800mhz due to heat - i would most probably need active cooling (fan) to keep the cpu cool enough to run at full speed if all cores are running at full load. for smaller or shorter load it runs fine and absolutely stable at 1.8 ghz. there are three problems hitting me the most right now: both usb ports (1x 2.0 & 1x 3.0) are working fine as long as i plugin devices directly to them, but as soon as i plug in a usb-hub none of the devices plugged into the usb hub are seem by the system - anyone any idea what might be the problem here? the hdmi monitor currently defaults to 1024x768 - not that critical and i think i had seen it at the 1280x1024 of the monitor already with other kernels - maybe an edid detection problem, will try to set the mode on the kernel cmdline next the missing ethernet - as i only have two working usb ports and can't use a usb hub yet the need to use a usb ethernet uses one of the usb ports and i can't use a keyboard and mouse together while connected to the network - it would be really cool if we could get native ethernet working ... best wishes - hexdump
  19. i think i have to revert my theory from yesterday: the problem with this h6 qplus box (as with most probably many other cheap h6 tv boxes) is not the cpu voltage but pure thermal topics. i removed the board from the box and did the following test: i switched the dtb to scale up to 1.8 ghz again and pushed a cooling pack against the heatsink while running glmark2 as a test and voila: it runs through perfectly fine at 1.8 ghz. also disabling two of the four cpu cores helps - this way it runs through completely stable with 1.8 ghz on the remaining two cores just with the small heatsink of the box (but not in the box, which gives way better heat dissipation). so in the end those h6 boxes are quite promising if they get cooled properly, as you can really run them at 1.8 ghz. thermally the h6 seems to be way better than for instance the rockchip 3328 as the h6 can run at 1.8 ghz with only 1.06 to 1.16 v while the rk3328 is already in the range of 1.2 to 1.5 v to even reach 1.5 ghz - this also explains while the rockchips are running so hot and are so hard to get to even 1.5 ghz compared to for instance amlogic cpus, which seem to run around 1.0 to 1.1 v (s905/s905x) for around 1.4 to 1.5 ghz. @jernej am i right, that this axpdummy regulator might simply be a dummy regulator allowing me to set the full range of voltages i need on the software side while in reality on the box the cpu simply runs with a hard coded voltage of maybe 1.06 v to reach the 1.5 ghz the box runs at maxium on android and in the case of my box even the 1.8 ghz. it still does frequency scaling, but most probably this will not help a lot on the thermal side without any real voltage scaling - i guess on android the constant hot plugging of unused cpu cores helps a bit to keep the temperature of the box acceptable. do i see it right that mainline linux does not support passive cpu cooling by dynamically disabling cpu cores? it does via dvfs, but this does not help us here, as there is most probably no voltage- (and just frequency-) scaling on those cheap h6 boxes. @jernej did you receive your tx-6 meanwhile? if yes any progress or plan regarding getting ethernet working? best wishes - hexdump
  20. i played around a bit more with the h6 qplus box - i used the kernel sources from https://github.com/megous/linux which are supposed to already contain some interesting h6 patches (dvfs, thermal sensor etc.). a defconfig kernel built from those sources runs fine and i could trick it into some dummy frequency scaling (with the default voltage only) with the attached dts and patch - depending on which (i guess virtual) voltage i gave my vcccpu regulator it scaled up to 1.8ghz (1.08hgz in the attached patch) and was running well and snappy as long as i kept the load on it low, but as soon as i put some heavy load on it (i ran glmark2 with mesa software rendering, which keeps the cpu cores at 50-80%) it rebooted after some minutes. looks like there is no way around understanding what the axpdummy device in android is doing to provide some voltage regulation - in android there is frequency scaling across several values with different voltages, so there must be some kind of voltage switching possible. i at some point also added some ethernet settings and got some ethernet interface, but as @jernej already mentioned in the libreelec forum there is most probably some coding for the phy required (got errors regarding the phy as soon as i tried to do anything with the interface). the thermal sensor points in /sys/class/thermal were there, but as soon as i tried to cat their temp values i only got an "invalid argument". i expected at least them to work, as they seem to be part of the soc itself and should not really depend on the device, but maybe my assumption here is wrong. (fyi @balbes150 for all the above). best wishes - hexdump qplus-dtb-plus-opp-changes.patch sun50i-h6-qplus.dts
  21. another update: meanwhile i have the box kind of booting using the libdram blob based uboot (so not redistributable), but still there is quite a bit left to be done to get it to some useful level. no progress so far on an open source dram config for ddr3 ram on h6 boxes. for more info see the github issue from the last post and this thread here: https://forum.libreelec.tv/thread/17636-tanix-tx6/?pageNo=1 ... best wishes - hexdump
  22. @Sico - did you get your usb serial adapter soldered properly to the board in the box and do you get some readable output when the box boots? if not there should be a lot of ressources on the net on how to get this working. please keep in mind, that rockchip boards usually use a speed of 1500000 instead of the usual 115200. if you get some boot output, then please create a pastebin of the boot output when you try to boot armbian on that box and post the link here. good luck - hexdump
  23. @Reddwarf for rk3328 you should look here:
  24. just a little update: there is now some more useful information regarding uboot for the h6 with ddr3 ram here: https://github.com/apritzel/u-boot/issues/4 (@jernej@balbes150) - a big thanks to andre for his very detailed responses! best wishes - hexdump
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines