[U-Boot] U-boot support for Non Console board

[U-Boot] U-boot support for Non Console board

[rajeev s]

Hi ,  
We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
port->no console) 
I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
I do not have a Console to do that ?

Please let me know the inputs ?

Thanks and Regards
Rajeev S

 
       

[U-Boot] U-boot support for Non Console board

[Wolfgang Denk]

Dear rajeev s,

In message <843260.87725.qm@web50008.mail.re2.yahoo.com> you wrote:
>
> We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
> The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
> port->no console) 
> I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
> I do not have a Console to do that ?

Well, somebody who designed this system must also have had some plan
how to operate the board?

Not having a console port sounds like a really stupid thing to me.

If you have ethenret on your board, you can try netconsole. But it
will be no fun to port U-Boot to such hardware.

I suggest you bring the board back to the hardware guys and ask for a
serial console port, at least for bring-up and debugging.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"In matrimony, to hesitate is sometimes to be saved."        - Butler

[U-Boot] U-boot support for Non Console board

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear rajeev s,
> 
> In message <843260.87725.qm@web50008.mail.re2.yahoo.com> you wrote:
>> We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
>> The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
>> port->no console) 
>> I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
>> I do not have a Console to do that ?
> 
> Well, somebody who designed this system must also have had some plan
> how to operate the board?
> 
> Not having a console port sounds like a really stupid thing to me.
> 
> If you have ethenret on your board, you can try netconsole. But it
> will be no fun to port U-Boot to such hardware.
> 
> I suggest you bring the board back to the hardware guys and ask for a
> serial console port, at least for bring-up and debugging.
> 
> Best regards,
> 
> Wolfgang Denk

On the u-boot side, you can write a "fake uart" that...
TX: Takes bytes and puts them in a "TX" queue in shared PCI memory.
RX: Looks at the "RX" queue in shared PCI memory for new characters.

Then on the host side, you write a custom fake uart driver to do the 
opposite (taking advantage of the OS's capabilities and support 
programs) or write a custom terminal program that implements the fake 
uart handling directly (simpler to get running, much less flexible and 
more maintenance long term).

