Who's the maintainer for the freescale MPC8349ITX board?

I'm sorry if this is a stupid question, but I can't figure it out from 
anything in the source.  I don't want to clutter up the mailing list with 
newbie questions so I'd like to get in touch with the person who did the 
linux/u-boot port for the MPC8349ITX board and take the discussion off 
line.

Thanks for the help.

Bruce Leonard
Schweitzer Engineering Labs
Pullman, WA USA

On Jan 17, 2007, at 12:27 AM, Bruce_Leonard@selinc.com wrote:

I'm sorry if this is a stupid question, but I can't figure it out from
anything in the source.  I don't want to clutter up the mailing  
list with
newbie questions so I'd like to get in touch with the person who  
did the
linux/u-boot port for the MPC8349ITX board and take the discussion off
line.

Ask the questions on the list, thus they are around for others to  
learn from if need by.

- kumar

linuxppc-embedded-bounces+brucle=selinc.com@ozlabs.org wrote on 01/17/2007 
07:42:09 AM:

On Jan 17, 2007, at 12:27 AM, Bruce_Leonard@selinc.com wrote:

quoted

anything in the source.  I don't want to clutter up the mailing 
list with
newbie questions so I'd like to get in touch with the person who 

Ask the questions on the list, thus they are around for others to 
learn from if need by.

- kumar

Well, okay.  I hate taking up bandwidth for something that's no doubt 
trivial to most of you, but here goes.  I'm trying to bring up the 
2.6.19.1 kernel using u-boot 1.1.6 on the MPC8349ITX board and I'm having 
problems with the open firmware part of it (which I am TOTALLY new to). 
Short version, I don't think the *.dts file for this board is correct and 
I'm wondering if anyone might have a newer version or good documentation 
as to the formatting of the *.dts files?

Long version: While booting the kernel it seems to hang in the do_div() 
call on line 933 of .../arch/powerpc/kernel/time.c (yes I know it's not 
really a call but inline assembly) because ppc_tb_freq is zero.  The 
get_freq() calls in generic_calibrate_decr() find the 'timebase-frequency' 
and 'clock-frequency' entries in the device tree, but the value is zero 
and thus ppc_tb_freq is zero.

Digging through the u-boot code, I found ft_setup() which is supposed to 
add some stuff to the device tree passed in on the bootm command line. One 
of the things it's supposed to do is fill in the 'timebase-frequency' 
portion of the device tree.  When it calls ft_get_prop() to find the 
'timebase-frequency' node it passes in the path 
'/cpus/PowerPC,8349@0/timebase-frequency' as what it's searching for, but 
what ft_get_prop() finds is 
'///cpus//cpus/PowerPC,8349@0/timebase-frequency', which of course doesn't 
match, so it returns NULL to ft_setup() and the 'timebase-frequency' never 
gets updated before being passed to the kernel.

So I'm guessing the my problem is either the *.dts file or dtc, but I'm 
not sure which since I'm so new to this and I'm not sure if the *.dts file 
I've got is properly formatted.  I suppose it's possible that 
ft_get_prop() in u-boot is wrong, but for now I'm betting it's right and 
my *.dts file is formatted wrong.  (FYI, I'm using 
.../arch/powerpc/boot/dts/mpc8349emitx.dts from the 2.6.19.1 kernel tree.)

Thanks for listening and for your feedback.

Bruce

On Jan 17, 2007, at 9:55 PM, Bruce_Leonard@selinc.com wrote:

linuxppc-embedded-bounces+brucle=selinc.com@ozlabs.org wrote on  
01/17/2007
07:42:09 AM:

quoted

On Jan 17, 2007, at 12:27 AM, Bruce_Leonard@selinc.com wrote:

quoted

anything in the source.  I don't want to clutter up the mailing
list with
newbie questions so I'd like to get in touch with the person who

Ask the questions on the list, thus they are around for others to
learn from if need by.

- kumar

Well, okay.  I hate taking up bandwidth for something that's no doubt
trivial to most of you, but here goes.  I'm trying to bring up the
2.6.19.1 kernel using u-boot 1.1.6 on the MPC8349ITX board and I'm  
having
problems with the open firmware part of it (which I am TOTALLY new  
to).
Short version, I don't think the *.dts file for this board is  
correct and
I'm wondering if anyone might have a newer version or good  
documentation
as to the formatting of the *.dts files?

There should be an update dts in the kernel source under arch/powerpc/ 
boot/dts

Long version: While booting the kernel it seems to hang in the  
do_div()
call on line 933 of .../arch/powerpc/kernel/time.c (yes I know it's  
not
really a call but inline assembly) because ppc_tb_freq is zero.  The
get_freq() calls in generic_calibrate_decr() find the 'timebase- 
frequency'
and 'clock-frequency' entries in the device tree, but the value is  
zero
and thus ppc_tb_freq is zero.

