@lex Posted January 22, 2017 Posted January 22, 2017 Additional info in: https://github.com/avafinger/dtb_bpi-m64 * firmware needs tol be in /lib/firmware with the kernel config, change if necessary * default u-boot environment on github is for booting from SD CARD and be able to format eMMC, this is my way, change if necessary * eMMC card is #2, so in my way this is the environment to boot from eMMC (change if necessary) #define CONFIG_EXTRA_ENV_SETTINGS \ "script=boot.scr\0" \ "mmcboot=run load_dtb load_kernel load_initrd set_cmdline boot_kernel\0" \ "console=ttyS0,115200\0" \ "root=/dev/mmcblk0p2\0" \ "load_addr=41000000\0" \ "fdt_addr=45000000\0" \ "kernel_addr=41080000\0" \ "initrd_addr=45300000\0" \ "kernel_filename=pine64/Image\0" \ "fdt_filename_prefix=pine64/sun50i-a64-\0" \ "fdt_filename_suffix=.dtb\0" \ "initrd_filename=initrd.img\0" \ "bootenv_filename=uEnv.txt\0" \ "load_bootenv=" \ "fatload mmc 2:1 ${load_addr} ${bootenv_filename}\0" \ "import_bootenv=" \ "env import -t ${load_addr} ${filesize}\0" \ "load_dtb=" \ "if test ${fdt_filename} = \"\"; then " \ "setenv fdt_filename ${fdt_filename_prefix}${pine64_model}${fdt_filename_suffix}; " \ "fi; " \ "fatload mmc 2:1 ${fdt_addr} ${fdt_filename}; " \ "fdt addr ${fdt_addr}; fdt resize\0" \ "load_kernel=" \ "fatload mmc 2:1 ${kernel_addr} ${kernel_filename}\0" \ "boot_kernel=booti ${kernel_addr} ${initrd_addr}:${initrd_size} ${fdt_addr}\0" \ "load_initrd=" \ "fatload mmc 2:1 ${initrd_addr} ${initrd_filename}; "\ "setenv initrd_size ${filesize}\0" \ "load_bootscript=" \ "fatload mmc 2:1 ${load_addr} ${script}\0" \ "scriptboot=source ${load_addr}\0" \ "set_cmdline=" \ "setenv bootargs console=${console} ${optargs} " \ "earlycon=uart,mmio32,0x01c28000 mac_addr=${ethaddr} " \ "root=${root} ro " \ "rootwait\0" \ "mmcbootcmd=" \ "if run load_bootenv; then " \ "echo Loading boot environment ...; " \ "run import_bootenv; " \ "fi; " \ "if run load_bootscript; then " \ "echo Booting with script ...; " \ "run scriptboot; " \ "else " \ "echo Booting with defaults ...; " \ "run mmcboot; " \ "fi\0" For all other things, use Pine64 build settings. Let me know if anything else is missing.
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 @ @lex Mainline u-boot can reassign card number 0 to eMMC/SD2 based on boot media reported by BROM. Maybe it can be implemented here too?
@lex Posted January 22, 2017 Posted January 22, 2017 Hi @zador.blood.stained I don't have any experience with Mainline u-boot so i can't say much about it, don't see any reason it could not but i think it needs an experienced developer (u-boot) i would not like to spend much time on it.
Igor Posted January 22, 2017 Posted January 22, 2017 To give full support is important to have the board on your desk, hope they send you one. The core problem is that I / we already have more boards than time to deal with We need to skip some boards, but if someone takes the lead and bring in some (similar) device, we will assist. Can those A64 devices share one legacy kernel? My Nano Pi M64 was dispatched, but first we need to expand Amlogic section ...
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 I don't have any experience with Mainline u-boot so i can't say much about it, don't see any reason it could not but i think it needs an experienced developer (u-boot) i would not like to spend much time on it. Well, it's simple enough, byte value at 0x28 is 0 if booted from MMC0 and 2 if booted from MMC2. You/we just need to find the right place to put this test in. Edit: and I would prefer a hack like this over any other hacks since this has to be integrated with existing Pine64 support without complicating it too much. Edit 2: I'm building a Pine64 image to see if this is executed during the boot process already Edit 3: Default boot environment relies on this variable, so it should work OK 1
@lex Posted January 22, 2017 Posted January 22, 2017 Can you point to some u-boot source that has been done this way? Did not see the link, sorry
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 @ @lex I pushed some changes to the Pine64 boot script, so it should work if loaded both from SD or eMMC: boot_part environment variable should point to the correct device and partition - either 0:1 or 2:1 sunxi#env print baudrate=115200 ... boot_part=0:1 ... boot_disk environment variable can also be used in the boot script to display an additional debugging message about the boot device. So now you should rename your DT and add it to this patch. Since I'm pretty sure that BPi M64 can't be easily differentiated from Pine64+ 2GB, correct DT file name (pine64_model environment variable) should be set manually in armbianEnv.txt at the image build time. Just so I don't read this whole thread again - do we need any changes to u-boot or kernel sources? CONFIG_EXTRA_ENV_SETTINGS at the top should not be needed after I changed the boot script.
@lex Posted January 22, 2017 Posted January 22, 2017 Well, it's simple enough, byte value at 0x28 is 0 if booted from MMC0 and 2 if booted from MMC2. You/we just need to find the right place to put this test in. Edit: and I would prefer a hack like this over any other hacks since this has to be integrated with existing Pine64 support without complicating it too much. Edit 2: I'm building a Pine64 image to see if this is executed during the boot process already Edit 3: Default boot environment relies on this variable, so it should work OK In my way the first boot is from SD CARD how you would fix this? Booting from eMMC root=/dev/mmcblk0p2 Booting from SD CARD (edited) root=/dev/mmcblk1p2
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 In my way the first boot is from SD CARD how you would fix this? Booting from eMMC root=/dev/mmcblk0p2 Booting from SD CARD root=/dev/mmcblk0p2 By using UUIDs (which is enabled for Pine64 by default). Well, writing the same image to SD and eMMC will create a collision, but we have the nand-sata-install script to handle the eMMC installation case. Edit: I believe you made a typo
@lex Posted January 22, 2017 Posted January 22, 2017 a) Just so I don't read this whole thread again - do we need any changes to u-boot or kernel sources? CONFIG_EXTRA_ENV_SETTINGS at the top should not be needed after I changed the boot script. b ) By using UUIDs (which is enabled for Pine64 by default). Well, writing the same image to SD and eMMC will create a collision, but we have the nand-sata-install script to handle the eMMC installation case. a) Yes, there is the new mmc driver. I worked on the same u-boot, i think a diff could suffice. Regarding Kernel source changes that depends on my modified mmc driver, if i did introduce a bug while i updated the mmc driver most likely the ugly hack should be discarded. b ) Ok, got it. I will update u-boot. How could i do something like this, will this be accepted coorect?: root=/dev/mmcblk${mmc_disk}p2 Edit: It is for my experiments.
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 How could i do something like this, will this be accepted coorect?: root=/dev/mmcblk${mmc_disk}p2 I'm not sure that kernel numbering will match the u-boot numbering - that's why there are labels and UUIDs, but if they always match for you, this can work for testing purposes.
@lex Posted January 22, 2017 Posted January 22, 2017 Can those A64 devices share one legacy kernel? Yes, i have the same legacy kernel for the Pine64 amd BPI-64. And most likely will work with NanoPi A64, that is what i will find out soon. 1
geektillithertz Posted January 26, 2017 Author Posted January 26, 2017 I have verified that the kernel inside of this: https://drive.google.com/open?id=0B_YnvHgh2rwjaVVMSi1xU1ZOY2c Builds, loads into the M64 eMMC using PhoenixCard, and will boot out of the eMMC. That is a recent Android 6.01 dump from Allwinner with M64 support added in. I will start turning it back into a repo (it started out as a repo and the middlemen removed the repo support) based on AOSP and load the git trees on gitlab. It is going to take me a couple of days to turn it back into a repo. Meanwhile you can download it and extract the working eMMC driver from it. The M64 eMMC wants to run in DDR mode. The older kernel in my Pine64 Android 5.1 does not have working eMMC DDR support in it. PS - the build tools were moved from that dump, you will have to add them back in. PPS - running pack on the Android side does not generate a valid image, in lichee './build.sh pack' does. This works very well... I've just had the time to test this. Sorry for my lack of input, my knowledge ATM is rather limited on the matter of uboot. I really appreciate the work this community is doing, opening up the code for such devices that have no support from the board o the chip manufacturers. I've got much to learn... thnx 1
wyrd Posted January 28, 2017 Posted January 28, 2017 Good day. I want to put Ubuntu or other Linux, but on Banana pi-m64 is not visible EMMC, I tried different images and everywhere there was one result. What to do?
@lex Posted January 28, 2017 Posted January 28, 2017 Feel free to try this ( https://github.com/avafinger/bpi-m64-firmware) if everything else fails, it is a WIP and i just need to make sure the instructions will actually "works".
wyrd Posted January 29, 2017 Posted January 29, 2017 Feel free to try this ( https://github.com/avafinger/bpi-m64-firmware) if everything else fails, it is a WIP and i just need to make sure the instructions will actually "works". You can give detailed instructions on the installation?
@lex Posted January 30, 2017 Posted January 30, 2017 You can give detailed instructions on the installation? I just finished initial instructions, you can try and see if it works for you. https://github.com/avafinger/bpi-m64-firmware#installation
wyrd Posted January 30, 2017 Posted January 30, 2017 @lex The image is created on the Banana or on any PC with Ubuntu Mate?
@lex Posted January 30, 2017 Posted January 30, 2017 1st you create SD card from a PC running any distro, you just need to install wget, fdisk and md5sum if you don't have it already installed. 2nd you boot M64 with this new SD card image and then you flash eMMC with the next instructions. The eMMC script has been fixed.
wyrd Posted January 31, 2017 Posted January 31, 2017 1st you create SD card from a PC running any distro, you just need to install wget, fdisk and md5sum if you don't have it already installed. 2nd you boot M64 with this new SD card image and then you flash eMMC with the next instructions. The eMMC script has been fixed. this is not working...
@lex Posted January 31, 2017 Posted January 31, 2017 this is not working... Please, describe in details the steps you did, step by step so i can figure out what is "not working..."
laserk Posted February 11, 2017 Posted February 11, 2017 I just run sysbench on BPI-M64, the test based on the image from(https://github.com/avafinger/bpi-m64-firmware and the os has been flashed in eMMC. however the the banchmark result looks too much positive than raspberry pi 3 M64 CPU test result total time 3.2352s ???raspberry pi 3 CPU test result 45.7901s ( the result comes from http://www.eeboard.com/bbs/thread-47335-1-1.html) I want to clarify whether the benchmark result is valid or there is something wrong made the result even faster than a PC?
tkaiser Posted February 11, 2017 Posted February 11, 2017 I want to clarify whether the benchmark result is valid or there is something wrong made the result even faster than a PC? Just take any OS image from SinoVoip and your BPi M64 will be immediately slow as hell: https://forum.armbian.com/index.php/topic/751-rfc-support-cortex-a53arm64/?p=12462 TL;DR: sysbench is one of the worst/stupid CPU benchmarks available. But people love numbers and trust blindly in numbers even if this is just data without any information. To get the idea what's wrong use Armbian's google powered search and enter 'sysbench prime number' or 'sysbench crap' or 'sysbench a64'. Or read post #5 of the linked thread above.
tkaiser Posted February 16, 2017 Posted February 16, 2017 SinoVoip now started to take @lex and community's work so good news for unfortunate BPi M64 customers since they soon might be able to use nearly all features of their boards (of course SinoVoip is still stupid enough to provide only ARMv6/ARMv7 rootfs so BPi M64 is still slowest A64 device around when relying on 'vendor OS offerings') https://github.com/BPI-SINOVOIP/BPI-files/commit/c1593759bdb1b7a511890c2371180097be47c96e (hell yeah: of course using same eth0 MAC address for all OS images to repeat every mistake made with Pine64 OS images and to prevent 2 or more BPi M64 connected to the same Ethernet broadcast domain from using network) @lex: they write kernel 3.10.102 (which is already outdated since months). Is this for a reason? Isn't the image you created already at 3.10.104 (and fixes 'Dirty COW' for example)?
@lex Posted February 17, 2017 Posted February 17, 2017 @lex: they write kernel 3.10.102 (which is already outdated since months). Is this for a reason? Isn't the image you created already at 3.10.104 (and fixes 'Dirty COW' for example)? I have chosen to freeze on this version because there are some of my personal development stuff in there, it is not for production environment. This vulnerability was fixed on Oct, 21 on Armbian and Oct, 22 on 3.10.104 (longsleep), maybe just timezone here but after i frozen to make my mods. TBH, i have seen so many people running linux with 'root' that makes 'Dirty COW' a kid in a kindergarten... Anyway, you got me, shame on me, i will do something to fix the flaw. 1
tkaiser Posted February 17, 2017 Posted February 17, 2017 TBH, i have seen so many people running linux with 'root' that makes 'Dirty COW' a kid in a kindergarten... Well, some distro makers like eg. DietPi folks even recommend this ('less hassles' or something like that IIRC) But I somewhat agree especially when having SinoVoip folks in mind (on some of their new OS images they ship with adb 'root backdoor' but since this requires physical access it's not worth that much thoughts anyway). Regarding a fix for the flaw please keep in mind that when your image is not using Armbian's apt repo to update the kernel at least longsleep's update scripts should work (SinoVoip of course put their stuff in a different location so that even if they use longsleep's kernel... updating it won't work -- stupid as usual). And even if you fix this now I wouldn't expect SinoVoip to follow. They're happy to provide OS images for each and every device they have that are vulnerable (numerous well known root exploits available). They don't give a sh*t about security anyway, not even on their 'routerboard' R1 that is supposed to be directly connected to the Internet.
@lex Posted February 18, 2017 Posted February 18, 2017 Just updated the kernel to 3.10.104 with the 'DIRTY COW' fix as promised i would do something. Releasing an Image (dev Image) comes responsibilities, bpi-m64 users are not left alone. I hope it works for you as it works for me. Have fun! Good luck. https://github.com/avafinger/bpi-m64-firmware#updating-kernel-to-310104 1
amiga23 Posted February 23, 2017 Posted February 23, 2017 @lex Thank you very much for your work. Bluetooth, GbE, WiFi and eMMC are working fine. Sometimes it does not boot. Neither from eMMC or SD. It seems to depend on the USB Devices. If I do have a USB Mouse and Keyboard connected it does not boot in most cases. The monitor turns into standby. Capslock / Numlock not working, not reachable via SSH. When holding down the uboot button it works most of the time. Without the mouse it seems to work always. Powersupply has 3A. The Network LEDs seem not to work correctly. One is flashing yellow in regular interval. I guess one should flash depending on traffic and the other one should be on steady to show link. But the switch shows 1000M. With help of your Image I managed to install ArchLinuxARM to the eMMC. I had to copy /lib/firmware/ap6212 from your image as it is not part of the ArchLinuxARM firmware package. Additionally I had to copy the modules.conf to /etc/modules-load.d. The only thing not working with ArchLinuxARM is bluetooth. Somehow "hciattach /dev/ttyS1 any" is running in your image but I have not found in which config file this is configured. If I run this command manually with my ArchLinuxARM image it does add a hci0 device but does not find any bluetooth devices and MAC is AA:AA:AA:AA:AA:AA. I did also try to use the mainline kernel, as it works fine on Lamobo-R1, and it contains a dtbs for the BPi-M64. But it seems that the Kernel-Image has a different format (file command shows msdos executable) so I guess I would need some tweaks to uboot?
@lex Posted February 23, 2017 Posted February 23, 2017 My work on the u-boot is available here: https://github.com/avafinger/u-boot-m64, you can adapt to your need as you wish. You should set MAC address to BT in a similar way Armbian does. Find in the conf where it gets $MAC_ADDRESS and set it (something like this), also you have to patch firmware somehow. I use a High Speed USB 2.0 (not powered) with the mouse and keyboard attached to it and not to USB port, never had a problem, but i think BPI boards has this USB power issues you describe, @lvmc helped them to fix this in the M2+.
Recommended Posts