parts, too. Fixed a potential overflow.
* The generic physical page mapper reserves the virtual address range
for the IO space now, so that noone can interfere until an area has
been created. The location of the IO space is no longer fixed; it
didn't look to me like it was necessary for x86, and we definitely
need to be flexible for PPC.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15855 a95241bf-73f2-0310-859d-f6bbb57e9c96
"IO space" out of the x86 specific source into arch/generic. We'll use
it for PPC as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15853 a95241bf-73f2-0310-859d-f6bbb57e9c96
device in the Open Firmware implementation of boot loader and
pass its path to the kernel, where it's opened and used for
getting/setting the real time. The expensive atomic_*64() on PPC
32-bit make things a bit more complicated. Moreover, missing
64 bit multiplication and division instructions won't really
allow system_time() to be anywhere near as fast as on x86. :-/
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15837 a95241bf-73f2-0310-859d-f6bbb57e9c96
substructure now (that's the only member actually). The system time
offset is therefore accessed via architecture specific accessor
functions.
Note, that this commit breaks the PPC build. Since I want to rename at
least one file I've already changed, I can't avoid that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15835 a95241bf-73f2-0310-859d-f6bbb57e9c96
(year, month,...) representation out of the x86 specific code and put
respective support functions into real_time_clock.c. We'll need those
for the PPC specific part too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15827 a95241bf-73f2-0310-859d-f6bbb57e9c96
Basically the architecture specific code is now responsible to
init and make use of the platform specific code, now. The reason
being that we have only one kernel per platform and thus cannot
decide at compile time, which platform to use (if any).
The PPC implementation features an abstract base class PPCPlatform
(implemented for all supported platforms) through which platform
support is provided.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15824 a95241bf-73f2-0310-859d-f6bbb57e9c96
bus, and time base frequency) in the PPC boot loader, and propagate
them to the kernel via kernel_args.
* Now we use the correct time base frequency for timer calculations.
* Implemented PPC specific system info stuff. Added a few PPC CPU
types to <OS.h>.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15817 a95241bf-73f2-0310-859d-f6bbb57e9c96
remapping stuff into separate functions and made them available to
others.
* Remap the exception handler space in arch_int_init_post_vm() into the
kernel address space (same issue as with the page table).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15783 a95241bf-73f2-0310-859d-f6bbb57e9c96
According to the spec we need to set it before taking over the MMU,
but we can't call it before arch_mmu_init(), since we need the OF
to allocate the page table. So we do it after we have allocated
the new page table.
* Added PPC specific kernel_args: The virtual address ranges we want
to keep in the kernel. We fill that in with the translations we
find when initializing the MMU stuff. We remove the memory the
boot loader occupies from those. Besides the stack for the boot
loader only the OF stuff remains.
* arch_mmu_allocate() now starts to search at KERNEL_BASE for a free
virtual address when no particular address is requested. This saves
us further trouble in the kernel, since those allocations would
need to be remapped otherwise.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15780 a95241bf-73f2-0310-859d-f6bbb57e9c96
the fact that I couldn't find ptesync in an otherwise more complete
documentation I downloaded yesterday made me suspicious.
* arch_cpu_global_TLB_invalidate() uses tlbia now. The instruction is
optional, but so is tlbie (how I understood it is that both exist,
when the architecture implementation has a TLB). And the former loop
looked just scary.
* Implemented arch_cpu_user_TLB_invalidate(). It does just the same as
arch_cpu_global_TLB_invalidate().
* Some changes with respect to synchronization required on page table
and segment register updates.
* Some more minor renaming. Pulled a new function
remove_page_table_entry() out of unmap_tmap().
* In arch_vm_translation_map_init_post_area() we do now remap the page
table into the kernel address space, if it was without before. The
page table might actually be a good application for BAT, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15773 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed occurrences of ASID/asid to VSID/vsid where appropriate.
* vm_translation_map_arch_info::vsid_base is now the first usable
VSID and doesn't need to be shifted anymore.
* Changed the VSID base shift from 4 to 3, since we need only 8 VSIDs
per team.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15772 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed several off-by-one comparisons with num_pages.
* vm_alloc_virtual_from_kernel_args() now makes sure the allocated
region lies within the kernel address space (or is at least
>= KERNEL_BASE).
* Simplified one or two patches.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15771 a95241bf-73f2-0310-859d-f6bbb57e9c96
fill_page_table_entry() by a ptesync(). Mapping the kernel heap
took about 2 minutes here before.
* Added missing shift of the asid_base in ppc_translation_map_change_asid().
* Commented out the BAT stuff in arch_vm_translation_map_init_post_area().
Besides that I think it won't work that way, it made the page table
unaccessible; though I'm not sure why.
* Added a bit of documentation to the beginning of the file. Should give
enough information to understand what happens here without further
detailed knowledge about the architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15769 a95241bf-73f2-0310-859d-f6bbb57e9c96
arch_mmu_allocate() to set the "cache inhibited" flag. One negative
effect was that for such memory the lwarx instruction (used by the
atomic_*() functions) does "... cause the system data storage error
handle to be invoked...", as the architecture specification puts it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15759 a95241bf-73f2-0310-859d-f6bbb57e9c96
{HAIKU,HOST,TARGET}_KERNEL_PIC_{CC,LINK}FLAGS which define the
compiler/linker flags specifying the kind of position independence
the kernel shall have. For x86 we had and still have -fno-pic, but the
PPC kernel has -fPIE (position independent executable) now, as we
need to relocate it.
* The boot loader relocates the kernel now. Mostly copied the relocation
code from the kernel ELF loader. Almost completely rewrote the PPC
specific relocation code, though. It's more correct and more complete now
(some things are still missing though).
* Added boot platform awareness to the kernel. Moved the generic
Open Firmware code (openfirmware.c/h) from the boot loader to the kernel.
* The kernel PPC serial debug output is sent to the console for the time
being.
* The PPC boot loader counts the CPUs now and allocates the kernel stacks
(made OF device iteration a bit more flexible on the way -- the search
can be restricted to subtree). Furthermore we really enter the kernel...
(Yay! :-) ... and crash in the first dprintf() (in the atomic_set()
called by acquire_spinlock()). kprintf() works, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15756 a95241bf-73f2-0310-859d-f6bbb57e9c96
when receiving a HELLO request. Thus it doesn't need to be restarted
when the image had been rebuilt. That was a bit annoying...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15735 a95241bf-73f2-0310-859d-f6bbb57e9c96
reported from our build tools under Linux. As it seems Linux does not
translate dirent::d_ino for mount points (BeOS and Haiku do), which
caused us not to find a mount point entry in its parent directory.
Thanks to Vampyre for the hint.
Fixes bugs #73 and #76.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15726 a95241bf-73f2-0310-859d-f6bbb57e9c96
I wouldn't be surprised, if more wrappers are still missing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15709 a95241bf-73f2-0310-859d-f6bbb57e9c96
specifying whether only the exact supplied address is acceptable. If
false, the address is considered a hint only. It will be picked, if
available, otherwise a greater address is tried to be acquired, and
as last resort any address. This feature is only implemented for PPC.
It is needed since the preferred kernel text base address 0x80000000
might not be available (and actually isn't on my Mac mini).
* Fixed a bug in the PPC memory management code:
is_{virtual,physical}_allocated() were checking whether the given
range was completely contained by an existing range instead of
checking for intersection. As a consequence we could (and did) allocate
a range intersecting with already allocated ranges. The kernel segment
thus overwrote OF memory for instance.
* The ELF loader makes sure that it got both text and data segment of
the image to be loaded.
The PPC boot loader successfully loads kernel and modules now. Next
comes the hard part, I'm afraid.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15708 a95241bf-73f2-0310-859d-f6bbb57e9c96
platform_allocation_region(). Since the callback stuff doesn't seem to
work, the Open Firmware didn't ask us to allocate memory in turn, and
thus we didn't know about the range that had been mapped and reused it
later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15699 a95241bf-73f2-0310-859d-f6bbb57e9c96
IP, and UDP, as well as a home brewn UDP based protocol, "remote disk",
which provides random access to a single remote file/device. The Open
Firmware flavored boot loader automatically initializes the net stack,
searches for a remote disk, and tries to boot from it, if the boot
device is a network device (e.g. when loading the boot loader via
TFTP).
This is quite nice for developing with a two-machine setup, since one
doesn't even need to install Haiku on the test machine anymore, but can
serve it directly from the development machine. When the networking
support in the kernel is working, this method could even be used to
fully boot, not just for loading kernel and initial modules.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15689 a95241bf-73f2-0310-859d-f6bbb57e9c96
argument value of 0 should only free the old allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15688 a95241bf-73f2-0310-859d-f6bbb57e9c96
* bfs_inode must be packed, otherwise the structure is larger due to
different alignment requirements.
* The off_t array returned by bfs_inode::Values() is in on-disk
endianess. This was ignored in some places. Hope I squashed all
occurences.
Those fixes should probably be back-ported to the kernel add-on, too.
Will do that when I get to that point in the kernel, unless someone
beats me to it.
The PPC boot loader does at least find the kernel on a BFS volume now.
Haven't dared to let it be loaded yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15686 a95241bf-73f2-0310-859d-f6bbb57e9c96
arch_cpu_user_TLB_invalidate(). Empty at the moment; will have a look at
that later. The PPC kernel builds again, now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15685 a95241bf-73f2-0310-859d-f6bbb57e9c96
of_call_method() which is actually an implementation of the
"call-method" client function.
* of_interpret() announced one less return value than actually needed.
Seemed to work anyway, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15683 a95241bf-73f2-0310-859d-f6bbb57e9c96
menu. The menu basically works, but has a couple of problems. The
harmless ones are graphical: we get cursor artifacts when the colors
are changed, and the item selection doesn't quite look as it should.
More serious is the lack of Home/End, Page Up/Down keys. All I read from
the console is a '\0' byte when such a key is pressed. The cursor keys
work fortunately. I mapped the functionality of Page Up/Down
additionally to the Left/Right cursor keys. So the menu should be usable
at least. I guess, I'll leave it in that state; Axel wants a graphical
menu anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15589 a95241bf-73f2-0310-859d-f6bbb57e9c96
effect that we were linking not only against the complete glue code, but
also against libroot.so. Now we explicitly link against
crtbegin.o/crtend.o only.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15545 a95241bf-73f2-0310-859d-f6bbb57e9c96
author ever checked the documentation for the function he was trying to
use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15492 a95241bf-73f2-0310-859d-f6bbb57e9c96
suboptimal (if working at all) -- review is appreciated.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15486 a95241bf-73f2-0310-859d-f6bbb57e9c96
easier to define them for now, since they are used unconditionally e.g.
in the Tracker sources.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15485 a95241bf-73f2-0310-859d-f6bbb57e9c96
one of the TODOs already says, the architecture specific parts should be
factored out into separate source files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15480 a95241bf-73f2-0310-859d-f6bbb57e9c96
but it compiles at least. :-)
* Pulled the architecture specific part out of <posix/setjmp.h> into
<posix/arch/<arch>/arch_setjmp.h>.
* Moved setjmp_save_sigs.c from the x86 specific implementation into a
"generic" sibling directory, since it is reusable (and actually used
by the PPC implementation).
* Added generic/longjmp_return.c containing a function __longjmp_return,
which is invoked at the end of siglongjmp(), resetting the signal mask
and validating the return value. It is used by the PPC implementation,
and should also be used by the x86 implementation, but I'll leave that
to someone who's motivated enough to also test it. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15479 a95241bf-73f2-0310-859d-f6bbb57e9c96
functions from glibc 2.3.2. Adding those one by one is extremely
boring and time-consuming work. We should probably just remove the
math stuff again, add a verbatim copy of the glibc directories, and
shuffle things around afterwards.
* Note that for x86 holds sizeof(long double) == 96. I removed the
generic 128 bit long double functions that were in use before and
added respective 96 bit versions to arch/x86 (or left them out, if
they weren't used). For PPC the System V ABI spec supplement specifies
sizeof(long double) == 128, but I had trouble configuring gcc to
actually use that setting (looks like there simply is no support for
TI mode for PPC 32). So we have to live with sizeof(long double) ==
sizeof(double) == 64 for the time being.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15477 a95241bf-73f2-0310-859d-f6bbb57e9c96
inline. Commented undefined virtual methods. BBitmapBuffer is still used, so
is ViewHWInterface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15472 a95241bf-73f2-0310-859d-f6bbb57e9c96
x86 the Haiku image still builds, so it is apparently not used. I
guess it would be best to abandon our posix_math.o completely and
use the glibc math implementations instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15446 a95241bf-73f2-0310-859d-f6bbb57e9c96
added a generic implementation using atomic_test_and_set().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15444 a95241bf-73f2-0310-859d-f6bbb57e9c96
glibc 2.3.2, which seems to be the version used in other places,
though I also found older files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15402 a95241bf-73f2-0310-859d-f6bbb57e9c96
system happy for the time being. We need real setjmp()/longjmp()
implementations for PPC eventually, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15401 a95241bf-73f2-0310-859d-f6bbb57e9c96
to make the build system happy for now. We'll see later what we
have to do.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15400 a95241bf-73f2-0310-859d-f6bbb57e9c96
build tools as well. The configure option --build-cross-tools-gcc4 has a
new parameter to specify the architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15382 a95241bf-73f2-0310-859d-f6bbb57e9c96
the sizes and alignments of syscall parameters. It no longer
generates and compiles functions with the same signature as the
syscalls. This simply doesn't generally work for cross-compilation.
Instead we provide a bit of architecture-specific code that knows
how things work for the target architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15196 a95241bf-73f2-0310-859d-f6bbb57e9c96
Each component is built in the respective subdirectory now
and no longer in src/system/Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15184 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold