summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/arm_port.mdwn
blob: 26e0b7709eb29e55ab4f218353a9fdd0a5dfc9d5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
[[!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

    <mcsim> Has anyone heard about porting hurd and gnu/mach to arm
      architecture?
    <braunr> mcsim: i think so
    <braunr> mcsim: why are you asking ?
    <mcsim> I found an article where author stated that he has ported hurd to
      arm, but I have never met this information before.
    <mcsim> He wrote ethernet driver and managed to use ping command
    <mcsim> author's name is Sartakov Vasily
    <braunr> well that's possible, a long time ago
    <braunr> and it was probably not complete enough to be merged upstream
    <braunr> like many other attempts at many other things
    <mcsim> Not so long. Article is dated by June 2011.
    <braunr> do you have a link ?
    <mcsim> Yes, but it is in Russian.
    <braunr> oh
    <braunr> well i don't remember him sharing that with us
    <antrik> mcsim: he did some work on porting Mach, but AIUI never got it
      nearly finished
    <antrik> nowadays he does L4 stuff
    <antrik> was also at FOSDEM


## IRC, freenode, #hurd, 2012-10-09

    <mcsim> bootinfdsds: There was an unfinished port to arm, if you're
      interested.
    <tschwinge> mcsim: Has that ever been published?
    <mcsim> 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

    <tschwinge> mcsim: If you have a contact to the ARM porter, could you
      please ask him to post what he has?
    <antrik> tschwinge: we all have the "contact" -- let me remind you that he
      posted his questions to the list...


## IRC, freenode, #hurd, 2012-10-17

    <mcsim> 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

    <matty3269> 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?
    <braunr> matty3269: not really currently
    <braunr> but if that's what you want to do, sure
    <tschwinge> 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.
    <tschwinge> matty3269: But if you're feeling adventurous, by all means work
      on it, and we'll try to help as we can.
    <tschwinge> 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.
    <tschwinge> matty3269: I can help with toolchains (GCC, etc.) things for
      ARM, if there's need.
    <matty3269> 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)
    <matty3269> 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?
    <tschwinge> 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.
    <tschwinge> matty3269: Basically, you'd need equivalents for the i386 (and
      similar) directories, yep.
    <tschwinge> Though, you may be able to avoid some cruft in there.
    <tschwinge> Does building for x86 have any issues?
    <tschwinge> matty3269: How is generally your understanding of the Hurd on
      Mach system architecture, and on microkernel-based systems generally, and
      on Mach in particular?
    <matty3269> tschwinge: yes, it seems to be progressing... I've got mig
      installed and it's just compiling now
    <matty3269> 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
    <tschwinge> 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.
    <matty3269> tschwinge: I have been running a GNU/Hurd system for a while
      now though
    <tschwinge> I'm happy to tell you that the schedules is still in the
      kernel.  ;-)
    <tschwinge> OK, good, so you know about the basic ideas.
    <braunr> matty3269: there has to be machine specific stuff in user space
    <braunr> for initial thread contexts for example
    <matty3269> tschwinge: Ok, just got gnumach built
    <braunr> but there isn't much and you can easily base your work from the
      x86 implementation
    <tschwinge> Yes.  Mach itself is the more difficult one.
    <matty3269> braunr: Yeah, looking around at things, it doesn't seem that
      there will be too much work involoved in the user-space stuff
    <tschwinge> braunr: Do you know off-hand whether there are some old Mach
      research papers describing architecture ports?
    <tschwinge> I know there are some describing the memory system (obviously),
      and I/O system -- which may help matty3269 to understand the general
      design/structure.
    <tschwinge> We might want to identify some documents, and make a list.
    <braunr> all mach related documentation i have is available here:
      ftp://ftp.sceen.net/mach/
    <braunr> (also through http://)
    <tschwinge> matty3269: Oh, definitely I'd suggest the Mach 3 Kernel
      Principles book.  That gives a good description of the Mach architecture.
    <matty3269> Great, that's my weekends reading then!
    <braunr> you don't need all that for a port
    <matty3269> Is it possible to run the gnumach binary standalone with qemu?
    <braunr> you won't go far with it
    <braunr> you really need at least one program
    <braunr> but sure, for a port development, it can easily be done
    <braunr> i'd suggest writing a basic static application for your tests once
      you reach an advanced state
    <braunr> the critical parts of a port are memory and interrupts
    <braunr> and memory can be particularly difficult to implement correctly
    <tschwinge> 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.
    <braunr> but the good news is that almost every bsd system still uses a
      similar interface
    <tschwinge> matty3269: And, you may want to become familiar with QEMU's
      built-in gdbserver, and how to connect to and use that.
    <braunr> so, for example, you could base your work from the netbsd/arm pmap
      module
    <tschwinge> matty3269: I think that's better than starting on real
      hardware.
    <braunr> tschwinge: you can use -kernel with a multiboot binary now

[[hurd/running/qemu#multiboot]].

    <braunr> tschwinge: and even creating iso images is so fast it's not any
      slower

    <braunr> ah, the gnumach executable is a correct elf image
    <matty3269> Is there particular reason that mach is linked at 0xc0100000?
    <matty3269> or is that where it is expected to be in VM>
    <tschwinge> That's my understanding.
    <braunr> kernels commmonly sti at high addresses
    <braunr> that's the "standard" 3G/1G split for user/kernel space
    <matty3269> I think Linux sits at a similar VA for 32-bit
    <braunr> no
    <matty3269> Oh, I thought it did, I know it does on ARM, the kernel is
      mapped to 0xc000000 
    <braunr> i don't know arm, but are you sure about this number ?
    <braunr> seems to lack a 0
    <matty3269> Ah, yes sorry
    <matty3269> so 0xC0000000
    <braunr> 0xc0100000 is just 1 MiB above it
    <braunr> 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)
    <matty3269> so with gnumach, does the boot-up sequence use PIC until VM is
      active and the kernel mapped to the linking address?
    <braunr> no
    <braunr> actually i'm not certain of the details
    <braunr> but there is no PIC
    <braunr> either special sections are linked at physical addresses
    <braunr> or it relies on the fact that all executable code uses near jumps
    <braunr> and uses offsets when accessing data
    <braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB)
    <matty3269> hmm,
    <braunr> 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
    <braunr> same*
    <matty3269> indeed, ARM is tricky because memory maps are vastly differnt
      on every platform


## IRC, freenode, #hurd, 2012-11-21

    <matty3269> Well, I have a ARM gnumach kernel compiled. It just doesn't
      run! :)
    <braunr> matty3269: good luck :)


