On 10/26/2014 08:35 AM, Andy Green wrote:
On 26 October 2014 20:18:39 GMT+08:00, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
On 10/26/2014 07:56 AM, Andy Green wrote:
On 26 October 2014 19:50:26 GMT+08:00, Robert Moskowitz
<rgm@xxxxxxxxxxxxxxx> wrote:
On 10/26/2014 07:33 AM, Andy Green wrote:
On 26 October 2014 18:40:55 GMT+08:00, Peter Robinson
<pbrobinson@xxxxxxxxx> 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_AllWinner_Devices
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
