On 25.11.18 14:55, Freek de Kruijf wrote:
> Op zaterdag 24 november 2018 19:43:24 CET schreef Alexander Graf:
>> On 24.11.18 17:57, Freek de Kruijf wrote:
>>> Op vrijdag 19 oktober 2018 09:52:32 CET schreef Alexander Graf:
>>>> Hi Freek,
>>>>
>>>> On 18.10.18 16:45, Freek de Kruijf wrote:
>>>>> I noticed a number of images/support for Banana Pi systems having an
>>>>> armv7
>>>>> type processor architecture. Also using names with sinovoipbpi in the
>>>>> name
>>>>> of the image.
>>>>>
>>>>> This name is also present in information about the Banana Pi M64 of
>>>>> which
>>>>> the processor architecture is aarch64. There is even an openSUSE
>>>>> Tumbleweed image, dating a year back, which runs on this system.
>>>>
>>>> Where did you find that image? Who created it?
>>>>
>>>> The Banana Pi M64 seems to be A64 based, so I'm fairly sure from a
>>>> kernel enablement point of view, we're in good shape. The only thing you
>>>> might be missing would be the low level firmware bits.
>>>
>>> Hi Alex,
>>>
>>> continued my research and found
>>> https://github.com/BPI-SINOVOIP/BPI-Mainline-kernel . I did a git clone
>>> to get the content in folder BPI-Mainline-kernel. I installed the
>>> required packages mentioned in ./linux-4.19/Documentation/
>>> process/changes.rst. However "oprofiled --version" is mentioned to check
>>> the version of the packet oprofile, but that did not work. The command
>>> should be "opreport --version".
>>> After that I ran "./build_kernel_64.sh" in folder BPI-Mainline-kernel,
>>> which succeeded. I got a lot of generated files in
>>> ./linux-4.19/output/bpi-64/ among other a vmlinux, which seems to be the
>>> new kernel. Also a lot of drivers and modules have been generated.
>>> I also downloaded the source of kernel 4.19.4 as a tar.xz, unpacked it in
>>> folder linux-4.19-4 in BPI-Mainline-kernel and adapted build_kernel_64.sh
>>> to enter linux-4.19.4. I also needed to copy a few file from linux-4.19
>>> to linux-4.19.4, build_64.sh and linux-4.19/arch/arm64/bpi_64_defconfig.
>>> After that I succeeded in building the kernel 4.19.4.
>>>
>>> So far what I did. Now the experiment to make the kernel run. If you have
>>> any suggestions, please let me know.
>>
>> I don't think you need any downstream patches for the kernel. Everything
>> in that tree only adds a few changes for the m2u/m2b boards which you
>> don't have. 4.19 from Tumbleweed should already have everything required
>> to run on that system.
>
> I did not have any idea what is needed. I just found this website and tried
> what it talked about, just trying to see if it also works for a newer kernel
> from its original source. I used cross compiling on my x86_64 system with
> Tumbleweed to get the kernel for the aarch64 system. In the generated files I
> do find similar file names which are present on /dev/mmcblk0p1, but not all.
>
>> So all you need is firmware that adheres to EBBR and you're all set with
>> a Tumbleweed JeOS.
>
> I am very fresh in this area. So I have no idea what EBBR means and how to
> build things for a JeOS system. I found in the original openSUSE image for
> the
> Banana Pi M64 on /dev/mmcblk0p1 a folder dtb/allwinner/ containing o.a. a
> file
> sun50i-a64-bananapi-m64.dtb which seems to be needed. Is this the one you are
> referring to? There is also a folder overlay which has files *.dtbo with
> names
> similar to the above.
> I did not find a folder dtb in the folder with the linux source, also not
> after the generation. However there is a folder dts as a subfolder of output,
> so generated, in which I found a file named like above, sun50i-a64-bananapi-
> m64.dtb.
>
>> Did anyone create a working (recent) image that works from eMMC? If so,
>> it probably boots using U-Boot? In that case, you should be able to just
>> abort the boot, modify the "boot_targets" variable to point to MMC boot
>> instead and run "boot" to boot into a Tumbleweed image on an SD card.
>
> Yes there is a debian system that can be started from the microSD card and
> that allows populating eMMC. However the openSUSE system does not show the
> eMMC device. After populating eMMC with that debian system, the system will
> start from eMMC, however after that the microSD is no longer visible, as far
> as I recall.
> However what you suggest above is most likely beyond my capabilities to
> figure
> out without some detailed instructions.
> Maybe it gives some clue to you when I show the content of /dev/mmcblk0p1:
> bpim64tum:~ # ls -l /mnt
> total 24692
> -rwxr-xr-x 1 root root 80 aug 29 2017 armbianEnv.txt
> -rwxr-xr-x 1 root root 1557 aug 29 2017 armbian_first_run.txt
> -rwxr-xr-x 1 root root 38518 aug 29 2017 boot.bmp
> -rwxr-xr-x 1 root root 2989 aug 29 2017 boot.cmd
> -rwxr-xr-x 1 root root 4882 aug 29 2017 boot-desktop.png
> -rwxr-xr-x 1 root root 3061 aug 29 2017 boot.scr
> -rwxr-xr-x 1 root root 137688 aug 29 2017 config-4.13.0-rc6-sun50iw1
> drwxr-xr-x 3 root root 4096 aug 29 2017 dtb
> -rwxr-xr-x 1 root root 12288008 aug 29 2017 Image
> -rwxr-xr-x 1 root root 4990985 aug 29 2017 initrd.img-4.13.0-rc6-sun50iw1
> -rwxr-xr-x 1 root root 0 aug 29 2017 .next
> -rwxr-xr-x 1 root root 2794420 aug 29 2017 System.map-4.13.0-rc6-sun50iw1
> -rwxr-xr-x 1 root root 4991049 aug 29 2017 uInitrd
> bpim64tum:~ #
> The file boot.cmd mentions U-boot
> At the end of that file are two lines showing:
> # Recompile with:
> # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
Ok, so they are not using distro boot - instead they rely on the old
boot.scr method. Also the dates sound quite old. 2017 is long past :).
That means we need to get you an updated U-Boot onto your system. Once
we have that, you should be good to just use any standard "efi" JeOS image.
Alex
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
