On 26 October 2014 16:51:43 GMT+08:00, Peter Robinson <pbrobinson@xxxxxxxxx> 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
