Hi, I realized booting with the rescue_fw method. This was actually pretty easy. It means everybody can boot custom debian without opening the NAS. It works like this: Instead of the normal USB stick with a single ext3 partition called "rootfs", create a usb stick with the following partition layout: 1. 100MB fat32 (name does not matter, i named it "rescue_fw" 2. Resby lordzahl - Debian
> It's good to know these keys values. However, when > you said "The Key codes are not quite correct for > our box/our config", then it means the GPIOs > number in the DTS are worng ones! Note the key > numeric values are not correlated to the GPIO > numbers. Ok, sure. I am confused by our dts: I can see the "gpio-keys" section, which is not workby lordzahl - Debian
> GPIO keys testing. > cat /etc/esekeyd.conf > > POWER:/usr/bin/logger -s -i "POWER button pushed" > RESTART:/usr/bin/logger -s -i "RESTART button > pushed" > COPY:/usr/bin/logger -s -i "COPY Button pushed" > Okay, The Key codes are not quite correct for our box/our config. keytest shows the right keys: KEY_116:/usr/bin/loggerby lordzahl - Debian
Hi bodhi, > Do you have the board inside the case? I think it > is more helpful if we confirm that the LEDs on the > outside are what we think they are. For example, > > Quoten2350:white:sys is indeed the system > LED and it turns on when we do "echo > default-on" Okay, you are right. I have it not assembled at the moment, but can still make out, which oby lordzahl - Debian
Hi bodhi, Okay, i have tested the LEDs. First by activating them manually. I have used a short script for that (attached to this post): root@debian:~# ./led.sh Checking n2350:white:sys Checking n2350:red:sys Checking n2350:white:sata1 Checking n2350:red:sata1 Checking n2350:white:sata2 Checking n2350:red:sata2 This blinks the LEDs LED3, LED5, LED6 in this order as labelled on the PCby lordzahl - Debian
Hi bodhi, > I would like you to keep this running for a few > hours. And then we'll get to the GPIO, ...the rest > of the peripherals checking. I had the box running over night just fine: mjung@debian:~$ uptime 22:19:29 up 8:54, 1 user, load average: 1.93, 1.57, 1.39 It is copying data over network onto a new zstd compressed btrfs volume. What GPIOs are available? Wby lordzahl - Debian
moving on..: I have added a disk to the system and updated the kernel to your 4.15 version. Adding the disk mixes up the /dev/sd*, so i changed the definition back to be label based. The boot commands are now: setenv mtdparts 'mtdparts=armada-nand:-(ubifs);spi1.0:0x00100000(uboot),0x00010000@0x00100000(uboot_env)' setenv load_dtb_addr 0x1000000 setenv load_initrd_addr 0x3000000by lordzahl - Debian
Hi bodhi, I would like to use this box in production soon. Therefore i gave it another try and i think i got the initrd working. After reading in the sunxi-wiki, i added setenv initrd_high 0xffffffff to the uboot commands. So overall they now look like this: setenv mtdparts 'mtdparts=armada-nand:-(ubifs);spi1.0:0x00100000(uboot),0x00010000@0x00100000(uboot_env)' setenv loaby lordzahl - Debian
Hi, Ok i tried the different initrd adresses, but didn't have complete success. First it kernel panic'd early. Then Starting from 0x5900000 i get: BootROM - 1.73 Booting from SPI flash General initialization - Version: 1.0.0 AVS selection from EFUSE disabled (Skip reading EFUSE values) Overriding default AVS value to: 0x23 Detected Device ID 6820 High speed PHY - Versionby lordzahl - Debian
Hi bodhi, > Interrupt the console after this uboot started, to > the countdown > > U-Boot 2013.01 (Apr 11 2018 - 19:28:35) Marvell > version: 2015_T1.0p18 > > > And then > > printenv > > And then try to boot into Debian the same way you > did with stock uboot. okay, here is the log: ustomer0-Thecus-N2350 SoC: MV88F6820 Rev A0by lordzahl - Debian
Success! So using the kwboot tool with the "-f" flag did not work, but the following did: $ ./download-serial.sh /dev/ttyUSB0 ../nx350_uboot/u-boot-2013.01-2015_T1.0p18/u-boot-a38x-2015T1_p18_Thecus-spi-uart.bin send-stop-pattern.c: In Funktion »main«: send-stop-pattern.c:24:2: Warnung: Implizite Deklaration der Funktion »sleep«; meinten Sie »beep«? [-Wimplicit-function-declaby lordzahl - Debian
Hi, So i build the gpl'd uboot images and tried them, since i had no luck with the mtd1 dump version. Three images are build: normal, uart and debug. The normal image is not identical with the mtd1 dump image, but it still does not boot (protocol error). The uart image does the following: $ ../kwboot-x86_64 -t -B 115200 /dev/ttyUSB0 -b ../nx350_uboot/u-boot-2013.01-2015_T1.0p18/by lordzahl - Debian
Hi, > Sorry, that's a typo! mtd1 is correct. Been a long > day :) No problem, you are answering so often and fast. Thanks for all the work! > We need to figure out why it takes so long to load. The mtd0 image did take so long to load - probably because it is 512MB.. The (correct) mtd1 image did not load at all (xmodem protocol error). > BTW, my diskless Thecus N2350by lordzahl - Debian
Hi, > 1. dump mtd0 and try kwboot with it. Here we go: root@debian:~# cat /proc/mtd dev: size erasesize name mtd0: 20000000 00020000 "ubifs" mtd1: 00100000 00001000 "uboot" mtd2: 00010000 00001000 "uboot_env" root@debian:~# dd if=/dev/mtd0 of=mtd0.thecus-n2350 bs=1024k conv=sync 512+0 records in 512+0 records out 536870912 bytes (537 MB, 512by lordzahl - Debian
Hi bodhi! I am back, so lets move forward: > Boot to Debian, and > > > echo "/dev/mtd2 0x00000 0x10000 0x10000" > > /etc/fw_env.config > fw_printenv > Here is the log: Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. debian Thecus N2350 Linux version 4.14.1-mvebu-tld-1 (root@tldDebianVM) (gcc verby lordzahl - Debian
Hi bodhi, Thecus just send me the uboot sources! uboot gpl I am still on vacation, but i wanted to share the link with you. Cheers, Manuelby lordzahl - Debian
This is probably my last message for the next 10 days. Hopefully Thecus the uboot sources until then. Booting stock: N2350:~# dmesg | grep -i20 spi1 grep: invalid option -- '2' BusyBox v1.16.1.2 (2018-01-19 12:29:19 CST) multi-call binary. Usage: grep [-HhnlLoqvsriFE] [-m N] [-A/B/C N] PATTERN/-e PATTERN.../-f FILE ... Search for PATTERN in FILEs (or stdin) Options:by lordzahl - Debian
Ok, i tried to dump the uboot image from spi.. using uboot. Boot and press key to get to uboot console: Marvell>> flash_part_print SF: Detected MX25L3205D with page size 64 KiB, total 4 MiB Linux/vxWorks partitions on spi flash -------------------------------------- Spi flash Address (rx) : 0xf4000000 Spi flash size : 8MB u-boot : offset=0x0000000by lordzahl - Debian
In the beginning of this thread, we dumped a mtd "mtd0_N2350" with nanddump and tried to kwboot it. At that time i had no clue how to get the timing right etc. I tried it again, and it starts upload, but it doesn't make any progress (more and more "...." dots, but at every line it still says 0%). However my real concern is: Since we have realized by now, that uboot isby lordzahl - Debian
Ok, i use now your original nand partition and spi partitions and changed the bootcmd to use spi1.0: setenv mtdparts 'mtdparts=armada-nand:-(ubifs);spi1.0:0x00100000(uboot),0x00010000@0x00100000(uboot_env)' setenv load_dtb_addr 0x1000000 setenv load_initrd_addr 0x2900000 setenv load_image_addr 0x02000000 setenv dtbfilename armada-385-thecus-n2350.dtb setenv usb_set_bootargsby lordzahl - Debian
....and more success! After a few iteration the kernel can talk with the spi flash. The stock boot log shows: [ 3.647453] m25p80 spi1.0: mx25l3205d (4096 Kbytes) [ 3.652367] 2 ofpart partitions found on MTD device spi1.0 [ 3.657900] Creating 2 MTD partitions on "spi1.0": [ 3.662714] 0x000000000000-0x000000400000 : "U-Boot-img" [ 3.669677] 0x000000100000-by lordzahl - Debian
Hi, I have made progress with the nand flash! I think the important part are the nand-ecc-* parameters. I got inspired by this dts. The mtd partition definitions are copied from the gpl dts. You probably know what we should put there? flash@d0000 { status = "okay"; num-cs = <1>; marvell,nand-keep-config; marvell,nand-enable-arbiteby lordzahl - Debian
bodhi Wrote: ------------------------------------------------------- > Here is version 9 DTS for testing. No luck: BootROM - 1.73 Booting from SPI flash General initialization - Version: 1.0.0 AVS selection from EFUSE disabled (Skip reading EFUSE values) Overriding default AVS value to: 0x23 Detected Device ID 6820 High speed PHY - Version: 2.0 Init Customer board board Seby lordzahl - Debian
Hi bodhi, Ok, thanks for elaborating on that. I agree, we should not care about NAND (at the moment) if we don't need it. (I still might take a quick look at the gpl kernel source to see, if there is any noticeable fixes from the thecus guys to the NAND Flash driver.) Let us concentrate on the SPI Flash. Cheers, Manuelby lordzahl - Debian
Hi bodhi, I did a quick google search on this issue and its seems that others have experienced it, while migrating from a 3.x to 4.x kernel. The conclusion of this thread is to use a kernel with CONFIG_PREEMPT. But if i read your kernel config correctly, the kernel is already build with that flag. So maybe something other is wrong. Just to let you know: I am able to test stuff for the neby lordzahl - Debian
Hi bodhi, bodhi Wrote: ------------------------------------------------------- > As I mentioned, wrong NAND defintion was not > supposed to stop the kernel from booting. So I > think stock GPL has the wrong cs. Yeah, the cs seems to be wrong. But now it doesn't boot anymore. > Here is the v8 patch on top of your current > version. Please apply this patch and recompby lordzahl - Debian
Hi, bodhi Wrote: ------------------------------------------------------- > Let's get our status in one post. Sure. > Please boot with version 7 and your ethernet > cleanup version. Interrupt serial console and > enter the envs, boot into Debian. > And post the entire serial console log here. Using the dts/dtb from this post, the resulting log is (with a networkby lordzahl - Debian
> Did you mean V7 tarball I've uploaded above? if > not, please try V7 and post serial console log > here. > https://forum.doozan.com/read.php?2,50829,55534#msg-55534 No, that was v7 already. I just was the only time you did not post bootcmds (which are of course still the same). I just referenced them for other people/future. > So far I'm happy with the kernel rby lordzahl - Debian
Regarding the network problem. The boot log shows [ 0.978941] mvneta f1070000.ethernet eth0: Using random mac address 2e:cc:86:ec:08:72 [ 0.989512] mvneta f1030000.ethernet eth1: Using random mac address a6:00:c8:41:5f:0b but the box has only one ethernet port. Indeed your dts shows: ethernet@30000 { status = "okay"; phy = <&phy1>; phy-mode =by lordzahl - Debian
Using root=/dev/sda1 i can boot the system and login (over serial, not tried anything else yet)! Can post the log at the moment, because it has some control characters in it. Have to find out how to stripe them.. edit: Here is the log. A network cable was/is connected, but there seems to be something wrong with the PHY setup (in the dts). BootROM - 1.73 Booting from SPI flashby lordzahl - Debian