Hi Mounir,
Took me a while, but here are the instructions for testing DT support on IGEP:
The current nightly u-boot builds should work out-of-the-box with
device tree support. You can use the prebuilt binaries
>From what I can tell, the kernel build doesn't yet have DT enabled for
any of the p
On Mon, Mar 21, 2011 at 03:25:16AM -0600, Grant Likely wrote:
>
[...]
> - Add packaging of .dtb files into linux-image-linaro-* packages.
> Loic and I discussed putting them under /lib/dtb/`uname -r`/, but
> thinking about it more, it might make more sense to share the modules
> directory and use
On Mon, Mar 28, 2011 at 9:35 AM, Grant Likely wrote:
> On Mon, Mar 28, 2011 at 9:10 AM, Tixy wrote:
>> Just found a device tree bug which corrupts __machine_type.
>> In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
>>
>> - __machine_arch_type = mdesc->nr;
>> + __machine_arch_type = mdes
On Mon, Mar 28, 2011 at 9:10 AM, Tixy wrote:
> Just found a device tree bug which corrupts __machine_type.
> In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
>
> - __machine_arch_type = mdesc->nr;
> + __machine_arch_type = mdesc_best->nr;
>
> This was stopping some Beagleboard drivers fr
Just found a device tree bug which corrupts __machine_type.
In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
- __machine_arch_type = mdesc->nr;
+ __machine_arch_type = mdesc_best->nr;
This was stopping some Beagleboard drivers from being initialised as
they were doing run-time checking
Just found a device tree bug which corrupts __machine_type.
In arch/arm/kernel/devtree.c at end of setup_machine_fdt()
- __machine_arch_type = mdesc->nr;
+ __machine_arch_type = mdesc_best->nr;
This was stopping some Beagleboard drivers from being initialised as
they were doing run-time checking
[cc'ing linaro-dev mailing list; other people will probably have the
same question]
On Mon, Mar 28, 2011 at 4:40 AM, Tixy wrote:
> On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
>> For each board, I need an engineer to do the following:
>>
> [...]
>> 2) Enable CONFIG_OF and CONFIG_PROC_DE
> tackling the off-by-one ramdisk sizes when I thought I'd check the list
> to see if anyone had been there before me :-)
:-) The tree I posted as a reply to the Device Tree on ARM status
report email shows my current trees. There were 2 initrd off-by-one
bugs, one in the kernel and o
On Fri, 2011-03-25 at 22:46 -0600, Grant Likely wrote:
[...]
> It appears that when U-Boot
> relocates the .dtb, it either moves it to a location that the kernel
> cannot read during early boot, or it corrupts it when it is moved.
> Either way, the kernel is hooped when it tries to parse the device
For those of you working on bringing up arm device tree support
against the Linaro u-boot * kernel trees, I've just pushed out a
couple of branches that work on Panda board. It's not complete yet
because there are some bugs I found in both the kernel and in u-boot,
but it should be useful to base
On Wed, Mar 23, 2011 at 3:11 PM, Grant Likely wrote:
> On Tue, Mar 22, 2011 at 04:58:26PM -0700, Andy Doan wrote:
>> On 03/21/2011 02:25 AM, Grant Likely wrote:
>> > Here is the list of hwpacks that should be supported to the best of my
>> > knowledge. Please reply with the hwpacks you can take r
On Wed, Mar 23, 2011 at 04:08:59PM -0600, John Rigby wrote:
> FDT support is in both so stick with stable. It is only enabled for
> beagle. Search of FDT in include/config/omap3_beagle.h to see how to
> turn it on for other boards.
>
> If we want this turned on for other boards let me know which
FDT support is in both so stick with stable. It is only enabled for
beagle. Search of FDT in include/config/omap3_beagle.h to see how to
turn it on for other boards.
If we want this turned on for other boards let me know which ones.
John
On Wed, Mar 23, 2011 at 3:09 PM, Grant Likely wrote:
>
On Tue, Mar 22, 2011 at 09:58:58AM +, Tixy wrote:
> Hi Grant
>
> On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
> > For each board, I need an engineer to do the following:
> >
> > 1) Enable CONFIG_OF_LIBFDT and CONFIG_SYS_BOOTMAPSZ against the Linaro
> > u-boot tree.
>
> Which tree s
Hi Grant
On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
> For each board, I need an engineer to do the following:
>
> 1) Enable CONFIG_OF_LIBFDT and CONFIG_SYS_BOOTMAPSZ against the Linaro
> u-boot tree.
Which tree should I use, u-boot-linaro-stable or u-boot-linaro-next ?
--
Tixy
__
I had great hopes of doing these status reports once a week; but it
turns out to take more effort to get together that I estimated.
Here's the status of ARM device tree support as of today. As always,
let me know if you have any corrections or additional information.
1 - Latest news
-
On Mon, 2011-02-07 at 14:28 -0700, Grant Likely wrote:
> On Mon, Feb 7, 2011 at 1:46 AM, Amit Kucheria
> wrote:
> > On 11 Feb 05, Grant Likely wrote:
> >> 2 - Task status
> >> ---
> >> Core infrastructure:
> >> [glikely] basic infrastructure to enable dt: DONE
> >> [r-herring] Allow d
On Mon, Feb 7, 2011 at 1:46 AM, Amit Kucheria wrote:
> On 11 Feb 05, Grant Likely wrote:
>> 2 - Task status
>> ---
>> Core infrastructure:
>> [glikely] basic infrastructure to enable dt: DONE
>> [r-herring] Allow dtb to be located anywhere in RAM: DONE
>> [bones] Debug dtb corruption d
On Sun, Feb 6, 2011 at 12:42 PM, Grant Likely wrote:
> Hi all,
>
[...]
>
> imx51 tasks
> enable dtb support in u-boot: TODO
> enable basic kernel dtb support: TODO
> enable registration of devices form dt: TODO
> ... add more details here, specific devices, etc...
>
[...]
> Shawn Guo [] imx51
I'm
On 11 Feb 05, Grant Likely wrote:
> Hi all,
>
> With several more engineers working on ARM device tree support, I'm
> going to start collecting the status of all the work that is going on
> (and I know about) and posting it in a regular status report,
> hopefully weekly, for the next few months un
On 6 February 2011 10:12, Grant Likely wrote:
> Hi all,
>
> With several more engineers working on ARM device tree support, I'm
> going to start collecting the status of all the work that is going on
> (and I know about) and posting it in a regular status report,
> hopefully weekly, for the next f
Hi all,
With several more engineers working on ARM device tree support, I'm
going to start collecting the status of all the work that is going on
(and I know about) and posting it in a regular status report,
hopefully weekly, for the next few months until the all of the major
features are implemen
22 matches
Mail list logo
