public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* PowerPC questions
@ 2004-10-11  5:23 Anthony Tonizzo
  0 siblings, 0 replies; 2+ messages in thread
From: Anthony Tonizzo @ 2004-10-11  5:23 UTC (permalink / raw)
  To: ecos-devel

Hi:

During the weekend I had to port eCos to a new platform based on the
PowerPC. Since eCos wanted to fight, I had to step through the whole
initialization sequence, and in the process, I came across a something
that need clarification, plus something downright misterious.

The clarification regards the some code that deals with the allocation 
of the buffer descriptors used by the rs-232 device. This is in quicc_smc1.c
and it looks something like this (for the RX buffers, but for the TX it
is more of the same...):

uart_pram->rbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum);

What I do not understand here is the "+ info->Rxnum". If we have to 
allocate Rxnum buffer descriptors, each 8 bytes long, the the only
thing needed is the number of buffer secriptors to allocate time the
length of a buffer descriptor.

This makes sure that the value passed is a multiple of 8 (the size of a
buffer descriptor ). The extra addition of "info->Rxnum" also creates an 
issue inside

_mpc8xx_allocBd()      //     (in file cpm.c)

since there is an ASSERT() if the value passed is not a multiple of 8. If
we add "info->Rxnum" to the length of the area to allocate we are sure to 
catch the assertion (unless we need 8 buffer descriptors.) The _mpc8xx_allocBd() 
goes on to normalize the length to a multiple of 8 with something like this:

len = (len + 7) & ~7;  // Multiple of 8 bytes

So isn't it more correct like this:

uart_pram->rbase = _mpc8xx_allocBd(sizeof(struct cp_bufdesc)*info->Rxnum);

in quicc_smc1.c and then

// Only if the length is not a multiple of 8...
if ( len & 7 )  
    len = (len & 7) + sizeof(struct cp_bufdesc);  

in smc.c?

The whole thing is pretty puzzling, because Rxnum is 4, and so the assertion
should be caught every time. Yet I have never had any issue with this
with my MBX board. Evidently I am missing something.

The second thing I find totally misterious happens in redboot.c. This is
where my BSP currently fails, and I need to understand what is going on. 
The code is this:

for (init_entry = __RedBoot_INIT_TAB__; init_entry != &__RedBoot_INIT_TAB_END__;  init_entry++) {
    (*init_entry->fun)();
}

There are no comments in the code, so any wisdom is appreciated. What does 
this code do? What are the items of the init_entry structure? O tried to 
look around the file, but I got nowhere.

Thanks
Anthony Tonizzo


-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: PowerPC questions
@ 2004-10-12  6:34 Harald Küthe
  0 siblings, 0 replies; 2+ messages in thread
From: Harald Küthe @ 2004-10-12  6:34 UTC (permalink / raw)
  To: ecos-devel

Hello Anthony

I stumbled around the same thing. There are 2 drivers for the smc's. 
I think one is used very early during init time. It uses the extra byte for the data transfer. 
so each bd has only one byte which is as well located in the dpram.

There is one patch in the list
    /*
     *  Set pointers to buffer descriptors.
     *  (Sections 16.15.4.1, 16.15.7.12, and 16.15.7.13)
     */
    len = sizeof(struct cp_bufdesc)*info->Rxnum + info->Rxnum;
    len = (len + 7) & ~7;    // Make len Multiple of 8 bytes
    uart_pram->rbase = _mpc8xx_allocBd(len);
    len = sizeof(struct cp_bufdesc)*info->Txnum + info->Txnum;
    len = (len + 7) & ~7;    // Make len Multiple of 8 bytes
    uart_pram->tbase = _mpc8xx_allocBd(len);
which 'solves' the assert issue

It seems that everyone uses only the NDEBUG version for ppc.

The second driver seems to be used later (located in devs/serial/...)
It uses a static bufferpool.

Thats what I found out, it is strange.

Regards
Harald

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2004-10-12  6:34 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-11  5:23 PowerPC questions Anthony Tonizzo
2004-10-12  6:34 Harald Küthe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).