John,
thanks again! I appreciate the quick responses...
Anyway to answer some of your questions:
It is somewhat confusing since it is not on the patch page but on the networking tutorial page. This implys that if you are using networking you must use this patch. Apparently not... Correct?
2). I will try your other suggestions below... thanks again.
3). > I think it's becuase it's a 16-bit flash and the way I
> have it set up for 32-bit accesses. It may only do 1/2
> word writes but can do a full 32-bit read.
This should be handled by the OPB_EMC controller - it should present
the flash as a 32-bit wide device on the OPB bus, even if that means the
controller does two X 16-bit accesses to achive it.
<Greg> True, but I had to change the OPB controller (latest) VHDL to make it act correctly. Like I said it is now read 32-bits on OBP, but writing is 16-bits at a time (as expected).
> Is there a way around this? I saw that there is some
> code (NEW) to accomidate for this, but I cannot get it
> to compile (see above). In fact the avobe is just the
> plain Vanilla with only the processor speed changed.
You probably need to verify that you have connected your flash device
properly, and configured it's controlling EMC perihperal in the right
way. I find board manufacturers' reference designs particularly useful
for this - no point re-inventing the wheel!
<Greg> again true. My board maker did not provide an example of the OPB interface using the EMC. That is why I did my own. I think I have my flash correct... i.e. I can boot from flash (I copy to ddr before). Also, when I write to it, I have to write like this:
(I wrote c to do this as well) - of course I erase and write the proper write commands first:
mwr 0xff000000 0xdead0000 (to write to the MSB 1/2 word)
mwr 0cff000002 0xffffbeef (to write to the LSB 1/2 word)
When I read from 0xff000000 I get 0xdeadbeef
So, since the kernel does not see the the flash properly, Im not sure if it has provitions to control it in this manner? Or, maybe the kernel is not recognizing the flash type properly.
Thanks.
John Williams <jwilliams@itee.uq.edu.au> wrote:
Hi Greg,
Greg Miller wrote:
> OK sorry for these dumb questions... Is it just me or is this whole
> thing confusing. I downloaded the CVS kernel again...
A suggestion here, that can save a lot of time and network bandwidth.
Setup a regularly scheduled task (cron under Linux), that each night
does a CVS update on a pristine, read-only (to you) image of the uClinux
tree (kernel and dist).
Then, you just make copies of this into working directories (I use
rsync), and work with your local copies. This way, when you trash your
local kernel tree (or want to start from scratch), it's trivial, just
copy a new version of the pristine tree, rather than pulling another
100megs over a slow CVS connection.
This makes you more willing to experiment, you can create "disposable"
trees to test things out, without int!
errupting
your normal workflow.
> -What I am after is the proper way to build the kernel from scratch:
>
> 1). download both uClinux-dist and source 2.4.x (as on your website)
> 2). Build kernel with only change (100Mhz). Get -lib error
> 3). Apply patch from your site - get 'Malformed patch at line 95'
hmm, this suggests a CR/LF error. Are you downloading the patch via a
windowsd-based browsser (even worse, Internet explorer)? If so, you
should run dos2unix over the patch before applying it on your linux
build box.
> 4). Do I apply the 'network patch' that is on your site as well? (that
> give a bunch of already patched and also seems to patch stuff).
I see no network patch on this page:
http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/Downloads/patches.html
Can you tell me where you found this mystery patch, so I can remove it?! :)
> 5). What is the best way to know that eve!
rything
is working?
hmm, a login prompt and running shell? Not really sure what you mean here.
> 6). I cannot use the autoconfig because I am using the newest DDR. I
> tried your fix in one of the e-mails and it still does not work. If I go
> back to an older DDR, it really messes up the clock hookup. Is there any
> way to get it to work with the latest version?
Yep - if you grab the latest uClinux-auto target from the website, you
can extract the "bsp/" subdirectory where the uclinux MLD/TCL lives. IT
now supports banked memory controllers such as the newer opb_ddr.
You'll put entries in your system.mss along the lines of
parameter main_memory = my_opb_ddr_0
parameter main_memory_bank = 0
Again, there's a nice complete example of this in the ml401 uclinux
reference design.
Hope this helps,
John
___________________________
microblaze-uclinux mailing
list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/