danman Posted June 26, 2019 Posted June 26, 2019 Wow! That is awesome! Do you have a detail of the main chip ? Or more pictures? What X-ray device was used? 0 Quote
jeanrhum Posted June 26, 2019 Posted June 26, 2019 15 hours ago, Staars said: I do not know, which terminal he used. I was under ubuntu using gtkterm. It's nice to see your experiments even if it has been better that realtek and manufacturers published documentations. 1 Quote
Staars Posted June 26, 2019 Author Posted June 26, 2019 5 hours ago, danman said: Wow! That is awesome! Do you have a detail of the main chip ? Or more pictures? What X-ray device was used? It is captured with an digital x-ray-system using digital image plates. Spatial resolution is limited, we can only zoom digitally. More pictures do not really make sense here. 0 Quote
Staars Posted June 27, 2019 Author Posted June 27, 2019 Just a small update on the kernel side. I uploaded all my latest local changes for the kernel tree 4.19.y (= 4.19.55), so you can build it (DEV) from my repo. But don't get too excited, it will not really work. This is only meant for further developing and hopefully some more skilled kernel-hackers can take look. There are some backports (for instance android/staging) and all API-changes were done according to the compiler output and the following internet search, so the process included traces of cargo-cult-programming. Expect stupid bugs here and there. Expected behaviour: A boot-log with surprisingly few errors but the inability to have a root device . The console output will stop and after while you should see a kernel error. Disabling usb or ahci or sd or mmc drivers (or combinations) will change the error slightly. It seems, as if there is always a DMA-problem, but that might be coincidence. I simply do not know, if there is just one wrong line of code somewhere or if the whole construction is lightyears away from working. Happy hacking! 1 Quote
danman Posted July 6, 2019 Posted July 6, 2019 I wrote a short guide how to recover from wiped boot sector https://blog.danman.eu/zidoo-x8-recovery/ 1 Quote
chewitt Posted August 1, 2019 Posted August 1, 2019 (edited) 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: Spoiler ...Banana Pi BPI-W2(SPI ROM:20180907) C1:80000000 C2 ? C3h SD card is detected !! C4 BPI: try bootcode_from_sdcard !! .BPI: support boot from sdcard Command 0x00000000 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x000000A0 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000000 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x00000000 Command 0x00000008 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000008 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x000000AA .response 0x9801058E = 0x00000013 Command 0x00000037 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000083 AppCommand 0x00000029 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000003F .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x000000FF .response 0x9801058C = 0x00000080 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000FF Command 0x00000037 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000083 AppCommand 0x00000029 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000003F .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x000000FF .response 0x9801058C = 0x00000080 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000FF Command 0x00000037 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000083 AppCommand 0x00000029 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000003F .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x000000FF .response 0x9801058C = 0x00000080 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000FF Command 0x00000037 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000083 AppCommand 0x00000029 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000003F .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x000000FF .response 0x9801058C = 0x00000080 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000FF Command 0x00000037 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000083 AppCommand 0x00000029 .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000003F .response 0x9801058A = 0x000000C1 .response 0x9801058B = 0x000000FF .response 0x9801058C = 0x00000080 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000FF card powerup status = 0x000000C1 card capacity status = 0x00000001 can switch to 1.8V = 0x00000001 Command 0x0000000B .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000000B .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000003 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x000000BD wait 0x98010585[4:0] 0 wait 0x98010585[4:0] done wait 0x98010585[4:0] 1 wait 0x98010585[4:0] done Command 0x00000002 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x0000000E .response 0x9801058A = 0x00000090 .response 0x9801058B = 0x000000D2 .response 0x9801058C = 0x00000001 .response 0x9801058D = 0x00000014 .response 0x9801058E = 0x00000067 .CID 0xA0000 = 0x%x 4453033F .CID 0xA0004 = 0x%x 36314C53 .CID 0xA0008 = 0x%x 0EBB8047 .CID 0xA000C = 0x%x 1401D290 Command 0x00000003 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x00000003 .response 0x9801058A = 0x000000E6 .response 0x9801058B = 0x00000024 .response 0x9801058C = 0x00000005 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x00000087 RCA = 0x0000E624 Command 0x00000007 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x00000007 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000007 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x00000075 SD card has been initialized. Command 0x00000037 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x00000037 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000009 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x00000033 AppCommand 0x00000006 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x00000006 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000009 .response 0x9801058D = 0x00000020 .response 0x9801058E = 0x000000B9 4-bit bus width SDR12/normal mode. Command 0x00000006 .interrupt 0x98010424 = 0x00000012 .Command pass .response 0x98010589 = 0x00000006 .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000009 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x000000DD DMA finished cr_auto_Read_Write_1, cmd_idx = 0x00000012 .Command pass .response 0x98010589 = 0x0000000C .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x0000000B .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x0000007F .interrupt 0x98010424 = 0x00000012 Command 0x0000000D .interrupt 0x98010424 = 0x00000002 .Command pass .response 0x98010589 = 0x0000000D .response 0x9801058A = 0x00000000 .response 0x9801058B = 0x00000000 .response 0x9801058C = 0x00000009 .response 0x9801058D = 0x00000000 .response 0x9801058E = 0x0000003F 64b U-Boot 2015.07 (Aug 01 2019 - 04:17:12 +0000) CPU : Cortex-A53 Quad Core - AARCH64 Board: Banana Pi BPI-W2 (RTD1296) DRAM: 2 GiB Watchdog: Disabled mapping memory 0x20000000-0x40000000 non-cached flushing dcache successfully. MMC: Initialize eMMC in traditional mmc flow. RTD1295 eMMC: 0 rsp[0]=0x15010038, . rsp[1]=0x474d4534, . rsp[2]=0x5201f67a, . rsp[3]=0xb8367491 The cid_val is 15. rsp[0]=0xd0270132, . rsp[1]=0x0f5903ff, . rsp[2]=0xf6dbffef, . rsp[3]=0x8e40400d mmc->version=0x40000000 version=0x00000004 [LY] cardtype=57, mmc->card_caps=0f [LY] freq = 00464388, clk diver = 00000080 [LY] speed up emmc at HS-200 [LY] HS-200 bus width=2 [LY] mmc->boot_caps = 20b TEMP TX_WINDOW=0x7ffffffe, TX_best=0xf RX_WINDOW=0xffffff80, RX_best=0x13 TX1_WINDOW=0x7fffff80, TX_best=0x12 [LY] hs200 : 0 [HC] ERASE Unit Size = 133693440 bytes [HC] WPG_SIZE = 4027056128 bytes Device: RTD1295 eMMC Manufacturer ID: 15 OEM: 100 Name: 8GME4 Tran Speed: 200000000 Rd Block Len: 512 MMC version 4.0 High Capacity: No Capacity: 7.3 GiB User Capacity: 7.3 GiB Boot Capacity: 4 MiB RPMB Capacity: 512 KiB Bus Width: 8-bit Speed: HS200 Factory: SD ------------can't find tmp/factory/000BootParam.h Set up default values [logo]src w/h=1920/1080 dst w/h=3840/2160 [ENV] read_env from factory failed Using default environment *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial HDMITx_HPD=False ------------can't find tmp/factory/video_rpc.bin tv_system=13 mode=1 Net: Realtek PCIe GBE Family Controller mcfg = 0024 dev->name=r8168#0 Checking default environment Hit Esc or Tab key to enter console mode or rescue linux: 3 ------------can't find tmp/factory/recovery ======== Checking into android recovery === 0 Start Boot Setup ... [Skip A] boot manual mode [Skip K] boot manual mode (execute "go all") Start Audio Firmware ... flushing dcache successfully. ** Bad device sd 0 ** Boot from eMMC mmc - MMC sub system Usage: mmc info - display info of the current MMC device mmc read addr blk# cnt mmc write addr blk# cnt mmc erase blk(Reminder: the device will ignore the start <addr> and round the start address to erase_group_size boundary and then erase the erase_group_size instead of #cnt)# cnt mmc rescan mmc part - lists available partition on current mmc device mmc dev [dev] [part] - show or set current mmc device [partition] mmc list - lists available devices ** Bad device sd 0 ** ** Bad device sd 0 ** ## Error: "uenvcmd" not defined ** Unrecognized filesystem type ** Start Boot Setup ... Wrong Image Format for do_booti command ERROR: can't get kernel image! Not raw Image, Starting Decompress Image.gz... Error: Bad gzipped data Decompress FAIL!! ERROR do_booti failed! Start Boot Setup ... Wrong Image Format for do_booti command ERROR: can't get kernel image! Not raw Image, Starting Decompress Image.gz... Error: Bad gzipped data Decompress FAIL!! ERROR do_booti failed! ==== boot_rescue_from_usb (secure mode:0)===== starting USB... rtk_usb_clock_init:49: Realtek-usb: Enable 1296 u3host clock and power USB0: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... Unknown request , typeReq = 0x200c 1 USB Device(s) found USB1: Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.10 scanning bus 1 for devices... Unknown request , typeReq = 0x200c 2 USB Device(s) found USB2: USB EHCI 1.00 scanning bus 2 for devices... 1 USB Device(s) found USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 3 for devices... Unknown request , typeReq = 0x200c Device not responding to set address. USB device not accepting new address (error=80000000) 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found USB device -1: device type unknown ** Bad device usb 0 ** Loading "rescue.emmc.dtb" from USB failed. Start Boot Setup ... Wrong Image Format for do_booti command ERROR: can't get kernel image! Not raw Image, Starting Decompress Image.gz... Error: Bad gzipped data Decompress FAIL!! ERROR do_booti failed! Start Boot Setup ... Wrong Image Format for do_booti command ERROR: can't get kernel image! Not raw Image, Starting Decompress Image.gz... Error: Bad gzipped data Decompress FAIL!! ERROR do_booti failed! ==== boot_rescue_from_usb (secure mode:0)===== USB device -1: device type unknown ** Bad device usb 0 ** Loading "rescue.emmc.dtb" from USB failed. Enter console mode, disable watchdog ... 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> BPI-W2> 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. Edited August 1, 2019 by chewitt 0 Quote
Staars Posted August 1, 2019 Author Posted August 1, 2019 Hi, I think that looks promising. As far as I know, the version of u-boot provided by Sinovoip expects a FAT partition with a certain naming scheme for kernel, DTB and audio firmware. Here is a pastebin from a user of their forums, where at least a kernel is loaded: https://pastebin.com/3MPFDLpS I can only provide some guesswork here, because I do not have an bananapi-w2. What is the partition/naming scheme of libreelec? Can you access an USB-stick like described some posts ago from the u-boot-console? 0 Quote
chewitt Posted August 1, 2019 Posted August 1, 2019 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. 0 Quote
chewitt Posted August 4, 2019 Posted August 4, 2019 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? 0 Quote
chwe Posted September 20, 2019 Posted September 20, 2019 you might ask @Lion Wang or @Nora Lee if they can give you access to their newest repository on github. the repo contains a bit of documentation from RTD how the bootloaders are supposed to work (e.g. recovery etc). It seems to contain also the sourcecode for the SPI part of the bootloader (I'm not up to date how much of this code is currently 'in the wild' so please forgive me if it only contains stuff you already know). 0 Quote
danman Posted September 21, 2019 Posted September 21, 2019 I like that they published complete guide how to use HW encoding with ffmpeg together with a patch and libraries 0 Quote
chewitt Posted September 21, 2019 Posted September 21, 2019 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? 0 Quote
chwe Posted September 21, 2019 Posted September 21, 2019 well this part will be for sure off topic but: https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt Quote For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. thankfully I don't have to give legal advises but I think you can have a 'confidential' document how to use your GPL derived code (and documentation is somehow a 'how to'). Is it a practice I support, for sure not but it is what it is. Luckily some companies decided to push further into making such stuff public (e.g. rockchip having a wiki, and opened a bunch of their kernelcode so that we can really work with, others like mediatek started to actively push their drivers to mainline as well - I hope others follow this way, it makes their SoCs just more useful in the long term). But back to topic, I might dive into the w2 adventure in the future I just need to sort out a few things cause I'm definitively not up to date here (actually this was some sort of a follow up after my work on the mt7623n which worked quite well in the end - well nobody here was really interested in the work in the end, but I got it more or less properly working with a mainline kernel in the end). As far as I understand the boot-process (and please correct if I'm wrong). There's a 32 bit bootloader (u-boot) supposed to chain-load the 64 bit u-boot somewhere in between the tools from them also provided the pieces of ATF needed (it's not really an isolated atf source right? this must come somewhere out during u-boot building I guess but I didn't dive into those sources right now to figure out what happens here and I'm rather unfamiliar with ATF, ). Finally, the 64 bit u-boot fires up the kernel with current limitations that this has to sit either in a squashfs or fat? (here things get messy in my head ). And there's some sort of rescue tools if you mess up with the SPI NOR to recover if you mess up there (before I really want to dive into this, I'm a uboot plumber by try and error not by complete understanding and for sure I'll mess it up more than once... ). For me as a armbian oriented plumber, it's obvious that the final u-boot needs to be able to load a kernel and a rootfs from an ext4 (I assume a 2015 u-boot should be capable to learn this, it's just a bit of tweaking needed (the mediatek u-boot for mt7623 was a 2014 version and finally also able to do this, wasn't that much work, once you figured out how outdated u-boots work). I won't repeat a fat adventure as I did with my experiments with the RPi 4 on 64 bit images built with armbians buildscript (yes, this stuff was never published and Images were never distributed, so no GPL issues here.. - and just in case someone asks, it's not gonna happen that I'll push this on github, too much mess in the buildscript to get out a barely working image - probably don't even have the branch anymore). But at least I need some hints how to recover a broken SPI once I'm there before trying heavy modifications on this side. So if one of you can summarize this a little bit, I would like to read it. 0 Quote
chewitt Posted September 22, 2019 Posted September 22, 2019 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. 0 Quote
Tido Posted September 22, 2019 Posted September 22, 2019 6 hours ago, chewitt said: I will submit the nag via some realtek people I tracked down via LinkedIn. It was either in this forum or over at SinoVoip where a guy from RT helped in his spare time, but I cannot remember his nickname. 0 Quote
chwe Posted September 22, 2019 Posted September 22, 2019 17 hours ago, chewitt said: 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. yeah this looks really familiar to u-boot 2014 from MediaTek.. including the common.h (I had a lot of fun and a lot more of frustration back then, cause this one at least understands FDT by default.. ) if you just want to mess around with u-boot (e.g. trying safe bootparameters without recompile u-boot the whole time or hack in the u-boot shell), scriptload (actually the way armbian boots as well) is a great tool. https://github.com/chwe17/u-boot-mt/blob/f5916a4c6d0ad8acf0e9b8fe3f649425272f5e6a/include/configs/mt7623-bpi-r2.h#L393-L397 especially cause everything inside this u-boot is defined as fatload even if ext4 should be available from the config you mentioned (there would be a proper way to probe if it's fat or ext but hell, it never worked well enough when I tried it ). with scriptload you can try to write a proper procedure to boot up your board. 10 hours ago, Tido said: It was either in this forum or over at SinoVoip where a guy from RT helped in his spare time, I think that was the guy from MediaTek sending their adjusted linux drivers upstream to u-boot to get it finally supported by u-boot. 17 hours ago, chewitt said: port them to a more modern u-boot (ideally mainline) well this would mean to look into the driver sources as well.. Something I don't do for more than one reason.. First you'd to check the code license from the code drops you got a bunch of it has no authorship and license headers mentioned. Second, I honestly don't believe it's our job to do the dirty work of getting their stuff upstream. I'm currently fine with a just spend enough time to get it working when it comes to u-boot. Ideally we would have only SoC's with upstream u-boot support but it tends to take to much time for the (more) important stuff (e.g. a proper mainline kernel support.. ). Any comments on my current understanding how this thing boots? 0 Quote
danman Posted September 29, 2019 Posted September 29, 2019 Good news! I have found the BOOTSEL pin on my board I connected my logic analyzer to DI pin on SPI header, shorted one suspected pad and saw signals on my analyzer. Then I made a jumper out of 1.27mm pitch pin header and did some fine soldering. Now the question is, what to load to my SPI flash? Does anybody have a full dump from bpi w2 here? 1 Quote
Staars Posted October 15, 2019 Author Posted October 15, 2019 Wow, that would be pretty cool! In comparison to your board, I think the solder points with the blue arrows should be connected, right? I strongly believe, that everything is in the u-boot-folder of the repo from the banana-folks. I do not remember the exact name right now, but it was something like drvboot.exe, which we can build (!=which will work ). @danman What do you see on the console, when you use your BOOTSEL? I just want to know, if I am able to replicate this. 0 Quote
danman Posted October 16, 2019 Posted October 16, 2019 @Staars it doesn't boot because I don't have the correct image but on the MISO/MOSI/CLK pins of SPI I can see some signals which were not there before attaching jumper. It doesn't show anything on serial because it doesn't boot It is not even possible to get to d/g/n mode when the jumper is attached (maybe someone with W2 can confirm this behavior?) I managed to compile some spi images after fixing some bugs in the "SDK" https://github.com/BPI-SINOVOIP/BPI-W2-openwrt-lede/issues/2 but I didn't have time to test them. You cannot use just any image because they differ per device in "hwsetting" file, ram config, etc... Still waiting for @chewitt to provide SPI dump from his W2 to compare the layout. 0 Quote
Staars Posted October 16, 2019 Author Posted October 16, 2019 Ahh, I understand. I had hoped, that at least the initial serial output would show some signs of success. BTW, I just test this an my bricked Lake-box and there is nothing new to be seen. (I used the marked solder points from above) Another little update: On LKML there is some new activity regarding new additions to the soc-family directly from realtek, which sounds good to me, even if this is in the very early stages. 0 Quote
y52 Posted December 20, 2019 Posted December 20, 2019 On 10/16/2019 at 10:13 AM, danman said: provide SPI dump from his W2 I've just get W2 delivered. How could the SPI dump be made? Being a couple of years Armbian's follower, I share the interest implementing the mainstream kernel build for W2 and ultimately put an Armbian on it. 0 Quote
danman Posted December 21, 2019 Posted December 21, 2019 19 hours ago, y52 said: I've just get W2 delivered. How could the SPI dump be made? Being a couple of years Armbian's follower, I share the interest implementing the mainstream kernel build for W2 and ultimately put an Armbian on it. Hi y52, can you show contents of your /dev/ folder? 0 Quote
y52 Posted December 21, 2019 Posted December 21, 2019 It's quite a long list : root@bpi-iot-ros-ai:~# ls -al /dev |less total 4 drwxr-xr-x 15 root root 14560 Dec 21 12:39 . drwxr-xr-x 23 root root 4096 Dec 21 13:52 .. crw------- 1 root root 10, 55 Dec 21 12:39 ashmem crw------- 1 root root 10, 235 Dec 21 12:39 autofs crw------- 1 root root 10, 54 Dec 21 12:39 binder drwxr-xr-x 2 root root 700 Dec 21 12:38 block crw-rw---- 1 root disk 10, 234 Dec 21 12:39 btrfs-control drwxr-xr-x 3 root root 60 Jan 1 1970 bus crw------- 1 root root 246, 0 Dec 21 12:39 cec-0 drwxr-xr-x 2 root root 13920 Dec 21 12:39 char crw------- 1 root root 10, 59 Dec 21 12:39 chip crw------- 1 root root 5, 1 Dec 21 12:39 console lrwxrwxrwx 1 root root 11 Dec 21 12:38 core -> /proc/kcore crw------- 1 root root 10, 52 Dec 21 12:39 cpu_dma_latency crw------- 1 root root 10, 203 Dec 21 12:39 cuse drwxr-xr-x 7 root root 140 Dec 21 12:38 disk crw-rw-rw- 1 root root 10, 56 Dec 21 12:39 dptx crw-rw---- 1 root video 29, 0 Dec 21 12:39 fb0 lrwxrwxrwx 1 root root 13 Dec 21 12:38 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Dec 21 12:39 full crw-rw-rw- 1 root root 10, 229 Dec 21 12:49 fuse crw------- 1 root root 254, 0 Dec 21 12:39 gpiochip0 crw------- 1 root root 254, 1 Dec 21 12:39 gpiochip1 drwxr-xr-x 2 root root 60 Dec 21 12:39 graphics crw-rw-rw- 1 root root 10, 57 Dec 21 12:39 hdmitx crw------- 1 root root 245, 0 Dec 21 12:39 hidraw0 crw------- 1 root root 245, 1 Dec 21 12:39 hidraw1 drwxr-xr-x 2 root root 0 Dec 21 12:38 hugepages crw------- 1 root root 10, 183 Dec 21 12:39 hwrng crw------- 1 root root 89, 0 Dec 21 12:39 i2c-0 crw------- 1 root root 89, 1 Dec 21 12:39 i2c-1 crw------- 1 root root 89, 2 Dec 21 12:39 i2c-2 crw------- 1 root root 89, 3 Dec 21 12:39 i2c-3 crw------- 1 root root 89, 4 Dec 21 12:39 i2c-4 crw------- 1 root root 89, 5 Dec 21 12:39 i2c-5 lrwxrwxrwx 1 root root 12 Dec 21 12:38 initctl -> /run/initctl drwxr-xr-x 4 root root 180 Dec 21 12:39 input crw-rw---- 1 root video 10, 61 Dec 21 12:39 ion crw------- 1 root root 10, 107 Dec 21 12:39 jpu crw-r--r-- 1 root root 1, 11 Dec 21 12:39 kmsg lrwxrwxrwx 1 root root 28 Dec 21 12:38 log -> /run/systemd/journal/dev-log crw-rw---- 1 root disk 10, 237 Dec 21 12:49 loop-control brw-rw---- 1 root disk 7, 0 Dec 21 12:39 loop0 brw-rw---- 1 root disk 7, 1 Dec 21 12:39 loop1 brw-rw---- 1 root disk 7, 2 Dec 21 12:39 loop2 brw-rw---- 1 root disk 7, 3 Dec 21 12:39 loop3 brw-rw---- 1 root disk 7, 4 Dec 21 12:39 loop4 brw-rw---- 1 root disk 7, 5 Dec 21 12:39 loop5 brw-rw---- 1 root disk 7, 6 Dec 21 12:39 loop6 brw-rw---- 1 root disk 7, 7 Dec 21 12:39 loop7 crw------- 1 root root 10, 47 Dec 21 12:39 mali0 drwxr-xr-x 2 root root 60 Jan 1 1970 mapper crw------- 1 root root 249, 0 Dec 21 12:39 mcp_core crw------- 1 root root 10, 49 Dec 21 12:39 memory_bandwidth brw-rw---- 1 root disk 179, 32 Dec 21 12:39 mmcblk0 brw-rw---- 1 root disk 179, 33 Dec 21 12:39 mmcblk0p1 brw-rw---- 1 root disk 179, 34 Dec 21 12:39 mmcblk0p2 brw-rw---- 1 root disk 179, 0 Dec 21 12:39 mmcblk1 brw-rw---- 1 root disk 179, 8 Dec 21 12:39 mmcblk1boot0 brw-rw---- 1 root disk 179, 16 Dec 21 12:39 mmcblk1boot1 brw-rw---- 1 root disk 179, 1 Dec 21 12:39 mmcblk1p1 brw-rw---- 1 root disk 179, 24 Dec 21 12:39 mmcblk1rpmb drwxrwxrwt 2 root root 40 Jan 1 1970 mqueue crw------- 1 root root 90, 0 Dec 21 12:39 mtd0 crw------- 1 root root 90, 1 Dec 21 12:39 mtd0ro drwxr-xr-x 2 root root 60 Jan 1 1970 net crw------- 1 root root 10, 51 Dec 21 12:39 network_latency crw------- 1 root root 10, 50 Dec 21 12:39 network_throughput crw-rw-rw- 1 root root 1, 3 Dec 21 12:39 null crw-r----- 1 root kmem 1, 4 Dec 21 12:39 port crw------- 1 root root 108, 0 Dec 21 12:39 ppp crw------- 1 root root 10, 1 Dec 21 12:39 psaux crw-rw-rw- 1 root tty 5, 2 Dec 21 18:15 ptmx drwxr-xr-x 2 root root 0 Dec 21 12:38 pts crw------- 1 root root 2, 176 Dec 21 12:39 ptya0 crw------- 1 root root 2, 177 Dec 21 12:39 ptya1 .... crw------- 1 root root 2, 174 Dec 21 12:39 ptyze crw------- 1 root root 2, 175 Dec 21 12:39 ptyzf brw-rw---- 1 root disk 1, 0 Dec 21 12:39 ram0 brw-rw---- 1 root disk 1, 1 Dec 21 12:39 ram1 brw-rw---- 1 root disk 1, 10 Dec 21 12:39 ram10 brw-rw---- 1 root disk 1, 11 Dec 21 12:39 ram11 brw-rw---- 1 root disk 1, 12 Dec 21 12:39 ram12 brw-rw---- 1 root disk 1, 13 Dec 21 12:39 ram13 brw-rw---- 1 root disk 1, 14 Dec 21 12:39 ram14 brw-rw---- 1 root disk 1, 15 Dec 21 12:39 ram15 brw-rw---- 1 root disk 1, 2 Dec 21 12:39 ram2 brw-rw---- 1 root disk 1, 3 Dec 21 12:39 ram3 brw-rw---- 1 root disk 1, 4 Dec 21 12:39 ram4 brw-rw---- 1 root disk 1, 5 Dec 21 12:39 ram5 brw-rw---- 1 root disk 1, 6 Dec 21 12:39 ram6 brw-rw---- 1 root disk 1, 7 Dec 21 12:39 ram7 brw-rw---- 1 root disk 1, 8 Dec 21 12:39 ram8 brw-rw---- 1 root disk 1, 9 Dec 21 12:39 ram9 crw-rw-rw- 1 root root 1, 8 Dec 21 12:39 random crw-rw-r-- 1 root netdev 10, 62 Dec 21 12:39 rfkill crw-rw-rw- 1 root root 240, 0 Dec 21 12:39 rpc0 crw-rw-rw- 1 root root 240, 1 Dec 21 12:39 rpc1 crw-rw-rw- 1 root root 240, 100 Dec 21 12:39 rpc100 crw-rw-rw- 1 root root 240, 2 Dec 21 12:39 rpc2 crw-rw-rw- 1 root root 240, 3 Dec 21 12:39 rpc3 crw-rw-rw- 1 root root 240, 4 Dec 21 12:39 rpc4 crw-rw-rw- 1 root root 240, 5 Dec 21 12:39 rpc5 crw-rw-rw- 1 root root 240, 6 Dec 21 12:39 rpc6 crw-rw-rw- 1 root root 240, 7 Dec 21 12:39 rpc7 lrwxrwxrwx 1 root root 4 Dec 21 12:39 rtc -> rtc0 crw------- 1 root root 253, 0 Dec 21 12:39 rtc0 crw------- 1 root root 10, 60 Dec 21 12:39 rtk_lockapi drwxrwxrwt 2 root root 40 Dec 21 12:38 shm drwxr-xr-x 3 root root 200 Dec 21 12:39 snd lrwxrwxrwx 1 root root 15 Dec 21 12:38 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Dec 21 12:38 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Dec 21 12:38 stdout -> /proc/self/fd/1 crw------- 1 root root 10, 58 Dec 21 12:39 sw_sync crw-rw-rw- 1 root tty 5, 0 Dec 21 12:39 tty crw--w---- 1 root tty 4, 0 Dec 21 12:39 tty0 crw--w---- 1 root tty 4, 1 Dec 21 12:50 tty1 ... crw------- 1 root root 3, 175 Dec 21 12:39 ttyzf crw------- 1 root root 10, 48 Dec 21 12:39 uctrl crw------- 1 root root 10, 239 Dec 21 12:39 uhid crw------- 1 root root 10, 223 Dec 21 12:39 uinput crw------- 1 root root 248, 250 Dec 21 12:39 uio250 crw------- 1 root root 248, 251 Dec 21 12:39 uio251 crw------- 1 root root 248, 252 Dec 21 12:39 uio252 crw------- 1 root root 248, 253 Dec 21 12:39 uio253 crw-rw-rw- 1 root root 1, 9 Dec 21 12:39 urandom crw------- 1 root root 247, 0 Dec 21 12:39 usbmon0 crw------- 1 root root 247, 1 Dec 21 12:39 usbmon1 crw------- 1 root root 247, 2 Dec 21 12:39 usbmon2 crw------- 1 root root 247, 3 Dec 21 12:39 usbmon3 crw------- 1 root root 247, 4 Dec 21 12:39 usbmon4 crw------- 1 root root 247, 5 Dec 21 12:39 usbmon5 crw------- 1 root root 247, 6 Dec 21 12:39 usbmon6 crw-rw---- 1 root tty 7, 0 Dec 21 12:39 vcs crw-rw---- 1 root tty 7, 1 Dec 21 12:39 vcs1 ... crw-rw---- 1 root tty 7, 134 Dec 21 12:39 vcsa6 crw------- 1 root root 234, 50 Dec 21 12:39 venus_ir crw------- 1 root root 10, 63 Dec 21 12:39 vga_arbiter crw------- 1 root root 10, 110 Dec 21 12:39 vpu crw------- 1 root root 10, 130 Dec 21 12:39 watchdog crw------- 1 root root 251, 0 Dec 21 12:39 watchdog0 crw------- 1 root root 10, 53 Dec 21 12:39 xt_qtaguid crw-rw-rw- 1 root root 1, 5 Dec 21 12:39 zero brw-rw---- 1 root disk 253, 0 Dec 21 12:39 zram0 0 Quote
danman Posted December 21, 2019 Posted December 21, 2019 Please try to dump mtd0 E.g.: dd if=/dev/mtd0 of=dump.dd 0 Quote
y52 Posted December 21, 2019 Posted December 21, 2019 root@bpi-iot-ros-ai:~# ls -al /dev/mtd0 crw------- 1 root root 90, 0 Dec 21 21:09 /dev/mtd0 root@bpi-iot-ros-ai:~# dd if=/dev/mtd0 of=dump.dd doesn't complete. root@bpi-iot-ros-ai:~# journalctl -f shows a lot of Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 17 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 12 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 16 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 18 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages root@bpi-iot-ros-ai:~# ls -al /root/dump.dd -rw-r--r-- 1 root root 0 Dec 21 21:42 /root/dump.dd 0 Quote
danman Posted December 24, 2019 Posted December 24, 2019 Can you try to dump it from u-boot? Like they do here: https://reverseengineering.stackexchange.com/a/6645 0 Quote
y52 Posted December 25, 2019 Posted December 25, 2019 I believe, this method will require an access through a serial console. I am waiting for the UART cable to get delivered. I shall try making more series of tests. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.