[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and
Re: [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM)
Sat, 17 Oct 2020 19:44:29 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
On 10/17/20 6:39 PM, BALATON Zoltan via wrote:
On Fri, 16 Oct 2020, Philippe Mathieu-DaudÃÂ© wrote:
On 10/16/20 11:58 AM, Mark Cave-Ayland wrote:
On 16/10/2020 00:47, BALATON Zoltan via wrote:
This is the cut down version of the earlier series omitting unfinished
patches that I plan to rework later and rebased to Mark's qemu-macppc
branch. Compared to v7 the only change is the cast to (target_ulong)
from (uint32_t) as requested by Mark in patch 1.
FWIW the reason for suggesting the cast to target_ulong is so that
the same code works for both qemu-system-ppc and qemu-system-ppc64.
For qemu-system-ppc that should correctly drop the sign extension
from 32-bit, whilst still allowing someone to load a 64-bit ELF into
qemu-system-ppc64 if requested.
IMO this is part of a bigger design problem. Not all
machines main bus is 64-bit. I did some experiments
but changing that involves a lot of work.
Did not want to reply to this to not bring it to your attention before
patch gets in finally but it's too late...
Not sure what you refer to
I refer to having machines with a N-bit main bus using a N-bit main bus
(currently all main busses are 64-bit wide).
Some 32-bit machines have access to 64-bit busses, some don't.
I have been wondering about it because of the AVR CPU which
uses a pair of busses, each less than 32-bit.
If one day I can finish my work there, the Old World mac might
benefit from it.
but in this particular case the problem only
seems to be load_elf loading 32 bit ELF files returning sign extended 64
bit address which looks bogus but since this function is widely used I
did not feel confident enough to propose a patch to load_elf.
By the way, also the parameters of load_elf could take a clean up to
remove all the mostly NULL values as I've pointed out before:
but all this could wait until later, these don't seem to be urgent
problems to prevent moving mac machines forward now and could all be
addressen in separate elf loading series. So just note the problem and
move on for now please.
- [PATCH v8 3/5] mac_oldworld: Drop a variable, use get_system_memory() directly, (continued)
- [PATCH v8 3/5] mac_oldworld: Drop a variable, use get_system_memory() directly, BALATON Zoltan, 2020/10/15
- [PATCH v8 4/5] mac_oldworld: Drop some variables, BALATON Zoltan, 2020/10/15
- [PATCH v8 1/5] mac_oldworld: Allow loading binary ROM image, BALATON Zoltan, 2020/10/15
- [PATCH v8 5/5] mac_oldworld: Change PCI address of macio to match real hardware, BALATON Zoltan, 2020/10/15
- Re: [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM), Mark Cave-Ayland, 2020/10/16
- Re: [PATCH v8 0/5] Mac Old World ROM experiment (ppc/mac_* clean ups and loading binary ROM), Philippe Mathieu-Daudé, 2020/10/16