This should allow easier porting of things like flashrom,
as it mimics FreeBSD's /dev/io behaviour.
Change-Id: Iaa6b6342cf7983a9655a7155adfcc46c8a8264f1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1077
Reviewed-by: Jérôme Duval <[email protected]>
Somehow the first review merged only the commit log.
FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.
Change-Id: I6372af6679e6773fbb6bf4c8b5b30512971a97a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3161
Reviewed-by: Alex von Gluck IV <[email protected]>
For some reason the kernel ended up with a bunch of .text.foo or
.data.rel.bar sections, each with their own ELF section headers and
other metadata. Forcing them into the base sections drops the binary
size by about 100kB, even for the stripped one.
I suspect it should work on other archs as well.
Change-Id: I7a8f46480d71267c07b75325423a0f5bfd2d12fb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3101
Reviewed-by: Alex von Gluck IV <[email protected]>
Next floppies actually do have a "disk label" (partitionning scheme),
the boot block being later on the disk.
This commit generates an identical label to the image I have here (but
not the copies at other sectors), including the checksum.
Change-Id: I7f939c26e70e3626d9af7a3eb342cfd32c298e3d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3098
Reviewed-by: Alex von Gluck IV <[email protected]>
Doesn't work yet though:
- we don't implement heap yet,
- non-color machines have 2bpp, so we'll have to hack this in some way.
Change-Id: Idf8f69c2256837db3915949d93265decbb43a524
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3097
Reviewed-by: Alex von Gluck IV <[email protected]>
Those were found in the official headers in the NeXTstep ISO, how come I
didn't even look there in the first place?
We do get enough info to use the framebuffer, but sadly the SCSI IO
seems invalid. Both the NetBSD and even NeXTstep bootblock have their
own embedded drivers, maybe they didn't trust their own rom?
Change-Id: I0a47c433da89b15091644cd5c69ffff24d0cdd1f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3096
Reviewed-by: Alex von Gluck IV <[email protected]>
Since the boot ROM API structure is declared with a custom alignment, we
simulate it with padding bytes around, and use aligntest.prg to verify
using ARAnyM + TOS/MiNT as we know how to link simple PRG files.
It now prints something to the screen then panics when initializing the
heap.
For now one must insert the loader manually into an existing floppy
image:
dd if=generated-m68k/objects/haiku/m68k/release/system/boot/next_m68k/haiku_loader.next_m68k bs=$((0x8000)) seek=1 of=next_floppy.img conv=notrunc
Change-Id: I06d74e9d85a352aab68dedce545bbe5fe9e990d5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2220
Reviewed-by: Adrien Destugues <[email protected]>
FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.
Not sure the 'hidden' define should go there.
Change-Id: I343f72d61dcacf7dfc180d112529f5a6521d7e3b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2213
Reviewed-by: Alex von Gluck IV <[email protected]>
The .rel.* sections were forgotten in the PE binary, so we just put them in a single .rel
Change-Id: I7bc564e18ec8dd64410b43106272ee74696c2883
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2973
Reviewed-by: Alex von Gluck IV <[email protected]>
I did some tcpdump recording, and I believe we confuse the receiver
with our Zero Window Probe, because we don't resent even though it only
ACKs the previous segment, and we keep sending things after it:
* we send the last segment before window is closed, next seg = N,
* we get ACK for N, with window=0
* we send Zero Window Probe with 1 byte, next seg = N+1,
* we eventually get a window>0 ACK still at N,
* we start sending stuff again, but starting from N+1,
* receiver keeps ACKing N because it never accepted it.
It seems sending either 1 or 0 byte is valid for a ZWP, although I'm not
entirely sure. At least it's easier to handle 0 than 1, and it seems to work.
Wireshark shows them as duplicate ACKs, but they get the thing going.
References:
* RFC 793: https://tools.ietf.org/html/rfc793#section-3.7
* RFC 6429: https://tools.ietf.org/html/rfc6429
* Wireshark wiki: https://www.wireshark.org/docs/wsug_html_chunked/ChAdvTCPAnalysis.html
Should fix#13769.
Change-Id: I95264ebbbb8c66c23411dfce6fc41871e0427166
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1188
Reviewed-by: waddlesplash <[email protected]>
Sadly the NetBSD elf2aout only support 32bit, and this one from FreeBSD
only supports 64bit. This one was simpler to fix because it only handles
basic stuff.
Change-Id: I70165f680ec1cd95c156d4116f9d96c6b4ac53b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2206
Reviewed-by: Adrien Destugues <[email protected]>
This should give more meaningful errors in pkgman
(not so sure, feel free to tweak the mapping),
and also avoid running the next job if fetching failed.
Change-Id: If76968f705ff25f7ecf1a5f91d88a02040d24665
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2186
Reviewed-by: Ryan Leavengood <[email protected]>
Very simple for now, just reuses the Haiku one with some gradients
removed.
Add it to the haiku_extras package.
Change-Id: I41729ed65b147fed72bf56e7c5c89367b75563bb
Reviewed-on: https://review.haiku-os.org/c/1431
Reviewed-by: waddlesplash <[email protected]>
app_server just passes the add-on path around.
Maybe we should make sure the add-on can be loaded when setting it.
Change-Id: I3acd3299782a22c1666bd5435dbf3d8053e359fa
Reviewed-on: https://review.haiku-os.org/c/1430
Reviewed-by: waddlesplash <[email protected]>
Since not everyone likes the default, make it an option in the vesa
settings file. Note setting a mode with the Screen prefs overwrites
the file so it will discard the option.
Also move the code to get_mode_from_settings() since we can't load driver
settings as early as vesa_init().
Change-Id: I93080bd1fbc064dab053624ad37935268b1ed17d
Code was comparing "/usr/bin/" with "/usr/bin/env" of whatever was
passed. We now only compare the substring.
Change-Id: I0d09589fa83227d88fc8ba458eaf4293e86a041b
starsseed told me it worked fine and is actually nice for demos :-)
Another option could be to add a menu entry to open a new window, but
I'm just back from JDLL so I'm quite lazy :p
Change-Id: I91e34517812f84157db7e24f2edff587deabbbe9
I tried to use the feature stuff to relocate objects but didn't managed
to get it to work, having another subdir seems to be the simplest
solution.
I managed to mount a clone of my BeBox' drive, but it KDLed shortly when mouting
read-write.
Change-Id: Ia4f126673e553e4f3e524a40218e6c623527b96d
Reviewed-on: https://review.haiku-os.org/c/645
Reviewed-by: Adrien Destugues <[email protected]>
Since NULL is not considered a user address anymore, we must check for
it first.
This fixes the "mount: Bad address" error after hrev52905.
Change-Id: If60ea58bb81b6c35c6bf27ecfa9b29bd7a25d8aa
This time we use the pci_info directly, it avoids a possible race with
PCI config regs, and we already have the value there anyway.
Signed-off-by: Augustin Cavalier <[email protected]>
One crucial fix by me: check if size == 0. This avoids the deadlock
seen in #14795.
Inode::_FindPath() always deletes the inode it uses regardless
the source, including when it's from the HashtableInodeSource.
But the later returned the inode object directly from the hashtable
when it's inside, so it gets deleted bu _FindPath… then reused later on
when searching the hashtable again.
I'm not sure it's the correct solution but at least malloc_debug doesn't
complain anymore.
Since it handles physical address it should really be this.
It's not like many drivers actually used it anyway. It shouldn't harm
compatibility, drivers calling it with only 32bit would leave garbage in
the higher bits but since on x86 it's a noop anyway, it would end up in
the MSB register tha's ignored because it expects a 32bit result.
ThemeManager has an UTF-8 copyright symbol in its rdef file.
The chroot set up by haikuporter doesn't export anything that would
hint grep to accept UTF-8 as text, so it freaks out...
So we force it to accept anything as text.
François Revol