after talking at devconf with David Cantrell about the best way to
support setting up uboot on arm devices in anaconda, the best approach
going forward is pretty clear, ill get to it in a bit first i want to
describe things as I see them.
Unified kernel while solving many issues introduces some. platform
detection was kinda simple with separate kernels. unified kernel means
that while we dont need to worry about having the right kernel, we do
need to worry about loading the right dtb.
platform detection is also needed to know where in ram we should load
the kernel and offsets for initramfs and dtb to be loaded. anaconda can
tell us the filesystem and device that we are installing to, but
depending on the exact way support is done in uboot we may need to put
in different values, SCSI vs SATA vs USB etc we also need to ensure we
use the right dtb file. for instance a pandaboard ES can use a
pandaboard dtb but will be 1ghz vs the 1.2ghz its capable of. some
systems like the highbank ones have the dtb in their uboot. while
others need to load an external file.
so as i see it we need a library that anaconda can import and use to
work out the right values for the system we are installing to. probably
the library should write out the uboot template and run mkconfig on
it. we could then reuse the library in a tool to say setup a boot
sdcard to run the installer on a system. we have an issue where it is
really not possible to make the equivilent of a boot.iso that will be
I think we should take this up to the cross distro list at linaro and
ideally have the distros work on a database at the least of platforms
and the values and types needed. if not the whole library that can be
used in different places to set things up.
this is only needed for 32 bit arm, 64 bit will have UEFI, ACPI and
grub2. potentially we also want to consider if we can implement
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec since we
need to implement something anyway.
Good Afternoon all,
Please join us today (Wednesday, February 27th) at 4PM EST (9PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) Aarch64 config.guess patching
3) A15 Kernel support in Fedora
4) ARM Tech Talks - suggestions for future talks, volunteers?
5) Open Floor
If there is something that you would like to discuss that isn't mentioned
please feel free to bring it up at the end of the meeting or send an email
to the list.
Your test kernel doesn't output anything on the console, but under a hardware debugger I can confirm that it does start, and then panics. I think it's a dtb problem. I tried using the reference one from the 3.8 rpm for ES and with no dtb. With no dtb we fall over in paging_init as we don't know what the physical machine looks like. With a dtb I don't yet have the exact failure caught (out of time tonight) but I suspect it is still a busted dtb. We can build a local kernel with debug, earlyprintk, and I can poke the debugger more on Wed evening. I skimmed the config only briefly, generally need more time to look into this.
Sent from my iPad