* As 104Mhz is stores as 10400 on atombios,
and 104000 everywhere else... this conversion
was going the wrong direction.
* Shrink the stored value to 10Khz units to properly
compare to the AtomBIOS value
* These aren't tested, but since we go off of DCE
versions for a lot of stuff, they may work.
* AMD doens't include market names in their drivers
anymore, so if we want to label them it will take
additional work.
* pptable.h now 100% stock
* atombios.h now 99% stock
* Resolves issues with radeon_hd on x86_64 by
making atombios structs match OS typedefs
* Resolves#10614
* For use on linux hosts to attach a secondary GPU directly
to a qemu / kvm virtual machine.
* The attached card may be in a limbo state, so the driver will
need to re-post the GPUU
* Add isb just because.
* pdziepak pointed out that ARMv5 and before
had different barrier support.
* pdziepak also mentioned that dsb was too strong
for __sync_synchronize
* On ARMv6 or older, we do a simulated dsb.
* Move __sync_synchronize into thread.c in libroot
and use the new arch_atomic.h dsb/dmb defines.
* Gets arm @bootstrap-raw to end of bootstrap.
* Don't assume verdex as it isn't clear this was
occurring.
* Make an educated guess on HAIKU_BOOT_PLATFORM
based on provided board (but still allow it to
be overridden)
* Error out if user doesn't populate
HAIKU_BOOT_PLATFORM or enters an unknown board
name.
* You need to add "-sHAIKU_BOOT_BOARD=xxx" to
your jam to build for the proper ARM device.
* Rename beagle to beagleboneblk as per the
documentation.
* Was causing LLVM to fail to build on x86_64
* Make XINT64 adjust based on architecture like
config/types.h to ensure these macros match
uint64 and int64 at all times.
* Resolves#10566
* As per the ML discussions. Bumps MIPS to tier 3.
* We've reached a unanimous descision that MIPS doesn't
target any real / valid hardware Haiku wants to pursue
at the moment. In the event that anyone wants to pursue
MIPS, feel free to fork Haiku into your own repository
(and we'll even link to it on the website ports page)
* If someone develops a viable plan for MIPS (and gets the
port working, it can be readded at a later date)
* Use atomic_get_and_set for return value
* Atomics are no longer volatile
* Add missing arch_cpu_pause stub
* Move arch_cpu_idle to arch_cpu header to match
other architectures
* Some cards have a lot of pins!
* Should fix#10536
* Add a check to give a friendy warning if we find
more GPIO pins than what we are prepared for.
* Technically the maximum GPIO pins could be
ATOM device max * 2 (16 for i2c and other)
however lets leave some room for expansion.
* This is less pretty, but we need access to the connector
to find the HPD gpio pin mask on the card.
* dp_aux communications seem to work again.
* If you have a DisplayPort item attached to your card you
may want to just unplug it at this point. We attempt DP
link training and it fails. This failure will also cause
other monitors to not function as app_server still isn't
multi-head aware (#10486)
* Bump i2c data into it's own struct
* Populate gGPIOInfo with general gpio pins
(for things like HPD, and voltage control)
* Attach HPD gpio pins to connectors
* Dump trace info of HPD pins as well as i2c pins
* There are GPIO pins for hotplug interrupts and i2c
communications (for edid). Add two fields to connector
(index for each in gGPIOInfo).
* DP aux communcation seems to want the hotplug GPIO pin
info, which we don't get (I think this is why DP AUX comms
is broken at the moment)
* GPIO LUT seems to know about a wide range of GPIO pins, while
the i2c gpio calls only know about the ones needed for i2c.
* I'm tempted to populate gGPIOInfo with the LUT pins and
then suplement that data with the i2c GPIO pins data.
(however, not sure how many pins there are generally defined
so it could impact performance. More investigation is needed)
This would reverse how it works now with this commit.
* The DPMS hook would be called on all
possible displays causing lots of link
training on incomplete connector structures
that may be not attached / connected.
* Added cards need testing.
* 3dfx, ati, neomagic, and s3 still don't build due to some
more complex pointer size issues. (and I don't have hardware
to test on)
* open_count only got raised on initial open,
subsequent opens didn't increment the counter
thus when they exited the driver unloaded
causing app_server to crash
* Thanks to hamishm for pointing out that
the if checks the pre-increment number
* Resolves#10452
* open_count only got raised on initial open,
subsequent opens didn't increment the counter
thus when they exited the driver unloaded
causing app_server to crash
* Thanks to hamishm for pointing out that
the if checks the pre-increment number
* Resolves#10452
* Add a kdl debug command to radeon_hd
* Fix incorrect cpu vendor name mapping
* Add additional CPU architectures
* Add additional CPU vendors
* Rework PowerPC arch_system_info passing
PVR back for cpu model
* Set max cpu to 1 for PPC until atomic functions are finished
* We have atomic functions inline in the kernel and assembly
code in libroot post-scheduler merge... isn't that a lot of
duplication?
* Resolves problem with secondary arch builds
not picking up secondary os kit headers
* Still need to build x86 gcc packages
* No binary changes, shouldn't need a bootstrap
* Displays standard CPUID, and shows what the
internal CPUID used by OS.h *should* be.
* Should help out in identifying new CPU's
as all end users have to do is run sysinfo
to get the CPU info + value for OS.h
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
* My BeagleBone gcc defines __ARMEL__ but not
__ARM__ which breaks the native tool builds
* As ARM was originally Little Endian, we assume
__ARM__ means as such.
* Look for Big Endian ARM and define the needed big
endian preprocessors
