Run and debug Fiasco.OC kernel and L4Re using a DSTREAM JTAG device and the ARM DS-5 IDE
Mahdi Aichouch
foxmehdi at gmail.com
Thu Nov 20 14:53:23 CET 2014
Hello everyone,
Thank you very much Adam and Martin for your answers and help.
I used this command line to compile the l4re.
$> make elfimage E=hello BOOTSTRAP_NO_STRIP=y PLATFORM_TYPE=imx6
Then I verified that the right imx platform file is being used as shown
below,
... Generating bootstrap.ld
... Compiling exec.o
... Compiling module.o
... Compiling ARCH-arm/crt0.o
... Compiling region.o
... Compiling startup.o
... Compiling init_kip_f.o
... Compiling libc_support+.o
... Compiling patch.o
... Compiling koptions.o
... Compiling platform_common.o
... Compiling memory.o
... Compiling boot_modules.o
... Compiling platform/imx.o
... Compiling ARCH-arm/reboot.o
... Compiling ARCH-arm/head.o
==> Linking bootstrap.elf
==> Post-processing bootstrap.elf
==> "bootstrap.elf" built
==> Installing bootstrap.elf in image directory
==> Installing bootstrap_hello in image directory
Image size(s) in bytes:
bootstrap_hello.elf: 1320092
Start address: 0x11000000
However, I tried to debug via JTAG, and I checked that the fiasco kernel
and l4re were wroking correctly but I was unable to see anything on the
minicom serial console.
I did some investigation in the UART driver code example from the i.MX 6
Platfrom SDK provided by Freescale, where in this case I was able to see
the debug message on a serial console and to debug the code step by step
via JTAG.
I figured out that the difference between this case and the case of running
a l4 fiasco kernel is that there is a set of configurations that are done
in the case of the UART driver and not in the l4 fiasco kernel bootstrap.
As we can see in attached files the code of the uart driver rely on a
source code that is automatically generated by the IOMUX tool to configure
the board. According to the documentation: "this tool frees the device
driver design developers from design details of each pin and pad. The
source code generated by the tool is used as-is by the SDK."
In the other hand, when the L4-fiasco kernel is started using uboot these
peripherals configuration are done. But if the L4-fiasco kernel is started
alone these configuration are not.
The problem is that if these configurations are integrated to the fiasco
bootstrap, they will be done twice when the kernel is started via uboot:
first in uboot and second in the L4-fiasco bootstrap.
Is there any elegant way to deal with this problematic situation?
My second question is related to the test of the hello world example via
tftp,
as I was able to run l4-fiasco via uboot and tftp and to get the debug
message on the serial terminal.
The problem is that after the bootstrap_hello.uimage file is loaded, the
kernel starts.
Then it is supposed to run the Hello World test example, however, in the
trace there is no Hello World scrolling...
Is there something that I am missing?
Thank you very much.
Best regards,
Mahdi
MX6Q SABRESD U-Boot > setenv bootfile
/var/lib/tftpboot/bootstrap_hello.uimage
MX6Q SABRESD U-Boot > tftp
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 10.8.33.17; our IP address is 10.8.33.200
Filename '/var/lib/tftpboot/bootstrap_hello.uimage'.
Load address: 0x10800000
Loading: #################################################################
##
done
Bytes transferred = 980460 (ef5ec hex)
MX6Q SABRESD U-Boot > bootm
## Booting kernel from Legacy Image at 10800000 ...
Image Name: L4 Image #22
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 980396 Bytes = 957.4 kB
Load Address: 11000000
Entry Point: 11000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
L4 Bootstrapper
Build: #22 Wed Nov 19 13:22:36 CET 2014, 4.8.3 20140320 (prerelease)
Scanning up to 1024 MB RAM, starting at offset 32MB
Memory size is 1024MB (10000000 - 4fffffff)
RAM: 0000000010000000 - 000000004fffffff: 1048576kB
Total RAM: 1024MB
Scanning fiasco
Scanning sigma0
Scanning moe
Moving up to 5 modules behind 11100000
moving module 02 { 110b5000-110ee63f } -> { 111a5000-111de63f } [235072]
moving module 01 { 110ab000-110b438b } -> { 1119b000-111a438b } [37772]
moving module 00 { 11044000-110aa64b } -> { 11134000-1119a64b } [419404]
moving module 04 { 1102a000-11043597 } -> { 1111a000-11133597 } [103832]
moving module 03 { 11010000-11029473 } -> { 11100000-11119473 } [103540]
Loading fiasco
Loading sigma0
Loading moe
find kernel info page...
found kernel info page at 0x10002000
Regions of list 'regions'
[ 10000000, 100000e3] { e4} Root mbi_rt
[ 10001000, 10001aff] { b00} Kern fiasco
[ 10002000, 10072fff] { 71000} Kern fiasco
[ 10090000, 10096edf] { 6ee0} Sigma0 sigma0
[ 10098000, 1009e177] { 6178} Sigma0 sigma0
[ 10140000, 10171d77] { 31d78} Root moe
[ 10178000, 101934ab] { 1b4ac} Root moe
[ 11000000, 1100f4ff] { f500} Boot bootstrap
[ 11100000, 11133fff] { 34000} Root Module
API Version: (87) experimental
Sigma0 config ip:10090100 sp:00000000
Roottask config ip:10140260 sp:00000000
Starting kernel fiasco at 100012c8
On Tue, Nov 18, 2014 at 6:55 PM, Mahdi Aichouch <foxmehdi at gmail.com> wrote:
> Hello Adam,
>
> I used this command line to compile the fiasco kernel and l4re.
>
> $> make -j 4 BOOTSTRAP_NO_STRIP=y PLATFORM_TYPE=imx6 PLATFORM_UART_NR=1
>
> I also added all these options to the src/l4/conf/Makeconf.boot
>
> But when I debug bootstrap_hello.elf binary, I still see that the
> uart_pl011.c that is used.
>
> As we can see in the attached config.all file the platform type is
> configured to i.mx6
>
> Do you have any idea.
>
> Thank you very much.
> Best regards,
>
>
>
> On Mon, Nov 17, 2014 at 11:39 AM, Mahdi Aichouch <foxmehdi at gmail.com>
> wrote:
>
>> Hello Adam,
>>
>> Thank you very much for your answer.
>>
>> I didn't tried yet using an SD card or tftp.
>> I am interested in testing it using tftp, is there any guide showing how
>> to setup a working configuration on my development machine?
>>
>> I compiled the kernel using this command line:
>> $> make BOOTSTRAP_NO_STRIP=y PLATFORM_UART_NR=1
>>
>> Now the debugger is not complaining. I have the debug information and I
>> can also see the source code (as shown in the attached screenshot).
>>
>> But I still not get the debug information from the kernel in the minicom
>> serial terminal.
>> I did a step by step walk through the code, the attached file shows all
>> the debug information that I get.
>>
>> Do I used the PLATFORM_UART_NR=1 option correctly, what verification
>> should I do also?
>>
>> Thank you very much in advance.
>>
>> Best regards,
>>
>>
>> On Sat, Nov 15, 2014 at 10:00 PM, Adam Lackorzynski <
>> adam at os.inf.tu-dresden.de> wrote:
>>
>>> Hi,
>>>
>>> On Fri Nov 14, 2014 at 15:33:50 +0100, Mahdi Aichouch wrote:
>>> > I have a Freescale i.MX 6 ARM Cortex A9 Sabre SD board.
>>> > I would like to test the Hello World example using the generated
>>> > bootstrap.elf binary.
>>> > I compiled the fiasco kernel and the l4re framework for the i.MX 6 ARM
>>> > Cortex-A9 using the menu configuration in both cases.
>>> >
>>> > Instead of using an SD card to run the binary on the board, I would
>>> like to
>>> > flash the RAM with the binary using the DSTREAM JTAG device and the ARM
>>> > DS-5 IDE.
>>> >
>>> > I connected the board to my host using the mini-usb to serial cable,
>>> and I
>>> > used minicom tool as a serial terminal.
>>> >
>>> > I tried to run the binary using the DS-5 debugger while the board is
>>> > connected through JTAG, but I didn't see any debug message on the
>>> serial
>>> > terminal.
>>>
>>> Is it working when you boot via SD card or tftp?
>>>
>>> > The source code I am using is from the "l4re-snapshot-2014092821".
>>> >
>>> > My questions:
>>> >
>>> > 1) Does anyone tried to run and debug fiasco kernel + l4re on a board
>>> using
>>> > a JTAG device?
>>> > What are the steps that I am missing?
>>>
>>> I've done it, however not with this particular board.
>>> I don't really think there could be anything missing. The info on the
>>> screenshot looks ok, the disassembly shows what it has to show.
>>> Did it stop itself? Or does it run and just no output? When you let it
>>> run a few seconds and stop it again, at which PC is it?
>>> Maybe just the wrong UART? UART2 is the default, UART1 would be
>>> PLATFORM_UART_NR=1
>>>
>>> > 2) The debug tool print a message saying that "WARNING(IMG53):
>>> > bootstrap.elf has no source level debug information", what are the
>>> options
>>> > required to include these information compiling the fiasco kernel +
>>> l4re?
>>>
>>> Add BOOTSTRAP_NO_STRIP=y when building the image (you can also put it
>>> into your l4/conf/Makeconf.boot).
>>>
>>>
>>>
>>>
>>> Adam
>>> --
>>> Adam adam at os.inf.tu-dresden.de
>>> Lackorzynski http://os.inf.tu-dresden.de/~adam/
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20141120/f7deb3f9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imx_uart.c
Type: text/x-csrc
Size: 7998 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20141120/f7deb3f9/attachment-0003.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uart1_iomux_config.c
Type: text/x-csrc
Size: 10111 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20141120/f7deb3f9/attachment-0004.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uart_iomux_config.c
Type: text/x-csrc
Size: 1873 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20141120/f7deb3f9/attachment-0005.c>
More information about the l4-hackers
mailing list