On Mon, 2012-06-04 at 11:07 +0200, Arnaud Patard wrote:
> Ian Campbell <ijc@hellion.org.uk> writes:
>
> Hi,
>
> > On Sun, 2012-06-03 at 19:48 +0100, Ben Hutchings wrote:
> >> hOn Sun, 2012-06-03 at 15:42 +0100, Ian Campbell wrote:
> >> > On Sat, 2012-06-02 at 23:47 +0100, Ben Hutchings wrote:
> >> > > Some hardware support; this can still be done after the freeze but the
> >> > > sooner the better:
> >> > >
> >> > > - [armhf] omapdrm driver
> >> > > - [x86] gma500 support for new chips
> >> > > - [x86] i915 improvements in Ivy Bridge support
> >> > > - radeon support for new chips
> >> > > - NVMe driver
> >> > > - tg3 support for 57766 chip
> >> > > - ipheth support for iPhone 4S
> >> > > - DRM/KMS driver for DisplayLink
> >> > > - qmi_wwan driver (#670241)
> >> >
> >> > Is dreamplug support in the kirkwood flavour still a possibility? It
> >> > required an ABI bump which is why it hasn't been done yet.
> >>
> >> I've lost track of the status of that.
> >
> > I've done the (mostly trivial) backport to 3.2 and am running it day to
> > day, it was basically pending an ABI bump due to the requirement to
> > enable the DT config option.
> >
> >> Is there a bug report for it?
> >
> > I don't think so, I'll double check and file one if not.
> >
> > Can we also install the DTB files on armel, i.e. something like
> > http://lists.debian.org/debian-kernel/2012/04/msg00571.html ? Shall I
> > make that a separate bug?
> >
>
> I'm still unsure about dtb vs dtc+dts but I guess that having to deal
> with a conflict with the dtc package would not be "fun".
I'm not entirely sure why Linux has apparently forked dtc, but given
that it has using the one from Linux seems wise and at that point we may
as well ship the dtb?
> btw, what about f-k side ? I was also wondering about suggesting to add
> some dummy bytes on kirkwood when not appending a dtb [ if we enable
> ARM_APPENDED_DTB ] to make sure that memory garbage is not detected as a
> dtb. wdyt ?
If you append some bytes then you would need to subtract those when you
came to append a DTB, which is harder than using "cat" like you can now.
I don't know about other platforms but my dreamplug shipped with a
command clear_kernel_in_mem which was called in the boot sequence:
setenv clear_kernel_in_mem echo Purging kernel in memory\; mw 0x6400000 0x0 0x300000
I would think this same approach would work for any platform which was
worried about false positives from APPENDED_DTB? Alternatively I suppose
u-boot could be convinced to append some zeroes to the end of the kernel
after loading using mw and the env vars set by the load commands.
I filed a bug+patch against flash-kernel to support copy DTBs into /boot
(I didn't do appending, but that would be possible too...) its #667681.
I think I still owe that an updated version which
uses /proc/device-tree/model to detect the exact platform.
Ian.
Attachment:
signature.asc
Description: This is a digitally signed message part