From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- open_issues/arm_port.mdwn | 267 ---------------------------------------------- 1 file changed, 267 deletions(-) delete mode 100644 open_issues/arm_port.mdwn (limited to 'open_issues/arm_port.mdwn') diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn deleted file mode 100644 index 26e0b770..00000000 --- a/open_issues/arm_port.mdwn +++ /dev/null @@ -1,267 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -Several people have expressed interested in a port of GNU/Hurd for the ARM -architecture. - - -# IRC, freenode, #hurd, 2012-07-28 - - Has anyone heard about porting hurd and gnu/mach to arm - architecture? - mcsim: i think so - mcsim: why are you asking ? - I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - He wrote ethernet driver and managed to use ping command - author's name is Sartakov Vasily - well that's possible, a long time ago - and it was probably not complete enough to be merged upstream - like many other attempts at many other things - Not so long. Article is dated by June 2011. - do you have a link ? - Yes, but it is in Russian. - oh - well i don't remember him sharing that with us - mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - nowadays he does L4 stuff - was also at FOSDEM - - -## IRC, freenode, #hurd, 2012-10-09 - - bootinfdsds: There was an unfinished port to arm, if you're - interested. - mcsim: Has that ever been published? - tschwinge: I don't think so. But I have an email of that person and - I think that this could be discussed with him. - - -## IRC, freenode, #hurd, 2012-10-10 - - mcsim: If you have a contact to the ARM porter, could you - please ask him to post what he has? - tschwinge: we all have the "contact" -- let me remind you that he - posted his questions to the list... - - -## IRC, freenode, #hurd, 2012-10-17 - - tschwinge: Hello. The person who I wrote regarding arm port of - gnumach still hasn't answered. And I don't think that he is going to - answer. - - -# IRC, freenode, #hurd, 2012-11-15 - - Well, I have a big interest in the ARM architecture, I worked - at ARM for a bit too, and I've written my own little OS that runs on - qemu. Is there an interest in getting hurd running on ARM? - matty3269: not really currently - but if that's what you want to do, sure - matty3269: Well, interest -- sure!, but we don't really have - people savvy in low-level kernel implementation on ARM. I do know some - bits about it, but more about the instruction set than about its memory - architecture, for example. - matty3269: But if you're feeling adventurous, by all means work - on it, and we'll try to help as we can. - matty3269: There has been one previous attempt for an ARM port, - but that person never published his code, and apparently moved to a - different project. - matty3269: I can help with toolchains (GCC, etc.) things for - ARM, if there's need. - tschwinge: That sounds great, thanks! Where would you recommend - I start (at the moment I've got Mach checked out and am trying to get it - compiled for i386) - I'm guessing that the Mach micro-kernel is all that would need - to be ported or are there arch-dependant bits of code in the server - processes? - matty3269: - http://www.gnu.org/software/hurd/faq/system_port.html has some - information. Mach is the biggest part, yes. Then some bits in glibc and - libpthread, and even less in the Hurd libraries and servers. - matty3269: Basically, you'd need equivalents for the i386 (and - similar) directories, yep. - Though, you may be able to avoid some cruft in there. - Does building for x86 have any issues? - matty3269: How is generally your understanding of the Hurd on - Mach system architecture, and on microkernel-based systems generally, and - on Mach in particular? - tschwinge: yes, it seems to be progressing... I've got mig - installed and it's just compiling now - hmm, not too great if I'm honest, I've done mostly monolithic - kernel development so having such low-level processes, such as - scheduling, done in user-space seems a little strinage - Ah, yes, MIG will need a little bit of porting, too. I can - help with that, but that's not a priority -- first you have to get Mach - to boot at all; MIG will only be needed once you need to deal with RPCs, - so user-land/kernel interaction, basically. Before, you can hack around - it. - tschwinge: I have been running a GNU/Hurd system for a while - now though - I'm happy to tell you that the schedules is still in the - kernel. ;-) - OK, good, so you know about the basic ideas. - matty3269: there has to be machine specific stuff in user space - for initial thread contexts for example - tschwinge: Ok, just got gnumach built - but there isn't much and you can easily base your work from the - x86 implementation - Yes. Mach itself is the more difficult one. - braunr: Yeah, looking around at things, it doesn't seem that - there will be too much work involoved in the user-space stuff - braunr: Do you know off-hand whether there are some old Mach - research papers describing architecture ports? - I know there are some describing the memory system (obviously), - and I/O system -- which may help matty3269 to understand the general - design/structure. - We might want to identify some documents, and make a list. - all mach related documentation i have is available here: - ftp://ftp.sceen.net/mach/ - (also through http://) - matty3269: Oh, definitely I'd suggest the Mach 3 Kernel - Principles book. That gives a good description of the Mach architecture. - Great, that's my weekends reading then! - you don't need all that for a port - Is it possible to run the gnumach binary standalone with qemu? - you won't go far with it - you really need at least one program - but sure, for a port development, it can easily be done - i'd suggest writing a basic static application for your tests once - you reach an advanced state - the critical parts of a port are memory and interrupts - and memory can be particularly difficult to implement correctly - matty3269: I once used QEMU's - virtual-FAT-filesystem-from-a-directory-on-the-host, and configured GRUB - to boot from that one, so it was easy to quickly reboot for kernel - development. - but the good news is that almost every bsd system still uses a - similar interface - matty3269: And, you may want to become familiar with QEMU's - built-in gdbserver, and how to connect to and use that. - so, for example, you could base your work from the netbsd/arm pmap - module - matty3269: I think that's better than starting on real - hardware. - tschwinge: you can use -kernel with a multiboot binary now - -[[hurd/running/qemu#multiboot]]. - - tschwinge: and even creating iso images is so fast it's not any - slower - - ah, the gnumach executable is a correct elf image - Is there particular reason that mach is linked at 0xc0100000? - or is that where it is expected to be in VM> - That's my understanding. - kernels commmonly sti at high addresses - that's the "standard" 3G/1G split for user/kernel space - I think Linux sits at a similar VA for 32-bit - no - Oh, I thought it did, I know it does on ARM, the kernel is - mapped to 0xc000000 - i don't know arm, but are you sure about this number ? - seems to lack a 0 - Ah, yes sorry - so 0xC0000000 - 0xc0100000 is just 1 MiB above it - the .text section of linux on x86 actually starts at c1000000 - (above 16 MiB, certainly to preserve as much dma-able memory since modern - machines now have a lot more) - so with gnumach, does the boot-up sequence use PIC until VM is - active and the kernel mapped to the linking address? - no - actually i'm not certain of the details - but there is no PIC - either special sections are linked at physical addresses - or it relies on the fact that all executable code uses near jumps - and uses offsets when accessing data - (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB) - hmm, - but you shouldn't worry about that i suppose, as the protocol - between the boot loader and an arm kernel will certainly not be the saem - same* - indeed, ARM is tricky because memory maps are vastly differnt - on every platform - - -## IRC, freenode, #hurd, 2012-11-21 - - Well, I have a ARM gnumach kernel compiled. It just doesn't - run! :) - matty3269: good luck :) - - -# IRC, freenode, #hurd, 2013-01-30 - - Hi, i've read there's an ongoing effort to port GNU Mach to ARM. How - is it going? - not sure where you read that - but i'm pretty sure it's not started if it exists - braunr: http://www.gnu.org/software/hurd/open_issues/arm_port.html - i confirm what i said - braunr: OK, thanks. I'm interested on it, and didn't want to - duplicate efforts. - little addition: it may have started, but we don't know about it - - -# IRC, freenode, #hurd, 2013-09-18 - - as i understand ; on startup, vm_resident.c functions configure - the whole available memory ; but at this point the system does not split - space for kernel and space for future apps - when pages are tagged to be used by userspace ? - Hooligan0: at page fault time - the split is completely virtual, vm_resident deals with physical - memory only - braunr: do you think it's possible to change (at least) - pmap_steal_memory to mark somes pages as kernel-reserved ? - why do you want to reserve memory ? - and which memory ? - braunr: first because on my mmu i have two entry points ; so i - want to set kernel pages into a dedicated space that never change on - context switch (for best cache performance) - braunr: and second, because i want to use larger pages into - kernel (1MB) to reduce mmu work - vm_resident isn't well suited for large pages :( - i don't see the effect of context switch on kernel pages - at many times, context switch flush caches - ah you want something like global pages on x86 ? - yes, something like - how is it done on arm ? - virtual memory is split into two parts depending on msb bits - for example 3G/1G - MMU will use two pages tables depending on vaddr (hi-side or - low-side) - hi is kernel, low is user ? - so, for the moment i've put mach at 0xC0000000 -> 0xFFFFFFFF ; - and want to use 0x00000000 -> 0xBFFFFFFF for userspace - yes - ok, that's what is done for x86 too - 1MB pages for kernel ; and 4kB (or 64kB) pages for apps - i suggest you give up the large page stuff - well, you can use them for the direct physical mapping, but for - kernel objects, it's a waste - or you can rewrite vm_resident to use something like a buddy - allocator but it's additional work - for the moment it's waste ; but with some littles changes this - allow only one level of allocation mapping ; -i think- it's better for - performances - Hooligan0: it is, but not worth it - will you allow changes into vm_resident if i update i386 too ? - Hooligan0: sure, as long as these are relevant and don't introduce - regressions - ok - Hooligan0: i suggest you look at x15, since you may want to use it - as a template for your own changes - as it was done for the slab allocator for example - e.g. x15 already uses a buddy allocator for physical memory -- cgit v1.2.3