hello, I want to use the ARM LPAE in Fiasco.OC, may I need to modify the start code of l4re? The board supports two DDR3 channels, and each channel supports two chip-selects. I need to use the memory device on CS0 populated for each channel. One memory rang is from 0x00000000 to 0x3fffffff, the anther is from 0x100000000 to 0x13fffffff. How can sigma0 see both of them?
thank you!
Hi,
On Tue Mar 22, 2016 at 22:24:49 +0800, li94575 wrote:
I want to use the ARM LPAE in Fiasco.OC, may I need to modify the start code of l4re? The board supports two DDR3 channels, and each channel supports
two chip-selects. I need to use the memory device on CS0 populated for each channel. One memory rang is from 0x00000000 to 0x3fffffff, the anther is from 0x100000000 to 0x13fffffff. How can sigma0 see both of them?
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Adam
hi Adam, At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Thank you for the answer. I know ARM LPAE is only a transitional solution for memory limitations. I hope I can run Fiasco.OC on 64-bit ARM processor( such as Cortext A53), Do you have such plans?
On Fri Mar 25, 2016 at 22:27:33 +0800, li94575 wrote:
hi Adam, At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Thank you for the answer. I know ARM LPAE is only a transitional solution for memory limitations. I hope I can run Fiasco.OC on 64-bit ARM processor( such as Cortext A53), Do you have such plans?
Yes, definitely. We're working on placing resources appropriately.
Adam
On Fri Mar 25, 2016 at 22:27:33 +0800, li94575 wrote:
hi Adam, At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Could you tell me where I need to change? I have modified the memory initialization in sigma0, and addeda new memory region (from 0x100000000 to 0x13fffffff) on the avl tree. However, it does not seem to work, because the page fault address is 32 bit (fpage also cann't hold 64-bit address), I wonder if I revise the wrong place.
Hi,
On Mon Mar 28, 2016 at 23:05:41 +0800, li94575 wrote:
On Fri Mar 25, 2016 at 22:27:33 +0800, li94575 wrote:
hi Adam, At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Could you tell me where I need to change? I have modified the memory initialization in sigma0, and addeda new memory region (from 0x100000000 to 0x13fffffff) on the avl tree. However, it does not seem to work, because the page fault address is 32 bit (fpage also cann't hold 64-bit address), I wonder if I revise the wrong place.
The size of an fpage is one thing to solve but far not the only one. Maybe an fpage can be changed to describe larger addresses (with other trade-offs) or sigma0 could use a different way/protocol to talk to the kernel. With that one could get to the memory above 4G through sigma0 (the sigma0 protocol for clients would probably also need some review regarding larger addresses). Would that be enough for your use case?
Adam
Hi,
At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Could you tell me where I need to change? I have modified the memory initialization in sigma0, and addeda new memory region (from 0x100000000 to 0x13fffffff) on the avl tree. However, it does not seem to work, because the page fault address is 32 bit (fpage also cann't hold 64-bit address), I wonder if I revise the wrong place.
The size of an fpage is one thing to solve but far not the only one. Maybe an fpage can be changed to describe larger addresses (with other trade-offs) or sigma0 could use a different way/protocol to talk to the kernel. With that one could get to the memory above 4G through sigma0 (the sigma0 protocol for clients would probably also need some review regarding larger addresses). Would that be enough for your use case?
I do not want to extend all of the physical address to 64 bit, including the fpage, this will involve too many places. So, we come up with a way to avoid using the 64-bit physical address, using 32-bit address (0x40000000 ~ 0x7fffffff) to replace the 33-bit physical address (0x100000000 ~ 0x13fffffff). When filling in the page table entry, we make judgments and fill the actual 33-bit physical address. Then, the address translation in MMU would be no problem, the kernel memory area(16MB) is still in the front 1G address. Is there a problem with this method? We test it in the kernel, it seems to work well, but processes in user space cannot use the address(0x40000000 ~ 0x7fffffff).
On Sun Apr 03, 2016 at 18:25:31 +0800, li94575 wrote:
Hi,
At 2016-03-25 06:41:45, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
With the current 32bit setup the second part won't be accessible as it goes beyond the 4GB space. Making this memory usable on 32bit could be done with some (very hacky) changes but commonly thoughts are that such an effort would be better spent for 64bit that does not have any such limitations.
Could you tell me where I need to change? I have modified the memory initialization in sigma0, and addeda new memory region (from 0x100000000 to 0x13fffffff) on the avl tree. However, it does not seem to work, because the page fault address is 32 bit (fpage also cann't hold 64-bit address), I wonder if I revise the wrong place.
The size of an fpage is one thing to solve but far not the only one. Maybe an fpage can be changed to describe larger addresses (with other trade-offs) or sigma0 could use a different way/protocol to talk to the kernel. With that one could get to the memory above 4G through sigma0 (the sigma0 protocol for clients would probably also need some review regarding larger addresses). Would that be enough for your use case?
I do not want to extend all of the physical address to 64 bit, including the fpage, this will involve too many places. So, we come up with a way to avoid using the 64-bit physical address, using 32-bit address (0x40000000 ~ 0x7fffffff) to replace the 33-bit physical address (0x100000000 ~ 0x13fffffff). When filling in the page table entry, we make judgments and fill the actual 33-bit physical address. Then, the address translation in MMU would be no problem, the kernel memory area(16MB) is still in the front 1G address. Is there a problem with this method? We test it in the kernel, it seems to work well, but processes in user space cannot use the address(0x40000000 ~ 0x7fffffff).
Ok, looks like a good idea to me and I think it should work. What happens when user programs access the second GB? And which programs, moe, or later ones?
Adam
At 2016-04-05 07:01:04, "Adam Lackorzynski" adam@os.inf.tu-dresden.de wrote:
I do not want to extend all of the physical address to 64 bit, including the fpage, this will involve too many places. So, we come up with a way to avoid using the 64-bit physical address, using 32-bit address (0x40000000 ~ 0x7fffffff) to replace the 33-bit physical address (0x100000000 ~ 0x13fffffff). When filling in the page table entry, we make judgments and fill the actual 33-bit physical address. Then, the address translation in MMU would be no problem, the kernel memory area(16MB) is still in the front 1G address. Is there a problem with this method? We test it in the kernel, it seems to work well, but processes in user space cannot use the address(0x40000000 ~ 0x7fffffff).
Ok, looks like a good idea to me and I think it should work. What happens when user programs access the second GB? And which programs, moe, or later ones?
We use Genode as the runtime environment, and already find the reasion why we cannot access the second GB. when thread receives a fpage (mem), It goes wrong while doing the fpage mapping, because we get a wrong physical address through calling 'v_lookup' function. So, we shuld also make judgment when lookup the page table, if the phys addr is 33bit, then minus 0xc0000000 (converting the addr into 0x40000000 ~ 0x7ffffff). Now, the method can works well, thank you for your help.
l4-hackers@os.inf.tu-dresden.de