From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Date: Fri, 31 Oct 2008 13:25:14 +0100 Subject: [U-Boot] U-boot support for Non Console board In-Reply-To: <490AF4A9.9080508@ge.com> References: <843260.87725.qm@web50008.mail.re2.yahoo.com> <20081031112632.64E13874F93F@gemini.denx.de> <490AF4A9.9080508@ge.com> Message-ID: <20081031122514.GA30935@game.jcrosoft.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.