chewitt

Members
  • Content Count

    6
  • Joined

  • Last visited

About chewitt

  • Rank
    Newbie

Recent Profile Visitors

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

  1. I did some diff'ing of u-boot code against the existing public sources back in August and while the total changeset is rather huge, most of the complexity added is associated with the recovery system that Realtek implemented. I think it should be possible (and IMHO beneficial) to isolate the smaller set of changes that provide actual board support and port them to a more modern u-boot (ideally mainline) and then you don't smack your head against the recovery stuff all the time. https://github.com/chewitt/u-boot/commits/bpiw2 has my low-quality u-boot n00b hacking to try and clean-up the boot process to reduce noise and increase comprehension of what's going on. The include/configs/rtd1295_common.h file is where the current u-boot env is set. The single biggest thing that would be useful is git history.. but that's unlikely, although I will submit the nag via some realtek people I tracked down via LinkedIn.
  2. I sort-of object to the word "published" when GPLv2 code is offered from a private repo with docs marked "Realtek Confidential" .. but I guess it's a form of progress?
  3. The repo contains an incomplete/unsuccessful attempt to port the driver to mainline kernels around 4.18/4.19 time. Even by the unbelievably low standards of 3.14 vendor bsp kernel drivers the code is fugly awful crap. In researching the origin of the sources I had one of the Rockchip driver team we collaborate with (based in China; native Mandarin speaker) phone around some of the chip distributors to ask Q's and it appears "South Silicon Village" (the SSV in ssv6051) went bust in 2016 so there's zero hope of getting newer sources (but the distibutors still have stock and are still offering a good deal to those who seek the cheapest chips). There's another Github repo (also doesn't compile work) that hints the driver is really a clone/rip-off of a Realtek design (although I forget which one) but some LE people experimented with some Realtek sources changing ID's and such but never got anything to work. TL/DR; If you have hardware with that chipset .. the cheapest $2 used Realtek USB wireless thing you can find on eBay is miles better NB: I've now added **NOT WORKING** to the Github repo description.
  4. Couple of issues solved. First the SD card drivers weren't being built due to CONFIG_SYS_CONFIG_NAME="rtd1295_qa_sd_bananapi" not being set in the u-boot config. Second one of the Sinovoip/Foxcon staff confirmed that u-boot has a 20MB size limit on the kernel. I was using an uncompressed uImage that also contains the LE initramfs that was ~22MB in size. Switching to a gzip KERNEL file dropped size to 10MB and working from the u-boot console I can fatload files etc. to reach this point: ## Booting kernel from Legacy Image at 03000000 ... Image Name: Image Type: AArch64 Linux Kernel Image (gzip compressed) Data Size: 11108954 Bytes = 10.6 MiB Load Address: 03b00000 Entry Point: 03b00000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02100000 Booting using the fdt blob at 0x2100000 Uncompressing Kernel Image ... OK reserving fdt memory region: addr=0 size=100000 reserving fdt memory region: addr=1f000 size=1000 reserving fdt memory region: addr=1ffe000 size=4000 reserving fdt memory region: addr=2200000 size=400000 reserving fdt memory region: addr=2600000 size=c00000 reserving fdt memory region: addr=3200000 size=b800000 reserving fdt memory region: addr=10000000 size=14000 reserving fdt memory region: addr=14200000 size=9200000 Using Device Tree in place at 0000000002100000, end 000000000210e694 Bring UP slave CPUs Starting Kernel ... but nothing on the console after that point, and I have set 'bootargs' using both the config in the original sinovoip env, and the settings that LE normally uses. The sequence of commands i'm running is effectively this: setenv bootargs earlycon=uart8250,mmio32,0x98007800 fbcon=map:0 boot=/dev/sda1 disk=/dev/sda2 ssh textmode console=ttyS0,115200n8 console=tty0 setenv fdt_loadaddr 0x02100000 setenv kernel_loadaddr 0x03000000 setenv audio_loadaddr 0x0f900000 setenv kernel KERNEL setenv dtb_name rtd-1296-bananapi-w2-2GB-HDMI.dtb setenv audio bluecore.audio fatload sd 0:1 ${fdt_loadaddr} ${dtb_name} fatload sd 0:1 ${kernel_loadaddr} ${kernel} fatload sd 0:1 ${audio_loadaddr} ${audio} bootm ${kernel_loadaddr} - ${fdt_loadaddr} I've also experimented with /dev/mmcblk0p1 and /dev/mmcblk0p2 .. and 1p1/1p2 and boot=UUID and boot=LABEL combinations - it's not clear what would be correct. Any suggestions?
  5. LE (on an SD card) uses two partitions. The first is fat (512MB) containing boot files; notably KERNEL (the kernel) and SYSTEM (rest of the OS in a SQUASHFS file). We normally use extlinux to boot board devices that need their own u-boot, but i'm not sure that will be an option here. The second partition is ext4 and provides persistent storage. The overall first partition structure of the Ubuntu image that I downloaded from Sinovoip looks similar to Amlogic (only less organised) where we are using bootm with a uEnv.ini file, and some boot scripts.
  6. Using @Staars u-boot and kernel repo's I managed to create a basic image using the LibreELEC build system (using Armbian's would require an old dog to learn new tricks). I know little about u-boot, but I appear to have created an SD card image that fails and ends up in the 2015 u-boot that was compiled from sources: BPI-W2> version U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000) aarch64-libreelec-linux-gnueabi-gcc-8.3.0 (GCC) 8.3.0 GNU ld (GNU Binutils) 2.32 BPI-W2> As you can see/guess, this is on W2, the switch is set to boot from SD card. Full boot log: Are any of you hanging around in IRC channels on freenode? .. I could use some help tweaking the boot files/contents to get the kernel working.