Hi all, I hope I wrote in the right place.
I've see that Fedora 31 now supports Rock64 sbc.
I've not found any guide to setup a sd card or any how-to boot Fedora 31 with it.
In addition, Hdmi does not works form me, nor serial console.
Any guide or how-to to follow?
If I look at Rock64 wiki page, i found images for Debian/Ubuntu/others, with a simple "dd image to your sd". And it works (serial console & hdmi too)! Any way to do the same with Fedora? Really, i don't like too mutch @deb distros .
Hope someone can help me.
Best regards, Agharta
Hi all, I hope I wrote in the right place.
You are.
I've see that Fedora 31 now supports Rock64 sbc.
It does.
I've not found any guide to setup a sd card or any how-to boot Fedora 31 with it.
I still need to update the documentation.
In addition, Hdmi does not works form me, nor serial console.
Serial console definitely does work, HDMI is currently untested but I believe there's still things going upstream for that to work completely.
Any guide or how-to to follow?
If I look at Rock64 wiki page, i found images for Debian/Ubuntu/others, with a simple "dd image to your sd". And it works (serial console & hdmi too)! Any way to do the same with Fedora? Really, i don't like too mutch @deb distros .
Which wiki page? You mean the one on the pine64 wiki?
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Any news? Thanks
On 11/7/19 11:53 AM, agharta agharta wrote:
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Any news? Thanks
Hi Agharta,
Have you tried any other linux distributions (ideally rpm based)?
Regards,
Benson
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Il sab 9 nov 2019, 07:47 Benson Muite benson_muite@emailplus.org ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote:
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole
--image=Fedora-Minimal-31-1.9.aarch64.raw.xz
--media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what
should I insert in
TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Any news? Thanks
Hi Agharta,
Have you tried any other linux distributions (ideally rpm based)?
Regards,
Benson
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite <benson_muite@emailplus.org mailto:benson_muite@emailplus.org> ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote: >> Hi Peter, >> Thank you for your support. >> >> Currently I'm trying to write fedora to sd card with this command: >> fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz >> --media=/dev/sdd --resizefs >> >> So, at the end the tool tells me: >> >> = No U-boot will be written. >> = No console listed for Mystery Board, adding default ttyS0,115200 . >> >> = Installation Complete! Insert into the Mystery Board and boot. >> >> And.....no console. (at 115200) >> I think that this may be because "= No U-boot will be written." >> Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in >> TARGET? >> >> "I still need to update the documentation." >> Do you already have the link? >> >> "Which wiki page? You mean the one on the pine64 wiki?" >> This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release >> >> Many thanks for Your patience. >> Cheers, >> Agharta > Any news? > Thanks Hi Agharta, Have you tried any other linux distributions (ideally rpm based)? Regards, Benson > _______________________________________________ > arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi,
So my rock64 is running Arch on a 64G eMMC ( Self built uboot / dtc's ) since there was no guide / install path back then )), most likely you have to dd uboot/boot loader manually try the arch install guide steps to do that.
I would imagine Fedora would be good for SBC;s as they very much keep up with current kernels which is always a pet peeve with .deb based distro's. Anyway here is some info from my unit,
Linux archrock 5.3.8-2-ARCH #1 SMP Sun Nov 3 14:59:20 UTC 2019 aarch64 GNU/Linux
Module Size Used by xt_CT 16384 1 xt_helper 16384 1 nf_conntrack_ftp 28672 1 nf_log_ipv4 16384 46 nf_log_common 16384 1 nf_log_ipv4 ip6table_raw 16384 0 ip6table_mangle 16384 0 ip6table_nat 16384 0 iptable_nat 16384 1 nf_nat 53248 2 ip6table_nat,iptable_nat xt_TCPMSS 16384 2 xt_LOG 20480 46 ipt_REJECT 16384 0 iptable_raw 16384 1 iptable_mangle 16384 0 xt_multiport 20480 0 xt_state 16384 0 xt_limit 16384 47 xt_conntrack 16384 10 nf_conntrack 176128 6 xt_conntrack,nf_nat,xt_state,xt_helper,nf_conntrack_ftp,xt_CT nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack ip6table_filter 16384 1 ip6_tables 28672 4 ip6table_filter,ip6table_raw,ip6table_nat,ip6table_mangle iptable_filter 16384 1 bpfilter 24576 0 snd_soc_hdmi_codec 20480 0 rc_cec 16384 0 dw_hdmi_i2s_audio 16384 0 dw_hdmi_cec 16384 0 realtek 20480 1 snd_soc_audio_graph_card 24576 0 snd_soc_simple_card_utils 28672 1 snd_soc_audio_graph_card gpio_ir_recv 16384 0 dwmac_rk 28672 0 stmmac_platform 24576 1 dwmac_rk stmmac 192512 2 stmmac_platform,dwmac_rk rockchipdrm 143360 0 phylink 36864 1 stmmac analogix_dp 49152 1 rockchipdrm dw_mipi_dsi 20480 1 rockchipdrm dw_hdmi 45056 2 dw_hdmi_i2s_audio,rockchipdrm cec 65536 2 dw_hdmi_cec,dw_hdmi snd_soc_rk3328 16384 0 rc_core 57344 5 rc_cec,gpio_ir_recv,cec drm_kms_helper 208896 4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp rtc_rk808 20480 1 lima 49152 0 gpu_sched 36864 1 lima drm 561152 8 gpu_sched,drm_kms_helper,dw_mipi_dsi,lima,rockchipdrm,dw_hdmi,analogix_dp dw_wdt 16384 0 rockchip_thermal 28672 0 drm_panel_orientation_quirks 20480 1 drm syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper snd_soc_rockchip_i2s 16384 0 snd_soc_rockchip_pcm 16384 1 snd_soc_rockchip_i2s snd_soc_rockchip_spdif 16384 0
By all accounts things should just work these days, hope this helps
Nige
On Sat, Nov 9, 2019 at 4:10 AM Benson Muite benson_muite@emailplus.org wrote:
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite benson_muite@emailplus.org ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote:
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Any news? Thanks
Hi Agharta,
Have you tried any other linux distributions (ideally rpm based)?
Regards,
Benson
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Nige,
Thank Your for Your feedback.
I hope your testimony is useful for the realization of a precise guide in Fedora about that.
Many thanks again.
Agharta
Il 09/11/19 12:40, Nigel Sollars ha scritto:
Hi,
So my rock64 is running Arch on a 64G eMMC ( Self built uboot / dtc's ) since there was no guide / install path back then )), most likely you have to dd uboot/boot loader manually try the arch install guide steps to do that.
I would imagine Fedora would be good for SBC;s as they very much keep up with current kernels which is always a pet peeve with .deb based distro's. Anyway here is some info from my unit,
Linux archrock 5.3.8-2-ARCH #1 SMP Sun Nov 3 14:59:20 UTC 2019 aarch64 GNU/Linux
Module Size Used by xt_CT 16384 1 xt_helper 16384 1 nf_conntrack_ftp 28672 1 nf_log_ipv4 16384 46 nf_log_common 16384 1 nf_log_ipv4 ip6table_raw 16384 0 ip6table_mangle 16384 0 ip6table_nat 16384 0 iptable_nat 16384 1 nf_nat 53248 2 ip6table_nat,iptable_nat xt_TCPMSS 16384 2 xt_LOG 20480 46 ipt_REJECT 16384 0 iptable_raw 16384 1 iptable_mangle 16384 0 xt_multiport 20480 0 xt_state 16384 0 xt_limit 16384 47 xt_conntrack 16384 10 nf_conntrack 176128 6 xt_conntrack,nf_nat,xt_state,xt_helper,nf_conntrack_ftp,xt_CT nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack ip6table_filter 16384 1 ip6_tables 28672 4 ip6table_filter,ip6table_raw,ip6table_nat,ip6table_mangle iptable_filter 16384 1 bpfilter 24576 0 snd_soc_hdmi_codec 20480 0 rc_cec 16384 0 dw_hdmi_i2s_audio 16384 0 dw_hdmi_cec 16384 0 realtek 20480 1 snd_soc_audio_graph_card 24576 0 snd_soc_simple_card_utils 28672 1 snd_soc_audio_graph_card gpio_ir_recv 16384 0 dwmac_rk 28672 0 stmmac_platform 24576 1 dwmac_rk stmmac 192512 2 stmmac_platform,dwmac_rk rockchipdrm 143360 0 phylink 36864 1 stmmac analogix_dp 49152 1 rockchipdrm dw_mipi_dsi 20480 1 rockchipdrm dw_hdmi 45056 2 dw_hdmi_i2s_audio,rockchipdrm cec 65536 2 dw_hdmi_cec,dw_hdmi snd_soc_rk3328 16384 0 rc_core 57344 5 rc_cec,gpio_ir_recv,cec drm_kms_helper 208896 4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp rtc_rk808 20480 1 lima 49152 0 gpu_sched 36864 1 lima drm 561152 8 gpu_sched,drm_kms_helper,dw_mipi_dsi,lima,rockchipdrm,dw_hdmi,analogix_dp dw_wdt 16384 0 rockchip_thermal 28672 0 drm_panel_orientation_quirks 20480 1 drm syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper fb_sys_fops 16384 1 drm_kms_helper snd_soc_rockchip_i2s 16384 0 snd_soc_rockchip_pcm 16384 1 snd_soc_rockchip_i2s snd_soc_rockchip_spdif 16384 0
By all accounts things should just work these days, hope this helps
Nige
On Sat, Nov 9, 2019 at 4:10 AM Benson Muite benson_muite@emailplus.org wrote:
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite benson_muite@emailplus.org ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote:
Hi Peter, Thank you for your support.
Currently I'm trying to write fedora to sd card with this command: fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --media=/dev/sdd --resizefs
So, at the end the tool tells me:
= No U-boot will be written. = No console listed for Mystery Board, adding default ttyS0,115200 .
= Installation Complete! Insert into the Mystery Board and boot.
And.....no console. (at 115200) I think that this may be because "= No U-boot will be written." Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in TARGET?
"I still need to update the documentation." Do you already have the link?
"Which wiki page? You mean the one on the pine64 wiki?" This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release
Many thanks for Your patience. Cheers, Agharta
Any news? Thanks
Hi Agharta,
Have you tried any other linux distributions (ideally rpm based)?
Regards,
Benson
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
/"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" /Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )/ /
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Thanks again for Your support.
Best regards,
Agharta
p Il 09/11/19 10:09, Benson Muite ha scritto:
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite <benson_muite@emailplus.org mailto:benson_muite@emailplus.org> ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote: >> Hi Peter, >> Thank you for your support. >> >> Currently I'm trying to write fedora to sd card with this command: >> fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz >> --media=/dev/sdd --resizefs >> >> So, at the end the tool tells me: >> >> = No U-boot will be written. >> = No console listed for Mystery Board, adding default ttyS0,115200 . >> >> = Installation Complete! Insert into the Mystery Board and boot. >> >> And.....no console. (at 115200) >> I think that this may be because "= No U-boot will be written." >> Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in >> TARGET? >> >> "I still need to update the documentation." >> Do you already have the link? >> >> "Which wiki page? You mean the one on the pine64 wiki?" >> This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release >> >> Many thanks for Your patience. >> Cheers, >> Agharta > Any news? > Thanks Hi Agharta, Have you tried any other linux distributions (ideally rpm based)? Regards, Benson > _______________________________________________ > arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
/"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" /Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )/ /
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
p Il 09/11/19 10:09, Benson Muite ha scritto:
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite <benson_muite@emailplus.org mailto:benson_muite@emailplus.org> ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote: >> Hi Peter, >> Thank you for your support. >> >> Currently I'm trying to write fedora to sd card with this command: >> fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz >> --media=/dev/sdd --resizefs >> >> So, at the end the tool tells me: >> >> = No U-boot will be written. >> = No console listed for Mystery Board, adding default ttyS0,115200 . >> >> = Installation Complete! Insert into the Mystery Board and boot. >> >> And.....no console. (at 115200) >> I think that this may be because "= No U-boot will be written." >> Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in >> TARGET? >> >> "I still need to update the documentation." >> Do you already have the link? >> >> "Which wiki page? You mean the one on the pine64 wiki?" >> This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release >> >> Many thanks for Your patience. >> Cheers, >> Agharta > Any news? > Thanks Hi Agharta, Have you tried any other linux distributions (ideally rpm based)? Regards, Benson > _______________________________________________ > arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=_*64*_; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=_*1*__*6384*_; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
/"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" /Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )/ /
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
p Il 09/11/19 10:09, Benson Muite ha scritto:
On 11/9/19 10:44 AM, agharta agharta wrote:
Hi Benson, Yes, i've successfully installed CentOs 7, take a look at this link https://wiki.pine64.org/index.php/ROCK64_Software_Release#CentOS-7_Community...
But CentOs 7 does not support PHP 7x for aarch64: i need to install nextcloud.... and PHP 7+ is required.
So, i've tried CentOs 8 stream too...but no luck....
Fedora 31 does support Rock64, as release notes says....so the question is simple: how to install Fedora 31 on rock64?
Should be simple, in theory.....
Many thanks. Cheers, Agharta
Hi Agharta,
a) If using a Fedora laptop/desktop, have you tried the ARM image installer:
https://fedoraproject.org/wiki/Architectures/ARM/Installation
A number of Pine64 boards are supported, but you might use as a bass to get something for rock64
b) The CentOS7 version you are using seems to use a kernel from Armbian. Maybe something similar (ARMRHEL) is needed for RHEL based distributions? At the moment the contributions seem to be haphazard, and driven by immediate needs rather than a long term vision. Perhaps an ARM roadmap for RHEL would be helpful in organizing development?
c) I have complied PHP 7 from source using GNU compilers. This was straight forward, so might be the way to go if you only need Nextcloud and do not need to many PHP extensions. When you need to update, just copy over the data directory in your Nextcloud installation.
Benson
Il sab 9 nov 2019, 07:47 Benson Muite <benson_muite@emailplus.org mailto:benson_muite@emailplus.org> ha scritto:
On 11/7/19 11:53 AM, agharta agharta wrote: >> Hi Peter, >> Thank you for your support. >> >> Currently I'm trying to write fedora to sd card with this command: >> fedora-arm-image-installer --addconsole --image=Fedora-Minimal-31-1.9.aarch64.raw.xz >> --media=/dev/sdd --resizefs >> >> So, at the end the tool tells me: >> >> = No U-boot will be written. >> = No console listed for Mystery Board, adding default ttyS0,115200 . >> >> = Installation Complete! Insert into the Mystery Board and boot. >> >> And.....no console. (at 115200) >> I think that this may be because "= No U-boot will be written." >> Any way? should I pass a --target=TARGET to commands? If yes, what should I insert in >> TARGET? >> >> "I still need to update the documentation." >> Do you already have the link? >> >> "Which wiki page? You mean the one on the pine64 wiki?" >> This one: https://wiki.pine64.org/index.php/ROCK64_Software_Release >> >> Many thanks for Your patience. >> Cheers, >> Agharta > Any news? > Thanks Hi Agharta, Have you tried any other linux distributions (ideally rpm based)? Regards, Benson > _______________________________________________ > arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> > To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org _______________________________________________ arm mailing list -- arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> To unsubscribe send an email to arm-leave@lists.fedoraproject.org <mailto:arm-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=_*64*_; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=_*1*__*6384*_; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
/"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" /Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )/ /
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded and 'what' to write into sdcard.
Should I write sidbloader.img or not? How are sidbloader.img and u-boot.itb builded? Does them contains all required stuffs?
Following Your link about ARMv8, i see at row 3:
|dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5|
But spl.img is not available in usr/share/uboot/ in my sdcard (Fedora 31 minimal).
So, I still searching over the web.
Meanwhile, did You known that standard serial console speed in Rock64 SPI flash is 1,500,000 baudrate? 1,500,000!! OMG, connecting to see spi boot at 115200 will never work! I have spent hours about it....hope it will be helpful for other users.
See these links:
https://forum.pine64.org/showthread.php?tid=5029
https://gist.github.com/tstellanova/b485fa84acf70889fb4e89c4af505440
Again, seems that not all usb-serial-console-adapters can works at 1,500,000 baudrate. FYI my cheap converter can't...so...i can't see spi boot.....I'm not luky with that board.
Thank You again.
Cheers,
Agharta
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=_*64*_; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=_*1*__*6384*_; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
/"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" /Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )/ /
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek= *64*; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=*1* *6384*; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro. On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
*"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" *Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
Serial console / uart setup,
1500000 8n1
Nige
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Many Thanks!
Here my minicom output
CTRL-A Z for help | 1500000 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline | ttyUSB0
Thanks again,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
I can tell you I have disabled the SPI Flash ( 128mb iirc ) and give SPI control back to SPIDEV as I am using this board in conjunction with a 915Mhz LoraWan Concentrator / Gateway board IC980a
Nige
On Wed, Nov 13, 2019 at 8:00 AM agharta82@gmail.com agharta82@gmail.com wrote:
Many Thanks!
Here my minicom output
CTRL-A Z for help | 1500000 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline | ttyUSB0
Thanks again,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
I've found this thread:
http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
I'm seriously thinking that the problem is how u-boot images are created.
I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder).
The content is here:
idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
The rock64 content is different:
idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
Missing files: spl_sd.img, spl_spi.img
I think that the uboot build for rock64 was made only for eMMC module, not for sd card.
How to known how uboot build was made?
Where are the build sources?
Many thanks again,
Agharta
Il 13/11/19 16:41, agharta82@gmail.com ha scritto:
I've found this thread:
http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Could you not grab the uboot and what nots from Ayufan,
https://github.com/ayufan-rock64/linux-u-boot
( perhaps build and test ), my original build ( current ) used this method..
Nige
On Thu, Nov 14, 2019 at 8:51 AM agharta82@gmail.com agharta82@gmail.com wrote:
I'm seriously thinking that the problem is how u-boot images are created.
I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder).
The content is here:
idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
The rock64 content is different:
idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
Missing files: spl_sd.img, spl_spi.img
I think that the uboot build for rock64 was made only for eMMC module, not for sd card.
How to known how uboot build was made?
Where are the build sources?
Many thanks again,
Agharta
Il 13/11/19 16:41, agharta82@gmail.com ha scritto:
I've found this thread:
http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Interesting thing.
Following Your idea, i've dowloaded the spi boot https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
After decompressing it, if I do a 'cfdisk u-boot-flash-spi-rock64.img' I can see sectors where images starts:
So, first boot image starts at sector 64, second at sector at 8192. Nice.
I need to investigate over it, to find a solution.
Thanks,
Agharta
Il 14/11/19 22:42, Nigel Sollars ha scritto:
Could you not grab the uboot and what nots from Ayufan,
https://github.com/ayufan-rock64/linux-u-boot
( perhaps build and test ), my original build ( current ) used this method..
Nige
On Thu, Nov 14, 2019 at 8:51 AM agharta82@gmail.com agharta82@gmail.com wrote:
I'm seriously thinking that the problem is how u-boot images are created.
I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder).
The content is here:
idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
The rock64 content is different:
idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
Missing files: spl_sd.img, spl_spi.img
I think that the uboot build for rock64 was made only for eMMC module, not for sd card.
How to known how uboot build was made?
Where are the build sources?
Many thanks again,
Agharta
Il 13/11/19 16:41, agharta82@gmail.com ha scritto:
I've found this thread:
http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
OH GUYS! WHAT A BEAUTIFUL DAY!!!!!
Finally I've found the solution!
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well:
File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8
I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required.
References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Next, download fedora aarch64 31 minimal xz image and:
arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff)
Insert sd into Rock64 and power on!
Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!!
Wait a bit (by default search for ipv6 ip).
Connect Keyboard and follow on screen setup to set root password, Timezone etc...
AT THE END ALL WORKS!!!!!
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.
Really guys, I am very very very happy!
Have a fantastic day!!!
Agharta
Il 15/11/19 09:18, agharta82@gmail.com ha scritto:
Interesting thing.
Following Your idea, i've dowloaded the spi boot https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
After decompressing it, if I do a 'cfdisk u-boot-flash-spi-rock64.img' I can see sectors where images starts:
So, first boot image starts at sector 64, second at sector at 8192. Nice.
I need to investigate over it, to find a solution.
Thanks,
Agharta
Il 14/11/19 22:42, Nigel Sollars ha scritto:
Could you not grab the uboot and what nots from Ayufan,
https://github.com/ayufan-rock64/linux-u-boot
( perhaps build and test ), my original build ( current ) used this method..
Nige
On Thu, Nov 14, 2019 at 8:51 AMagharta82@gmail.com agharta82@gmail.com wrote:
I'm seriously thinking that the problem is how u-boot images are created.
I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder).
The content is here:
idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
The rock64 content is different:
idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
Missing files: spl_sd.img, spl_spi.img
I think that the uboot build for rock64 was made only for eMMC module, not for sd card.
How to known how uboot build was made?
Where are the build sources?
Many thanks again,
Agharta
Il 13/11/19 16:41,agharta82@gmail.com ha scritto:
I've found this thread:
http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AMagharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta agharta agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM,agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yes http://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at:
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here:
https://pagure.io/arm-image-installer
https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM,agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated at https://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list --arm@lists.fedoraproject.org To unsubscribe send an email toarm-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com agharta82@gmail.com wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!!
Finally I've found the solution!
So,* first for all SPI flash should be ERASED*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well:
File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8
I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required.
References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Next, download fedora aarch64 31 minimal xz image and:
arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff)
Insert sd into Rock64 and power on!
Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!!
Wait a bit (by default search for ipv6 ip).
Connect Keyboard and follow on screen setup to set root password, Timezone etc...
AT THE END ALL WORKS!!!!!
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.
Really guys, I am very very very happy!
Have a fantastic day!!!
Agharta
Il 15/11/19 09:18, agharta82@gmail.com ha scritto:
Interesting thing.
Following Your idea, i've dowloaded the spi boot https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
After decompressing it, if I do a 'cfdisk u-boot-flash-spi-rock64.img' I can see sectors where images starts:
So, first boot image starts at sector 64, second at sector at 8192. Nice.
I need to investigate over it, to find a solution.
Thanks,
Agharta
Il 14/11/19 22:42, Nigel Sollars ha scritto:
Could you not grab the uboot and what nots from Ayufan, https://github.com/ayufan-rock64/linux-u-boot
( perhaps build and test ), my original build ( current ) used this method..
Nige
On Thu, Nov 14, 2019 at 8:51 AM agharta82@gmail.com agharta82@gmail.com agharta82@gmail.com wrote:
I'm seriously thinking that the problem is how u-boot images are created.
I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder).
The content is here:
idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
The rock64 content is different:
idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb
Missing files: spl_sd.img, spl_spi.img
I think that the uboot build for rock64 was made only for eMMC module, not for sd card.
How to known how uboot build was made?
Where are the build sources?
Many thanks again,
Agharta
Il 13/11/19 16:41, agharta82@gmail.com ha scritto:
I've found this thread: http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td38456...
Seems seek value for dd are correct.
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
The question is if idbloader was built dorm mmc or for sdcard too....
Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot.
Regards,
Agharta
Il 13/11/19 13:58, Nigel Sollars ha scritto:
Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house.
Nige
On Wed, Nov 13, 2019 at 7:55 AM agharta82@gmail.comagharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
Many thanks Nigel, but nope.
This is the output:
C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� U� �WE���i���+� � �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U��
Not good....
Benson, i would contribute to Pagure..... if something works!
Actually I've found boot images of Rock64 inside fedora sdcard but I can't made them working.
Nigel, do You have a Rock64 sbc? Does Your serial console works during SPI boot?
Many thanks to both.
Cheers,
Agharta
Il 13/11/19 04:49, Benson Muite ha scritto:
On 11/13/19 2:29 AM, Nigel Sollars wrote:
Serial console / uart setup,
1500000 8n1
Thanks Nigel.
Nige
Agharta, Please let us know if it works, and if so can you contribute to the Pagure repository?
On Tue, Nov 12, 2019 at 2:08 PM agharta aghartaagharta82@gmail.com agharta82@gmail.com wrote:
Hi Benson,
No, unfortunately seems not working.
I've tried with seek (16348, 64, 512, etc). No luck.
I think the problem is related how to boot images are builded.
Should I write sidbloader.img?
Following Your link about ARMv8, i see at row 3:
dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; sync; sleep 5
But spl.img is not available in usr/share/uboot/ in my sdcard.
So, I still searching over web.
Meanwhile, did You known that serial console speed of
Il 12/11/19 07:46, Benson Muite ha scritto:
Hi Agharta,
Thanks for the update. Responses below. Hope you are successful.
Benson
On 11/11/19 7:09 PM, agharta82@gmail.com wrote:
Hi Benson,
You helped me a lot!!!
Following Your suggestion, I've investigate over $TARGET and $MEDIA.
After writing sdcard with pine64-lts, inside usr/share/uboot/ (of sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many other sbc not listed into arm-image-installer folder (/usr/share/arm-image-installer/boards.d/)!!!!!!!!
So, rock64 is really supported by fedora (31, minimal, aarch64)!!!
Another interesting thing: if I create a file called rock64-rk3328 into my /usr/share/arm-image-installer/boards.d/ and set --target=rock64-rk3328, arm-image-installer executes IT!
So, next step: I've copied pine64-lts into rock64-rk3328.
One question: rock64-rk3328 folder does not have sunxi-spl.bin, but a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin?
Following this link seems yeshttp://opensource.rock-chips.com/wiki_Boot_option
Thanks, this seems helpful.
Seems needed to add some extra stuffs too (seek):
dd if=idbloader.img of=sdb seek=64 dd if=u-boot.itb of=sdb seek=16384
So, script become as follow:
# write uboot echo "= Writing idbloader.img for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k seek=64; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=16384; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
Looks similar to what is at: https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8
https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7
Might need to change seek value. I do not have that board, so cannot try this out, but hope it works. If it does work, can you contribute the script back? I believe additions are also needed here: https://pagure.io/arm-image-installer https://pagure.io/arm-image-installer/blob/master/f/boards.d
Tomorrow I'll try!
Thanks a lot for Your support.
Best regards,
Agharta
Il 11/11/19 16:21, Benson Muite ha scritto:
Hi Agharta,
I used an earlier Fedora release on Banana pro (after first using Fedora combined with a different kernel). It worked ok, but took a bit of time for the Arm image to support Banana pro.
On 11/11/19 4:04 PM, agharta82@gmail.com wrote:
Hi Benson
a) Yes, but I can't specify Rock64 as --target parameter.
"A number of Pine64 boards are supported, but you might use as a bass to get something for rock64" Can You explain me how? Is it possibile without manual recompilation, etc...? (see why in b) and c) )
There was a message earlier on the list that support had been added for rock 64. Thus you might be able to take the configuration for Pine64 and modify that for Rock 64, though can also wait. After installing the arm image installer, as indicated athttps://fedoraproject.org/wiki/Architectures/ARM/Installation in a terminal I can type
$ls /usr/share/arm-image-installer/boards.d/
to get a listing of supported boards. Typing
$more /usr/share/arm-image-installer/boards.d/pinebook
gives settings for Pinebook, which are
# write uboot echo "= Writing sunxi-spl.bin for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k seek=1; sync echo "= Writing u-boot FIT image for $TARGET ...." dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k seek=5; sync; sleep 5 # set console for allwinner SYSCON=ttyS0,115200
The commands for pine_h64, pine64_plus and pine64-lts are the same, so you might try these for your Rock 64.
b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel.
Ok.
c) Yes, is possibile, but i still prefer a community delivered rpm (and maintained).
Noted. Thanks for using and reporting where work is still required. Sorry cannot be much more help at present.
Thanks again for Your support.
Best regards,
Agharta
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Already to 5.4.0?!?! WO-HA!
Now I'm playing with rock64, some feedbacks:
* USB3 port seems not working. * I have some problem with df-update and " The operation would result in removing the following protected packages: systemd-udev"....still investigate.
I'll keep you up-to-date.
Cheers,
Agharta
Il 27/11/19 15:00, Nigel Sollars ha scritto:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution! So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xz Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328 # write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!! Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package. Really guys, I am very very very happy! Have a fantastic day!!! Agharta Il 15/11/19 09:18, agharta82@gmail.com <mailto:agharta82@gmail.com> ha scritto:Interesting thing. Following Your idea, i've dowloaded the spi boot https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-flash-spi-rock64.img.xz After decompressing it, if I do a 'cfdisk u-boot-flash-spi-rock64.img' I can see sectors where images starts: So, first boot image starts at sector 64, second at sector at 8192. Nice. I need to investigate over it, to find a solution. Thanks, Agharta Il 14/11/19 22:42, Nigel Sollars ha scritto:Could you not grab the uboot and what nots from Ayufan, https://github.com/ayufan-rock64/linux-u-boot ( perhaps build and test ), my original build ( current ) used this method.. Nige On Thu, Nov 14, 2019 at 8:51 AMagharta82@gmail.com <mailto:agharta82@gmail.com> <agharta82@gmail.com> <mailto:agharta82@gmail.com> wrote:I'm seriously thinking that the problem is how u-boot images are created. I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder). The content is here: idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb The rock64 content is different: idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb Missing files: spl_sd.img, spl_spi.img I think that the uboot build for rock64 was made only for eMMC module, not for sd card. How to known how uboot build was made? Where are the build sources? Many thanks again, Agharta Il 13/11/19 16:41,agharta82@gmail.com <mailto:agharta82@gmail.com> ha scritto:I've found this thread: http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td384563.html Seems seek value for dd are correct. sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 The question is if idbloader was built dorm mmc or for sdcard too.... Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot. Regards, Agharta Il 13/11/19 13:58, Nigel Sollars ha scritto:Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house. Nige On Wed, Nov 13, 2019 at 7:55 AMagharta82@gmail.com <mailto:agharta82@gmail.com> <agharta82@gmail.com> <mailto:agharta82@gmail.com> wrote:> Hi all, > > Many thanks Nigel, but nope. > > This is the output: > > C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U > ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ > Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� > U� �WE���i���+� � > �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U�� > > > Not good.... > > Benson, i would contribute to Pagure..... if something works! > > Actually I've found boot images of Rock64 inside fedora sdcard but I > can't made them working. > > Nigel, do You have a Rock64 sbc? Does Your serial console works > during SPI boot? > > > Many thanks to both. > > Cheers, > > Agharta > > > > Il 13/11/19 04:49, Benson Muite ha scritto: > > On 11/13/19 2:29 AM, Nigel Sollars wrote: > > Serial console / uart setup, > > 1500000 8n1 > > Thanks Nigel. > > > Nige > > Agharta, Please let us know if it works, and if so can you > contribute to the Pagure repository? > > > On Tue, Nov 12, 2019 at 2:08 PM agharta agharta > agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson, > > No, unfortunately seems not working. > > I've tried with seek (16348, 64, 512, etc). No luck. > > I think the problem is related how to boot images are builded. > > Should I write sidbloader.img? > > Following Your link about ARMv8, i see at row 3: > > dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; > sync; sleep 5 > > But spl.img is not available in usr/share/uboot/ in my sdcard. > > So, I still searching over web. > > Meanwhile, did You known that serial console speed of > > > > Il 12/11/19 07:46, Benson Muite ha scritto: > > Hi Agharta, > > Thanks for the update. Responses below. Hope you are successful. > > Benson > > On 11/11/19 7:09 PM,agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson, > > You helped me a lot!!! > > Following Your suggestion, I've investigate over $TARGET and $MEDIA. > > After writing sdcard with pine64-lts, inside usr/share/uboot/ (of > sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many > other sbc not listed into arm-image-installer folder > (/usr/share/arm-image-installer/boards.d/)!!!!!!!! > > So, rock64 is really supported by fedora (31, minimal, aarch64)!!! > > Another interesting thing: if I create a file called rock64-rk3328 > into my /usr/share/arm-image-installer/boards.d/ and set > --target=rock64-rk3328, arm-image-installer executes IT! > > So, next step: I've copied pine64-lts into rock64-rk3328. > > One question: rock64-rk3328 folder does not have sunxi-spl.bin, but > a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin? > > Following this link seems yes > http://opensource.rock-chips.com/wiki_Boot_option > > Thanks, this seems helpful. > > Seems needed to add some extra stuffs too (seek): > > dd if=idbloader.img of=sdb seek=64 > dd if=u-boot.itb of=sdb seek=16384 > > So, script become as follow: > > # write uboot > echo "= Writing idbloader.img for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k > seek=64; sync > echo "= Writing u-boot FIT image for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k > seek=16384; sync; sleep 5 > # set console for allwinner > SYSCON=ttyS0,115200 > > > Looks similar to what is at: > > https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8 > > > https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7 > > > Might need to change seek value. I do not have that board, so cannot > try this out, but hope it works. If it does work, can you contribute > the script back? I believe additions are also needed here: > > https://pagure.io/arm-image-installer > > https://pagure.io/arm-image-installer/blob/master/f/boards.d > > Tomorrow I'll try! > > > Thanks a lot for Your support. > > Best regards, > > Agharta > > > > Il 11/11/19 16:21, Benson Muite ha scritto: > > Hi Agharta, > > I used an earlier Fedora release on Banana pro (after first using > Fedora combined with a different kernel). It worked ok, but took a > bit of time for the Arm image to support Banana pro. > > On 11/11/19 4:04 PM,agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson > > a) Yes, but I can't specify Rock64 as --target parameter. > > "A number of Pine64 boards are supported, but you might use as a > bass to get something for rock64" Can You explain me how? Is it > possibile without manual recompilation, etc...? (see why in b) and c) ) > > There was a message earlier on the list that support had been added > for rock 64. Thus you might be able to take the configuration for > Pine64 and modify that for Rock 64, though can also wait. After > installing the arm image installer, as indicated at > https://fedoraproject.org/wiki/Architectures/ARM/Installation in a > terminal I can type > > $ls /usr/share/arm-image-installer/boards.d/ > > to get a listing of supported boards. Typing > > $more /usr/share/arm-image-installer/boards.d/pinebook > > gives settings for Pinebook, which are > > # write uboot > echo "= Writing sunxi-spl.bin for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k > seek=1; sync > echo "= Writing u-boot FIT image for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k > seek=5; sync; sleep 5 > # set console for allwinner > SYSCON=ttyS0,115200 > > The commands for pine_h64, pine64_plus and pine64-lts are the same, > so you might try these for your Rock 64. > > b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel. > > Ok. > > c) Yes, is possibile, but i still prefer a community delivered rpm > (and maintained). > > Noted. Thanks for using and reporting where work is still required. > Sorry cannot be much more help at present. > > Thanks again for Your support. > > Best regards, > > Agharta > > > > _______________________________________________ > arm mailing list --arm@lists.fedoraproject.org mailto:arm@lists.fedoraproject.org > To unsubscribe send an email toarm-leave@lists.fedoraproject.org mailto:arm-leave@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org > > >
-- “Science is a differential equation. Religion is a boundary condition.” Alan Turing
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!
Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xz Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328 # write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!
Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.
Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
Really guys, I am very very very happy! Have a fantastic day!!! Agharta Il 15/11/19 09:18, agharta82@gmail.com <mailto:agharta82@gmail.com> ha scritto:Interesting thing. Following Your idea, i've dowloaded the spi boot https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-flash-spi-rock64.img.xz After decompressing it, if I do a 'cfdisk u-boot-flash-spi-rock64.img' I can see sectors where images starts: So, first boot image starts at sector 64, second at sector at 8192. Nice. I need to investigate over it, to find a solution. Thanks, Agharta Il 14/11/19 22:42, Nigel Sollars ha scritto:Could you not grab the uboot and what nots from Ayufan, https://github.com/ayufan-rock64/linux-u-boot ( perhaps build and test ), my original build ( current ) used this method.. Nige On Thu, Nov 14, 2019 at 8:51 AMagharta82@gmail.com <mailto:agharta82@gmail.com> <agharta82@gmail.com> <mailto:agharta82@gmail.com> wrote:I'm seriously thinking that the problem is how u-boot images are created. I've searched inside usr/share/uboot/rockpro64-rk3399/ of sd-card, same chip manufacturer. FYI all series of 3399 have same content (rock960, rock-pi-4, roc, puma, orangepi, etc.. see usr/share/uboot filder). The content is here: idbloader.img spl_sd.img spl_spi.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb The rock64 content is different: idbloader.img u-boot-dtb.img u-boot-spl.bin u-boot.bin u-boot.dtb u-boot.img u-boot.itb Missing files: spl_sd.img, spl_spi.img I think that the uboot build for rock64 was made only for eMMC module, not for sd card. How to known how uboot build was made? Where are the build sources? Many thanks again, Agharta Il 13/11/19 16:41,agharta82@gmail.com <mailto:agharta82@gmail.com> ha scritto:I've found this thread: http://u-boot.10912.n7.nabble.com/help-with-serial-on-the-rockchip64-td384563.html Seems seek value for dd are correct. sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 The question is if idbloader was built dorm mmc or for sdcard too.... Mmm.... as soon as I've resolved serial spi boot problem I think I can tell You why Fedora does not boot. Regards, Agharta Il 13/11/19 13:58, Nigel Sollars ha scritto:Yes the output I gave you in my first post is a Rock64 4GB with a 64GB eMMC running Arch Linux. I can get you all the info you need when I get back to the house. Nige On Wed, Nov 13, 2019 at 7:55 AMagharta82@gmail.com <mailto:agharta82@gmail.com> <agharta82@gmail.com> <mailto:agharta82@gmail.com> wrote:> Hi all, > > Many thanks Nigel, but nope. > > This is the output: > > C`Ek�kh[j�C4Mkj_C6�n�4��Vj-[mC`�d[�6��K��RV%���<U�5TU��]JU�BVU��꭫U�U���U�U > ]��UեUQR����(�(��U*U�U��L�\� �ꨊ婪����ժ�)U�UQQ > Q�ժw�UUQQQ���U�(J�*�(�U*�e�E��� > U� �WE���i���+� � > �UU(�UU�i+�*��*���Uj�*�E�*�J���BZ���U��.�ծ���������(���U��UTQQ���i-���U��UTQQ�%��(��u,�U�� > > > Not good.... > > Benson, i would contribute to Pagure..... if something works! > > Actually I've found boot images of Rock64 inside fedora sdcard but I > can't made them working. > > Nigel, do You have a Rock64 sbc? Does Your serial console works > during SPI boot? > > > Many thanks to both. > > Cheers, > > Agharta > > > > Il 13/11/19 04:49, Benson Muite ha scritto: > > On 11/13/19 2:29 AM, Nigel Sollars wrote: > > Serial console / uart setup, > > 1500000 8n1 > > Thanks Nigel. > > > Nige > > Agharta, Please let us know if it works, and if so can you > contribute to the Pagure repository? > > > On Tue, Nov 12, 2019 at 2:08 PM agharta agharta > agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson, > > No, unfortunately seems not working. > > I've tried with seek (16348, 64, 512, etc). No luck. > > I think the problem is related how to boot images are builded. > > Should I write sidbloader.img? > > Following Your link about ARMv8, i see at row 3: > > dd if=$PREFIX/usr/share/uboot/$TARGET/spl.img of=$MEDIA seek=64; > sync; sleep 5 > > But spl.img is not available in usr/share/uboot/ in my sdcard. > > So, I still searching over web. > > Meanwhile, did You known that serial console speed of > > > > Il 12/11/19 07:46, Benson Muite ha scritto: > > Hi Agharta, > > Thanks for the update. Responses below. Hope you are successful. > > Benson > > On 11/11/19 7:09 PM,agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson, > > You helped me a lot!!! > > Following Your suggestion, I've investigate over $TARGET and $MEDIA. > > After writing sdcard with pine64-lts, inside usr/share/uboot/ (of > sdcard) i can see rock64-rk3328 (my sbc), rockpro64-rk3399 and many > other sbc not listed into arm-image-installer folder > (/usr/share/arm-image-installer/boards.d/)!!!!!!!! > > So, rock64 is really supported by fedora (31, minimal, aarch64)!!! > > Another interesting thing: if I create a file called rock64-rk3328 > into my /usr/share/arm-image-installer/boards.d/ and set > --target=rock64-rk3328, arm-image-installer executes IT! > > So, next step: I've copied pine64-lts into rock64-rk3328. > > One question: rock64-rk3328 folder does not have sunxi-spl.bin, but > a file called idbloader.img. Should I 'dd' it insead of sunxi-spl.bin? > > Following this link seems yes > http://opensource.rock-chips.com/wiki_Boot_option > > Thanks, this seems helpful. > > Seems needed to add some extra stuffs too (seek): > > dd if=idbloader.img of=sdb seek=64 > dd if=u-boot.itb of=sdb seek=16384 > > So, script become as follow: > > # write uboot > echo "= Writing idbloader.img for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/sidbloader.img of=$MEDIA bs=8k > seek=64; sync > echo "= Writing u-boot FIT image for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k > seek=16384; sync; sleep 5 > # set console for allwinner > SYSCON=ttyS0,115200 > > > Looks similar to what is at: > > https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv8 > > > https://pagure.io/arm-image-installer/blob/master/f/socs.d/Rockchips-ARMv7 > > > Might need to change seek value. I do not have that board, so cannot > try this out, but hope it works. If it does work, can you contribute > the script back? I believe additions are also needed here: > > https://pagure.io/arm-image-installer > > https://pagure.io/arm-image-installer/blob/master/f/boards.d > > Tomorrow I'll try! > > > Thanks a lot for Your support. > > Best regards, > > Agharta > > > > Il 11/11/19 16:21, Benson Muite ha scritto: > > Hi Agharta, > > I used an earlier Fedora release on Banana pro (after first using > Fedora combined with a different kernel). It worked ok, but took a > bit of time for the Arm image to support Banana pro. > > On 11/11/19 4:04 PM,agharta82@gmail.com mailto:agharta82@gmail.com wrote: > > Hi Benson > > a) Yes, but I can't specify Rock64 as --target parameter. > > "A number of Pine64 boards are supported, but you might use as a > bass to get something for rock64" Can You explain me how? Is it > possibile without manual recompilation, etc...? (see why in b) and c) ) > > There was a message earlier on the list that support had been added > for rock 64. Thus you might be able to take the configuration for > Pine64 and modify that for Rock 64, though can also wait. After > installing the arm image installer, as indicated at > https://fedoraproject.org/wiki/Architectures/ARM/Installation in a > terminal I can type > > $ls /usr/share/arm-image-installer/boards.d/ > > to get a listing of supported boards. Typing > > $more /usr/share/arm-image-installer/boards.d/pinebook > > gives settings for Pinebook, which are > > # write uboot > echo "= Writing sunxi-spl.bin for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/sunxi-spl.bin of=$MEDIA bs=8k > seek=1; sync > echo "= Writing u-boot FIT image for $TARGET ...." > dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA bs=8k > seek=5; sync; sleep 5 > # set console for allwinner > SYSCON=ttyS0,115200 > > The commands for pine_h64, pine64_plus and pine64-lts are the same, > so you might try these for your Rock 64. > > b) Yes, an Armbian kernel....but I'd like to use a 'standard' kernel. > > Ok. > > c) Yes, is possibile, but i still prefer a community delivered rpm > (and maintained). > > Noted. Thanks for using and reporting where work is still required. > Sorry cannot be much more help at present. > > Thanks again for Your support. > > Best regards, > > Agharta > > > > _______________________________________________ > arm mailing list --arm@lists.fedoraproject.org mailto:arm@lists.fedoraproject.org > To unsubscribe send an email toarm-leave@lists.fedoraproject.org mailto:arm-leave@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org > > >
-- “Science is a differential equation. Religion is a boundary condition.” Alan Turing
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xz
It may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
Hi Benson,
I'm really new in Pagure. Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xzIt may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xzIt may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xzIt may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
Hi Benson,
see below
Il 28/11/19 13:19, Benson Muite ha scritto:
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Ok, I have to try it. Thanks for your feedback.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Price is ok, board seems too.....but there are some problems:
* in debian-like images the network hangs if rebooted. Performance is very good. https://wiki.pine64.org/index.php/ROCK64_Software_Release#Linux_Image_Releas... * in fedora 31 minimal have bad performance (ssh & console for example . I need to do a cpu/sd/memory test in both OSes to create a valid comparison) * in debian-like images, if I connect a device to usb3 port it hangs after a bit....I have not yet figured out if it is a hardware or software problem....investigation is needed. In any case a ticket is already open https://github.com/ayufan-rock64/linux-build/issues/112 * in fedora usb3 does not work..... * My final target is to boot Rock64 via sd-card and connect 2 HDD in raid-1 mode through usb 3 (and relative hub) and store Nextcloud data into raid-1 fs. * My oniric target is to use that board with IP-cameras and Zoneminder too....but for now I would be satisfied with the previous point.
Actually I am getting familiar with fedora 31 aarch64: it is quite different form x64 version, dnf update gives me errors about protected packages (......).
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Seek values provided by socs.d/Rockchips-ARMv8 seems not working for me, but beacuse I can't see serial console I don't know why....
In any case spl.img file is not availabe in fedora .xz build.
I have used the default seek values form main Rockchip guide: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
Actually Fedora can run into Rock64 IF AND ONLY IF spi boot is erased. I think that an spi-compatibe image should be added in fedora (as debian do). If yes, boot could be executed directy from usb disk (and raid-1 disks I hope).
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you for your patience, I'll keep you informed about problems & resolutions.
My best cheers,
Agharta
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xzIt may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
Hi all,
About USB3, seem that Fedora w/kernel 5.3.7-301 see usb 3 port as usb 1.1 !!!!
See below, the first BUS row is very clear.
lsusb -vvv
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ohci_hcd
iProduct 2 Generic Platform OHCI controller
iSerial 1 ff5d0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0012
No power switching (usb 1.0)
No overcurrent protection
bPwrOn2PwrGood 2 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 ff5c0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 dwc2_hsotg
iProduct 2 DWC OTG Controller
iSerial 1 ff580000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0000
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Oblivious, a "modprobe xhci_hcd" does not fix the problem.
Any ideas?
Nigel, your Arch kernel does support Rock64's USB3 well? Have you tried a heavy write on it? If yes, does it hangs?
Best regards,
Agharta
Il 28/11/19 13:58, agharta82@gmail.com ha scritto:
Hi Benson,
see below
Il 28/11/19 13:19, Benson Muite ha scritto:
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Ok, I have to try it. Thanks for your feedback.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Price is ok, board seems too.....but there are some problems:
- in debian-like images the network hangs if rebooted. Performance is very good. https://wiki.pine64.org/index.php/ROCK64_Software_Release#Linux_Image_Releas...
- in fedora 31 minimal have bad performance (ssh & console for example . I need to do a cpu/sd/memory test in both OSes to create a valid comparison)
- in debian-like images, if I connect a device to usb3 port it hangs after a bit....I have not yet figured out if it is a hardware or software problem....investigation is needed. In any case a ticket is already open https://github.com/ayufan-rock64/linux-build/issues/112
- in fedora usb3 does not work.....
- My final target is to boot Rock64 via sd-card and connect 2 HDD in raid-1 mode through usb 3 (and relative hub) and store Nextcloud data into raid-1 fs.
- My oniric target is to use that board with IP-cameras and Zoneminder too....but for now I would be satisfied with the previous point.
Actually I am getting familiar with fedora 31 aarch64: it is quite different form x64 version, dnf update gives me errors about protected packages (......).
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Seek values provided by socs.d/Rockchips-ARMv8 seems not working for me, but beacuse I can't see serial console I don't know why....
In any case spl.img file is not availabe in fedora .xz build.
I have used the default seek values form main Rockchip guide: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
Actually Fedora can run into Rock64 IF AND ONLY IF spi boot is erased. I think that an spi-compatibe image should be added in fedora (as debian do). If yes, boot could be executed directy from usb disk (and raid-1 disks I hope).
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you for your patience, I'll keep you informed about problems & resolutions.
My best cheers,
Agharta
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com mailto:agharta82@gmail.com <agharta82@gmail.com mailto:agharta82@gmail.com> wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!! Finally I've found the solution!Excellent
So,*_first for all SPI flash should be ERASED_*: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rockchip-ayufan-1065-g95f6152134/u-boot-erase-spi-rock64.img.xzIt may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well: File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8 I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required. References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card Next, download fedora aarch64 31 minimal xz image and: arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff) Insert sd into Rock64 and power on! Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!! Wait a bit (by default search for ipv6 ip). Connect Keyboard and follow on screen setup to set root password, Timezone etc... AT THE END ALL WORKS!!!!!Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy! Have a fantastic day!!! Agharta
I have a usb3 to sata drive, il run some speed tests and get the information for you using this later kernel.
Il dig up what the dtc/dtb used is also ( most likely itle be pretty default )
Nige
On Thu, Nov 28, 2019 at 9:51 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
About USB3, seem that Fedora w/kernel 5.3.7-301 see usb 3 port as usb 1.1 !!!!
See below, the first BUS row is very clear.
lsusb -vvv
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ohci_hcd
iProduct 2 Generic Platform OHCI controller
iSerial 1 ff5d0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0012
No power switching (usb 1.0) No overcurrent protectionbPwrOn2PwrGood 2 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 ff5c0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching Per-port overcurrent protectionbPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 dwc2_hsotg
iProduct 2 DWC OTG Controller
iSerial 1 ff580000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching Per-port overcurrent protection TT think time 8 FS bitsbPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0000
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Oblivious, a "modprobe xhci_hcd" does not fix the problem.
Any ideas?
Nigel, your Arch kernel does support Rock64's USB3 well? Have you tried a heavy write on it? If yes, does it hangs?
Best regards,
Agharta
Il 28/11/19 13:58, agharta82@gmail.com ha scritto:
Hi Benson,
see below
Il 28/11/19 13:19, Benson Muite ha scritto:
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Ok, I have to try it. Thanks for your feedback.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Price is ok, board seems too.....but there are some problems:
in debian-like images the network hangs if rebooted. Performance is very good. https://wiki.pine64.org/index.php/ROCK64_Software_Release#Linux_Image_Releas... in fedora 31 minimal have bad performance (ssh & console for example . I need to do a cpu/sd/memory test in both OSes to create a valid comparison) in debian-like images, if I connect a device to usb3 port it hangs after a bit....I have not yet figured out if it is a hardware or software problem....investigation is needed. In any case a ticket is already open https://github.com/ayufan-rock64/linux-build/issues/112 in fedora usb3 does not work..... My final target is to boot Rock64 via sd-card and connect 2 HDD in raid-1 mode through usb 3 (and relative hub) and store Nextcloud data into raid-1 fs. My oniric target is to use that board with IP-cameras and Zoneminder too....but for now I would be satisfied with the previous point.
Actually I am getting familiar with fedora 31 aarch64: it is quite different form x64 version, dnf update gives me errors about protected packages (......).
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Seek values provided by socs.d/Rockchips-ARMv8 seems not working for me, but beacuse I can't see serial console I don't know why....
In any case spl.img file is not availabe in fedora .xz build.
I have used the default seek values form main Rockchip guide: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
Actually Fedora can run into Rock64 IF AND ONLY IF spi boot is erased. I think that an spi-compatibe image should be added in fedora (as debian do). If yes, boot could be executed directy from usb disk (and raid-1 disks I hope).
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you for your patience, I'll keep you informed about problems & resolutions.
My best cheers,
Agharta
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com agharta82@gmail.com wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!!
Finally I've found the solution!
Excellent
So, first for all SPI flash should be ERASED: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
It may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well:
File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8
I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required.
References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Next, download fedora aarch64 31 minimal xz image and:
arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff)
Insert sd into Rock64 and power on!
Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!!
Wait a bit (by default search for ipv6 ip).
Connect Keyboard and follow on screen setup to set root password, Timezone etc...
AT THE END ALL WORKS!!!!!
Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.
Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy!
Have a fantastic day!!!
Agharta
So as a compare here is th info from my board,
[nsollars@archrock ~]$ lsusb -vv
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice 5.04 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x001f bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.04 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 5.04 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.04 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 5.04 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 [nsollars@archrock ~]$ lsusb Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
On Fri, Nov 29, 2019 at 5:51 PM Nigel Sollars nsollars@gmail.com wrote:
I have a usb3 to sata drive, il run some speed tests and get the information for you using this later kernel.
Il dig up what the dtc/dtb used is also ( most likely itle be pretty default )
Nige
On Thu, Nov 28, 2019 at 9:51 AM agharta82@gmail.com agharta82@gmail.com wrote:
Hi all,
About USB3, seem that Fedora w/kernel 5.3.7-301 see usb 3 port as usb 1.1 !!!!
See below, the first BUS row is very clear.
lsusb -vvv
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ohci_hcd
iProduct 2 Generic Platform OHCI controller
iSerial 1 ff5d0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0012
No power switching (usb 1.0) No overcurrent protectionbPwrOn2PwrGood 2 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 ff5c0000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching Per-port overcurrent protectionbPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.03
iManufacturer 3 Linux 5.3.7-301.fc31.aarch64 dwc2_hsotg
iProduct 2 DWC OTG Controller
iSerial 1 ff580000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9 bDescriptorType 2 wTotalLength 0x0019 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching Per-port overcurrent protection TT think time 8 FS bitsbPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0000
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Oblivious, a "modprobe xhci_hcd" does not fix the problem.
Any ideas?
Nigel, your Arch kernel does support Rock64's USB3 well? Have you tried a heavy write on it? If yes, does it hangs?
Best regards,
Agharta
Il 28/11/19 13:58, agharta82@gmail.com ha scritto:
Hi Benson,
see below
Il 28/11/19 13:19, Benson Muite ha scritto:
On 11/28/19 2:37 PM, agharta82@gmail.com wrote:
Hi Benson,
I'm really new in Pagure.
So am I. It seemed ok, once uploaded an ssh key, could then use command line git interface. Web interface seems limited compared to Gitlab/Github, but it is better integrated with Fedora infrastructure.
Ok, I have to try it. Thanks for your feedback.
Feel free to edit and make pull request. I don't wont to make errors or create confusions.
Git keeps history, so errors can be undone. The more people that can add to code the better. It would be of interest to learn your thoughts on Rock64 board. Price point seems similar to Raspberry Pi. Are you using USB to attach an external hard drive for Nextcloud?
Price is ok, board seems too.....but there are some problems:
in debian-like images the network hangs if rebooted. Performance is very good. https://wiki.pine64.org/index.php/ROCK64_Software_Release#Linux_Image_Releas... in fedora 31 minimal have bad performance (ssh & console for example . I need to do a cpu/sd/memory test in both OSes to create a valid comparison) in debian-like images, if I connect a device to usb3 port it hangs after a bit....I have not yet figured out if it is a hardware or software problem....investigation is needed. In any case a ticket is already open https://github.com/ayufan-rock64/linux-build/issues/112 in fedora usb3 does not work..... My final target is to boot Rock64 via sd-card and connect 2 HDD in raid-1 mode through usb 3 (and relative hub) and store Nextcloud data into raid-1 fs. My oniric target is to use that board with IP-cameras and Zoneminder too....but for now I would be satisfied with the previous point.
Actually I am getting familiar with fedora 31 aarch64: it is quite different form x64 version, dnf update gives me errors about protected packages (......).
Finally, there is a file socs.d/Rockchips-ARMv8, which would fit description for rk3328 (https://en.wikipedia.org/wiki/Rockchip), but the specifications there are different than what you used. Maybe rk3328 should be Rockchip-rk3328?
Seek values provided by socs.d/Rockchips-ARMv8 seems not working for me, but beacuse I can't see serial console I don't know why....
In any case spl.img file is not availabe in fedora .xz build.
I have used the default seek values form main Rockchip guide: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Some of the other files, such as socs.d/exynos5 and socs.d/st have a few more steps than the others. Downloading spi boot binaries is not so great in Fedora as the build process is not under Fedora control. Not sure what the best solution is for this.
Actually Fedora can run into Rock64 IF AND ONLY IF spi boot is erased. I think that an spi-compatibe image should be added in fedora (as debian do). If yes, boot could be executed directy from usb disk (and raid-1 disks I hope).
It may be helpful to check the Fedora list guidelines, https://fedoraproject.org/wiki/Mailing_list_guidelines - top posting is discouraged, though I sometimes find I do it.
Thanks for your contributions. I look forward to trying out Rock64 board in the future.
Thank you for your patience, I'll keep you informed about problems & resolutions.
My best cheers,
Agharta
Thank you.
Best regards,
Agharta
Il 28/11/19 12:24, Benson Muite ha scritto:
On 11/27/19 5:22 PM, Benson Muite wrote:
On 11/27/19 5:00 PM, Nigel Sollars wrote:
Well done!,
I was waiting to see how this one went. in the meantime Arch pushed out a 5.4.0-1 kernel,
archrock 5.4.0-1-ARCH #1 SMP
[ 0.000000] Linux version 5.4.0-1-ARCH (builduser@leming) (gcc version 8.3.0 (GCC)) #1 SMP Tue Nov 26 02:44:10 UTC 2019 [ 0.000000] Machine model: Pine64 Rock64
Looks like the Lima driver got some work ( more info inside dmesg ) among other cleanups
Nige
On Wed, Nov 27, 2019 at 8:43 AM agharta82@gmail.com agharta82@gmail.com wrote:
OH GUYS! WHAT A BEAUTIFUL DAY!!!!!
Finally I've found the solution!
Excellent
So, first for all SPI flash should be ERASED: fedora aarch64 does not have spi boot images (at 2019-11-27). To erase spi follow this link: https://github.com/ayufan-rock64/linux-u-boot/releases/download/2017.09-rock...
It may be worth opening an issue in Pagure for this, not sure how it should be best included in the arm installer for Fedora.
Second, install fedora-arm-installer package, then create a new ad-hoc script; this script for rock64 that I have made works well:
File is placed into folder /usr/share/arm-image-installer/boards.d/ and named rock64-rk3328
Made one change, put file in socs.d/rk3328 and added a softlink from boards.d/rock64 to socs.d/rk3328
Not sure if names I choose are the most appropriate.
# write uboot echo "= Writing idbloader.img for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/idbloader.img of=$MEDIA seek=64; sync; sleep 5 echo "= Writing u-boot FIT image for $TARGET .... on media $MEDIA" dd if=$PREFIX/usr/share/uboot/$TARGET/u-boot.itb of=$MEDIA seek=16384; sync; sleep 5 # set console for Rockchips SYSCON=ttyS2,115200n8
I'm not sure about SYSCON because my serial adapter does not works at 1500000 baudrate, so I can't test it. I have leaved it at default. Hope someone can test and correct it if required.
References to find right dd seek: http://opensource.rock-chips.com/wiki_Boot_option#Boot_from_SD.2FTF_Card
Next, download fedora aarch64 31 minimal xz image and:
arm-image-installer --image=Fedora-Minimal-31-1.9.aarch64.raw.xz --resizefs --media=/dev/THE_SD_MEDIA --target=rock64-rk3328 --addconsole (and other stuff)
Insert sd into Rock64 and power on!
Connect HDMI cable, IT WORKS AND YOU CAN BOOT (a part of it)!!!
Wait a bit (by default search for ipv6 ip).
Connect Keyboard and follow on screen setup to set root password, Timezone etc...
AT THE END ALL WORKS!!!!!
Great
Benson, feel free to integrate it to Pagure, and make a new fedora-arm-image-installer package.
Can start on this, though I do not have this board, so cannot really test it. Let me know if you have used Pagure or Git, usually it is good for the person who found the solution to add it to the repository. If still want me to do it, can do so.
It seems you already forked the repository, so feel free to make your additions there. There is a pull request at:
https://pagure.io/arm-image-installer/pull-requests
Really guys, I am very very very happy!
Have a fantastic day!!!
Agharta
-- “Science is a differential equation. Religion is a boundary condition.”
Alan Turing
-
agharta agharta -
agharta82＠gmail.com
-
Benson Muite -
Nigel Sollars -
Peter Robinson