chwe

Moderators
  • Content count

    583
  • Joined

  • Last visited

1 Follower

About chwe

Profile Information

  • Location
    Switzerland

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. chwe

    BananaPi R2 (.csc)

    A shortly update: U-Boot is fixed to a level where I decide, that it isn't worth to put more efforts in at the moment... Bootorder: tries to boot with bootscript sitting in /boot/boot.scr (tested works) in case there is not bootscript or the script fails --> uInitrd, zImage, dtb in armbians default folders and if there is no uInitrd (or it isn't 'sane') it boots with zImage and dtb only. booargs=earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 Memory adressing: ~62MB for the kernel 512kB for boot.scr 512kB for DTB 32MB for uInitrd Don't know how 'sane' those settings are, but it should be more than enough... In case someone wants for whatever reasons uImages with flattened device tree, you can place a bootscript in mmc 1:1 /boot/boot.scr and do whatever u-boot is able to do. Every boot without a boot.scr will set some default bootargs (earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0), in case you test a build and those bootargs aren't correct for you (especially root=/dev/mmcblk0p1 and rootfstype=ext4) better interrupt the boot (you've a 3 seconds timeframe for doing that, and set proper bootargs for your boot to avoid fooling your kernel.. earlyprintk is enabled by default when you use my config file and it's set to the right serial-console for the R2 CONFIG_DEBUG_UART_PHYS=0x11004000 CONFIG_DEBUG_UART_VIRT=0xf1004000 (earlyprintk will be silent without proper settings here, and the currently available defconfig sets them false, probably cause it's based on the evb board, where UART0 is used as debug, whereas the R2 uses UART2 for it) There is currently no 'preboot logic' for to decide if mmc 1 (SD-card) or mmc 0 (eMMC) should be initialized and u-boot expects ext4 FS , but cause all load commands and all calls to mmc_number/partition are done with variables, such a 'preboot-logic' shouldn't be that hard to implement. It's flexible enough but I didn't implement it yet. We're far away for a 'nand-sata-install' implementation and therefore there it's to early to care about such a implementation. As far as I see it at the moment such a 'preboot logic' wouldn't need any rework of the 'bootlogic' (but who knows, u-boot fooled me more than once... ). There are still a bunch of warnings during build of u-boot but none of them seems to be 'harmful'. As long as u-boot doesn't bother me anymore or not behaves as it should, I wont clean it up more that it is now.. eMMC is not on my 'priority list' so don't expect that care much about it in the near future It's somewhere between HDMI and onboard wifi and I don't care about both 'features'... Just to point it out. I will not look into HDMI as long as those patches aren't available in Linus tree. If someone else writes a proper patch to implement it earlier fine, I'm not willing to do it (and I don't have a spare HDMI display to test it, so someone else has to test it too.. ). 799 bytes read in 34 ms (22.5 KiB/s) Running boot/boot.scr from: mmc 1:1 using boot/boot.scr ## Executing script at 85f80000 33841 bytes read in 47 ms (703.1 KiB/s) 4789617 bytes read in 695 ms (6.6 MiB/s) 6091360 bytes read in 864 ms (6.7 MiB/s) Booting boot/zImage boot/uInitrd boot/dtb/mt7623n-bananapi-bpi-r2.dtb from: mmc 1:1 using bootargs=initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 loglevel=1 bootm flag=0, states=1 Kernel image @ 0x82000000 [ 0x000000 - 0x5cf260 ] ## Loading init Ramdisk from Legacy Image at 86080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4789553 Bytes = 4.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 86000000 Booting using the fdt blob at 0x86000000 bootm flag=0, states=700 Loading Ramdisk to 8fb6e000, end 8ffff531 ... OK Loading Device Tree to 8fb62000, end 8fb6d430 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. ... ... ... [ OK ] Reached target Login Prompts. [ OK ] Started LSB: Start NTP daemon. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux 9 bananapir2 ttyS0 bananapir2 login: Next steps: Network (mostly untested, but as far as I know, it doesn't connect automatically to my router) Kernelconfig should be adjusted to have something 'armbianalike' As soon as network works 'reliable', I hope that others step in for discussion & testing. I think we reach than a point where most of the 'interesting features' (USB, SATA, Network) are there, so usage as NAS or 'Routerboard'. At the moment, desktop is disabled, and might be disabled until someone deals with HDMI. [off topic] Still don't think that I'm a experienced u-boot hacker... But arrogant enough to call my self a u-boot plumber now...
  2. Opi zero! =opi zero plus... Search for the correct image, the downloadpage shows you a picture to compare.. zero Plus is h3/h5 (if i have it right in mind) and the normal zero is a h2+ soc.
  3. chwe

    Booting a rt preempt patched kernel

    Solved (in armbian) with armbianEnv.txt (or boot.cmd for the risky ones.. don't do it! ) IMO every board which has the SD-Card first in bootorder should'nt have a bootmenu in u-boot (you can interupt the boot by hitting every key... ) and if one of those 'bootscripts' has a saveenv in it.. better hope that it's a garbage variable you don't use..
  4. chwe

    Librecomputer Tritium H3

    That's what 'known issues' are for.. We can't avoid that people will not notice it but that's also true for all the boards we currently support. For me, there's no reason to provide the BSP kernel for new boards anymore. IMO the goal must be to get the BSP kernel dropped, as soon as the VPU works on mainline. Then, the only use case which comes to my mind for the BSP kernel would be 'camera' but the last time I looked into it, camera (ov5640 only cause there's no mainlinedriver for the gc2035) on mainline seems to work too (somebody here ever tried it here?). Adding more boards to the BSP kernel would only mean that we have to convince more people that they should switch to mainline as soon as we drop the BSP kernel. Armbian got popular... (I'm one of the guys dropped into it when H2+/H3 boards worked more or less without major issues). Cause initial boardsupport was relatively easy in the past for H3 boards (add a board.conf, fex-file, patching u-boot with adding one defconfig more, mostly copy paste from another one - as long as it isn't a BPi-M2-Zero ) adding more boards was easy, armbian gets more popular --> more boards of the same SoC came to the table. Maintaining all those H3 boards is what needs a lot of resources. More or less every boardmaker selling H3 devices writes the Allwinner specs for the SoC (maybe possible with Android, I don't know, I don't care) and not "what is possible/works with Linux" on their boarddescription, so most people. And people don't do research first for a board which cost 8-20$, they buy it and they expect that this works. Why not? The Raspberry was able to play Kodi with minor issues ~2012, so why should a board which is sold in 2018 not be able to do what's written in the description (don't hang me on the exact date, I'm to lazy do to the research when the RPi was able to run Kodi 'smoothly' )? I can somehow understand people that this should work in 2018. To lazy to go through all boardmakers (I think friendlyarm doesn't advertise 'videocapability' but I can be wrong)... What about: Having them as .csc until one of the GitHub maintainers decide to take care/responsibility for it (doesn't mean that the others should avoid working on/with it, but that at leas one maintainer knows how good the board works/ what's currently not working etc.) all CSC boards have their separate patch folder so that they can't harm board we support (may need some rework of patches when they get moved to wip or supported) but then the maintainer decided to take responsibility for that new board knows what to do. I think even boards which are initially supported by a maintainer should start as csc first, to get 'a feeling' if it's worth to level the board up to wip or supported.. People expect active work on wip boards and we have currently 7 boards (master branch) which are labeled wip (rock64 will switch to supported, and olinuxino A64 disappeared in development). Do we have (at the moment) enough resources to bring more boards to wip (isn't there some work related to the merge of development --> master which might be of higher priority - I happily help with everything I committed to the dev branch)?
  5. chwe

    Booting a rt preempt patched kernel

    have fun... don't be upset when it b*tches you... When it looks like this one: you might understand why I removed it fully... It could be fun, in case you're patient enough to test it.. I prefer bootscripts, they can be adjusted in case something goes wrong.. The bootmenu needs recompilation of u-boot... The only usecase I can imagine is to load different bootscripts... (okay, maybe some 'fancy' stuff like boot over Ethernet, or recovery over *whatever is implemented* in u-boot might be useful)..
  6. chwe

    Booting a rt preempt patched kernel

    Boot menu for what? Choosing different kernels/OS? There was also one on mediateks/BPi R2 u-boot (removed it, I don't think it does sane things)... You can define multiple bootcommands, and during bootup of u-boot you can decide which one you want to run... The mediatek one was highly 'static' and not really useful so I saw no reason to keep it inside... If it's there, people will think it does sane things.. IMO if this is not tested (for armbian) it might mess up things, be save, patch it out...
  7. chwe

    BananaPi R2 (.csc)

    Sometimes... You've to try it.. Welcome to the flattened device tree.... (I don't post the whole bootlog, but it comes into login screen) mmc1 is available mt7623-uboot > setenv bootargs earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 mt7623-uboot > setenv loadaddr 0x82000000 mt7623-uboot > setenv kernel_addr_r 0x82000000 mt7623-uboot > setenv fdtaddr 0x86000000 mt7623-uboot > setenv fdt_addr_r 0x86000000 mt7623-uboot > setenv rdaddr 0x86080000 mt7623-uboot > setenv ramdisk_addr_r 0x86080000 mt7623-uboot > setenv bootm_size 0x10000000 mt7623-uboot > ext4load mmc 1:1 ${fdtaddr} /boot/dtb/mt7623n-bananapi-bpi-r2.dtb 33841 bytes read in 67 ms (493.2 KiB/s) mt7623-uboot > ext4load mmc 1:1 ${kernel_addr_r} /boot/zImage 6091368 bytes read in 870 ms (6.7 MiB/s) mt7623-uboot > ext4load mmc 1:1 ${rdaddr} /boot/uInitrd 4789600 bytes read in 699 ms (6.5 MiB/s) mt7623-uboot > bootz ${kernel_addr_r} ${rdaddr} ${fdtaddr} bootm flag=0, states=1 Kernel image @ 0x82000000 [ 0x000000 - 0x5cf268 ] ## Loading init Ramdisk from Legacy Image at 86080000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4789536 Bytes = 4.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 86000000 Booting using the fdt blob at 0x86000000 bootm flag=0, states=700 Loading Ramdisk to 8fb6e000, end 8ffff520 ... OK Loading Device Tree to 8fb62000, end 8fb6d430 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.43-mt7623n (root@Buildmachine) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5 SMP Thu May 24 00:19:20 CEST 2018 [ 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Bananapi BPI-R2 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] [WMT-CONSYS-HW][W]reserve_memory_consys_fn: name: consys-reserve-memory, base: 0xffe00000, size: 0x100000 [ 0.000000] OF: reserved mem: initialized node consys-reserve-memory, compatible id mediatek,consys-reserve-memory [ 0.000000] cma: Reserved 64 MiB at 0xfb800000 [ 0.000000] percpu: Embedded 17 pages/cpu @eed99000 s38476 r8192 d22964 u69632 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 522303 [ 0.000000] Kernel command line: earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait audit=0 [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1990528K/2096124K available (9216K kernel code, 771K rwdata, 2816K rodata, 1024K init, 563K bss, 40060K reserved, 65536K cma-reserved, 1244156K highmem) ... [ OK ] Started LSB: Start NTP daemon. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux 9 bananapir2 ttyS0 bananapir2 login: Thank you @zador.blood.stained.
  8. chwe

    BananaPi R2 (.csc)

    From what I understand so far.. U-boot sits at the beginning of memory, defined in #define CONFIG_SYS_TEXT_BASE 0x81E00000 means that as soon as I start to load my stuf in >0x81E00000, I 'should be save'. The rest of u-boot is leveled to the highest available memory (or the highest u-boot can initialize).. And the kernelpanic is related to, u-boot is moving around my dtb so that the kernel does not longer find it and therefore struggles due to not getting its information from the dtb. (written like a noob, but I'm not a u-boot hacker... ). From what I think I understand (partly), everything between, SYS_TEXT_BASE and SYS_MALLOC_LEN should be save for Linux. right? And now.. the part which is confusing or 'not that clear'. So this is the u-boot confing related part for memory: /********************************************************************************************** * Memory **********************************************************************************************/ /* Memory layout */ /* DRAM definition */ /* * Iverson 20140521 : We detect ram size automatically. * CONFIG_SYS_SDRAM_SIZE define max uboot size. * The max size that auto detection support is 256MB. */ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_SYS_SDRAM_BASE 0x80000000 /* Code Layout */ //#define CONFIG_SYS_TEXT_BASE 0x80000000 #define CONFIG_SYS_TEXT_BASE 0x81E00000 /* Uboot definition */ #define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_UBOOT_MAX_SIZE SZ_2M #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_TEXT_BASE + \ CONFIG_SYS_UBOOT_MAX_SIZE - \ GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_MALLOC_LEN SZ_32M /* RichOS memory partitions */ #define CONFIG_SYS_DECOMP_ADDR 0x80008000 #define CONFIG_SYS_LOAD_ADDR 0x83000000 #define CONFIG_SYS_IMAGE_HDR_ADDR CONFIG_SYS_LOAD_ADDR /* Linux DRAM definition */ #define CONFIG_LOADADDR CONFIG_SYS_LOAD_ADDR /* * For booting Linux, the board info and command line data * have to be in the first 64 MB of memory, since this is * the maximum mapped by the Linux kernel during initialization. */ #define CONFIG_SYS_BOOTM_LEN 0x4000000 So, my u-boot can initialize half of a memorychip (there are 4x512MB on the board), up to 0x81E00000 and over (256MB-32MB=)224MB is used by u-boot so, better don't mess in this area as long as u-boot controls the hardware. The kernel itself has (according to the comment here) to be in the first 64MB (between 0x81E00000 and 0x85E00000 - I'm really bad in converting numbers.. ), the FDT can be slightly over it. 0x86000000) and we give it some 'save space' means, 0x86000000 - 0x86080000 = 512kB which should be more than enough for a DTB, currently its: mt7623-uboot > ext4load mmc 1:1 0x83000000 /boot/dtb/mt7623n-bananapi-bpi-r2.dtb 33841 bytes read in 49 ms (673.8 KiB/s) and over this there is space for uInitrd (0x86080000 - 0x87F80000) cause over 0x87F80000, the place is resvered by U-Boot with CONFIG_SYS_MALLOC_LEN. Are some of those env variables 'generic', means a normal u-boot should clearly understand what they are for (e.g bootm_size etc.)? I found a example here: #define DEFAULT_LINUX_BOOT_ENV \ "loadaddr=0x82000000\0" \ "kernel_addr_r=0x82000000\0" \ "fdtaddr=0x88000000\0" \ "fdt_addr_r=0x88000000\0" \ "rdaddr=0x88080000\0" \ "ramdisk_addr_r=0x88080000\0" \ "scriptaddr=0x80000000\0" \ "pxefile_addr_r=0x80100000\0" \ "bootm_size=0x10000000\0" or do I have to dive into this definition file and do a lot of comparing with mine? So adjusted to mine, this would mean: #define DEFAULT_LINUX_BOOT_ENV \ "loadaddr=0x82000000\0" \ "kernel_addr_r=0x82000000\0" \ "fdtaddr=0x86000000\0" \ "fdt_addr_r=0x86000000\0" \ "rdaddr=0x86080000\0" \ "ramdisk_addr_r=0x86080000\0" \ "bootm_size=0x10000000\0" and a bit later I had to make some space for scriptaddr (e.g another 512kb --> 0x82000000 - 0x82080000 and set kernel_addr_r to 0x82080000).. I guess most of those questions can only be found out by testing.. but just to get a clue if I think in the right direction... To avoid: Edit: better put script near to fdt_addr, due to, don't need the lower space as long as it is properly loaded right? hmmmm... questions over questions...
  9. chwe

    BananaPi R2 (.csc)

    Last update for today... I compiled a kernel with earlyprintk (not set by default, and I think I lost it somehow when I messed around with kernelconfigs...) So it panics quite early with: bootargs: earlyprintk initcall_debug console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait coherent_pool=4M audit=0 Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.43-mt7623n (root@Buildmachine) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5 SMP Thu May 24 00:19:20 CEST 2018 [ 0.000000] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Bananapi BPI-R2 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] [WMT-CONSYS-HW][W]reserve_memory_consys_fn: name: consys-reserve-memory, base: 0xffe00000, size: 0x100000 [ 0.000000] OF: reserved mem: initialized node consys-reserve-memory, compatible id mediatek,consys-reserve-memory [ 0.000000] cma: Reserved 64 MiB at 0xfb800000 [ 0.000000] Unable to handle kernel paging request at virtual address 3fff4000 [ 0.000000] pgd = c0004000 [ 0.000000] [3fff4000] *pgd=00000000 [ 0.000000] Internal error: Oops: 5 [#1] SMP ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.43-mt7623n #5 [ 0.000000] Hardware name: Mediatek Cortex-A7 (Device Tree) [ 0.000000] task: c0f071c0 task.stack: c0f00000 [ 0.000000] PC is at fdt_check_header+0xc/0x80 [ 0.000000] LR is at __unflatten_device_tree+0x80/0x2d4 [ 0.000000] pc : [<c091f818>] lr : [<c06fdce0>] psr: 600000d3 [ 0.000000] sp : c0f01ed0 ip : c0f01ee0 fp : c0f01edc [ 0.000000] r10: 00000000 r9 : c104f0e4 r8 : 00000000 [ 0.000000] r7 : c0e3ddfc r6 : 3fff4000 r5 : c0e5db54 r4 : c0fba4f0 [ 0.000000] r3 : 00000000 r2 : c104f0e4 r1 : 00000000 r0 : 3fff4000 [ 0.000000] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none [ 0.000000] Control: 10c5387d Table: 8000406a DAC: 00000051 [ 0.000000] Process swapper (pid: 0, stack limit = 0xc0f00218) [ 0.000000] Stack: (0xc0f01ed0 to 0xc0f02000) [ 0.000000] 1ec0: c0f01f14 c0f01ee0 c06fdce0 c091f818 [ 0.000000] 1ee0: c0e1e58c c0e1e148 ffffffff c0e3ddfc c0e5db54 c0f06ec0 fff00000 c0ffa154 [ 0.000000] 1f00: efffce80 fffff000 c0f01f34 c0f01f18 c0e3f088 c06fdc6c 00000000 c0f01f28 [ 0.000000] 1f20: c012e374 c0f08488 c0f01fac c0f01f38 c0e03c34 c0e3f050 ffffffff 10c5387d [ 0.000000] 1f40: ffffffff 8000406a 80000200 c0bb9e24 c0c80000 c0f0bde8 c0fc8990 c0f28fd8 [ 0.000000] 1f60: c0bb8414 c0f01fa4 c0f01f84 c0f01f78 c017e32c c017cfcc c0f01f9c c0f01f88 [ 0.000000] 1f80: c017dc90 00000000 00008200 c0f03c40 ffffffff 8000406a 410fc073 00000000 [ 0.000000] 1fa0: c0f01ff4 c0f01fb0 c0e00ae4 c0e033d0 00000000 00000000 00000000 00000000 [ 0.000000] 1fc0: 00000000 c0e6ba28 00000000 c0fc8794 c0f03c58 c0e6ba24 c0f08600 8000406a [ 0.000000] 1fe0: 410fc073 00000000 00000000 c0f01ff8 8000807c c0e00a80 00000000 00000000 [ 0.000000] [<c091f818>] (fdt_check_header) from [<c06fdce0>] (__unflatten_device_tree+0x80/0x2d4) [ 0.000000] [<c06fdce0>] (__unflatten_device_tree) from [<c0e3f088>] (unflatten_device_tree+0x44/0x54) [ 0.000000] [<c0e3f088>] (unflatten_device_tree) from [<c0e03c34>] (setup_arch+0x870/0xc8c) [ 0.000000] [<c0e03c34>] (setup_arch) from [<c0e00ae4>] (start_kernel+0x70/0x3c4) [ 0.000000] [<c0e00ae4>] (start_kernel) from [<8000807c>] (0x8000807c) [ 0.000000] Code: e89da800 e1a0c00d e92dd800 e24cb004 (e5903000) [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x50/0x58 with crng_init=0 [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! Any help is appreciated..
  10. chwe

    BananaPi R2 (.csc)

    A small follow up: -USB dmesg error is gone, due to (once again thank to frank-w): CONFIG_REGULATOR_FIXED_VOLTAGE=y so, USB devices get recognized: [ 253.503520] usb 3-1: new high-speed USB device number 2 using xhci-mtk -general-packaging-4.17-dev.patch was applied to dev kernelbranch and packs the kernel as expected (didn't test the image yet). -Flattened device trees still fail with more or less every combination which comes to my mind (uImage/zImage). That's normally the last message I get... mt7623-uboot > setenv bootargs console=ttyS0,115200n1 root=/dev/mmcblk0p1 rw rootfstype=ext4 rootwait coherent_pool=4M audit=0 mt7623-uboot > ext4load mmc 1:1 0x84000000 /boot/dtb/mt7623n-bananapi-bpi-r2.dtb 33841 bytes read in 44 ms (751 KiB/s) mt7623-uboot > ext4load mmc 1:1 0x86000000 /boot/uInitrd 4789596 bytes read in 705 ms (6.5 MiB/s) mt7623-uboot > ext4load mmc 1:1 0x83000000 /boot/zImage 6100568 bytes read in 874 ms (6.7 MiB/s) mt7623-uboot > bootz 0x83000000 0x86000000 0x84000000 bootm flag=0, states=1 Kernel image @ 0x83000000 [ 0x000000 - 0x5d1658 ] ## Loading init Ramdisk from Legacy Image at 86000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4789532 Bytes = 4.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 84000000 Booting using the fdt blob at 0x84000000 bootm flag=0, states=700 Loading Ramdisk to ffb6e000, end fffff51c ... OK Loading Device Tree to ffff4000, end fffff430 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. -the first cleaned up bootsequence is a bit faulty.. but I think it's just something obvious I missed.. bpi r2 boardconfig is separated from evb board, so in case a second board works with the same u-boot (to my knowledge all u-boots for mt-7623 SoCs are based on a 2014.04 and nobody tried to bring MT u-boot support to upstream).
  11. chwe

    Quick review of NanoPi Fire3

    nice to learn. I would still be interested if somebody ever saw tests, testing procedures (cause more or less every SD-Card is rated up to 85°C). I had some initial ideas testing this.. But obviously you need many cards from the same brand, from different production batches, from trusted sources but not from them self (to ensure you get what the average buyer of original cards get) to get somehow scientific valid data.. Which then I thought, it's not worth the efforts just out of curiosity.. Cause you maintain probably 'one or two' SBCs more than me.. did you notice issues related to this? So that reliable (and I think you don't use crappy SD-Cards anywhere) SD-Cards die faster on small boards if they run at higher temperatures for a longer time? Cause this is not really related to the nanopi fire 3 review, I happily split this into it's own topic to keep this one clean in case you prefer it.
  12. chwe

    BananaPi R2 (.csc)

    I really don't care about naming for the BOARDFAMILY yet... There are two SoCs, the mt7623a and the mt7623n. According to Mediateks 'marketing page': if we can support both chips with one config.. fine would it make easier to maintain it.. If they differ to much, IMO we should have two config files.. But I don't think about the 'endproduct' as long as more important issues aren't solved, might be related to my background, but every-time I try to solve eveything with something I think it's a smart solution I got fooled (not only related to SBCs, it's also they way science works). So, my 'roadmap' looks like the following: reliable boot.scr that works on the first boot & further u-boot clean up (there are a bunch of functions defined in the boardconfig file from the 'bootmenu' which was there before, since this menu is fully removed (I don't like it, we don't need it, it's a way to 'static' for my purposes - I'm far away from calling my solution 'smart' but at least I can change things from linux with /boot/boot.cmd without recompilation of u-boot everytime and it drove me nuts to get 'this feature', as said I'm not an experienced u-boot hacker and 'source' only works if you load it into the right adress, it fools you if you don't do it 'right'). E.g. ext4load mmc 1:1 0x83000000 /boot/boot.scr source 0x83000000 didn't work.... but ext4load mmc 1:1 0x84000000 /boot/boot.scr source worked due to somewhere before there was something like: /* RichOS memory partitions */ #define CONFIG_SYS_DECOMP_ADDR 0x80008000 #define CONFIG_SYS_LOAD_ADDR 0x84000000 #define CONFIG_SYS_IMAGE_HDR_ADDR CONFIG_SYS_LOAD_ADDR /* Linux DRAM definition */ #define CONFIG_LOADADDR CONFIG_SYS_LOAD_ADDR That said, I hope that someone knowing u-boot ~2014 well enough can give me some hints to clean things up.. or Sinovoip decides to help cleaning up u-boot.. The bootmenu does just look wrong/useless to me. get rid of the annoying 'appended device tree blob to zImage' (I don't like it, it seems to be not necessary due to evb board with the same SoC doesn't need it) testing interfaces - the only one I'm interested at the moment are ETH, SATA and USB (and then mPCIe), I don't care about HDMI nor pinheader nor internal wifi (if someone cares, fine fix it test it send PRs). I don't care about benchmarking those interfaces (that's for the people who do benchmarking always wrong or for those who do care about proper benchmarking - I don't want to be one of the first group and I've neither the equipment nor the experience to be in the second group, so let other people do this...) find a somehow 'armbian-like' kernel config (so that modules we have activated on most next/dev images are here too and people do not get fooled that this is the only board where *random kernel module* isn't there 1&2 are for me of most importance.. 3 to the point that those interfaces work and 4.. hmm I still hope that others join the 'party' otherwise I might bring it only to the point where it's usable for me (and with some nasty hacks, making it usable for me would probably be an easy task - but I'm looking for a solution which is easy to maintain in case this SoC gets support by armbian and therefore I try to avoid nasty hacks)... the chip is called mt6625ln if I saw this right (getting 'eye cancer' by reading such tiny tiny labels)..
  13. chwe

    BananaPi R2 (.csc)

    If that's the only mistake in my starter, well than I probably didn't did much wrong.. Compared to the Gitbook, the wiki seems to be a way more readable.. It's to that spot new, that I didn't notice it before.. It's somehow readable, there's for sure space for improvements but I prefer one wiki page per board over 100 gitbook slides so for me this is an improvement.. Thanks for sharing.. It's somewhere on my 'look into list' shortly before internals wifi cause not of much interest for my purposes at the moment. There are obviously more issues to solve to improve my current builds. As far as I understand, due to NDAs there will be no chance that you can release the sources of HEAD440, HEAD512b and the preloader right? Armbians write uboot platform function of the buildscript works quite well, and those images boot (at least into u-boot without issues, it still needs some housekeeping for the kernel but that's under rework. It looks like the following: dd if=PI-R2-HEAD440-0k.img of=$2 bs=440 seek=0 count=1 status=noxfer > /dev/null 2>&1 dd if=BPI-R2-HEAD1-512b.img of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1 dd if=BPI-R2-preloader-2k.img of=$2 bs=1k seek=2 status=noxfer > /dev/null 2>&1 dd if=u-boot.bin of=$2 bs=1k seek=320 status=noxfer > /dev/null 2>&1 but if I've a look into the files: -rw-rw-r-- 1 opi opi 1536 May 13 14:19 BPI-R2-HEAD1-512b.img -rw-rw-r-- 1 opi opi 440 May 13 14:19 BPI-R2-HEAD440-0k.img -rw-rw-r-- 1 opi opi 91996 May 13 14:19 BPI-R2-preloader-2k.img HEAD1-512b doesn't fit, and gets mostly overwritten by the preloader... It works, and I don't see anything going wrong but can you explain what HEAD-512b exactly does? I guess it sets some env variables for u-boot cause even when I remove them fully from the boardconfig file in u-boot, they're still there... How are those HEAD files generated, is there a chance to generate them by our own and when not, can you provide a head which is cleaned up (I don't need any variables set by a binary, I set them happily by my self with the boardconfig or via bootscript ). Next question about those binaries: BPI-R2-preloader-2k.img BPI-R2-720P-2k.img BPI-R2-2k-SD-20180320.img BPI-R2-1080P-2k.img can you explain the differences between all those 2k preloaders? I guess 720p/1080p relates to HDMI, is this just during bootup? (in case yes, I don't care) At the moment I use 'BPI-R2-preloader-2k.img' and it works.. what's the difference between this one and the more recent one 'BPI-R2-2k-SD-20180320.img'? And the last question I have... Can you comment this one: So, the SoC, u-boot and a similar board is capable for flattened dtb. Every attempt I tried with not appended device tree blobs failed.. The DTB is recognized, u-boot 'knows' that it's there e.g. BPI-IoT> bootz 0x84000000 - 0x83000000 bootm flag=0, states=1 Kernel image @ 0x84000000 [ 0x000000 - 0x5d1680 ] ## Flattened Device Tree blob at 83000000 Booting using the fdt blob at 0x83000000 bootm flag=0, states=700 Loading Device Tree to ffff4000, end fffff430 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. 'Uncompressing Linux... done, booting the kernel.' is to my knowledge not a u-boot message (to my knowledge the last u-boot message you get is Starting kernel ...) but then, it gets silent.. Some adjustments for your kernel config: CONFIG_DEBUG_UART_PHYS=0x11004000 CONFIG_DEBUG_UART_VIRT=0xf1004000 Cause compared to the evb board R2 standard debug uart sits on UART2 not UART0, otherwise the device gets silent with starting kernel ... So by correcting this I got one message more.. but it's still not solved.. I would prefer to have kernel and DTB separated and 'it should be possible' cause a similar board (according to Wolfgang the evb is able whereas the bpi not).
  14. chwe

    single user mode ?

    nope, I dd /dev/zero to card and it shows that card is zeroed, I remove card, return it and the old content is there... no way to write anything to card, it's ignoring writes (silently) ... that confirms also that the crappy card is dead.. and that this can fool you cause 'everything looks fine'... Read only is mostly a clear sign that things gone wrong.. And your cheap card costs you in fact more if you count the time you wasted to debug it.. (but you learned something, this might be worth for the future)... It works to the point were everything works as expected... My personal opinion, everyone who deals with SBCs should spend 1-2$ for a USB-UART (IMO every board >20$ should be sent with a el cheapo USB-UART, but different story). Reporting kernel-output to UART works even with a 'near to death' kernel, whereas HDMI.... you figured it out by your own.. It struggles earlier.. All the HDMI port's on my SBCs are 'virgin' cause they are either running headless over Ethernet or connected via UART during troubleshooting.
  15. chwe

    single user mode ?

    So I'll move this one two to the famous crappy SD-Card/PSU section as well (it was maybe not that crappy in the beginning but for sure.. now it is).... Just out of curiosity.. before you throw away the SD card... Can you format it with whatever you use.. and then let F3 or h2testw running and post the result you get here... It would enhance our collection of 'It's not a software problem - your SD card is crappy' (not to blame you for something, just to show people that those ideas of 'crappy/dead sd-cards' isn't only a myth.. otherwise people start to believe that SD-Cards life forever... ). and to my shame.. I came up with UART a way to late.. It's normally the first recommendation... well... I quoted this just for fun...