Colin,

In response to your question about LoLo API there is extensive documentation installed to the path 'C:\cygwin\home\logic\sample_zoom_app\docs\html' when you download and install the Zoom Sample Application from the following link:

http://www.logicpd.com/do...sample_app_1_6_2.zip

I'll have someone look into the first part of your post.

Thank you,

Aaron

Thanks for the reply. The reason I could find nothing on the API was that my doco was out of date. Our SDK reports the following version info:



Should I be looking at replacing LoLo (and/or BoLo)?

I noticed that the API provides malloc and other memory handling functions - Is there a reason to use these and not the standard libraries? (in our case supplied via the ARM RVDS - RealView Developers Suite).

Are there any issues (parameter passing etc) that I would need to be aware of if I wanted to use the APIs with RVDS?

For whoever might be looking at my previous code I have created a simpler version which should just send "<>" to the UART. It exhibits the same problem as I reported previously.



Many Thanks
Colin

colin,

I'm going to try and answer your questions, but it might take a few more back and forths, so please don't get discouraged.

Memory being repeated:

In order to handle many sizes of SDRAM, the controller built into the A40x processors have a few interesting properties. The most significant of these is manufactured "holes" for 32 and 64 Mbyte SDRAM configurations. I believe that we have all of this documented in the user's guide or the one of the other guides. This is also all documented in the Sharp manuals.

Basically, with 32 Mbytes of SDRAM, you wind up with chunks of 4Mbyte blocks seperated by invalid (or repeated) spaces in the memory map. With 64 Mbytes of SDRAM attached to the processor, you get 8Mbyte chunks.

The LogicLoader (and other operating systems) program the chip's Memory Management Unit (MMU) to make the SDRAM address space appear flat. If you are writing your own code, and you want a flat address space, then you need to do the same thing. If you don't want to setup the MMU, then you need to understand and deal with the holes in the memory map some other way.

Should you be looking at replacing LoLo:

I recommend staying current if possible. The latest version should be available for download from the website. Upgrading is an easy operation.

LoLo's API versus the ARM RDS libraries:

Because LoLo is a "general" bootloader environment, it stays away from proprietary libraries. LoLo is built using the GNU tools and contains its own, minimal implementation of the standard C-library.

LoLo boots all kinds of operating systems and programs including; Linux, WindowsCE, VxWorks, uCOS-II, and custom programs.

LoLo also runs on several different processor architectures including; ARM, XScale, SH, and ColdFire.

Finally, LoLo runs on at least a dozen different hardware platforms.

Due to our requirements of supporting all of those various operating systems, architectures, and platforms, we cannot tie ourselves down to one set of development tools and environment.

If you want to write your own stand-alone application which uses all of the ARM libraries, you are free to do so. You may continue to use LoLo as your bootloader (thus saving you from rewriting flash routines, file-systems, board initialization, etc.) and jump to your application via the "exec" or "jump" command.

Using the LoLo API with RVDS:

You won't be able to do this. The LoLo API is implemented via a system-call, trap architecture. I've no idea how RVDS is implemented, but it won't be the same way.

Hope this helps a bit, feel free to write back for more clarification on anything.

Regards,
--mikee

Hi Mike

Thanks for the feedback, especially the comments about the API.

I replaced BoLo/LoLo and took what appeared to be one giant step backwards. This turned out to be a change in the way the different LoLo versions set up the memory mapping. The old LoLo did have a remapping for virtual address 0xC2000000, wherease the current one does not.

With a little too much guess work I have remapped physical memory at 0xC4000000 to virtual address 0xC2000000 and have managed to get some improvement. I need to spend some extra time on this.

Part of the reason I had trouble with the remapping is the original LoLo Memory Map addendum (PN: 70000085-A01) that came with our board had a memory mapping table which included an entry for mapping physical address 0xD000 0000 to virtual address 0xC200 0000. I tried this via the remap command and it didn't seem to work (ie write data, read back - didn't verify) This address translation table is missing from the latest issue of this document. Can you point me at a source of info for this. (Reading the Sharp doc I felt I was making too many guesses)

How I would like to use LoLo is as you made mention of - ie as a Bootloader which sets up the clock, MMU, cache and SDRAM. Once I have jumped to my app I will hijack the interrupts and set up my own heap, stacks etc. Any suggestions on pitfalls with this approach would be greatly appreciated.

