Hi, Guenter,
Le 07/11/2016 à 20:54, Guenter Roeck a écrit :
> Hi Marek,
>
> On 11/07/2016 10:14 AM, Marek Vasut wrote:
>> On 11/07/2016 04:58 AM, Guenter Roeck wrote:
>>> On Tue, Oct 25, 2016 at 09:57:43PM +0200, Marek Vasut wrote:
>>>> From: Chris Wulff <crwu...@gmail.com>
>>>>
>>>> Add support for emulating Altera NiosII R1 architecture into qemu.
>>>> This patch is based on previous work by Chris Wulff from 2012 and
>>>> updated to latest mainline QEMU.
>>>>
>>>> Signed-off-by: Marek Vasut <ma...@denx.de>
>>>> Cc: Chris Wulff <crwu...@gmail.com>
>>>> Cc: Jeff Da Silva <jdasi...@altera.com>
>>>> Cc: Ley Foon Tan <lf...@altera.com>
>>>> Cc: Sandra Loosemore <san...@codesourcery.com>
>>>> Cc: Yves Vandervennet <yvand...@altera.com>
>>>> ---
>>>> V3: Thorough cleanup, deal with the review comments all over the place
>>>> V4: - Use extract32()
>>>> - Fix gen_goto_tb() , suppress tcg_gen_goto_tb()
>>>> - Clean up gen_check_supervisor() helper
>>>> - Use TCGMemOp type for flags
>>>> - Drop jump labels from wrctl/rdctl
>>>> - More TCG cleanup
>>>> V5: - Simplify load/store handling
>>>> - Handle loads into R_ZERO from protected page, add comment
>>>> V6: - Fix division opcode handling
>>>> - Add missing disas handling
>>>> - V5 review comments cleanup
>>>> ---
>>> [ ... ]
>>>
>>>> diff --git a/target-nios2/cpu.h b/target-nios2/cpu.h
>>>> new file mode 100644
>>>> index 0000000..17c9a0f
>>> [ ... ]
>>>
>>>> +static inline void cpu_get_tb_cpu_state(CPUNios2State *env, target_ulong
>>>> *pc,
>>>> + target_ulong *cs_base, uint32_t
>>>> *flags)
>>>> +{
>>>> + *pc = env->regs[R_PC];
>>>> + *cs_base = 0;
>>>> + *flags = (env->regs[CR_STATUS] & (CR_STATUS_EH | CR_STATUS_U));
>>>> +}
>>>> +
>>>> +#endif /* CPU_NIOS2_H */
>>>> +
>>>
>>> The empty line at the end results in a whitespace message from git.
>>
>> Dropped, thanks. Is there anything else or is this patchset starting to
>> become acceptable ?
>>
>
> Hard for me to say. I tried to build and run the series with the latest linux
> kernel (v4.9-rc4), but it is stuck in early boot. I tried with 10m50_defconfig
> and 10m50_devboard.dtb. gcc is 6.1.0 built with buildroot, though I also tried
> with toolchains from CodeSourcery. Obviously I have no idea if there is a
> kernel bug or a qemu bug or a problem with the command line I used.
>
> Here is my command line:
>
> qemu-system-nios2 -M 10m50-ghrd -kernel vmlinux -dtb 10m50_devboard.dtb \
> -append "earlycon=uart8250,mmio32,0x18001600,115200n8 console=ttyS0"
I'm also using Buildroot to build the Linux initrd system and it works fine :)
I'm using the CodeSourcery toolchain and I also tried with the Buildroot
internal toolchain too, I guess it's a problem with your Qemu command line.
Here is my Buildroot config:
BR2_nios2=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="10m50"
BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="board/qemu/nios2-10m50/linux-4.8.fragment"
BR2_TARGET_ROOTFS_INITRAMFS=y
The board/qemu/nios2-10m50/linux-4.8.fragment file contain the following lines
to extend the 10m50 kernel defconfig:
CONFIG_NIOS2_DTB_SOURCE_BOOL=y
CONFIG_NIOS2_DTB_SOURCE="arch/nios2/boot/dts/10m50_devboard.dts"
With that, you should be able to boot Qemu with the following command line:
qemu-system-nios2 -kernel output/images/vmlinux -nographic
[...]
Welcome to Buildroot
buildroot login: root
# cat /proc/cpuinfo
CPU: Nios II/fast
MMU: present
FPU: none
Clocking: 75.00 MHz
BogoMips: 150.00
Calibration: 75000000 loops
HW:
MUL: yes
MULX: no
DIV: yes
Icache: 32kB, line length: 32
Dcache: random: fast init done
32kB, line length: 32
TLB: 16 ways, 256 entries, 8 PID bits
But I haven't tested the upcoming v4.9 kernel yet.
I'll add this Buildroot Qemu defconfig to Buildroot as soon as the nios2 has
been merged in Qemu :)
Best regards,
Romain
>
> This may be wrong, but the boot is stuck in an endless loop in mark_bootmem(),
> which seems early and odd. I tried with both vmlinux and
> arch/nios2/boot/vmImage,
> with the same results.
>
> Can you provide a working command line and kernel version, and/or directions
> how
> to create a working image if I need to run the image, for example, from
> u-boot ?
> Sorry if that is posted somewhere and I missed it.
>
>> I'll wait a bit before you finish discussing the whitespace errors in
>> 1/7 with Sandra.
>>
>
> I can't really comment on the whitespace issues; the qemu maintainers will
> have
> to decide if they can accept this patch as-is. I am sure they will appreciate
> a heads-up, though.
>
> Thanks,
> Guenter
>
>
