19 Oct
2018
19 Oct
'18
3:45 a.m.
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.
Will there be support for the Banana Pi M64 with a more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
19 Oct
19 Oct
8:52 p.m.
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.
The idea openSUSE scenario for that would be if someone in the community
did a "firmware installer" that really just writes U-Boot and ATF onto
the eMMC. That U-Boot would then run distro boot and provide a workable
DT for the platform.
With that in place, you could just take the openSUSE installer iso, boot
it, and install your system as with any other machine. No need for images.
Will there be support for the Banana Pi M64 with a
more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
It's not very complicated to have such an image available. In fact, all
it takes is someone who takes the pieces necessary (ATF, U-Boot), makes
sure everything's mainline and built in our copies and then sends a
submit request to the JeOS package to enable the port.
Alex
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
20 Oct
20 Oct
12:32 a.m.
Op vrijdag 19 oktober 2018 09:52:32 CEST schreef Alexander Graf:
Hi Freek,
On 18.10.18 16:45, Freek de Kruijf wrote:
There are two images on https://dev.banana-pi.org.cn/Image/BPI-M64/
2017-08-29-openSUSE-Tumbleweed-ARM-MATE-desktop-demo-bpi-m64-aarch64-sd-
emmc.img.zip
and
2017-08-29-opensuse-xfce-desktop-demo-bpi-m64-aarch64-sd-emmc.img.zip
I could not find who created these images. Asked for information in the
BananaPi forum, but got no answer.
I used the MATE image and was able to update the system to the latest
Tumbleweed version. However a new kernel and initrd was generated but was not
put on the boot partition. So a reboot worked but showed the old kernel. The
boot partition mmcblk0p1 is not mounted only the root partition mmcblk0p2. I
compared the new initrd and Image in /boot on the root partition with the old
one on the boot partition (mmcblk0p1) and did not try to replace these files.
The eMMC is shown on the debian system as /dev/mmcblk1. There are other
partitions /dev/mmcblk1boot0, /dev/mmcblk1boot1, /dev/mmcblk1p0 and /dev/
mmcblk1p1. The first two are read-only, the second two are currently a small
fat32 partition (256M and a large ext4 partition (6.7G). Although the first
two share the text mmcblk1, they do not show up in fdisk -l /dev/mmcblk1
In some documentation I found a type of shell script which reads a file
uEnv.txt and at the end contains a load command which first loads something
like a dtb file, second a file initrd.img and third a file Image. In the boot
partition are folder with names 1080p, 480p, 720p, lcd5 and lcd7. In these
folders are three files all with the same name in each folder. The names are
bootlogo.bmp, sun50i-a64-bpi-m64-lcd5.dtb and uEnv.txt. uEnv.txt contains
parameter definitions for console, kernel_filename, initrd_filename and
fdt_filename of which only fdt_filename receives different values in the
different folders. Both kernel_filename and initrd_filename point to files in
the parent folder of these
I assume that this type of shell script exists somewhere on the bootX devices.
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.
The idea openSUSE scenario for that would be if someone in the community
did a "firmware installer" that really just writes U-Boot and ATF onto
the eMMC. That U-Boot would then run distro boot and provide a workable
DT for the platform.
With that in place, you could just take the openSUSE installer iso, boot
it, and install your system as with any other machine. No need for images.
Do you want some more information on the openSUSE image?
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Will there be support for the Banana Pi M64 with
a more recent image? It
does seem very complicated to have such an image available in the ports
repository for aarch64.
It's not very complicated to have such an image available. In fact, all
it takes is someone who takes the pieces necessary (ATF, U-Boot), makes
sure everything's mainline and built in our copies and then sends a
submit request to the JeOS package to enable the port.
Alex
1:53 a.m.
Op vrijdag 19 oktober 2018 13:32:25 CEST schreef Freek de Kruijf:
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Op vrijdag 19 oktober 2018 09:52:32 CEST schreef
Alexander Graf:
I was wrong. This type shell script is in the boot partition (mmcblk0p1) of
the openSUSE image. This partition looks quite different from the boot
partition of the debian image. On the boot partition of the openSUSE image
almost everything is in the top folder. There is only a dtb subfolder.
On debian the real content starts in bananapi/bpi-m64/linux/ with the file
Image etc. like mentioned before.
The content of the shell script mentioned U-boot and also a command mkimage to
generate images.
On openSUSE I dont see a device /dev/mmcblk1, so the eMMC is invisible.
Hi Freek,
On 18.10.18 16:45, Freek de Kruijf wrote:
There are two images on https://dev.banana-pi.org.cn/Image/BPI-M64/
2017-08-29-openSUSE-Tumbleweed-ARM-MATE-desktop-demo-bpi-m64-aarch64-sd-
emmc.img.zip
and
2017-08-29-opensuse-xfce-desktop-demo-bpi-m64-aarch64-sd-emmc.img.zip
I could not find who created these images. Asked for information in the
BananaPi forum, but got no answer.
I used the MATE image and was able to update the system to the latest
Tumbleweed version. However a new kernel and initrd was generated but was
not put on the boot partition. So a reboot worked but showed the old
kernel. The boot partition mmcblk0p1 is not mounted only the root partition
mmcblk0p2. I compared the new initrd and Image in /boot on the root
partition with the old one on the boot partition (mmcblk0p1) and did not
try to replace these files.
The eMMC is shown on the debian system as /dev/mmcblk1. There are other
partitions /dev/mmcblk1boot0, /dev/mmcblk1boot1, /dev/mmcblk1p0 and /dev/
mmcblk1p1. The first two are read-only, the second two are currently a small
fat32 partition (256M and a large ext4 partition (6.7G). Although the first
two share the text mmcblk1, they do not show up in fdisk -l /dev/mmcblk1
In some documentation I found a type of shell script which reads a file
uEnv.txt and at the end contains a load command which first loads something
like a dtb file, second a file initrd.img and third a file Image. In the
boot partition are folder with names 1080p, 480p, 720p, lcd5 and lcd7. In
these folders are three files all with the same name in each folder. The
names are bootlogo.bmp, sun50i-a64-bpi-m64-lcd5.dtb and uEnv.txt. uEnv.txt
contains parameter definitions for console, kernel_filename,
initrd_filename and fdt_filename of which only fdt_filename receives
different values in the different folders. Both kernel_filename and
initrd_filename point to files in the parent folder of these
I assume that this type of shell script exists somewhere on the bootX
devices. 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.
The idea openSUSE scenario for that would be if someone in the community
did a "firmware installer" that really just writes U-Boot and ATF onto
the eMMC. That U-Boot would then run distro boot and provide a workable
DT for the platform.
With that in place, you could just take the openSUSE installer iso, boot
it, and install your system as with any other machine. No need for images.
Do you want some more information on the openSUSE image? Will there be support for the Banana Pi M64 with
a more recent image? It
does seem very complicated to have such an image available in the ports
repository for aarch64.
It's not very complicated to have such an image available. In fact, all
it takes is someone who takes the pieces necessary (ATF, U-Boot), makes
sure everything's mainline and built in our copies and then sends a
submit request to the JeOS package to enable the port.
Alex
25 Nov
25 Nov
5:57 a.m.
Op vrijdag 19 oktober 2018 09:52:32 CET schreef Alexander Graf:
Hi Freek,
On 18.10.18 16:45, Freek de Kruijf wrote:
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.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
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.
7:43 a.m.
On 24.11.18 17:57, Freek de Kruijf wrote:
Op vrijdag 19 oktober 2018 09:52:32 CET schreef
Alexander Graf:
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.
So all you need is firmware that adheres to EBBR and you're all set with
a Tumbleweed JeOS.
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.
Alex
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Hi Freek,
On 18.10.18 16:45, Freek de Kruijf wrote:
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 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.
26 Nov
26 Nov
2:55 a.m.
Op zaterdag 24 november 2018 19:43:24 CET schreef Alexander Graf:
On 24.11.18 17:57, Freek de Kruijf wrote:
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.
Op vrijdag 19 oktober 2018 09:52:32 CET schreef
Alexander Graf:
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. Hi Freek,
On 18.10.18 16:45, Freek de Kruijf wrote:
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 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. 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
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
10:23 a.m.
On 25.11.18 14:55, Freek de Kruijf wrote:
Op zaterdag 24 november 2018 19:43:24 CET schreef
Alexander Graf:
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: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
On 24.11.18 17:57, Freek de Kruijf wrote:
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.
Op vrijdag 19 oktober 2018 09:52:32 CET schreef
Alexander Graf:
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. 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. 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 
7:34 a.m.
Hi Freek,
Am 18.10.18 um 16:45 schrieb Freek de Kruijf:
Will there be support for the Banana Pi M64 with a
more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
Please see my Wiki page: https://en.opensuse.org/HCL:BananaPi_M64
While we don't have an image for the BPi-M64 specifically (yet), you can
derive one from JeOS-pine64 by replacing its U-Boot as described above.
Note that some images like these cannot appear on the download server in
the official places because they depend on TF-A packages not in Factory.
I'm seeing issues with my serial console not working reliably (only
fragments; already tried multiple known-working cables) but it boots up
okay with 4.19.1 and I could ssh into the resulting image.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
10:20 a.m.
On 25.11.18 19:34, Andreas Färber wrote:
Hi Freek,
Am 18.10.18 um 16:45 schrieb Freek de Kruijf:
Are you sure? There is an upstream U-Boot port for the M64 and I don't
see anything striking me that would require ATF modifications compared
to the Pine64.
So it would be a good start to just try and build pine64 ATF + upstream
U-Boot compiled for M64.
My suggestion to you Freek would be to join us in IRC on Freenode's
#opensuse-arm channel and we'll try to figure this out together.
Alex
Will there be support for the Banana Pi M64 with
a more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
Please see my Wiki page: https://en.opensuse.org/HCL:BananaPi_M64
While we don't have an image for the BPi-M64 specifically (yet), you can
derive one from JeOS-pine64 by replacing its U-Boot as described above.
Note that some images like these cannot appear on the download server in
the official places because they depend on TF-A packages not in Factory.
I'm seeing issues with my serial console not working reliably (only
fragments; already tried multiple known-working cables) but it boots up
okay with 4.19.1 and I could ssh into the resulting image.
Cheers,
Andreas
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
10:53 a.m.
Am 25.11.18 um 22:20 schrieb Alexander Graf:
On 25.11.18 19:34, Andreas Färber wrote:
Yes! :)
Am 18.10.18 um 16:45 schrieb Freek de Kruijf:
Are you sure? Will there be support for the Banana Pi M64 with
a more recent image? It does
seem very complicated to have such an image available in the ports repository
for aarch64.
Please see my Wiki page: https://en.opensuse.org/HCL:BananaPi_M64
While we don't have an image for the BPi-M64 specifically (yet), you can
derive one from JeOS-pine64 by replacing its U-Boot as described above.
Note that some images like these cannot appear on the download server in
the official places because they depend on TF-A packages not in Factory. There is an upstream U-Boot port for the M64 and I
don't
see anything striking me that would require ATF modifications compared
to the Pine64.
So it would be a good start to just try and build pine64 ATF + upstream
U-Boot compiled for M64.
Why?! I packaged u-boot-bananapim64 myself (as linked in the Wiki above)
and updated arm-trusted-firmware to support A64. TF-A has downstream
dependencies in hardware:boot (HiKey) and therefore TF-A cannot go to
Factory until those get resolved. Ideas welcome.
Both hardware:boot and Contrib:Pine64 build mainline U-Boot with
mainline TF-A. There is no need to use arm-trusted-firmware-pine64
anymore, it is unused now and IMO candidate for deletion if no bug
reports arrive for the current A64 and H5 based U-Boot packages.
Regards,
Andreas
My suggestion to you Freek would be to join us in IRC on Freenode's
#opensuse-arm channel and we'll try to figure this out together.
Alex
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
27 Nov
27 Nov
1:08 a.m.
Op zondag 25 november 2018 22:53:41 CET schreef Andreas Färber:
> My suggestion to you Freek would be to join us in
IRC on Freenode's
> #opensuse-arm channel and we'll try to figure this out together.
I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, and
started the Banana Pi M64 with it. It did boot, which I followed on the serial
console, USB-TTL serial cable. However the Ethernet device did not come up.
I did a reboot and now the Ethernet device comes up and gets addresses. Also
zypper ref works.
I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
installed. There I also found u-boot-bananapim64, should that one be
installed?
Also journalctl gives only lines of 80 characters and 40 lines. I installed
xterm and used resize to give the command "COLUMNS=132;LINES=41;export COLUMNS
LINES;", which solved that problem. Pleased with the results so far.
Using IRC would be my first time. Will search how to use it.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
3:53 a.m.
Op maandag 26 november 2018 13:08:36 CET schreef Freek de Kruijf:
Op zondag 25 november 2018 22:53:41 CET schreef
Andreas Färber:
So far I failed to use IRC. Nickname is freek. Tried also using the
Because the installed openssh-7.8p1-1.1 does not allow ssh access I replaced
it by openssh-7.9p1-198.1, which I found somewhere on OBS.
I also did a "zypper dup --no-r" which replaced kernel-default from 4.19.2-1
to 4.18.15-1. Symbolic links in /boot all point to these new files. However
"uname -a" still shows "4.19.2-1-default". Anyway it works and it uses
the
same aarch64 repository as for the Raspberry Pi 3B except for the u-boot...
package.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
> My suggestion to you Freek would be to join
us in IRC on Freenode's
> #opensuse-arm channel and we'll try to figure this out together.
I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD, and
started the Banana Pi M64 with it. It did boot, which I followed on the
serial console, USB-TTL serial cable. However the Ethernet device did not
come up. I did a reboot and now the Ethernet device comes up and gets
addresses. Also zypper ref works.
I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
installed. There I also found u-boot-bananapim64, should that one be
installed?
Also journalctl gives only lines of 80 characters and 40 lines. I installed
xterm and used resize to give the command "COLUMNS=132;LINES=41;export
COLUMNS LINES;", which solved that problem. Pleased with the results so
far.
Using IRC would be my first time. Will search how to use it.
29 Nov
29 Nov
2:31 a.m.
Op maandag 26 november 2018 15:53:38 CET schreef Freek de Kruijf:
Op maandag 26 november 2018 13:08:36 CET schreef Freek
de Kruijf:
Problem with 4.19.2 being booted is solved. It was and still is the preferred
system in grub. I changed the preferred system to 4.18.15 using yast ->
bootloader, however 4.19.2 is still the one that is booted by default. I have
to select 4.18.15 in the Advanced setting in the grub screen to get this
kernel.
Still a problem with starting the system to get an Ethernet connection.
Sometimes it works, mostly not. Need to "shutdown -r now" from the serial
console to get eth0 up with the requested IP addresses.
I search for this problem and found a solution to reload the driver, here
dwmac_sun8i, with modprobe, but that did not work. Just need to do a reboot
until the eth0 device comes up.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Op zondag 25 november 2018 22:53:41 CET schreef
Andreas Färber:
So far I failed to use IRC. Nickname is freek. Tried also using the
Because the installed openssh-7.8p1-1.1 does not allow ssh access I replaced
it by openssh-7.9p1-198.1, which I found somewhere on OBS.
I also did a "zypper dup --no-r" which replaced kernel-default from 4.19.2-1
to 4.18.15-1. Symbolic links in /boot all point to these new files. However
"uname -a" still shows "4.19.2-1-default". Anyway it works and it
uses the
same aarch64 repository as for the Raspberry Pi 3B except for the u-boot...
package. > My suggestion to you Freek would be to join
us in IRC on Freenode's
> #opensuse-arm channel and we'll try to figure this out together.
I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD,
and
started the Banana Pi M64 with it. It did boot, which I followed on the
serial console, USB-TTL serial cable. However the Ethernet device did not
come up. I did a reboot and now the Ethernet device comes up and gets
addresses. Also zypper ref works.
I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
installed. There I also found u-boot-bananapim64, should that one be
installed?
Also journalctl gives only lines of 80 characters and 40 lines. I
installed
xterm and used resize to give the command "COLUMNS=132;LINES=41;export
COLUMNS LINES;", which solved that problem. Pleased with the results so
far.
Using IRC would be my first time. Will search how to use it.
2 Dec
2 Dec
3:47 a.m.
Am 26.11.18 um 13:08 schrieb Freek de Kruijf:
I downloaded the Upstream Pine64 image, did put it on
a 16 GB micro-SD, and
started the Banana Pi M64 with it. It did boot, which I followed on the serial
console, USB-TTL serial cable. However the Ethernet device did not come up.
Did you or did you not dd the M64 u-boot-sunxi-with-spl.bin file as I
documented on the Wiki page?
If you use the Pine64 bootloader and Device Tree, all kinds of things
can go wrong.
I did a reboot and now the Ethernet device comes up
and gets addresses. Also
zypper ref works.
I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
installed. There I also found u-boot-bananapim64, should that one be
installed?
It doesn't matter which package is installed, it only matters which
binary was written (dd'ed) to the right location on the SD card.
Uninstalling u-boot-pine64plus is certainly a good idea to avoid
mistakes, but installing u-boot-bananapim64 is only one way of obtaining
the binary to dd onto the SD card. You could also extract the .rpm on
another machine, using e.g. file-roller or command line tools.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
4:59 a.m.
Op zaterdag 1 december 2018 15:47:17 CET schreef Andreas Färber:
Am 26.11.18 um 13:08 schrieb Freek de Kruijf:
> I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD,
> and
> started the Banana Pi M64 with it. It did boot, which I followed on the
> serial console, USB-TTL serial cable. However the Ethernet device did not
> come up.
Hi Andreas,
thanks for your answer.
Did you or did you not dd the M64
u-boot-sunxi-with-spl.bin file as I
documented on the Wiki page?
I did not. Didn't know where to find that file.
If you use the Pine64 bootloader and Device Tree, all
kinds of things
can go wrong.
Apparently I am fine, except that when booting right after power on, the
Ethernet device does not come up. However a "shutdown -r now" does a reboot
and the device does come up.
> I did a reboot and now the Ethernet device comes
up and gets addresses.
> Also zypper ref works.
> I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
> installed. There I also found u-boot-bananapim64, should that one be
> installed?
I just tried a "zypper in --download-only u-boot-
bananapim64-2018.11-95.1.aarch64" which conflicts with u-boot-
pine64plus-2018.11-95.1.aarch64.
I downloaded it using curl and got:
# rpm -ql u-boot-bananapim64-2018.11-95.1.aarch64.rpm
/boot/sunxi-spl.bin
/boot/u-boot-sunxi-with-spl.bin
/boot/u-boot.itb
/usr/share/doc/packages/u-boot-bananapim64
/usr/share/doc/packages/u-boot-bananapim64/README
/usr/share/licenses/u-boot-bananapim64
/usr/share/licenses/u-boot-bananapim64/gpl-2.0.txt
It doesn't matter which package is installed, it
only matters which
binary was written (dd'ed) to the right location on the SD card.
So these above files in /boot are not used in the boot process?
Uninstalling u-boot-pine64plus is certainly a good
idea to avoid
mistakes, but installing u-boot-bananapim64 is only one way of obtaining
the binary to dd onto the SD card. You could also extract the .rpm on
another machine, using e.g. file-roller or command line tools.
So I should move the above /boot/u-boot-sunxi-with-spl.bin to my desktop
system and dd that file with "dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX
bs=1024 seek=8" to the SD card?
This moves the content of that file to a location on the micro-SD which lies
before the sector 2048 on which /dev/mmcblk0p1 starts. Starts at sector 16?
Regards,
Andreas
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
6:24 a.m.
Op zaterdag 1 december 2018 16:59:44 CET schreef Freek de Kruijf:
Op zaterdag 1 december 2018 15:47:17 CET schreef
Andreas Färber:
Tried another test SD card with your recipe on the wiki. Did work. So I also
transferred u-boot-sunxi-with-spl.bin to the SD card I already did have
running. Now the Ethernet interface comes up right away.
Will update the wiki on how to get u-boot-sunxi-with-spl.bin.
On the test SD I saw also the eMMC visible, however it not visible on my first
SD which I am preparing for production. On this SD I removed kernel 4.19.2,
now running 4.18.15-1.
Just saw Tumbleweed 20181129 is available. Will install that system. Uses
4.19.4.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
Am 26.11.18 um 13:08 schrieb Freek de Kruijf:
> I downloaded the Upstream Pine64 image, did put it on a 16 GB micro-SD,
> and
> started the Banana Pi M64 with it. It did boot, which I followed on the
> serial console, USB-TTL serial cable. However the Ethernet device did
> not
> come up.
Hi Andreas,
thanks for your answer.
Did you or did you not dd the M64
u-boot-sunxi-with-spl.bin file as I
documented on the Wiki page?
I did not. Didn't know where to find that file.
If you use the Pine64 bootloader and Device Tree,
all kinds of things
can go wrong.
Apparently I am fine, except that when booting right after power on, the
Ethernet device does not come up. However a "shutdown -r now" does a reboot
and the device does come up.
> I did a reboot and now the Ethernet device
comes up and gets addresses.
> Also zypper ref works.
> I inspected repository Factory-Contrib-Pine64 and u-boot-pine64plus is
> installed. There I also found u-boot-bananapim64, should that one be
> installed?
I just tried a "zypper in --download-only u-boot-
bananapim64-2018.11-95.1.aarch64" which conflicts with u-boot-
pine64plus-2018.11-95.1.aarch64.
I downloaded it using curl and got:
# rpm -ql u-boot-bananapim64-2018.11-95.1.aarch64.rpm
/boot/sunxi-spl.bin
/boot/u-boot-sunxi-with-spl.bin
/boot/u-boot.itb
/usr/share/doc/packages/u-boot-bananapim64
/usr/share/doc/packages/u-boot-bananapim64/README
/usr/share/licenses/u-boot-bananapim64
/usr/share/licenses/u-boot-bananapim64/gpl-2.0.txt
It doesn't matter which package is installed,
it only matters which
binary was written (dd'ed) to the right location on the SD card.
So these above files in /boot are not used in the boot process?
Uninstalling u-boot-pine64plus is certainly a
good idea to avoid
mistakes, but installing u-boot-bananapim64 is only one way of obtaining
the binary to dd onto the SD card. You could also extract the .rpm on
another machine, using e.g. file-roller or command line tools.
So I should move the above /boot/u-boot-sunxi-with-spl.bin to my desktop
system and dd that file with "dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX
bs=1024 seek=8" to the SD card?
This moves the content of that file to a location on the micro-SD which lies
before the sector 2048 on which /dev/mmcblk0p1 starts. Starts at sector 16?
> Regards,
> Andreas
8:11 a.m.
New subject: [opensuse-arm] Question about support for Banana Pi (M64) [ANSWERED]
I updated the wiki on Banana Pi M64, which shows how it is supported.
Many thanks for the discussions.
--
fr.gr.
member openSUSE
Freek de Kruijf
--
To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org
819
days inactive
863
days old
17 comments
3 participants
participants (3)
-
Alexander Graf -
Andreas Färber -
Freek de Kruijf