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

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

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.