From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Id4by-0002aK-2M for qemu-devel@nongnu.org; Wed, 03 Oct 2007 09:50:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Id4bq-0002Yu-Vi for qemu-devel@nongnu.org; Wed, 03 Oct 2007 09:50:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Id4bq-0002Yr-Rs for qemu-devel@nongnu.org; Wed, 03 Oct 2007 09:49:54 -0400 Received: from [85.186.197.132] (helo=swpark.galati.ro) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Id4bq-0000Lm-6e for qemu-devel@nongnu.org; Wed, 03 Oct 2007 09:49:54 -0400 Message-ID: <47039DDF.7050004@comsys.ro> Date: Wed, 03 Oct 2007 16:49:19 +0300 From: Vlad Lungu MIME-Version: 1.0 Subject: Re: [Qemu-devel] U-Boot patch for qemu -M mips References: <4702185B.3010807@comsys.ro> <20071002164027.GG16772@networkno.de> <470352E7.8050200@comsys.ro> <20071003133706.GM16772@networkno.de> In-Reply-To: <20071003133706.GM16772@networkno.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Thiemo Seufer wrote: > Vlad Lungu wrote: > [snip] > >>>> +long int initdram(int board_type) >>>> +{ >>>> + /* Sdram is setup by assembler code */ >>>> + /* If memory could be changed, we should return the true value >>>> here */ >>>> + return MEM_SIZE*1024*1024; >>>> >>>> >>> Qemu gets the amount of RAM passed via a command line switch, the >>> qemu-mips emulation sets up a Linux kernel like "command line" in >>> memory where u-boot could parse it from. >>> >>> >>> >> Does it, or just when you pass -kernel to it? I'll check. >> > > Hm, you are right, it does that only for -kernel. Would it make sense > to change that in Qemu? > IDK. Maybe I can probe the RAM size in U-Boot , or if this does not work, put some info somewhere (RAM, register, emulated DIP-dwitch), like RAM size, endianness of the CPU. > Since the mips_r4k machine doesn't correspond to any real hardware we > have a bit of leeway with the "hardware" design. > > >>>> +} >>>> + >>>> + >>>> +int checkboard (void) >>>> +{ >>>> + u32 proc_id; >>>> + >>>> + proc_id = read_32bit_cp0_register(CP0_PRID); >>>> + >>>> + switch (proc_id >> 24) { >>>> + default: >>>> + printf ("Unsupported cpu %d, proc_id=0x%x\n", proc_id >> >>>> 24, proc_id); >>>> + } >>>> + >>>> + return 0; >>>> +} >>>> >>>> >>> Huh? What is this code good for? >>> >>> >>> >> Checking for the type of board, I suppose :-) I think all BSPs have it and >> it's called early in the boot process. I could either do only a return 0 or >> actually decode CP0_PRID and print something meaningful, if Qemu sets it to >> something sensible. Or just print a nice banner. >> > > As it is, this code prints a nice "Unsupported CPU" banner no matter what > (and proceeds anyway instead of bailing out). > True, because it does not care much about this at the moment. Nor do I. But that can change. > Latest CVS Qemu supports a number of different CPUs (see the -cpu switch), > the default for 32 bit is a 24Kf, and for 64 bit a R4000. > > I'll look into this and see what use can we make of CP0_PRID. Vlad