Who's the maintainer for the freescale MPC8349ITX board?

Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Kumar Gala]

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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

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:
> 
> > 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Kumar Gala]

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:
>
>>
>> On Jan 17, 2007, at 12:27 AM, Bruce_Leonard@selinc.com wrote:
>>
>>> 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Grant Likely]

On 1/17/07, Bruce_Leonard@selinc.com <Bruce_Leonard@selinc.com> 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

Hi all,

Kumar Gala <galak@kernel.crashing.org> 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Kim Phillips]

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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Timur Tabi]

Bruce_Leonard@selinc.com wrote:

>>> 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

Kim Phillips <kim.phillips@freescale.com> wrote on 01/18/2007 10:40:31 AM:

> > 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Grant Likely]

On 1/18/07, Bruce_Leonard@selinc.com <Bruce_Leonard@selinc.com> wrote:
> Kim Phillips <kim.phillips@freescale.com> wrote on 01/18/2007 10:40:31 AM:
>
> > > 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Russell McGuire]

Bruce,

Did you ever get linux to boot up?

I am wondering if I am having similar problems on my system, though it is
based on the MPC8360E. Serial port code and clocking is the same between
these systems, at least it should be.

I am using Linux 2.6.19.2, and U-boot 1.1.6-dirty, though I think it
'mostly' U-boot 1.2.0 equivalent code, as 1.2.0 was released about a day
after I downloaded it.

I also can generate a 8360.blob file, and when I attempt to boot into the
kernel, it hangs with ZERO serial output, even though early serial is
defined.

-Russ

> > 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

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

"Russell McGuire" <rmcguire@uwbt.com> wrote on 01/19/2007 07:06:56 PM:

> Bruce,
> 
> Did you ever get linux to boot up?
> 
> I am wondering if I am having similar problems on my system, though it 
is
> based on the MPC8360E. Serial port code and clocking is the same between
> these systems, at least it should be.
> 
> 
Russ (and anyone else who may be watching this thread),

I did finally get the 2.6.19 kernel to boot using u-boot 1.2.0/open 
firmware device tree, but I had to do some hacking on a *.dts file that 
Timur sent me.  There may also be issues with assumptions that u-boot 
makes versus the assumptions the kernel makes versus assumptions that DTC 
make.  But, I haven't had a chance to work this issue for the last few 
days and before I put out a final word I want to have all my ducks in a 
row.  I'm going to get back to this on Monday, so stand by for more 
tomorrow evening.

Bruce

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Benjamin Herrenschmidt]

> > '/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.

Re: Who's the maintainer for the freescale MPC8349ITX board?

[Bruce_Leonard]

"Russell McGuire" <rmcguire@uwbt.com> wrote on 01/19/2007 07:06:56 PM:

> Bruce,
> 
> Did you ever get linux to boot up?
> 
> I am wondering if I am having similar problems on my system, though it 
is
> based on the MPC8360E. Serial port code and clocking is the same between
> these systems, at least it should be.
Russ,

Sorry I took so long to get back to you on this.  I've spent the last 
couple of days trying to reproduce the problems I had bringing this board 
up to see if there really were any issues in the code or if it was just me 
not knowing what the heck I was doing.  Turned out to be the latter, 
naturally.

I can't speak to the 8360, but since it's in the same family I expect the 
differences in this regard are trivial.  I did finally manage to get the 
2.6.19.1 kernel to boot on the MPC8349ITX board using u-boot 1.2.0 (I 
don't know if u-boot 1.1.6-dirty is close enough or not) and the 
mpc8349emitx.dts file in the 2.6.19.1 tree.  Some things to know however 
(which I didn't when I started :O ).  You need to use the '-f' flag with 
the DTC to force it to compile (at least I had to with the version I 
have), otherwise it will error out when it finds no 'chosen' node.  You 
don't need one, u-boot will add a 'chosen' node on the fly.  Also, you 
need to use the '-V 0x10' flag in DTC, otherwise it defaults to making a 
version 3 blob.  u-boot seems unable to parse a version 3 blob and 
therefore can't fill in the properties it needs to for the kernel to boot. 
 So, in the end my command to generate the blob file looked like this:

./dtc -I dts -O dtb -f -V 0x10 mpc8349emitx.dts > 8349.blob

This worked for me, your milage may vary.

See 'ya!

Bruce