On Wed 15 Aug, Andrew Kozin wrote:
> Hm, I got almost all of Debian base working on my Psion 5 kernel
> I even compiled mpg123 for Psion, and it WORKS!, but SLOWLY... :))
use splay or madplay if you want to play MP3s on ARM - they don't use
> Links looks like the best browser for Psion, you can imagine. If you
> want to see pictures, may be some fb viewers can help you... Or may be
> it's not a bad idea to hack links, and add a image->fb routines.
You could use the XML-renderer that transvirutal use in pocketlinux or there
various commercial browsers that work well in a small machine and framebuffer
(e.g ANT's fresco ought to do the trick but they haven't lent me one to test
yet ;-). Anyone tried opera yet?
> I have some troubles with programs using fork() - it seem to be a kernel
> problem, so i suggest to move to 2.4 kernels for Psion 5 (AFAIK 5mx already
> get it working), but I have some misunderstanding of how to implement
> Series 5 fragmented memory with 2.4 . I already have some ideas, but don't
> know if they correct...
> Here they are, if somebody can tell me, are they suck or rule,
> PLEASE do it:
> The real configuration is
> 0xc0000000 size 512k
> 0xc0100000 size 512k
> 0xc0400000 size 512k
> 0xc0500000 size 512k
> 0xc1000000 size 512k
> 0xc1100000 size 512k
> 0xc1400000 size 512k
> 0xc1500000 size 512k
> 0xd0000000 size 512k
> 0xd0100000 size 512k
> 0xd0400000 size 512k
> 0xd0500000 size 512k
> 0xd1000000 size 512k
> 0xd1100000 size 512k
> 0xd1400000 size 512k
> 0xd1500000 size 512k
> phys addr bits: 110n 000n 0n0n 0xxx xxxx xxxx xxxx xxxx
> virt addr bits: 1100 0000 0nnn nxxx xxxx xxxx xxxx xxxx
yuck! - is that how the ram's set out?
> If I understand something, the conversion from physical to virtual
> addresses can be
> #define __phys_to_virt(x) ((x) & 0xc007ffff) | \
> (((x) & 0x10000000) >> 6) | \
> (((x) & 0x01000000) >> 3) | \
> (((x) & 0x00400000) >> 2) | \
> (((x) & 0x00100000) >> 1)
> And we have one 8Mb bank. Isn't it?
> Or, may be it will be better to write something like
> #define __phys_to_virt(x) ((x) & 0xc057ffff) | \
> (((x) & 0x10000000) >> 7) | \
> (((x) & 0x01000000) >> 5)
> #define __virt_to_phys(x) ((x) & 0xc057ffff) | \
> (((x) & 0x00200000) << 7) | \
> (((x) & 0x00080000) << 5)
> i,e. shift only bits 28 and 24 to "empty" bits 21 and 19 to get
> contiguous virtual memory????
> Or, it's better to get 2 banks of 4Mb?
> As far, as I understand - if we have highly fragmented memory - we
> have to create __phys_to_virt and __virt_to_phys transform functions.
You always have to have these macros even if all the ram is one block. And
the virtual addresses the same as the physical.
> We have to think out a method of how to shift highest physical
> address bits, corresponding to fragment start addresses, to make
> them stay as close as possible.
That seems like a good idea, although you can probably just use a simple
mapping and let the kernel worry about the small blocks. The kernel can deal
with an arbitrary number of blocks. On the other hand concatenating them is
probably a good idea.
In this case it may well be better to have a 1:1 virt/phys mapping and use
the NUMA support to deal with the resulting holes in memory. This is the
approach taken by the LART in the 2.4 kernel. The lart does have larger
contiguous chunks though - which may be a consideration. Check out the LART
code and see if that approach is easier.
> In my case it looks like
> | +---+--+
> | | V V
> 110n 000n 0n0n 0xxx xxxx xxxx xxxx xxxx
I am slightly concerned that this mapping does not preserve order. It should
be OK so long as everything uses it....
> If the above OK, there is one more question:
> We have kernel (say, 4Mb in size) loaded by loader
> into following fragments:
> Using the above __phys_to_virt transform
> we get
> Where we must set up page tables for that layout?
> In head-armv.S?
> In the above example we need not only section translation table with 4
> entries, but also 4 page tables with large pages. Or we have to use
> small pages?
I'm not sure about this, without spending more time looking at the code, and
it really is hometime now!
Cave Surveying group, 734 Newmarket Rd CAMBRIDGE, CB5 8RS, UK
Tel (00 44) 1223 811679
http://www.survex.com/ play: http://www.chaos.org.uk/~wookey/