phelum

Members
  • Content Count

    32
  • Joined

  • Last visited

About phelum

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

512 profile views
  1. Hi, I suspect you'll need a special version of u-boot and I don't know if such a version exists. The NAND boot process requires boot0 in blocks 0 and 1, and boot1 in blocks 2 to 7, and the kernel and u-boot-bin in the first partition. The MBR and partitions are all in the "logical" section of NAND which is after the reserved (maybe 12) blocks in NAND. The blocks in this logical section aren't necessarily where they appear to be due to bad block relocation and wear levelling. The problem I see with booting from NAND is that unless you have a kernel that can access the NAND then you will have the situation where you can't update your kernel. So I stick to the old 3.4 kernel for my NAND boot systems but I'm stuck with running wheezy here and this is becoming a major disadvantage. The good thing about an SD-card is that if it packs up it's easy to replace. Maybe it is the better option. However, if there is a u-boot-bin version that will load the kernel from NAND then maybe it's worth a try. This would help if the onboard SD card reader packs up. Cheers, Steven
  2. Hi, I'm trying to create a DT overlay for my Cubietruck running 4.19.62 and I've placed it in /boot/overlay-user and changed the user_overlays entry in boot.scr to load it. It is being loaded but I'm getting FDT_ERR_NOTFOUND when trying to apply it. The overlay is meant to change the label and default-trigger entries for the four LEDs in the leds node. I'm using dtc 4.1.4 and it does compile this overlay. Can anybody tell me how I can change this overlay so it will work ? Or perhaps tell me if this is not possible. /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target = <&leds>; __overlay__ { blue { label = "blue"; linux,default-trigger = "heartbeat"; }; orange { label = "orange"; linux,default-trigger = "cpu0"; }; white { label = "white"; linux,default-trigger = "cpu1"; }; green { label = "green"; linux,default-trigger = "mmc0"; }; }; }; }; Thanks, Steven
  3. Hi, DNS would be difficult because the hosts on this local network have dynamic addresses. This is why nmbd (part of the Samba suite) is good and it works fine on hosts running wheezy or jessie (or Windows). There is an option called "socket options" in smb.conf and I've tried setting SO_RTIMEO (receive timeout) but it doesn't have any effect. The host running stretch can use ssh <other host name> to connect to any other host but other hosts find it very difficult to use ssh <stretch host name> to connect to the stretch host. I'll try running wireshark to see if the stretch host is getting the broadcast and if it is replying. As I said, the timeout seems very short. Cheers, Steven
  4. The resultant file is like a devicetree file in that it contains hardware details. Old kernels use this to get the addresses of devices for instance. So it's mainly used by the kernel. Some U-Boots have 'script_parser_fetch' code which means that the U-Boot is also accessing details from the file. Cheers, Steven
  5. Hi, I'm using NetBIOS names when using ssh to access other CTs on my local network. Most of the CTs and other hosts are running Wheezy. Now I have a CT running Stretch and it's very difficult to access this host using 'ssh <stretch host name>' because it's not responding to the broadcas from the calling host. If I repeat the request (and broadcast for the name) multiple times then sooner or later the Stretch CT will respond in time. The timeout on the host doing the broadcast seems very short. Does anybody know where this timeout is specified and how to change it ? Thanks, Steven
  6. &amp;nbsp; &amp;nbsp;Hi, I bought a TK1 because it runs real OpenGL. I have managed to get it running with my CubieTruck system (Debian) and the NVidia kernel. The major hassle was getting the NVidia driver to work. So it definitely can be done and the video driver was the only bit that took some work. I'm running Wheezy and I haven't tried a Jessie system. The NAND setup is way different from Cubie boards. On the TK1 the NAND is /dev/mmcblk0 and the boot files are in the /boot directory. Cheers, Steven
  7. Hi Igor, I built U-Boot from https://github.com/linux-sunxi/u-boot-sunxi.git and selected the sunxi branch and used the standard defconfigs (Cubieboard_config, Cubieboard2_config, and Cubietruck_config). I haven't patched or changed anything. Cheers, Steven
  8. Try my replacement U-Boot at http://phelum.net/temp/CB2/u-boot-sunxi-with-spl.bin and see if this helps. Cheers, Steven
  9. [ 2.559830] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV This looks like the U-Boot problem I hit a while ago. I have a replacement U-Boot at http://phelum.net/temp/CB1/u-boot-sunxi-with-spl.bin which might help. Cheers, Steven
  10. I hit this recently when I had a new u-boot-sunxi-with-spl.bin and my boot volume didn't have boot.scr. If you're seeing an attempt to load from the network then I think your u-boot is being found and run (because it is u-boot that tries to load from the network). Do you have /boot.scr or /boot/boot.scr in the first volume on your SD card ? Cheers, Steven
  11. Hi, Possibly the boot0 and boot1 files in NAND are incorrect. Installing Linaro (or something similar) with Phoenixsuit should replace these files with the ones required to boot Linux kernels. An alternative is to run the bootfix program from https://github.com/phelum/CT_NandBoot. This runs on a host machine (e.g. another CT or a PC) and loads the correct boot0 and boot1 files. This update doesn't affect the NAND partitions so if you've already loaded them then the CT should start automatically after the update. Cheers, Steven
  12. I assume you have a Cubieboard2 (A20). You might have a U-Boot problem. I've uploaded my CB2 U-Boot to http://phelum.net/temp/CB2/u-boot-sunxi-with-spl.bin so you can try it if you like. Cheers, Steven
  13. I think it's openGL ES only. The only OpenGL board I have is an NVidia TK1. I tried OpenGL on an A20 but it is software rendering only. Cheers, Steven
  14. Hi Igor, Yes, your config patch solves the problem. Much better than needing an old U-Boot for legacy kernels. Update: I've just found that Cubieboard_defconfig doesn't select "Enable workarounds for booting old kernels". Selecting this option fixes the boot problem (same as your patch). Cheers, Steven
  15. Hi, I've tried with and without "setenv bootm_boot_mode sec". My boot.scr works with the legacy U-Boot (2014.04) and the mainline U-Boot (2013.10) I probably got from a disk image. But it doesn't work (hang after "Starting kernel") with the mainline U-Boot (2016.05). My boot.scr is below. All 3 partitions on the SD card are ext2. Cheers, Steven (apologies if this doesn't format correctly; something in my browser is annoying the forum software). env set fdt_high ffffffff setenv bootargs console=ttyS0,115200 disp.screen0_output_mode=EDID:1024x768p60 \ root=/dev/mmcblk0p2 rootwait panic=10 rootfstype=ext2 #setenv extraargs rootfstype=ext2 #setenv script script.cb1 #setenv machid 0x10bb #setenv bootfstype ext2 #setenv scriptaddr 0x43000000 # mode sec required for old kernels, this forces single CPU mode !!! setenv bootm_boot_mode sec #printenv ext2load mmc 0 0x43000000 /boot/script.cb1 ext2load mmc 0 0x48000000 /boot/uImage bootm 0x48000000