Thanks again - hope you have a great weekend,
Colin

colin,

Could you please post the versions of BoLo/LoLo you were/are using? I want to know why/if the memory map changed.

As to your question about using LoLo as a straight bootloader, we have lots of customers that do this. It is, in fact, the main purpose of the LogicLoader. That is to say, we wrote it to boot custom applications as well as operating systems.

The only potential pitfall is if we change some initialization code within LoLo and you upgrade. Which isn't really that big of an issue because you can always move back to the version you were using before, or we can patch the newer one for you. You will just have to be a little more aware of it than our standard BSP customers because we test the BSPs with new versions of LoLo to ensure everything still works as expected. Obviously, we won't have access to your application, so you'll have to handle that type of testing yourself. And, again, it only becomes an issue if you need/want to upgrade LoLo.

You don't even have to hijack the interrupts, using the "exec" command will turn off the interrupts, synchronize the cache, etc. for you. Then, you can probably just re-enable the cache and the MMU from within your application, or you can use the LoLo API calls to do it.

Since the MMU will be off, your application will then be loaded into the physical address space including the holes. As long as the start of your program re-enables the MMU before it tries to cross a 4MB boundary, you should be fine. If you don't quite follow that, let me know and I'll explain it a bit better.

Regards,
--mikee

Hi Mike

Versions as reported at LoLo startup:



I am pretty sure something has changed, since from boot-up it is no longer possible to use the LoLo w command to modify memory at 0xC2000000 without first doing a remap.

From memory I think the old LoLo used to report a mapping of 0xC2000000 -> 0xC2000000 when 'info cpu' was executed. I cannot check this without burning the old LoLo back in which I am not keen to do. The old LoLo certainly did have a much longer remap list when 'info cpu' was executed.

I think the major problem I face at the moment is having confidence in the remapping that I need to do. According to 'info cpu' the 32MB that starts at 0xC0000000 has a 'one to one' virtual to physical remapping. In one of your postings you mentioned 8Mbyte chunks, and trying to follow the Sharp doco I would expect the discontinuities to show in the remapping that the 'info cpu' reports.

Now that I am getting a slightly better handle on this issue I think my two most important questions are:
- Has LoLo/Bolo configured the SDMC for the full 64Mbytes?
- What 'remapping' do I need to do to get the additional 32Mbytes to appear from 0xC2000000..0xC3FFFFFF?

Thanks for your ongoing help with this.
Colin H.

remap 0xc4000000 0xc2000000 0x2000000

Hi Mike/ Bruce

Thanks for your help with this. I now seem to have all 64M where I want them.

The only issue I don't fully understand is the actual remapping. Mike, in one of your postings you mentioned that with 64MB RAM we would have 8MB chunks and discontinuities between these. Reading the Sharp documentation I can see what this is all about. However the remapping Bruce provided implies a 32MB contiguous chunk. Any chance of a simple explanation?

Thanks again,
Colin

colin,

Excellent question!

The answer lies in the usage of the nary-understood SROMLL bit located in one of the registers in the SDRAM controller. Basically, by setting that bit, you can make the eight 4Mbyte discontinuous chunks of memory look like one contiguous 32Mbyte array.

With 64 Mbytes of memory on the board, it does almost the same thing except it turns the eight 8Mbyte chunks into two 32Mbyte chunks seperated by a huge hole.

Sharp has never really, in my opinion, fully documented this bit and how to use it. We stumbled upon it here and our internal resource at Sharp said something like; "yeah, that bit might work like that."

A couple of our hardware guys looked at it real hard and decided that, yes, this is what that bit does, so we decided to make use of it.

In summary, the board has 64 Mbytes of SDRAM on it. Left alone, this memory is divided up into eight 8Mbyte chunks of memory seperated by gaps in the address space. To make the memory contiguous, you can use the MMU and its corresponding page tables to re-map all eight chunks. Or, you can set the SROMLL bit. If you do that, you wind up with two 32 Mbyte chunks of memory seperated by a gap. Then, using the MMU and page tables as before, you can erase the gap.

Now, wasn't that simple?

--mikee

Hi Mike

With your help I've now seen the light

Once again thanks for your excellent support.

Cheers,
Colin.

Colin,

My pleasure. I'm always glad to help out.

Please keep us posted on your progress.

Regards,
--mikee