It'd be great if folks could help out with the Beta RC1 testing. The cloud images seem to be busted but everything else is available for testing, and Dennis will look into the Cloud issues tomorrow. In the meantime if people can help get the ARM and Workstation/KDE tests run it'd be a big help.
You can use my silly relval tool - https://www.happyassassin.net/wikitcms/ - as an alternative to editing the wiki pages to report results, if you like. Set up the repo, install relval, and run 'relval report-results --username=(fasname)'. You might find it a bit easier/more efficient than editing the pages.
On Fri, Oct 24, 2014 at 01:15:18AM -0700, Adam Williamson wrote:
It'd be great if folks could help out with the Beta RC1 testing. The cloud images seem to be busted but everything else is available for testing, and Dennis will look into the Cloud issues tomorrow. In the
Weird. The kickstart file is now not truncated, but ime images are still coming put 193k. (E.g. empty!)
On 24 October 2014 16:15:18 GMT+08:00, Adam Williamson adamwill@fedoraproject.org wrote:
It'd be great if folks could help out with the Beta RC1 testing. The cloud images seem to be busted but everything else is available for testing, and Dennis will look into the Cloud issues tomorrow. In the meantime if people can help get the ARM and Workstation/KDE tests run it'd be a big help.
(Snipped the non-arm guys)
On a Cubietruck, unpacking Fedora-Minimal-armhfp-21_Alpha-1-sda.raw.xz to an SD gets me nothing useful, it seems because the U-Boot that needs to be on SD Card at a magic sector offset is missing.
U-Boot 2011.09-rc1-00003-ge89ab14-dirty (Jan 03 2014 - 12:57:33) Allwinner Technology
[ 0.143]version: 1.1.0 [ 0.146]pmbus: ready [ 0.251]PMU: AXP209 [ 0.254]PMU: AXP20x found [ 0.257]PMU: bat ratio = 100 [ 0.260]after set, dcdc2 =1400mv [ 0.264]PMU: dcdc2 1400 [ 0.266]PMU: pll1 912 Mhz boot_clock = 912 dcdc2_vol = 1400 [ 0.274]after set, dcdc2 =1400mv dcdc3_vol = 1250 ldo2_vol = 3000 ldo3_vol = 2800 ldo4_vol = 2800 power_start = 0 storage_type = -1 usb_recovery = 1 find power_sply to end fel key old mode run key detect no key found no key input dram_para_set start dram_para_set end [ 0.310]DRAM: 2 GiB relocation Offset is: 75b23000 donn't initialize ther user_gpio (main_key:boot_init_gpio) DRV_DISP_Init: opened [ 0.525]boot_disp.output_type=4 [ 0.528]boot_disp.output_mode=4 [ 0.531]boot_disp.auto_hpd=0 workmode = 0 [ 0.536]NAND: NAND_UbootInit NB1 : enter NAND_LogicInit nand : get id_number_ctl from script, 3 not burn nand partition table! NB1 : nand_info_init fail [ 6.998]nand init fail set to recovery try sprite_led_gpio config sunxi sprite begin screen_width = 1024 screen_height = 768 bar x1: 256 y1: 344 bar x2: 768 y2: 424 read mbr failed sprite update error: no data part found read mbr failed sprite update error: read image start error sprite update error: current card sprite failed now hold the machine fail to find part named env Using default environment
In: serial Err: serial --------fastboot partitions-------- mbr not exist base bootcmd=run setargs_nand boot_normal bootcmd set setargs_nand key 0 recovery key high 6, low 4 cant find fstbt value no misc partition is found to be run cmd=run setargs_nand boot_normal the part isn't exist WORK_MODE_BOOT WORK_MODE_BOOT [ 7.091]Hit any key to stop autoboot: 0 cant find part named boot sunxi_flash - sunxi_flash sub-system
Usage: sunxi_flash read command parmeters : parmeters 0 : addr to load(hex only) parmeters 1 : the name of the part to be load [parmeters 2] : the number of bytes to be load(hex only) if [parmeters 2] not exist, the number of bytes to be load is the size of the part indecated on partemeter 1 boota: bad boot image magic, maybe not a boot.img? sunxi#
So that's dead out of the box on Cubietruck and presumably Cubieboard 2 since it has the same requirement.
Making it work needs these instructions from this list
git clone https://github.com/jwrdegoede/u-boot-sunxi.git cd u-boot-sunxi git checkout -B next origin/next make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig make -j4 CROSS_COMPILE=arm-linux-gnu- dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
(You can transplant a Cubieboard 2 U-Boot, which I tried first, and it will "work", but Ethernet is dead and he understands he only has 1GB. So you need a Cubietrack-specific U-boot)
U-Boot SPL 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) DRAM: 2048 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
U-Boot 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) Allwinner Technology
CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Reserved 8192kB of RAM for Framebuffer. In: serial Out: serial Err: serial SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: dwmac.1c50000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 557 bytes read in 100 ms (4.9 KiB/s) Ignoring unknown command: ui Ignoring malformed menu command: autoboot Ignoring malformed menu command: hidden Ignoring unknown command: totaltimeout Fedora-Minimal-armhfp-21_Alpha-1 Boot Options. 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Enter choice: 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Retrieving file: /initramfs-3.16.1-301.fc21.armv7hl.img 29206005 bytes read in 1702 ms (16.4 MiB/s) Retrieving file: /vmlinuz-3.16.1-301.fc21.armv7hl 5460688 bytes read in 461 ms (11.3 MiB/s) append: ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8 Retrieving file: /dtb-3.16.1-301.fc21.armv7hl/sun7i-a20-cubieboard2.dtb 20757 bytes read in 2163 ms (8.8 KiB/s) Wrong Image Format for sysboot command ERROR: can't get kernel image! Kernel image @ 0x42000000 [ 0x000000 - 0x5352d0 ] ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 4e425000, end 4ffff5f5 ... OK Loading Device Tree to 4e41c000, end 4e424114 ... OK
Starting kernel ...
Then nothing due to no default console... edit /boot/extlinux/extlinux.conf on the SD
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice. Ethernet etc seems to work fine.
So it's the usual Fedora goodness once you get over the hump, but does not work out of the box on Cubie*.
-Andy
You can use my silly relval tool - https://www.happyassassin.net/wikitcms/ - as an alternative to editing the wiki pages to report results, if you like. Set up the repo, install relval, and run 'relval report-results --username=(fasname)'. You might find it a bit easier/more efficient than editing the pages.
On 25 October 2014 09:32:53 GMT+08:00, Andy Green andy@warmcat.com wrote:
On 24 October 2014 16:15:18 GMT+08:00, Adam Williamson adamwill@fedoraproject.org wrote:
It'd be great if folks could help out with the Beta RC1 testing. The cloud images seem to be busted but everything else is available for testing, and Dennis will look into the Cloud issues tomorrow. In the meantime if people can help get the ARM and Workstation/KDE tests run it'd be a big help.
(Snipped the non-arm guys)
On a Cubietruck, unpacking Fedora-Minimal-armhfp-21_Alpha-1-sda.raw.xz to an SD gets me nothing useful, it seems because the U-Boot that needs to be on SD Card at a magic sector offset is missing.
U-Boot 2011.09-rc1-00003-ge89ab14-dirty (Jan 03 2014 - 12:57:33) Allwinner Technology
[ 0.143]version: 1.1.0 [ 0.146]pmbus: ready [ 0.251]PMU: AXP209 [ 0.254]PMU: AXP20x found [ 0.257]PMU: bat ratio = 100 [ 0.260]after set, dcdc2 =1400mv [ 0.264]PMU: dcdc2 1400 [ 0.266]PMU: pll1 912 Mhz boot_clock = 912 dcdc2_vol = 1400 [ 0.274]after set, dcdc2 =1400mv dcdc3_vol = 1250 ldo2_vol = 3000 ldo3_vol = 2800 ldo4_vol = 2800 power_start = 0 storage_type = -1 usb_recovery = 1 find power_sply to end fel key old mode run key detect no key found no key input dram_para_set start dram_para_set end [ 0.310]DRAM: 2 GiB relocation Offset is: 75b23000 donn't initialize ther user_gpio (main_key:boot_init_gpio) DRV_DISP_Init: opened [ 0.525]boot_disp.output_type=4 [ 0.528]boot_disp.output_mode=4 [ 0.531]boot_disp.auto_hpd=0 workmode = 0 [ 0.536]NAND: NAND_UbootInit NB1 : enter NAND_LogicInit nand : get id_number_ctl from script, 3 not burn nand partition table! NB1 : nand_info_init fail [ 6.998]nand init fail set to recovery try sprite_led_gpio config sunxi sprite begin screen_width = 1024 screen_height = 768 bar x1: 256 y1: 344 bar x2: 768 y2: 424 read mbr failed sprite update error: no data part found read mbr failed sprite update error: read image start error sprite update error: current card sprite failed now hold the machine fail to find part named env Using default environment
In: serial Err: serial --------fastboot partitions-------- mbr not exist base bootcmd=run setargs_nand boot_normal bootcmd set setargs_nand key 0 recovery key high 6, low 4 cant find fstbt value no misc partition is found to be run cmd=run setargs_nand boot_normal the part isn't exist WORK_MODE_BOOT WORK_MODE_BOOT [ 7.091]Hit any key to stop autoboot: 0 cant find part named boot sunxi_flash - sunxi_flash sub-system
Usage: sunxi_flash read command parmeters : parmeters 0 : addr to load(hex only) parmeters 1 : the name of the part to be load [parmeters 2] : the number of bytes to be load(hex only) if [parmeters 2] not exist, the number of bytes to be load is the size of the part indecated on partemeter 1 boota: bad boot image magic, maybe not a boot.img? sunxi#
So that's dead out of the box on Cubietruck and presumably Cubieboard 2 since it has the same requirement.
Making it work needs these instructions from this list
git clone https://github.com/jwrdegoede/u-boot-sunxi.git cd u-boot-sunxi git checkout -B next origin/next make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig make -j4 CROSS_COMPILE=arm-linux-gnu- dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
(You can transplant a Cubieboard 2 U-Boot, which I tried first, and it will "work", but Ethernet is dead and he understands he only has 1GB. So you need a Cubietrack-specific U-boot)
U-Boot SPL 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) DRAM: 2048 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
U-Boot 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) Allwinner Technology
CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Reserved 8192kB of RAM for Framebuffer. In: serial Out: serial Err: serial SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: dwmac.1c50000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 557 bytes read in 100 ms (4.9 KiB/s) Ignoring unknown command: ui Ignoring malformed menu command: autoboot Ignoring malformed menu command: hidden Ignoring unknown command: totaltimeout Fedora-Minimal-armhfp-21_Alpha-1 Boot Options. 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Enter choice: 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Retrieving file: /initramfs-3.16.1-301.fc21.armv7hl.img 29206005 bytes read in 1702 ms (16.4 MiB/s) Retrieving file: /vmlinuz-3.16.1-301.fc21.armv7hl 5460688 bytes read in 461 ms (11.3 MiB/s) append: ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8 Retrieving file: /dtb-3.16.1-301.fc21.armv7hl/sun7i-a20-cubieboard2.dtb 20757 bytes read in 2163 ms (8.8 KiB/s) Wrong Image Format for sysboot command ERROR: can't get kernel image! Kernel image @ 0x42000000 [ 0x000000 - 0x5352d0 ] ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 4e425000, end 4ffff5f5 ... OK Loading Device Tree to 4e41c000, end 4e424114 ... OK
Starting kernel ...
Then nothing due to no default console... edit /boot/extlinux/extlinux.conf on the SD
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice. Ethernet etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
There's some nasty 'fex' thing on these boards I managed to avoid until now maybe it's related to that.
- Although firstboot stuff ran on console, sshd-keygen never ran. So ssh is up but he can't do key exchange. Journald makes it obvious
Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: fatal: No supported key exchange algorithms [preauth]
Just run sshd-keygen to fix it
-Andy
So it's the usual Fedora goodness once you get over the hump, but does not work out of the box on Cubie*.
-Andy
You can use my silly relval tool - https://www.happyassassin.net/wikitcms/ - as an alternative to editing the wiki pages to report results, if you like. Set up the repo,
install
relval, and run 'relval report-results --username=(fasname)'. You
might
find it a bit easier/more efficient than editing the pages.
Then nothing due to no default console... edit /boot/extlinux/extlinux.conf on the SD
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice. Ethernet etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream in the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Also do you see the issue with the 3.17.x kernels from F-21? I'm not seeing any issues with my Cubietruck on uboot 2014.10 with 3.17.x
There's some nasty 'fex' thing on these boards I managed to avoid until now maybe it's related to that.
fex is AllWinner's equiv of DeviceTree, I think it's used by some others too. Shouldn't be an issue with mainline u-boot or Fedora's.
So it's the usual Fedora goodness once you get over the hump, but does not work out of the box on Cubie*.
Seems to work OK with my Cubieboard v1 and CubieTruck. Would be interested how you get on with RC1 as is shouldn't be pulling in rawhide stuff that TC4 did due to the fedora-release* mess.
Peter
On 26 October 2014 16:51:43 GMT+08:00, Peter Robinson pbrobinson@gmail.com wrote:
Then nothing due to no default console... edit /boot/extlinux/extlinux.conf on the SD
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream in the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd image provided by Fedora.
Honestly I would be surprised if it was since it exactly and incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
Sunxi guys need to do something better than that kind of build-time config hack.
Also do you see the issue with the 3.17.x kernels from F-21? I'm not seeing any issues with my Cubietruck on uboot 2014.10 with 3.17.x
Yes, I see the problem on my board with 3 different kernels, the original f21 alpha kernel, the updated kernel from f21 repo and the rawhide kernel.
There's some nasty 'fex' thing on these boards I managed to avoid
until now maybe it's related to that.
fex is AllWinner's equiv of DeviceTree, I think it's used by some others too. Shouldn't be an issue with mainline u-boot or Fedora's.
I'm not sure it's equivalent to dt relationship to kernel, seems to be some nasty pre-uboot state that controls what the pre-uboot bootloader does (which uboot and kernel then rely on / inherit).
It's possible our different experience is related to your fex giving working onboard eth0 and my board (purchased from a subterranean otaku dungeon in Guanghua, Taipei where it may have rested a while first) has something that doesn't lead to a good result there.
So it's the usual Fedora goodness once you get over the hump, but
does
not work out of the box on Cubie*.
Seems to work OK with my Cubieboard v1 and CubieTruck. Would be interested how you get on with RC1 as is shouldn't be pulling in rawhide stuff that TC4 did due to the fedora-release* mess.
I only updated the specifically the kernel with rawhide kernel by hand, by adding the rawhide repo disabled by default. So it's not related to wrong default repos, the alpha is ok for that, and it hasn't drawn in anything from rawhide except parallel install of rawhide kernel*.
-Andy
Peter
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream in the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd image provided by Fedora.
Honestly I would be surprised if it was since it exactly and incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson pbrobinson@gmail.com wrote:
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream
in
the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson pbrobinson@gmail.com wrote:
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream
in
the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
That will never happen. Maybe one day all the board vendors will ship an onboard sane uboot similar to that of a PC BIOS. You don't have a single firmware on PC, the difference is they ship it. Unfortunately cheap dev boards don't put flash etc on board because it adds to the cost.
On 10/26/2014 07:44 AM, Peter Robinson wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson pbrobinson@gmail.com wrote:
> append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 > console=ttyS0,115200 loglevel=8 > > Then he boots into firstboot on serial console which is nice.
Ethernet
> etc seems to work fine. Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream
in
the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
That will never happen. Maybe one day all the board vendors will ship an onboard sane uboot similar to that of a PC BIOS. You don't have a single firmware on PC, the difference is they ship it. Unfortunately cheap dev boards don't put flash etc on board because it adds to the cost.
Ah, the early days of PC Bios and the rise of the Phoenix.
And yet they have all that NAND that has a uboot on it?
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson pbrobinson@gmail.com wrote:
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream
in
the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Perhaps I came at it differently. It was actually easy for me for some odd reason. One dd step to get the right uboot. For a while in the pre-alpha, I needed a special uboot for the Cubieboard2 direct from Hans; this is no longer the case though.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 26 October 2014 19:50:26 GMT+08:00, Robert Moskowitz rgm@htt-consult.com wrote:
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson
pbrobinson@gmail.com wrote:
> append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 > console=ttyS0,115200 loglevel=8 > > Then he boots into firstboot on serial console which is nice.
Ethernet
> etc seems to work fine. Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates
the
link OK but he cannot pass traffic. Googling around other people
get
this from non-3.4 kernel, so it's something missing upstream I
guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and
update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it,
it's
still broken.
That uboot is no longer being updated as everything is now
upstream
in
the mainline uboot. I'd use the one shipped with Fedora or
upstream
u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at
+16
sectors of the sd image.
No, we don't provide any default uboot on the images by design
because
the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Perhaps I came at it differently. It was actually easy for me for some
ha, no.
I mean the unification work that has taken place to make the U-Boots all act the same.
I was even able to update my kernel using yum without the whole thing blowing up, and that should work on any of the supported boards. It's a lot of work behind the scenes to get there.
If you look back a couple of years, when there was not even a single kernel binary for arm that could do this much, that is actually really surprising progress.
Also I don't think it's 'easy' you have just been conditioned into thinking it must be super difficult.
When was the last time you needed to dd some crap on to your x86 Fedora install to make it do something more than die? Actually this current situation is still unreasonable despite the great progress.
-Andy
odd reason. One dd step to get the right uboot. For a while in the pre-alpha, I needed a special uboot for the Cubieboard2 direct from Hans; this is no longer the case though.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 10/26/2014 07:56 AM, Andy Green wrote:
On 26 October 2014 19:50:26 GMT+08:00, Robert Moskowitz rgm@htt-consult.com wrote:
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson
pbrobinson@gmail.com wrote:
>> append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 >> console=ttyS0,115200 loglevel=8 >> >> Then he boots into firstboot on serial console which is nice. Ethernet >> etc seems to work fine. > Couple more findings > > - Cubietruck Ethernet onboard is broken. His phy negotiates
the
link OK but he cannot pass traffic. Googling around other people
get
this from non-3.4 kernel, so it's something missing upstream I
guess.
> Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and
update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it,
it's
still broken.
That uboot is no longer being updated as everything is now
upstream
in
the mainline uboot. I'd use the one shipped with Fedora or
upstream
u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required at
+16
sectors of the sd image.
No, we don't provide any default uboot on the images by design
because
the image is designed to be used on a lot more devices than just the AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Perhaps I came at it differently. It was actually easy for me for some
ha, no.
I mean the unification work that has taken place to make the U-Boots all act the same.
I was even able to update my kernel using yum without the whole thing blowing up, and that should work on any of the supported boards. It's a lot of work behind the scenes to get there.
If you look back a couple of years, when there was not even a single kernel binary for arm that could do this much, that is actually really surprising progress.
Also I don't think it's 'easy' you have just been conditioned into thinking it must be super difficult.
When was the last time you needed to dd some crap on to your x86 Fedora install to make it do something more than die? Actually this current situation is still unreasonable despite the great progress.
F20 on my Lenovo x120. It was a mess, as the write of the efi cruft failed. What it took to get it to work was scary. Supposedly what we learned from my misadventure has been 'fixed' with F21. I have a Lenovo x120 just waiting here for me to test, but I first have to build a local repo, as they have elminated the full DVD with only netinstall which is a pain for those of us with DSL.
We have lived with PC Bios for a long time. I actually like this developing uboot process for right now. Does remind me of all the times I needed to book with a DOS diskette and load a new Bios file to fix some Bios bug. In fact, I had to do this just last year.
I started on PCs in '83 and ran DOS 1.0, and went from there. Linux came MUCH later.
But enough remembering how it was. Peter did point out what we have to deal with the current SOCs and this is not likely to change for some time. For them, if they can get Android working, that is enough to ship their chip.
-Andy
odd reason. One dd step to get the right uboot. For a while in the pre-alpha, I needed a special uboot for the Cubieboard2 direct from Hans; this is no longer the case though.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 26 October 2014 20:18:39 GMT+08:00, Robert Moskowitz rgm@htt-consult.com wrote:
On 10/26/2014 07:56 AM, Andy Green wrote:
On 26 October 2014 19:50:26 GMT+08:00, Robert Moskowitz
rgm@htt-consult.com wrote:
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson
pbrobinson@gmail.com wrote:
>>> append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 >>> console=ttyS0,115200 loglevel=8 >>> >>> Then he boots into firstboot on serial console which is nice. > Ethernet >>> etc seems to work fine. >> Couple more findings >> >> - Cubietruck Ethernet onboard is broken. His phy negotiates
the
> link OK but he cannot pass traffic. Googling around other
people
get
> this from non-3.4 kernel, so it's something missing upstream I
guess.
>> Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and
update
> to latest sunxi U-Boot ( e847610a41af2b @ > https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it,
it's
> still broken. > > That uboot is no longer being updated as everything is now
upstream
in
> the mainline uboot. I'd use the one shipped with Fedora or
upstream
> u-boot 2014.10 GA release. Okay... but it does not seem to be present at +16 sectors on the
sd
image provided by Fedora.
Honestly I would be surprised if it was since it exactly and
incompatibly conflicts with the Cubieboard 2 uboot also required
at
+16
sectors of the sd image.
No, we don't provide any default uboot on the images by design
because
the image is designed to be used on a lot more devices than just
the
AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Perhaps I came at it differently. It was actually easy for me for
some
ha, no.
I mean the unification work that has taken place to make the U-Boots
all act the same.
I was even able to update my kernel using yum without the whole thing
blowing up, and that should work on any of the supported boards. It's a lot of work behind the scenes to get there.
If you look back a couple of years, when there was not even a single
kernel binary for arm that could do this much, that is actually really surprising progress.
Also I don't think it's 'easy' you have just been conditioned into
thinking it must be super difficult.
When was the last time you needed to dd some crap on to your x86
Fedora install to make it do something more than die? Actually this current situation is still unreasonable despite the great progress.
F20 on my Lenovo x120. It was a mess, as the write of the efi cruft failed. What it took to get it to work was scary. Supposedly what we learned from my misadventure has been 'fixed' with F21. I have a Lenovo x120 just waiting here for me to test, but I first have to build a local repo, as they have elminated the full DVD with only netinstall which is
a pain for those of us with DSL.
We have lived with PC Bios for a long time. I actually like this developing uboot process for right now. Does remind me of all the times I needed to book with a DOS diskette and load a new Bios file to fix some Bios bug. In fact, I had to do this just last year.
I started on PCs in '83 and ran DOS 1.0, and went from there. Linux came MUCH later.
I don't know about your particular Lenovo misadventures, but that has nothing to do with what I am saying.
To install on x86 there is no step about dd some machine-specific thing on the install medium like there is here, right?
You can do nice things like take the SSD out of one x86 machine that blew up and put it into your new machine, and it'll usually at least boot, you can use USB or ethernet on the new board immediately, etc.
But enough remembering how it was. Peter did point out what we have to
Yes.
deal with the current SOCs and this is not likely to change for some time. For them, if they can get Android working, that is enough to ship their chip.
Actually the kernel has gotten its house in order about single kernel binary. U-Boot is now the blocker for it being painless.
At least, U-Boot does have all the boot support in one tree at the same time, so some kind of consolidation is not impossible to consider. It's already too bloated to fit in anybody's SRAM, so actually it can bloat like the kernel bloats with multiple arches in there and nobody cares.
And just like it copies most of its drivers from Linux, Kconfig, apis from Linux, has a full fdt stack, maybe one day it will copy the single binary idea from Linux.
I think in the near future, there will be an sudden increase in reasons for people to consider this approach, although I don't underestimate what a monster problem it is. (And indeed if v8 works better for this from the start the v7 situation may quickly become a legacy problem nobody cares about any more.)
-Andy
-Andy
odd reason. One dd step to get the right uboot. For a while in the pre-alpha, I needed a special uboot for the Cubieboard2 direct from Hans; this is no longer the case though.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 10/26/2014 08:35 AM, Andy Green wrote:
On 26 October 2014 20:18:39 GMT+08:00, Robert Moskowitz rgm@htt-consult.com wrote:
On 10/26/2014 07:56 AM, Andy Green wrote:
On 26 October 2014 19:50:26 GMT+08:00, Robert Moskowitz
rgm@htt-consult.com wrote:
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson
pbrobinson@gmail.com wrote:
>>>> append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 >>>> console=ttyS0,115200 loglevel=8 >>>> >>>> Then he boots into firstboot on serial console which is nice. >> Ethernet >>>> etc seems to work fine. >>> Couple more findings >>> >>> - Cubietruck Ethernet onboard is broken. His phy negotiates
the
>> link OK but he cannot pass traffic. Googling around other
people
get
>> this from non-3.4 kernel, so it's something missing upstream I
guess.
>>> Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and
update
>> to latest sunxi U-Boot ( e847610a41af2b @ >> https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it,
it's
>> still broken. >> >> That uboot is no longer being updated as everything is now
upstream
in >> the mainline uboot. I'd use the one shipped with Fedora or
upstream
>> u-boot 2014.10 GA release. > Okay... but it does not seem to be present at +16 sectors on the
sd
image provided by Fedora. > Honestly I would be surprised if it was since it exactly and incompatibly conflicts with the Cubieboard 2 uboot also required
at
+16
sectors of the sd image.
No, we don't provide any default uboot on the images by design
because
the image is designed to be used on a lot more devices than just
the
AllWinner devices.
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin...
Yeah. I know it's difficult to do what you're doing.
Perhaps I came at it differently. It was actually easy for me for
some
ha, no.
I mean the unification work that has taken place to make the U-Boots
all act the same.
I was even able to update my kernel using yum without the whole thing
blowing up, and that should work on any of the supported boards. It's a lot of work behind the scenes to get there.
If you look back a couple of years, when there was not even a single
kernel binary for arm that could do this much, that is actually really surprising progress.
Also I don't think it's 'easy' you have just been conditioned into
thinking it must be super difficult.
When was the last time you needed to dd some crap on to your x86
Fedora install to make it do something more than die? Actually this current situation is still unreasonable despite the great progress.
F20 on my Lenovo x120. It was a mess, as the write of the efi cruft failed. What it took to get it to work was scary. Supposedly what we learned from my misadventure has been 'fixed' with F21. I have a Lenovo x120 just waiting here for me to test, but I first have to build a local repo, as they have elminated the full DVD with only netinstall which is
a pain for those of us with DSL.
We have lived with PC Bios for a long time. I actually like this developing uboot process for right now. Does remind me of all the times I needed to book with a DOS diskette and load a new Bios file to fix some Bios bug. In fact, I had to do this just last year.
I started on PCs in '83 and ran DOS 1.0, and went from there. Linux came MUCH later.
I don't know about your particular Lenovo misadventures, but that has nothing to do with what I am saying.
To install on x86 there is no step about dd some machine-specific thing on the install medium like there is here, right?
You can do nice things like take the SSD out of one x86 machine that blew up and put it into your new machine, and it'll usually at least boot, you can use USB or ethernet on the new board immediately, etc.
Nope. Can't do that any more. Tried it even from one Lenovo to another. Failed. Current X86 systems with EFI makes moving drives no longer possible.
But enough remembering how it was. Peter did point out what we have to
Yes.
deal with the current SOCs and this is not likely to change for some time. For them, if they can get Android working, that is enough to ship their chip.
Actually the kernel has gotten its house in order about single kernel binary. U-Boot is now the blocker for it being painless.
At least, U-Boot does have all the boot support in one tree at the same time, so some kind of consolidation is not impossible to consider. It's already too bloated to fit in anybody's SRAM, so actually it can bloat like the kernel bloats with multiple arches in there and nobody cares.
And just like it copies most of its drivers from Linux, Kconfig, apis from Linux, has a full fdt stack, maybe one day it will copy the single binary idea from Linux.
I think in the near future, there will be an sudden increase in reasons for people to consider this approach, although I don't underestimate what a monster problem it is. (And indeed if v8 works better for this from the start the v7 situation may quickly become a legacy problem nobody cares about any more.)
-Andy
-Andy
odd reason. One dd step to get the right uboot. For a while in the pre-alpha, I needed a special uboot for the Cubieboard2 direct from Hans; this is no longer the case though.
Just looking through your list, the u-boots all conflict badly.
This is a terrible shame when we have a single kernel binary now.
Maybe someday there will be a 'single u-boot binary'.
-Andy
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 10/26/2014 06:40 AM, Peter Robinson wrote:
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice.
Ethernet
etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the
link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update
to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
That uboot is no longer being updated as everything is now upstream in the mainline uboot. I'd use the one shipped with Fedora or upstream u-boot 2014.10 GA release.
Okay... but it does not seem to be present at +16 sectors on the sd image provided by Fedora.
Honestly I would be surprised if it was since it exactly and incompatibly conflicts with the Cubieboard 2 uboot also required at +16 sectors of the sd image.
No, we don't provide any default uboot on the images by design because the image is designed to be used on a lot more devices than just the AllWinner devices.
And the one step to dd the right uboot is easy enough. It would be nice if the installer were smarter and not just limited to the original list of 6 boards...
https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_AllWin... _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Andy.
I am packing up to catch my flight, but caught your messages, and it seems that you are using an old ALpha build, not the current Beta release?
I grabbed:
https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC1/Images/armhfp/Fedora-...
I then ran the installer that I downloaded a long time ago:
http://pwhalen.fedorapeople.org/fedora-arm-image-installer.tar.bz2
Now I see you have some issues with the location of the bootloader itself on the SD card. This installer puts it there. It is actually running:
sudo dd if=/tmp/root/usr/share/uboot/Cubietruck/u-boot-sunxi-with-spl.bin of=/dev/<media-location> bs=1024 seek=8 conv=fsync,notrunc
(see: https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation).
For the Cubieboard2, I was successful with:
sudo dd if=/tmp/root/usr/share/uboot/Cubieboard2/u-boot-sunxi-with-spl.bin of=/dev/<media-location> bs=1024 seek=8 conv=fsync,notrunc
Ethernet works well on both my Cubietruck and Cubieboard2. CT finally has a stable MACaddr between boots. No WiFi on CT though (at least the LEDs are no longer flashing as with F19/F20 remixes). Mine are recent purchases from:
George has been very helpful.
On 10/25/2014 09:13 PM, Andy Green wrote:
On 25 October 2014 09:32:53 GMT+08:00, Andy Green andy@warmcat.com wrote:
On 24 October 2014 16:15:18 GMT+08:00, Adam Williamson adamwill@fedoraproject.org wrote:
It'd be great if folks could help out with the Beta RC1 testing. The cloud images seem to be busted but everything else is available for testing, and Dennis will look into the Cloud issues tomorrow. In the meantime if people can help get the ARM and Workstation/KDE tests run it'd be a big help.
(Snipped the non-arm guys)
On a Cubietruck, unpacking Fedora-Minimal-armhfp-21_Alpha-1-sda.raw.xz to an SD gets me nothing useful, it seems because the U-Boot that needs to be on SD Card at a magic sector offset is missing.
U-Boot 2011.09-rc1-00003-ge89ab14-dirty (Jan 03 2014 - 12:57:33) Allwinner Technology
[ 0.143]version: 1.1.0 [ 0.146]pmbus: ready [ 0.251]PMU: AXP209 [ 0.254]PMU: AXP20x found [ 0.257]PMU: bat ratio = 100 [ 0.260]after set, dcdc2 =1400mv [ 0.264]PMU: dcdc2 1400 [ 0.266]PMU: pll1 912 Mhz boot_clock = 912 dcdc2_vol = 1400 [ 0.274]after set, dcdc2 =1400mv dcdc3_vol = 1250 ldo2_vol = 3000 ldo3_vol = 2800 ldo4_vol = 2800 power_start = 0 storage_type = -1 usb_recovery = 1 find power_sply to end fel key old mode run key detect no key found no key input dram_para_set start dram_para_set end [ 0.310]DRAM: 2 GiB relocation Offset is: 75b23000 donn't initialize ther user_gpio (main_key:boot_init_gpio) DRV_DISP_Init: opened [ 0.525]boot_disp.output_type=4 [ 0.528]boot_disp.output_mode=4 [ 0.531]boot_disp.auto_hpd=0 workmode = 0 [ 0.536]NAND: NAND_UbootInit NB1 : enter NAND_LogicInit nand : get id_number_ctl from script, 3 not burn nand partition table! NB1 : nand_info_init fail [ 6.998]nand init fail set to recovery try sprite_led_gpio config sunxi sprite begin screen_width = 1024 screen_height = 768 bar x1: 256 y1: 344 bar x2: 768 y2: 424 read mbr failed sprite update error: no data part found read mbr failed sprite update error: read image start error sprite update error: current card sprite failed now hold the machine fail to find part named env Using default environment
In: serial Err: serial --------fastboot partitions-------- mbr not exist base bootcmd=run setargs_nand boot_normal bootcmd set setargs_nand key 0 recovery key high 6, low 4 cant find fstbt value no misc partition is found to be run cmd=run setargs_nand boot_normal the part isn't exist WORK_MODE_BOOT WORK_MODE_BOOT [ 7.091]Hit any key to stop autoboot: 0 cant find part named boot sunxi_flash - sunxi_flash sub-system
Usage: sunxi_flash read command parmeters : parmeters 0 : addr to load(hex only) parmeters 1 : the name of the part to be load [parmeters 2] : the number of bytes to be load(hex only) if [parmeters 2] not exist, the number of bytes to be load is the size of the part indecated on partemeter 1 boota: bad boot image magic, maybe not a boot.img? sunxi#
So that's dead out of the box on Cubietruck and presumably Cubieboard 2 since it has the same requirement.
Making it work needs these instructions from this list
git clone https://github.com/jwrdegoede/u-boot-sunxi.git cd u-boot-sunxi git checkout -B next origin/next make -j4 CROSS_COMPILE=arm-linux-gnu- Cubietruck_defconfig make -j4 CROSS_COMPILE=arm-linux-gnu- dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
(You can transplant a Cubieboard 2 U-Boot, which I tried first, and it will "work", but Ethernet is dead and he understands he only has 1GB. So you need a Cubietrack-specific U-boot)
U-Boot SPL 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) DRAM: 2048 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
U-Boot 2014.10-rc1-g7190869 (Oct 25 2014 - 09:23:15) Allwinner Technology
CPU: Allwinner A20 (SUN7I) I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 Reserved 8192kB of RAM for Framebuffer. In: serial Out: serial Err: serial SCSI: SUNXI SCSI INIT SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: dwmac.1c50000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 557 bytes read in 100 ms (4.9 KiB/s) Ignoring unknown command: ui Ignoring malformed menu command: autoboot Ignoring malformed menu command: hidden Ignoring unknown command: totaltimeout Fedora-Minimal-armhfp-21_Alpha-1 Boot Options. 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Enter choice: 1: Fedora-Minimal-armhfp-21_Alpha-1 (3.16.1-301.fc21.armv7hl) Retrieving file: /initramfs-3.16.1-301.fc21.armv7hl.img 29206005 bytes read in 1702 ms (16.4 MiB/s) Retrieving file: /vmlinuz-3.16.1-301.fc21.armv7hl 5460688 bytes read in 461 ms (11.3 MiB/s) append: ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8 Retrieving file: /dtb-3.16.1-301.fc21.armv7hl/sun7i-a20-cubieboard2.dtb 20757 bytes read in 2163 ms (8.8 KiB/s) Wrong Image Format for sysboot command ERROR: can't get kernel image! Kernel image @ 0x42000000 [ 0x000000 - 0x5352d0 ] ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 4e425000, end 4ffff5f5 ... OK Loading Device Tree to 4e41c000, end 4e424114 ... OK
Starting kernel ...
Then nothing due to no default console... edit /boot/extlinux/extlinux.conf on the SD
append ro root=UUID=c078beec-18b2-44ae-aac5-e6fc275b45c5 console=ttyS0,115200 loglevel=8
Then he boots into firstboot on serial console which is nice. Ethernet etc seems to work fine.
Couple more findings
- Cubietruck Ethernet onboard is broken. His phy negotiates the link OK but he cannot pass traffic. Googling around other people get this from non-3.4 kernel, so it's something missing upstream I guess.
Latest rawhide kernel (3.18.0-0.rc1.git2.1.fc22.armv7hl) and update to latest sunxi U-Boot ( e847610a41af2b @ https://github.com/jwrdegoede/u-boot-sunxi ) did not solve it, it's still broken.
There's some nasty 'fex' thing on these boards I managed to avoid until now maybe it's related to that.
- Although firstboot stuff ran on console, sshd-keygen never ran. So ssh is up but he can't do key exchange. Journald makes it obvious
Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key Oct 26 08:59:34 localhost.localdomain sshd[1000]: fatal: No supported key exchange algorithms [preauth]
Just run sshd-keygen to fix it
-Andy
So it's the usual Fedora goodness once you get over the hump, but does not work out of the box on Cubie*.
-Andy
You can use my silly relval tool - https://www.happyassassin.net/wikitcms/ - as an alternative to editing the wiki pages to report results, if you like. Set up the repo,
install
relval, and run 'relval report-results --username=(fasname)'. You
might
find it a bit easier/more efficient than editing the pages.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm