Jan Kiszka wrote:
> andrzej zaborowski wrote:
>> Hi,
>>
>> On 13/04/2008, Jan Kiszka <jan.kiszka@web.de> wrote:
>>> This is the board emulation for Freecom's MusicPal, featuring
>>>   - rudimentary PIT and PIC
>>>   - up to 2 UARTs
>>>   - 88W8xx8 Ethernet controller
>>>   - 88W8618 audio controller
>>>   - Wolfson WM8750 mixer chip (volume control and mute only)
>> Are you sure that hw/wm8750.c is not reusable?  It's probably better
>> to extend it with volume control, and audio data transmission through
>> i2c, instead of having two implementations in QEMU.
> 
> Will check again, but I don't think it is helpful, at least at this
> point. The thing is that the MusicPal uses the on-chip DAC, not the one
> of the Wolfson. The latter seems to be responsible for analogous mixing
> only.

That was nonsense: The audio architecture of the MusicPal appears to be
much like the one of the Spitz. Redirecting the audio stream to the
Wolfson should be feasible. However, lacking support for volume control
and muting currently prevents this.

Andrzej, as you have written the wm8750, do you already know where which
volume level would have to be applied (open-coded or via some
AUD_set_volume)? I'm currently only using LOUT2VOL, and I'm a bit lazy
to study the datasheet /wrt all the mixer details.

>>>   - 128×64 display with brightness control
>>>   - all input buttons
>>>
>>>  Using up to 32 MB flash, I hit a limit /wrt phys_ram_size. I worked
>>>  around this for now by extending MAX_BIOS_SIZE to 32 MB, surely not a
>>>  nice solution.
>> You can use -m 150 or similar.
>>
>> Please also format the code similarly to rest of Qemu.
> 
> That would just increase ram_size, thus won't help as I need memory
> beyond it (here for the pflash in R/W mode).

OK, I see what you mean after looking at your N800 patches: You apply a
fixed RAM size, leaving the rest of what the user provided via -m to
SRAM and flash. Not optimal IMHO, you may sometimes also want to play
with the RAM size even if the real devices has a fixed amount. And it is
far from being intuitive as well.

The only true solution I see right now is moving qemu_vmalloc into the
machine initialization code. Is there anything between current
qemu_vmalloc and machine->init that relies on phys_ram_base being valid
(and which can't be moved after the machine init) and thus prevents this?

Jan