I get the following in Ubuntu. It sees my sd card as /dev/sdb1, and shows that it writes data to the card (or so it appears), but the card is empty?? I'm hoping it's something simple I missed.
Note that sdb1 means partition. You want to write to raw SD card, which is achieved by removing the number, so you should use only /dev/sdb
Is the next step to copy this file to an SD card (formatted as FAT32)??
Filesystem type doesn't matter because we will work on SPL itself (SPL - secondary program loader, this loads U-Boot binary). U-Boot also supports many filesystems, so FAT32 is not requirement, it could also be ext4 or something else.
Anyway, 32-bit U-Boot without ATF (ARM trust firmware) and without correct DT can't really boot Linux. As I said earlier, it's only to examine how libdram intializes DRAM.
You can burn U-Boot by executing sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 (replace sdX with actuall device name, check dmesg after you plugged in your SD card). Please double check device name, you don't want to corrupt your PC disk.
*** Your GCC is older than 6.0 and is not supported
I think this issue is pretty self-explanatory. If you don't have new enough gcc, you can always download one from linaro page. If you want to use linaro toolchain, just extract it in one folder and execute export CROSS_COMPILE=/path/to/linaro/compiler/arm-linux-gnueabihf- (just replace "/path/to/linaro/compiler" with absolute path where you extracted linaro gcc).
CONFIG_MACH_SUN50I_H6_32=y
CONFIG_DRAM_SUN50I_H6=y /* this was previously not set */
CONFIG_DRAM_SUN50I_H6 is for 64-bit build, while CONFIG_MACH_SUN50I_H6_32 is for 32-bit. Note that libdram is 32-bit library, so it can be linked only with 32-bit SPL, so CONFIG_MACH_SUN50I_H6 should not be set.
CONFIG_NR_DRAM_BANKS=2 /* this was previously 1 - my box has 4GB RAM - what should this be set to???*/
This should be set to 1 for all Allwinner boards on all SoCs. It has nothing to do with amount of RAM, but how many memory regions there are. All Allwinner SoCs have whole DRAM mapped in one continuous region. Actually, there are other dislocated small SRAM regions, but they have special purpose so they don't count.
CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-tanix-tx6" /* changed the device tree name - should it be changed back???? */
At the end, it will be changed to "sun50i-h6-tanix-tx6", but this file doesn't exist yet and it currently doesn't matter much. Most, if not all, Allwinner boards follow common design, so for very basic functionality almost doesn't matter which DT you use in U-Boot. Linux is however different story, but we are not there yet. Just keep original value for now.
ukmark62 Congratulations! Small request, would you mind making basic device page with UART how-to on linux-sunxi.org (template: http://linux-sunxi.org/device_page_example)? You certainly don't need fill everything, but it would be nice to describe UART connection.
Ideally, you should now find which of USB ports is USB OTG. That way you could experiment with U-Boot without SD card, but you would need to corrupt existing Android installation. You would also need USB A to A cable, which may damage hardware if wrongly used (5V line could be cut to lower chance to damage anything). You decide if fast experimenting without SD card is worth this trouble. If so, I can give you few more advices how to do that.
If you are fine with burning your experimental U-Boot everytime to SD card, you could go to next step, which is to make working U-Boot with libdram (Allwinner DRAM driver). It's useful to have something which works and you then have register values which works for sure. Fortunately, someone already wrote short tutorial how to do that: https://forum.armbian.com/topic/10174-since-tanix-tx6-can-boot-from-the-sd-card/?do=findcomment&comment=80301
Note: Before you start following above instructions, make sure you have 32-bit ARM compiler. On my distro it's arm-none-eabi-gcc. You should also execute export CROSS_COMPILE=arm-none-eabi-, so U-Boot build system will pick up correct compiler.
Is there any way to monitor the temperature sensor for SoC?
No, there is no mainline driver for temperature sensor yet. Patches exist, but I didn't bother to include them. I think it runs on low enough temperature to not cause any defects. If you think SoC on your board is too hot, maybe you can help integrate patches and make PR to LE github?
Polczak Can you test this update if it fixes your HDMI audio issue? You have OrangePi PC+, right?
libreelec-h3.arm-9.1-devel-20190605180056-cdc4ec0-orangepi_pc_plus.tar
It contains this fix, which might solve issue you have: drm/rockchip: hdmi: fix no sound some time · Kwiboo/linux-rockchip@28e3e05 · GitHub
What commands you issued to change the BT MAC address?
btmgmt public-addr 00:03:19:9e:8b:00 But be aware that btmgmt is not included in image. I found it in bluez build folder.
This is every boot change or just one time?
Yes, every time. Somebody didn't find important to change default MAC address in production.
Quick solution would be to remove default MAC address check in driver, but then it would become an issue if someone has two such boards.
power_yura I'm not aware of any such tutorial. Procedure also depends if you want to use Armbian with mainline or BSP kernel. Additionally, if you would like to use mainline Armbian, you would have to keep kernels and dtb files separate because both projects contain a lot out of tree patches, which may not be compatible.
Hi jernej it's knowing bugs on opiplus2e in 2 last update
Is this based on last nightlies? If so, please wait for new update which should be available in about a week at most. There is a lot of video related fixes. If it still won't be fixed by that, then I will ask you for some information. But let's wait for updated image first.
ukmark62 Nice! Did you manage to capture some UART traffic already?
I'm not sure how much you know electronics, so I apologize if this is too basic for you:
At the end it doesn't matter which GND pin you use, if it's really GND. Be aware that those two pins could also be CTS and RTS signals being low most of the time or some other signals. GND pin can be usually visually identified by checking if it is connected to ground plane, which is also the reason why you need a bit more heat to solder anything to them (ground plane acts as a heatsink). Another method is to put one probe on something which is really ground, like negative contact on power connector or shield (ring) around screw hole, and then with other probe check continuity on GND pin candidates.
faredgeoffate You are probably using OrangePi 3 image? Be aware that they are not completely compatible. I would have to check differences in schematic. Images will be available for OrangePi Lite 2 too, eventually.
can you pass the command used to build it?
PROJECT=Allwinner ARCH=arm DEVICE=H6 UBOOT_SYSTEM=orangepi_3 make image
I fixed ethernet reboot issue. Bluetooth actually works, if you manage to change MAC address. I have to figure out how to do this best.
This branch will be PRed once I figure out why PineH64 is broken with OPi3 patches.
natumbri please test this image first: libreelec-h3.arm-9.1-devel-20190605004918-cdc4ec0-nanopi_m1.img.gz
If it is good, I'll ask to include this board in nightlies.
just wondering if you've been able to add the nano pi M1 build, at this stage?
It's in master, so now I have to ask to add it to nightly builds.
I also test different video resolutions and looks like only 1080p is affected with no HDMI sound.
If you switch back, does it work or not? It may be only notification issue.
Does this mean, HDMI passthrough is working if the issues are fixed?
No, passthrough is separate effort. Currently you might get lucky to get it work, but I wouldn't count on that.
Anyway, can anyone tells me what is so special on passtrough? Does it really matter if audio is decoded on SBC or AVR side? After all, in both cases audio is digitally transferred, so no loss of precision occurs.
I have been on holiday and will be back later this week to work on the Tanix TX6 H6 box.
Good. I hope you rested for DRAM driver work, which can be frustrating at times.
Hello.
As an addition to my issue with Audio not working on HDMI OPPC+: As I read all posts on this forum I notice solution to change resolution 1080p to 1080i.
Strange! But when I changed from 1080p to 1080i audio start working on HDMI and looks like HDMI Pass Trough is working also.
HDMI Audio related stuff in kernel will get rewrited in order to be acceptable for inclusion in mainline kernel. Hopefully rewrite will fix such issues and not introduce new ones. We'll see.
Can you test if changing in any other resolution also solves the problem?
I prepared initial OrangePi 3 support. Initial image can be found here:
libreelec-h6.arm-9.1-devel-20190603225103-f3b379f-orangepi_3.img.gz
Sources can be found here:
GitHub - jernejsk/LibreELEC.tv at aw_linux_patches
Known issues (apart from those in OP):
- ethernet doesn't work after reboot (physical power disconnection is needed, probably PMU related)
- bluetooth doesn't work (probably wrong firmware)
* The Orange PI PC device tree operating points table has only three states, and the fastest is 1.0 Ghz. As far as I remember, the SoC was supposed to run up to 1.5Ghz @ 1.3volts
Yeah, that's mainline issue due to missing temperature monitor driver. 1.5Ghz @ 1.3volts is actually already a overclocking, more like 1.3 GHz would be maximum. Anyway, you don't need any of that extra speed if you watch videos which are HW decoded.
* There is no cpufreq driver built in the kernel. Is it expected?
I have to check that.
* About CEC, there is a Kodi thread that apparently is using a lot of cpu time related to CEC. Doing a strace over it seems to continously scan the /sys directory in search for something and never stops. Maybe there's something missing to let it find the proper CEC device to listen to
Can you check if this is related to tinkerboard: disable 5s polling for CEC adapters by viulian · Pull Request #3506 · LibreELEC/LibreELEC.tv · GitHub ?