# IRC, freenode, #hurd, 2013-01-30

    <slpz> Hi, i've read there's an ongoing effort to port GNU Mach to ARM. How
      is it going?
    <braunr> not sure where you read that
    <braunr> but i'm pretty sure it's not started if it exists
    <slpz> braunr: http://www.gnu.org/software/hurd/open_issues/arm_port.html
    <braunr> i confirm what i said
    <slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
      duplicate efforts.
    <braunr> little addition: it may have started, but we don't know about it


# IRC, freenode, #hurd, 2013-09-18

    <Hooligan0> 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
    <Hooligan0> when pages are tagged to be used by userspace ?
    <braunr> Hooligan0: at page fault time
    <braunr> the split is completely virtual, vm_resident deals with physical
      memory only
    <Hooligan0> braunr: do you think it's possible to change (at least)
      pmap_steal_memory to mark somes pages as kernel-reserved ?
    <braunr> why do you want to reserve memory ?
    <braunr> and which memory ?
    <Hooligan0> 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)
    <Hooligan0> braunr: and second, because i want to use larger pages into
      kernel (1MB) to reduce mmu work
    <braunr> vm_resident isn't well suited for large pages :(
    <braunr> i don't see the effect of context switch on kernel pages
    <Hooligan0> at many times, context switch flush caches
    <braunr> ah you want something like global pages on x86 ?
    <Hooligan0> yes, something like
    <braunr> how is it done on arm ?
    <Hooligan0> virtual memory is split into two parts depending on msb bits
    <Hooligan0> for example 3G/1G
    <Hooligan0> MMU will use two pages tables depending on vaddr (hi-side or
      low-side)
    <braunr> hi is kernel, low is user ?
    <Hooligan0> so, for the moment i've put mach at 0xC0000000 -> 0xFFFFFFFF  ;
      and want to use 0x00000000 -> 0xBFFFFFFF for userspace
    <Hooligan0> yes
    <braunr> ok, that's what is done for x86 too
    <Hooligan0> 1MB pages for kernel ; and 4kB (or 64kB) pages for apps
    <braunr> i suggest you give up the large page stuff
    <braunr> well, you can use them for the direct physical mapping, but for
      kernel objects, it's a waste
    <braunr> or you can rewrite vm_resident to use something like a buddy
      allocator but it's additional work
    <Hooligan0> 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
    <braunr> Hooligan0: it is, but not worth it
    <Hooligan0> will you allow changes into vm_resident if i update i386 too ?
    <braunr> Hooligan0: sure, as long as these are relevant and don't introduce
      regressions
    <Hooligan0> ok
    <braunr> Hooligan0: i suggest you look at x15, since you may want to use it
      as a template for your own changes
    <braunr> as it was done for the slab allocator for example
    <braunr> e.g. x15 already uses a buddy allocator for physical memory