Posts by jernej

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from Gatuno

    I'm testing the Orange PI 3 image and still has the "ethernet reboot issue". I understand that this is a 'known bug'.

    Which image? the one I linked? if yes, then yeah, that image still has that issue. However, if you build your image from source, it should work.

    Quote from Gatuno

    In other things, I would be very useful for orange pi 3 if you could add "mmc2" definition in the device tree for u-boot loader. This could allow the image to be "dumped" directly to the integrated emmc. I understand that there is not official support for "dumping" the image yet, but, useful.


    In the current testing image, the emmc is not listed at /dev (usually named mmcblk2).

    It would be best to add them to U-Boot and Linux kernel (not the same DT files are used for now). You can make pull request against Libreelec master with necessary updates to opi3 patches.

    Quote from natumbri

    Thanks - I've done a basic test, and the image seems to work at least as well as the early build.

    Ok, thanks for testing, I'll ask for nightly builds. I'll ask for OrangePi 3 too (I know you are not interested in that board, but just for public note).

  • Tanix TX6

    Quote from ukmark62

    What would be the next step for me to do? Thx.t

    Now the fun begins. First of all, make a backup of those binaries, they will be useful to check out register values at later time. Better yet, make another clone of that git repository in another folder, like this:

    git clone https://github.com/apritzel/u-boot.git u-boot-dram-wip

    go into that folder and execute:

    Code
    git checkout 7702a7c2b1ef4c56fc6fd6b7605f81ede82a07db
git checkout -b h6-ddr3

    Important, you need 64-bit ARM GCC for that, including correct CROSS_COMPILE value.

    Now you will have U-Boot with work in progress H6 DDR3 driver. Building instructions still applies here, except that libdram is no longer used. This code is just few commits back from libdram one.

    We will have to fix arch/arm/mach-sunxi/dram_sun50i_h6.c and arch/arm/mach-sunxi/dram_timings/h6_ddr3_1600.c .

    This is also perfect time to get familiar with our primary sources of information for this job. File arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h has a lot of useful references to similar DRAM controllers with documentation available. It would be useful to obtain a copy of pdf or find a web page with docs.

    So from now on it's modify above files, build new U-Boot, flash it on SD card and test if it helps anything. Standard debug practice is to add printf(), so you can see final register values and compare to the working ones from libdram version.

    I will help you with ideas what to change based on reverse engineering libdram and looking what it does for DDR3.

    BTW, I'll ask moderators to split this conversation to a new thread.

  • Tanix TX6

    Quote from ukmark62

    It mentions RAM of 2gb in the log, should that not be 4gb? The box is 4gb ram and 64gb rom (or supposed to be).

    H6 only supports 3 GiB of memory, so if you have it 4 GiB on board, you should see 3 GiB reported in U-Boot.

    There are two possible reasons why you see 2 GiB reported:

    1. libdram supports only power of two sizes

    2. Eachlink board has only 2 GiB of RAM and there is a hack for that.

    In any way, when DDR3 support will be fixed, you should see 3 GiB reported.

  • Tanix TX6

    Quote from ukmark62

    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

  • Tanix TX6

    Quote from ukmark62

    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.

  • Tanix TX6

    Quote from ukmark62

    *** 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).

    Quote from ukmark62

    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.

    Quote from ukmark62

    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.

    Quote from ukmark62

    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.

  • Tanix TX6

    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.

  • Nightly images for A64, H3, H5, H6 and R40 boards

    Quote from Gatuno

    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.

    Quote from Gatuno

    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.

  • Nightly images for A64, H3, H5, H6 and R40 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.

    Quote from hostkit

    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.