Hi, Chris:
I know that the Hypervisor toolkit (which with a prebuilt kernel.elf ---
note: only for ARMv7) can working, but what I am talking about is
that the source code which you pulled from the Git repository will never
working. Am I right?
Regards.
Charles, Liu
----- Original Message -----
From: "Jenkins, Christipher Derell" <cdj...@sandia.gov>
To: <codezero-devel@lists.l4dev.org>
Sent: Thursday, May 10, 2012 10:37 PM
Subject: Re: [codezero-devel] [EXTERNAL] Re: Codezero for PandaBoard bootloader
question
> Liu,
>
> Be sure to use the patched QEMU from the website. I believe the manual gives
> the link. I believe you can also download the 0.5.0 toolkit and it have both
> insight, gdb, and the patch qemu. Like yourself, I did see issues when I did
> a fetch from the Git repo. I believe the codezero team will be releasing some
> new code soon (according to emails and mail-serv posts) that should help with
> ARMv7 development.
>
> Best,
> Chris J
>
> -----Original Message-----
> From: 起凌 [mailto:chipl...@yeah.net]
> Sent: Thursday, May 10, 2012 3:25 AM
> To: amit.maha...@b-labs.com; Jenkins, Christipher Derell
> Cc: codezero-devel@lists.l4dev.org
> Subject: Re: [codezero-devel] [EXTERNAL] Re: Codezero for PandaBoard
> bootloader question
> Importance: High
>
> Hello, Dear all:
>
> In fact, as in my test result, the codezero source code which from Git
> repository & the download page that cannot work, even the ARMv5's code. With
> the Git version and follow the http://www. l4dev.org/build_from_scratch
> document, We can produced a "final.elf" for PB926-Versatile Platform &
> ARM926EJ-S processor with an "empty" or "hello_world" baremetal project, but
> when you run the final image with qemu & gdb debugger, and after the
> following messages:
>
> ELF Loader: Loader image size: 557KB, placed at physical 0xe00000 - 0xe8b6b8
> Loading the kernel...
> Entry point: 0x8000
> Copying to range from 0x8000 to 0x1fdf8 of size: 0x17df8 Clearing memory...
> starting from 1fdf8, size: 0 Copying to range from 0x20000 to 0x2d000 of
> size: 0xd000 Clearing memory... starting from 2d000, size: 61c8 Copying to
> range from 0x34000 to 0x38390 of size: 0x4390 Clearing memory... starting
> from 38390, size: 0
>
> Loading containers...
>
> Loading section .cont.0 from top-level elf file.
> Loading .img.0 section image...
> Entry point: 0xa0000000
> Copying to range from 0x10295c to 0x10297c of size: 0x20 Clearing memory...
> starting from 10297c, size: 0 Copying to range from 0x100000 to 0x10297c of
> size: 0x297c Clearing memory... starting from 10297c, size: 0 Copying to
> range from 0x103000 to 0x1030b4 of size: 0xb4 Clearing memory... starting
> from 1030b4, size: 104c
>
> Total of 1 images in this container.
> Total of 1 container images.
> elf-loader: kernel entry point is 0x8000
> elf-loader: Starting kernel
>
> code0: start kernel...
>
> code0: Init kernel mappings...
> code0: Virtual memory enabled.
> code0: Kernel area 0xf0008000 - 0xf0039000 remapped as 49 pages
> code0: Kernel built on May 10 2012, 15:44:05
> code0: Mapping 0x3000 bytes as RX from 0x100000 physical to 0xa0000000
> virtual for hello_world0
> code0: Mapping 0x2000 bytes as RW from 0x103000 physical to 0xa0003000
> virtual for hello_world0
>
> you will see the message as following( when you using "c" or "n" command in
> gdb after the init_finalize() ):
>
> Pager (1) faulted on itself. FSR: 0x1f, FAR: 0xa00040ec, PC: 0xa0001d2c pte:
> 0x104ffe CPU0 Exiting.
>
> this message seems is come from file src/arch/arm/exception-common.c,
> function fault_ipc_to_pager(), line 121, I don't know if this is a bug or
> not, because in my mind, the correct message should be come from file
> conts/baremetal/hello_world/hello,c, function print_hello_world(), line 10,
> which as following:
>
> cont0: Hello world from hello_world0!
>
> but my test result always failed after init_finalize(). So, that means I do
> not believe that someone said that their demos which also come from the
> codezero's Git repository can working. Am I wrong?
>
> By the way, especially for Amit and B-labs R&D team, I found a small bug in
> file print-early.c(all of the platform), function printhex8, line 51 & line
> 54(this line numbers means in the pb926 platform version, for realview
> platform's version is line 58 & 61, beagle's version is line 50 & 53), the
> correct code should like this:
>
> 51 *temp = '\0';
> 52
> 53 if ( !val ) {
> 54 *(--temp) = '0';
>
> Am I right?
>
> Regards,
>
> Charles, Liu
>
>
> ----- Original Message -----
> From: "Amit Mahajan" <amit.maha...@b-labs.com>
> To: "Jenkins, Christipher Derell" <cdj...@sandia.gov>
> Cc: <codezero-devel@lists.l4dev.org>
> Sent: Thursday, May 10, 2012 5:59 AM
> Subject: Re: [codezero-devel] [EXTERNAL] Re: Codezero for PandaBoard
> bootloader question
>
>
>> On Wed, 2012-05-09 at 21:52 +0000, Jenkins, Christipher Derell wrote:
>>> Hello Amit.
>>>
>>> I'm new to C0 development. I pulled codezero from the Git repository and
>>> have the helloworld, mutex, and threading demos working. However, they only
>>> work for ARMv5. Also, looking at 'git log' I notice no commits have
>>> happened since June 2010. Is the development of codezero still progressing?
>>>
>>
>> Hi Chris,
>>
>> Yes we are actively working on Codezero and Virtualization. We have not
>> released ARM-V7 sources publicly yet. Instead we have release toolkits
>> for v7 based platforms like VX and panda board.
>>
>> Check l4dev.org for the toolkit downloads.
>>
>>
>> --
>> Thanks,
>> Amit Mahajan
>>
>>
>> _______________________________________________
>> codezero-devel mailing list
>> codezero-devel@lists.l4dev.org
>> http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
> _______________________________________________
> codezero-devel mailing list
> codezero-devel@lists.l4dev.org
> http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
>
_______________________________________________
codezero-devel mailing list
codezero-devel@lists.l4dev.org
http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
