tmountain

  • Posts

    9
  • Joined

  • Last visited

tmountain's Achievements

  1. Yes, my. issue is resolved. Thank you for your help.
  2. I could not get the aforementioned kernel to work, but I have managed to build a u-boot that works with the NanoPC-T4 without using trust_merger (only using the ATF). $ docker run -ti ubuntu:focal # apt-get update # apt-get -y install build-essential flex bison gcc-aarch64-linux-gnu git device-tree-compiler python3 gcc-arm-none-eabi bc # cd /root # git clone https://github.com/ARM-software/arm-trusted-firmware.git # git clone https://github.com/u-boot/u-boot.git # cd arm-trusted-firmware/ # make realclean # make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31 # cp /root/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf ../u-boot/ # cd ../u-boot # make CROSS_COMPILE=aarch64-linux-gnu- nanopc-t4-rk3399_defconfig # make CROSS_COMPILE=aarch64-linux-gnu- # git clone http://github.com/armbian/rkbin rkbin # rkbin=./rkbin # ./tools/mkimage -n rk3399 -T rksd -d ${rkbin}/rk33/rk3399_ddr_800MHz_v1.24.bin idbloader.img # cat ${rkbin}/rk33/rk3399_miniloader_v1.19.bin >> idbloader.img Copy files to target machine... # dd if=idbloader.img of=/dev/mmcblk2 conv=fsync,notrunc bs=512 seek=64 # dd if=u-boot.itb of=/dev/mmcblk2 conv=fsync,notrunc bs=512 seek=16384
  3. Sure, I will test this. The whole set up right now is a "throwaway". I'm basically using the nano to learn more about SoC, u-boot, aarch64, etc. I've been testing with the kernel that ships with Nix, but I've also done some testing with kernel that ships with Armbian. I'll report back.
  4. Hi, Space is reserved at the beginning of the emmc for u-boot, and your kernel, initrd, etc... are located after this reserved space. When u-boot starts up, it does a bunch of initialization and then hands over control the kernel. As such, updating your kernel does not require a re-flash, as u-boot will find the new kernel by default. The document below is useful in understanding the storage topology. http://opensource.rock-chips.com/wiki_Boot_option Secondly, I should mention that there is a more discrete relationship between u-boot and the root filesystem, as it will read files in your /boot directory which can influence its behavior (boot.scr and armbianEnv.txt) or for some OS (extlinux.conf, etc), but you should not need to change settings unless you want to customize your boot process (change the boot logo, etc). Lastly, some devices like the raspberry pi look for a dedicated FAT partition for the aforementioned boot files, but it looks like the Rockpi 4C looks for its root partition at 0x8000 as referenced in the document above. You can see the partition table to confirm by doing: fdisk /dev/mmcblk2 then pressing "p".
  5. Negative. It behaves in the same way as the issue I reported to the u-boot mailing list. You can see my post here: https://lists.denx.de/pipermail/u-boot/2021-January/437950.html And my boot log here (via UART): https://gist.github.com/tmountain/f3fd939dece80aaeb069c28db7d54e3d The only way I've been able to get the NanoPC-T4 to work is via building a standalone trust.bin and using the Armbian patches.
  6. Just to clarify, are you saying that using trust_merger is a requirement?
  7. Hi, I have been studying Armbian's build script, and I have managed to extrapolate a standalone u-boot build process for my NanoPC-T4 by cherry-picking the relevant commands / patches from the builder repo: https://github.com/tmountain/u-boot-nanopct4 This works well, and it opens the door for additional flexibility for those who need it regarding making the most of their hardware. That said, it raises a few questions. 1) My NanoPC-T4 will not boot without the Armbian patches. The vanilla u-boot does not work out of the box. I reported this issue here, but I'm wondering if the Armbian folks ever try to get patches back into upstream? 2) After many attempts, I cannot get a working u-boot (even with the patches) if I try to go the route of linking bl31.elf using the $BL31 environment variable. The only way I can get the loader to work is by building a separate trust.bin using the trust_merger binary. In looking at the Armbian build script, I see that a custom ini file is included with this section related to the BL31: [BL31_OPTION] SEC=1 PATH=bl31.elf ADDR=0x10000 I'm wondering if that ADDR line is the reason that building a trust.bin works, but trying to link against bl31.elf does not. Is there a way to build u-boot without using trust.bin to achieve an identical result? My exact build steps are as follows: $ docker run -ti ubuntu:focal # apt-get update # apt-get -y install build-essential flex bison gcc-aarch64-linux-gnu git \ device-tree-compiler python3 gcc-arm-none-eabi bc # cd /root # git clone https://github.com/tmountain/u-boot-nanopct4 # cd u-boot-nanopct4 # make CROSS_COMPILE=aarch64-linux-gnu- nanopc-t4-rk3399_defconfig # make u-boot-dtb.bin CROSS_COMPILE=aarch64-linux-gnu- # tools/mkimage -n rk3399 -T rksd -d vendor/rkbin/blobs/rk3399_ddr_800MHz_v1.24.bin idbloader.bin # cat vendor/rkbin/blobs/rk3399_miniloader_v1.19.bin >> idbloader.bin # export PATH=$PATH:`pwd`/vendor/rkbin/bin # trust_merger --replace bl31.elf vendor/rkbin/blobs/rk3399_bl31_v1.30.elf trust.ini # loaderimage --pack --uboot ./u-boot-dtb.bin uboot.img # dd if=idbloader.bin of=/dev/mmcblk2 seek=64 conv=notrunc # dd if=uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc # dd if=trust.bin of=/dev/mmcblk2 seek=24576 conv=notrunc # sync Lastly, I want to give a quick thanks to the Armbian project for doing such amazing work. Looking through all of the builder code has really given me an appreciation as to the level of detail and knowledge embedded in this work, and it's super impressive how well everything works out of the box. Thanks!
  8. Ah, thank you for this. Got it working!
  9. Hi, I'm new to the SoC / Armbian world, and I'm trying to connect to my NanoPC-T4 via UART (Armbian 20.11.7 Focal with Linux 5.9.14-rockchip64). I'm using an ADAFRUIT Industries 954 USB-to-TTL serial cable. The NanoPC-T4 pin spec indicates SPI1_TXD/UART4_TX(3V) as pin 19, GND as pin 20, and SPI1_RXD/UART4_RX(3V) as pin 21. I have hooked up my ADAFRUIT accordingly with the white receptacle (RX) to pin 19, the black receptacle (GND) to pin 20, and the green receptacle (TX) to pin 21. The full NanoPC-T4 pin spec is here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4. The kernel command line is as follows: [ 0.000000] Kernel command line: root=UUID=cb1cdae1-67a0-4938-850e-0ca79ecd821c rootwait rootfstype=ext4 bootsplash.bootfile=bootsplash.armbian console=ttyS0,1500000 console=ttyS2,1500000 console=tty1 consoleblank=0 loglevel=1 ubootpart=7fa9e296-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 Dmesg says the following regarding serial: [ 2.776290] printk: console [ttyS0] disabled [ 2.776366] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 39, base_baud = 1500000) is a 16550A [ 2.776554] printk: console [ttyS0] enabled [ 2.776724] serial serial0: tty port ttyS0 registered [ 2.777537] ff1a0000.serial: ttyS2 at MMIO 0xff1a0000 (irq = 40, base_baud = 1500000) is a 16550A [ 2.778797] Serial: AMBA driver I've connected the USB end of the cable to my raspberry pi to attempt to connect via screen: root@retropie:/home/pi# screen /dev/ttyUSB0 1500000 root@retropie:/home/pi# screen /dev/ttyUSB0 115200 Neither of those gives a login prompt. I have been able to make this work in the opposite direction (connecting from NanoPC-T4 to the serial of the Pi). Any suggestions would be appreciated. Thanks!