The queue can be a simple /n/ byte array (I would set /n/ to 256 or some 
larger power of 2 since size doesn't matter ;-) with head and tail 
indexes.  The writer puts a byte in queue[head++] and the reader checks 
"if (head != tail) return queue[tail++]".  Note that there is only one 
writer to "head" and one to "tail" so you don't have any race 
condition/locking issues (assuming your r/w access is atomic and you 
don't code any bugs into your algorithm).

Details glossed over:
* head and tail must be incremented modulo the queue length
* You *NEVER* want to set head or tail to be equal to the queue length
     in the shared memory (that would be out-of-bounds on the array).
     "head = (head + 1) % sizeof(queue);" should be save (check the
     assembly code, compiled with optimization!).  If you use
     "head = ++head % sizeof(queue);", the compiler will write head++
     with with wrong value 256 every 256 bytes (see the next bullet)
     and then do the modulo and re-write head with the correct value (0).
* You need to make all the shared variables "volatile"
* You need to prevent head from overtaking tail.  For instance, if
     (head + 1) == tail (check *before* writing the byte to the queue),
     you have an overflow condition and will have to drop the byte.

I have not googled, I'm sure many people have done this before.  Maybe 
you will get lucky and someone will have published source under a GPL 
(compatible) license.

Best regards,
gvb

[U-Boot] U-boot support for Non Console board

[Jean-Christophe PLAGNIOL-VILLARD]

On 08:06 Fri 31 Oct     , Jerry Van Baren wrote:
> Wolfgang Denk wrote:
> > Dear rajeev s,
> > 
> > In message <843260.87725.qm@web50008.mail.re2.yahoo.com> you wrote:
> >> We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
> >> The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
> >> port->no console) 
> >> I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
> >> I do not have a Console to do that ?
> > 
> > Well, somebody who designed this system must also have had some plan
> > how to operate the board?
> > 
> > Not having a console port sounds like a really stupid thing to me.
> > 
> > If you have ethenret on your board, you can try netconsole. But it
> > will be no fun to port U-Boot to such hardware.
> > 
> > I suggest you bring the board back to the hardware guys and ask for a
> > serial console port, at least for bring-up and debugging.
> > 
> > Best regards,
> > 
> > Wolfgang Denk
> 
> On the u-boot side, you can write a "fake uart" that...
> TX: Takes bytes and puts them in a "TX" queue in shared PCI memory.
> RX: Looks at the "RX" queue in shared PCI memory for new characters.
> 
> Then on the host side, you write a custom fake uart driver to do the 
> opposite (taking advantage of the OS's capabilities and support 
> programs) or write a custom terminal program that implements the fake 
> uart handling directly (simpler to get running, much less flexible and 
> more maintenance long term).
> 
> The queue can be a simple /n/ byte array (I would set /n/ to 256 or some 
> larger power of 2 since size doesn't matter ;-) with head and tail 
> indexes.  The writer puts a byte in queue[head++] and the reader checks 
> "if (head != tail) return queue[tail++]".  Note that there is only one 
> writer to "head" and one to "tail" so you don't have any race 
> condition/locking issues (assuming your r/w access is atomic and you 
> don't code any bugs into your algorithm).
> 
> Details glossed over:
> * head and tail must be incremented modulo the queue length
> * You *NEVER* want to set head or tail to be equal to the queue length
>      in the shared memory (that would be out-of-bounds on the array).
>      "head = (head + 1) % sizeof(queue);" should be save (check the
>      assembly code, compiled with optimization!).  If you use
>      "head = ++head % sizeof(queue);", the compiler will write head++
>      with with wrong value 256 every 256 bytes (see the next bullet)
>      and then do the modulo and re-write head with the correct value (0).
> * You need to make all the shared variables "volatile"
> * You need to prevent head from overtaking tail.  For instance, if
>      (head + 1) == tail (check *before* writing the byte to the queue),
>      you have an overflow condition and will have to drop the byte.
> 
> I have not googled, I'm sure many people have done this before.  Maybe 
> you will get lucky and someone will have published source under a GPL 
> (compatible) license.
IIRC I've seen this in the Prism54 driver

Best Regards,
J.

[U-Boot] U-boot support for Non Console board

[Ira Snyder]

On Fri, Oct 31, 2008 at 01:25:14PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:06 Fri 31 Oct     , Jerry Van Baren wrote:
> > Wolfgang Denk wrote:
> > > Dear rajeev s,
> > > 
> > > In message <843260.87725.qm@web50008.mail.re2.yahoo.com> you wrote:
> > >> We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
> > >> The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
> > >> port->no console) 
> > >> I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
> > >> I do not have a Console to do that ?

[snip]

> > 
> > I have not googled, I'm sure many people have done this before.  Maybe 
> > you will get lucky and someone will have published source under a GPL 
> > (compatible) license.
> IIRC I've seen this in the Prism54 driver
> 

I'm currently working on a custom board based on MPC8349EMDS. It works
in PCI agent mode.

I have written a Linux driver that implements both ethernet and a uart
over the PCI bus. I don't think it would be hard to port to your board.
Search the linuxppc-dev or LKML archives for the patch. The subject is
"net: add PCINet driver".

I'm currently trying to get the driver merged into Linux. I have also
written U-Boot drivers that offer the same functionality. I can "see"
the U-Boot prompt over PCI, and tftp + nfs boot over PCI. It is very
convenient.

I was going to post up the U-Boot drivers after I get the Linux driver
merged, just in case there are changes. I've inlined the patches below.
The first adds ethernet, the second adds a serial port.

Please note that they are MPC8349EMDS specific right now, but they might
provide inspiration. Showing your support of the PCINet driver on LKML
might help get it reviewed. Noone has taken much interest.

Ira

[U-Boot] U-boot support for Non Console board

[rajeev s]

hi Ira Snyder,
Thanks for the respone. The solution mentioned looks feasible..

Could you please send the U-boot patch in the current shape .. Shall test the same patch with modifications as required to support our board.

Thanks again .
Rajeev S


Ira Snyder <iws@ovro.caltech.edu> wrote: On Fri, Oct 31, 2008 at 01:25:14PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:06 Fri 31 Oct     , Jerry Van Baren wrote:
> > Wolfgang Denk wrote:
> > > Dear rajeev s,
> > > 
> > > In message <843260.87725.qm@web50008.mail.re2.yahoo.com> you wrote:
> > >> We have a custom board based on coldfire (MCF5484) Similar to MCF5484 Kitlite
> > >> The board runs Coldfire as PCI agent , 64MB of SDRAM, 4 MB of Bootflash and the PCI bus as a slave (no serial
> > >> port->no console) 
> > >> I can flash U-boot using the JTAG . Can you let know how can i pass the Commands over PCI .
> > >> I do not have a Console to do that ?

[snip]

> > 
> > I have not googled, I'm sure many people have done this before.  Maybe 
> > you will get lucky and someone will have published source under a GPL 
> > (compatible) license.
> IIRC I've seen this in the Prism54 driver
> 

I'm currently working on a custom board based on MPC8349EMDS. It works
in PCI agent mode.

I have written a Linux driver that implements both ethernet and a uart
over the PCI bus. I don't think it would be hard to port to your board.
Search the linuxppc-dev or LKML archives for the patch. The subject is
"net: add PCINet driver".

I'm currently trying to get the driver merged into Linux. I have also
written U-Boot drivers that offer the same functionality. I can "see"
the U-Boot prompt over PCI, and tftp + nfs boot over PCI. It is very
convenient.

I was going to post up the U-Boot drivers after I get the Linux driver
merged, just in case there are changes. I've inlined the patches below.
The first adds ethernet, the second adds a serial port.

Please note that they are MPC8349EMDS specific right now, but they might
provide inspiration. Showing your support of the PCINet driver on LKML
might help get it reviewed. Noone has taken much interest.

Ira

[U-Boot] U-boot support for Non Console board

[Ira Snyder]

On Mon, Nov 03, 2008 at 09:17:48PM -0800, rajeev s wrote:
> hi Ira Snyder,
> Thanks for the respone. The solution mentioned looks feasible..
> 
> Could you please send the U-boot patch in the current shape .. Shall test the same patch with modifications as required to support our board.

The two U-Boot patches (one for ethernet, one for serial) were inlined
into my last message to this thread. I haven't changed them since that
post.

I've inlined the Linux patch below. I've posted it to the lkml,
linux-netdev, and linux-ppcdev lists, but I haven't gotten much feedback
other than "Wow, that's cool. We could really use that." I'm not sure if
nobody is interested, or if they are just ignoring me.

Ira