Sounds like your u-boot isn't properly filling out parts of the  
devtree while booting.

Digging through the u-boot code, I found ft_setup() which is  
supposed to
add some stuff to the device tree passed in on the bootm command  
line. One
of the things it's supposed to do is fill in the 'timebase-frequency'
portion of the device tree.  When it calls ft_get_prop() to find the
'timebase-frequency' node it passes in the path
'/cpus/PowerPC,8349@0/timebase-frequency' as what it's searching  
for, but
what ft_get_prop() finds is
'///cpus//cpus/PowerPC,8349@0/timebase-frequency', which of course  
doesn't
match, so it returns NULL to ft_setup() and the 'timebase- 
frequency' never
gets updated before being passed to the kernel.

Hmm, that's odd.  I'm pretty sure the '/' are added while we parse  
the tree seems like some prefix is getting added on you '///cpus/' if  
I was to guess.  I'd double check your .dts against the one in the  
kernel tree.

So I'm guessing the my problem is either the *.dts file or dtc, but  
I'm
not sure which since I'm so new to this and I'm not sure if the  
*.dts file
I've got is properly formatted.  I suppose it's possible that
ft_get_prop() in u-boot is wrong, but for now I'm betting it's  
right and
my *.dts file is formatted wrong.  (FYI, I'm using
.../arch/powerpc/boot/dts/mpc8349emitx.dts from the 2.6.19.1 kernel  
tree.)

Well that's really odd than.  I'd try grabbing u-boot 1.2.0 and see  
if you still have the same issue.

Also, how are you invoking dtc to get the dtb?

Thanks for listening and for your feedback.

- k

On 1/17/07, Bruce_Leonard@selinc.com [off-list ref] wrote:

I'm trying to bring up the
2.6.19.1 kernel using u-boot 1.1.6 on the MPC8349ITX board and I'm having
problems with the open firmware part of it (which I am TOTALLY new to).
Short version, I don't think the *.dts file for this board is correct and
I'm wondering if anyone might have a newer version or good documentation
as to the formatting of the *.dts files?

There is some device tree documentation in the kernel tree:
Documentation/powerpc/booting-without-of.txt

Also, make sure you're either using the latest dtc;  If not, then you
need to use the '-V 0x10' switch to get the correct tree format.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi all,

Kumar Gala [off-list ref] wrote on 01/17/2007 08:23:50 PM:
[...major snip...]

Well that's really odd than.  I'd try grabbing u-boot 1.2.0 and see 
if you still have the same issue.

Do you mean u-boot 2.0 or did you really mean go backwards?  I've diffed 
ft_build.c between 1.1.6 and 2.0 and they're the same.

Also, how are you invoking dtc to get the dtb?

Originally is was using:
'dtc -I dts -O dtb mpc8349emitx.dts > 8349.blob'

Per Grant's suggestion I changed it to:
'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob'

It changed the behavior but it still doesn't boot.  Something else I've 
observed that leads me to believe the *.dts is bad is that i have no 
output on the serial port once I jump to the kernel code.

Thanks for the suggestions, I'll keep digging.

Bruce

On Thu, 18 Jan 2007 10:33:55 -0800
Bruce_Leonard@selinc.com wrote:

Per Grant's suggestion I changed it to:
'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob'

I get a 0 length 8349.blob file using the above.  Have you tried -f?

Kim

Bruce_Leonard@selinc.com wrote:

quoted

quoted

anything in the source.  I don't want to clutter up the mailing 
list with
newbie questions so I'd like to get in touch with the person who 

I'm the maintainer.

Well, okay.  I hate taking up bandwidth for something that's no doubt 
trivial to most of you, but here goes.  I'm trying to bring up the 
2.6.19.1 kernel using u-boot 1.1.6 on the MPC8349ITX board and I'm having 

1.1.6 does not support the MPC8349ITX.  Try 1.2.0.  My name is listed as the 
maintainer for this board in the U-Boot MAINTAINERS file.

problems with the open firmware part of it (which I am TOTALLY new to). 
Short version, I don't think the *.dts file for this board is correct and 
I'm wondering if anyone might have a newer version or good documentation 
as to the formatting of the *.dts files?

Long version: While booting the kernel it seems to hang in the do_div() 
call on line 933 of .../arch/powerpc/kernel/time.c (yes I know it's not 
really a call but inline assembly) because ppc_tb_freq is zero.  The 
get_freq() calls in generic_calibrate_decr() find the 'timebase-frequency' 
and 'clock-frequency' entries in the device tree, but the value is zero 
and thus ppc_tb_freq is zero.

