request for Banana Pi M64


geektillithertz
 Share

7 7

Recommended Posts

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.

Link to post
Share on other sites

Donate and support the project!

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 ...

Link to post
Share on other sites

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

Link to post
Share on other sites

@ @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. 

Link to post
Share on other sites

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
Link to post
Share on other sites

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  :) 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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?

 

599b226dc38cdd0f11360b627858510bf448c028

Link to post
Share on other sites

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.

Link to post
Share on other sites

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)?

Link to post
Share on other sites

@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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

@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?

Link to post
Share on other sites

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+.

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

7 7