Digging through the u-boot code, I found ft_setup() which is supposed to 
add some stuff to the device tree passed in on the bootm command line. One 
of the things it's supposed to do is fill in the 'timebase-frequency' 
portion of the device tree.  When it calls ft_get_prop() to find the 
'timebase-frequency' node it passes in the path 
'/cpus/PowerPC,8349@0/timebase-frequency' as what it's searching for, but 
what ft_get_prop() finds is 
'///cpus//cpus/PowerPC,8349@0/timebase-frequency', which of course doesn't 
match, so it returns NULL to ft_setup() and the 'timebase-frequency' never 
gets updated before being passed to the kernel.

This sounds like a generic bug in the U-Boot OF code, but I'll check it out. 
The DTS for the 8349ITX is defined just like the other DTSes.

So I'm guessing the my problem is either the *.dts file or dtc, but I'm 

Hmmm, it could be the DTC.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Kim Phillips [off-list ref] wrote on 01/18/2007 10:40:31 AM:

quoted

Per Grant's suggestion I changed it to:
'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob'

I get a 0 length 8349.blob file using the above.  Have you tried -f?

Kim

Hummmmm, interesting.  I get a blob of about 4K when I do it.  Oh, ooops. 
Sorry.  I did have to modify the *.dts file to get it to compile.  There 
was an error because there wasn't a 'linux,boot-cpu' entry in the cpu 
node.

Adding the '-V 0x10' changed the behavior and I now seem to be hanging in 
__delay() in serial8250_console_putchar().  Seems maybe the kernel is (at 
least partially) up but I've got no console port.  There may have been a 
version issue.  The DTC I'm using defaluted to a version 3 of the device 
tree.  I think I'm getting further in the kernel booting process (haven't 
had a chance to really debug it yet) than I was now that I'm telling DCT 
to generate a version 0x10 device tree.

I'm thinking this is a u-boot/*.dts file problem.  The *.dts files isn't 
complete and/or u-boot 1.1.6. isn't finishing filling in the device tree 
as expected.  I think now my problem is that the *.dts file expects u-boot 
to fill in the 'clock-frequency' node in the serial ports and it's not 
doing so.  Timur indicates 1.1.6 doesn't support this board and I should 
move to 1.2.  Kumar also suggested this (even though I thought he was 
suggesting I go backwards ;) sorry for the confusion Kumar) so I think 
I'll give it a try.  I appreciate all the help from here, but since it 
seems more u-boot-ish than kernel I'm going to switch this to the u-boot 
list.  Seems more appropriate.  If I find there are problems with the 
*.dts file, I'll push that back here since they're part of the kernel 
tree.

Thanks again for the help.

Bruce

On 1/18/07, Bruce_Leonard@selinc.com [off-list ref] wrote:

Kim Phillips [off-list ref] wrote on 01/18/2007 10:40:31 AM:

quoted

quoted

Per Grant's suggestion I changed it to:
'dtc -I dts -O dtb -V 0x10 mpc8349emitx.dts > 8349.blob'

I get a 0 length 8349.blob file using the above.  Have you tried -f?

Kim

Hummmmm, interesting.  I get a blob of about 4K when I do it.  Oh, ooops.
Sorry.  I did have to modify the *.dts file to get it to compile.  There
was an error because there wasn't a 'linux,boot-cpu' entry in the cpu
node.

BTW, you don't need to add a linux,boot-cpu node to your .dts file.
In fact you don't need anything in the /chosen node at all.  Just pass
the -f flag to your version of dtc.  (This is also something fixed in
the latest dtc code from www.jdl.com)

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

quoted

'/cpus/PowerPC,8349@0/timebase-frequency' as what it's searching for, but 
what ft_get_prop() finds is 
'///cpus//cpus/PowerPC,8349@0/timebase-frequency', which of course doesn't 
match, so it returns NULL to ft_setup() and the 'timebase-frequency' never 
gets updated before being passed to the kernel.

This sounds like a generic bug in the U-Boot OF code, but I'll check it out. 
The DTS for the 8349ITX is defined just like the other DTSes.

Reminds me we should really look into writing, one of these days, both
for uboot, the zImage wrapper, and the kernel itself, a smarter OF path
parser that can

 - ignore spurrious /
 - handle relative path from a given node
 - handles getting passed the name without the unit address (the @ part)
   when non-ambiguous (when ambiguous, returns one of the nodes matching
   with no guarantee of which one)
 - handles getting passed the unit address without the name

That would make usage of path for "fixing up" properties or looking up
properties easier in many cases.

Any volunteer ? :-)

Ben.