Re: Instructions for Networking with Xilinx BSP and Qemu

[Sebastian Huber]

Hello Joel,

On 17/06/16 17:40, Joel Sherrill wrote:

Hi

Are there instructions for doing this?


https://git.rtems.org/rtems-libbsd/tree/libbsd.txt#n342

I do nearly all the libbsd development with the |xilinx_zynq_a9_qemu BSP.

|

Or even the realview BSP?


It would need some Qemu patches, since the libbsd doesn't supports its 
default network interfaces.




Thanks.

--joel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Chris Johns]

On 20/06/2016 10:34, Pavel Pisa wrote:

Hello Chris,

On Monday 20 of June 2016 01:58:09 Chris Johns wrote:

On 20/06/2016 09:08, Joel Sherrill wrote:

Does this append to the boot arguments?


Yes.


If so, shouldn't it be /dev/com1? Or did you fix that Chris to work both
ways on the master?


Yes. I noticed this after I sent the email. The doco in the wiki is
correct ...

https://devel.rtems.org/wiki/Developer/Simulators/QEMU#BootinganRTEMSexecut
abledirectlywithqemu


I have not looked into code but I have feeling that

   --console=com1


I do not think it actually works so maybe a BSPTOPS default is working.



worked for me. Is there support for both or only

   --console=/dev/com1 is p

is guaranteed now?



The support removed pre-pending '/dev' to the device names so now the 
command line option and the '/dev' directory match. This also means the 
command line and the entries in the console device tables match. I do 
not expect any further changes.


I made the change to clean up the code when sorting out the legacy and 
PCI uart support when used with the GDB stub support. The gdb stub 
previously did not support the PCI UARTS. You now have --gdb=/dev/com2 
or --gdb=/dev/pcicom1 plus --gdb-break for running on real-hardware (I 
know qemu has gdb support built in). We may also have other devices in 
the future, for example the UEFI API has console and device interfaces 
which I see as being useful and may become available when support is 
added. On the Minnow Max board you can direct the UEFI console to a UART 
making the board headless and I see RTEMS's UEFI support having it's 
console use the UEFI console. This is important for target testing.



As for my usual options

   -net nic,vlan=0,model=e1000 -net user,vlan=0

I have feeling that they are incorrect for RTEMS because
I have found e1000 PCI support only in some PowerPC RTME BSP.


You may be correct.


So the line should be changed to something which
is supported by current RTEMS.


OK. If something knows a command that works please let me know.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Pavel Pisa]

Hello Chris,

On Monday 20 of June 2016 01:58:09 Chris Johns wrote:
> On 20/06/2016 09:08, Joel Sherrill wrote:
> > Does this append to the boot arguments?
>
> Yes.
>
> > If so, shouldn't it be /dev/com1? Or did you fix that Chris to work both
> > ways on the master?
>
> Yes. I noticed this after I sent the email. The doco in the wiki is
> correct ...
>
> https://devel.rtems.org/wiki/Developer/Simulators/QEMU#BootinganRTEMSexecut
>abledirectlywithqemu

I have not looked into code but I have feeling that

  --console=com1

worked for me. Is there support for both or only

  --console=/dev/com1 is p

is guaranteed now?

As for my usual options

  -net nic,vlan=0,model=e1000 -net user,vlan=0

I have feeling that they are incorrect for RTEMS because
I have found e1000 PCI support only in some PowerPC RTME BSP.

So the line should be changed to something which
is supported by current RTEMS.

Best wishes,

   Pavel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Chris Johns]

On 20/06/2016 09:08, Joel Sherrill wrote:


Does this append to the boot arguments?



Yes.


If so, shouldn't it be /dev/com1? Or did you fix that Chris to work both
ways on the master?


Yes. I noticed this after I sent the email. The doco in the wiki is 
correct ...


https://devel.rtems.org/wiki/Developer/Simulators/QEMU#BootinganRTEMSexecutabledirectlywithqemu

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Joel Sherrill]

On Jun 19, 2016 4:44 PM, "Chris Johns"  wrote:
>
> On 20/06/2016 00:06, Pavel Pisa wrote:
>>
>>
>> I have rebuild RTEMS from actual head (I hope make rebuild right files
>> according to the dependencies) and run it by QEMU
>>
>>QEMU emulator version 2.6.0, Copyright (c) 2003-2008 Fabrice Bellard
>>
>>   qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \
>>-vga cirrus \
>>-net nic,vlan=0,model=e1000 -net user,vlan=0 \
>>-append "--console=com1" \
>
>   ^^^
> This is the bit that is missing from the documentation.

Does this append to the boot arguments?

If so, shouldn't it be /dev/com1? Or did you fix that Chris to work both
ways on the master?

>
>>-serial stdio \
>>
>> and output appears right on the console.
>> I have tested without --console=com1 argument and output
>> goes to QEMU emulated VESA screen.
>>
>> So the run of RTEMS through -kernel option seems to work
>> (at least on my computer).
>
>
> Excellent and thanks for the report. I will edit the wiki.
>
> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Chris Johns]

On 20/06/2016 00:06, Pavel Pisa wrote:


I have rebuild RTEMS from actual head (I hope make rebuild right files
according to the dependencies) and run it by QEMU

   QEMU emulator version 2.6.0, Copyright (c) 2003-2008 Fabrice Bellard

  qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \
   -vga cirrus \
   -net nic,vlan=0,model=e1000 -net user,vlan=0 \
   -append "--console=com1" \

  ^^^
This is the bit that is missing from the documentation.


   -serial stdio \

and output appears right on the console.
I have tested without --console=com1 argument and output
goes to QEMU emulated VESA screen.

So the run of RTEMS through -kernel option seems to work
(at least on my computer).


Excellent and thanks for the report. I will edit the wiki.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Raspberry pi not working with latest compiler and rtems-git

[Pavel Pisa]

Hello Alan,

On Friday 17 of June 2016 19:04:58 Alan Cudmore wrote:
> I refreshed my RSB build and pulled the latest rtems git changes. ( as of
> today ) and the Raspberry Pi BSPs are not working.
> I built the sparc/sis RSB and BSP and my tests run fine on that.
> I will troubleshoot in the next day or so and try to find the error.
>
> What is the best ARM simulator BSP to try?
> I have qemu-system-arm 2.5.0 installed, and I can run some bare metal
> examples using the -M versatilepb sim.
>
> Thanks,
> Alan

I have successfully build and run actual RTEMS master on RPi1 B+
but with U-boot load. Last commit

commit 16706b723f788cd26a3d5cb475f5468a68dcf263
Author: Sebastian Huber 
Date:   Fri Jun 17 08:06:56 2016 +0200

bsps: Fix printk() format warning

I have pushed set of my debug prints hacks to my personal
rtems-rpi-devel branch on GitHub

  https://github.com/ppisa/rtems/tree/rtems-rpi-devel

Commit

   "HACKS to locate Raspberry Pi boot problems."


Try to build that version of RTEMS and run it on RPi1 and RPi2
where you experience problems.

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: testing pc386 with qemu?

[Pavel Pisa]

Hello,

On Thursday 09 of June 2016 02:54:17 Chris Johns wrote:
> On 09/06/2016 09:57, Gedare Bloom wrote:
> > On Wed, Jun 8, 2016 at 6:58 PM, Chris Johns  wrote:
> >> On 09/06/2016 06:31, Gedare Bloom wrote:
> >>> I'm not seeing output with the current pc386 BSP using qemu.
> >>
> >> Is this the RSB qemu or another one?
> >
> > RSB built, but awhile back.
> > QEMU emulator version 2.3.50, Copyright (c) 2003-2008 Fabrice Bellard
>
> Thanks.
>
> >>> I suspect
> >>> this is due to some combination of the changes made in the BSP or the
> >>> printk support. Any advice?
> >>
> >> I will take a look.
> >>
> >>> I have tried to configure with and without USE_COM1_AS_CONSOLE=1, and
> >>> run qemu with and without redirecting serial to stdio.
> >>
> >> What boot flags did you supply?
> >
> > I was using the qemu -kernel method to load the executable. I did not
> > try with a boot disk.
>
> I have never tried this with the i386. I suppose the multiboot and
> related paths are fine with this, they should be.

I have rebuild RTEMS from actual head (I hope make rebuild right files
according to the dependencies) and run it by QEMU

  QEMU emulator version 2.6.0, Copyright (c) 2003-2008 Fabrice Bellard


 qemu-system-x86_64 -enable-kvm -kernel $APP_BINARY \
  -vga cirrus \
  -net nic,vlan=0,model=e1000 -net user,vlan=0 \
  -append "--console=com1" \
  -serial stdio \

and output appears right on the console.
I have tested without --console=com1 argument and output
goes to QEMU emulated VESA screen.

So the run of RTEMS through -kernel option seems to work
(at least on my computer).

Best wishes,

  Pavel

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] arm/raspberrypi: Ensure that buffers used for VC mail box

[Pavel Pisa]

From: Pavel Pisa 

---
 c/src/lib/libbsp/arm/raspberrypi/misc/vc.c | 42 ++
 c/src/lib/libbsp/arm/raspberrypi/misc/vc_defines.h | 21 +++
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c 
b/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
index 54935af..91f9174 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "vc_defines.h"
 
 #if (RPI_L2_CACHE_ENABLE == 1)
@@ -45,6 +46,26 @@ bcm2835_mailbox_send_read_buffer(void *buf)
   return 0;
 }
 
+/*
+ * When cache is enabled then content of buffer exchanged
+ * with VideoCore has to be propagated through ARM11/Cortex-A7
+ * caches
+ */
+static inline void
+bcm2835_mailbox_buffer_flush_and_invalidate(void *buf, size_t size)
+{
+  uint32_t sctlr_val;
+
+  sctlr_val = arm_cp15_get_control();
+
+  arm_cp15_drain_write_buffer();
+  if (sctlr_val & (ARM_CP15_CTRL_C | ARM_CP15_CTRL_M)) {
+arm_cp15_drain_write_buffer();
+rtems_cache_flush_multiple_data_lines(buf, size);
+rtems_cache_invalidate_multiple_data_lines(buf, size);
+  }
+}
+
 #define BCM2835_MBOX_VAL_LENGTH_MASK(_val_len) \
   (_val_len&(~BCM2835_MBOX_TAG_VAL_LEN_RESPONSE))
 
@@ -55,10 +76,11 @@ 
bcm2835_mailbox_get_display_size(bcm2835_get_display_size_entries *_entries)
 bcm2835_mbox_buf_hdr hdr;
 bcm2835_mbox_tag_display_size get_display_size;
 uint32_t end_tag;
-  }buffer __attribute__((aligned (16)));
+  }buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG_NO_REQ(_display_size,
 BCM2835_MAILBOX_TAG_GET_DISPLAY_SIZE);
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   if (bcm2835_mailbox_send_read_buffer())
 return -1;
   _entries->width = buffer.get_display_size.body.resp.width;
@@ -83,7 +105,7 @@ 
bcm2835_mailbox_init_frame_buffer(bcm2835_init_frame_buffer_entries* _entries)
 bcm2835_mbox_tag_allocate_buffer allocate_buffer;
 bcm2835_mbox_tag_get_pitch get_pitch;
 uint32_t end_tag;
-  } buffer __attribute__((aligned (16)));
+  } buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG(_display_size,
 BCM2835_MAILBOX_TAG_SET_DISPLAY_SIZE);
@@ -117,6 +139,7 @@ 
bcm2835_mailbox_init_frame_buffer(bcm2835_init_frame_buffer_entries* _entries)
   buffer.allocate_buffer.body.req.align = 0x100;
   BCM2835_MBOX_INIT_TAG_NO_REQ(_pitch,
 BCM2835_MAILBOX_TAG_GET_PITCH);
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   if (bcm2835_mailbox_send_read_buffer())
 return -1;
   _entries->xres = buffer.set_display_size.body.resp.width;
@@ -151,10 +174,11 @@ bcm2835_mailbox_get_pitch(bcm2835_get_pitch_entries* 
_entries)
 bcm2835_mbox_buf_hdr hdr;
 bcm2835_mbox_tag_get_pitch get_pitch;
 uint32_t end_tag;
-  }buffer __attribute__((aligned (16)));
+  }buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG_NO_REQ(_pitch,
 BCM2835_MAILBOX_TAG_GET_PITCH);
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   if (bcm2835_mailbox_send_read_buffer())
 return -1;
   _entries->pitch = buffer.get_pitch.body.resp.pitch;
@@ -171,10 +195,11 @@ bcm2835_mailbox_get_cmdline(bcm2835_get_cmdline_entries* 
_entries)
 bcm2835_mbox_buf_hdr hdr;
 bcm2835_mbox_tag_get_cmd_line get_cmd_line;
 uint32_t end_tag;
-  }buffer __attribute__((aligned (16)));
+  }buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG_NO_REQ(_cmd_line,
 BCM2835_MAILBOX_TAG_GET_CMD_LINE);
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   if (bcm2835_mailbox_send_read_buffer())
 return -1;
   for (i = 0;
@@ -196,12 +221,13 @@ 
bcm2835_mailbox_set_power_state(bcm2835_set_power_state_entries *_entries)
 bcm2835_mbox_buf_hdr hdr;
 bcm2835_mbox_tag_power_state set_power_state;
 uint32_t end_tag;
-  }buffer __attribute__((aligned (16)));
+  }buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG(_power_state,
 BCM2835_MAILBOX_TAG_SET_POWER_STATE);
   buffer.set_power_state.body.req.dev_id = _entries->dev_id;
   buffer.set_power_state.body.req.state = _entries->state;
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   if (bcm2835_mailbox_send_read_buffer())
 return -1;
   _entries->dev_id = buffer.set_power_state.body.resp.dev_id;
@@ -218,10 +244,11 @@ 
bcm2835_mailbox_get_arm_memory(bcm2835_get_arm_memory_entries* _entries)
 bcm2835_mbox_buf_hdr hdr;
 bcm2835_mbox_tag_get_arm_memory get_arm_memory;
 uint32_t end_tag;
-  }buffer __attribute__((aligned (16)));
+  }buffer BCM2835_MBOX_BUF_ALIGN_ATTRIBUTE;
   BCM2835_MBOX_INIT_BUF();
   BCM2835_MBOX_INIT_TAG_NO_REQ(_arm_memory,
 BCM2835_MAILBOX_TAG_GET_ARM_MEMORY);
+  bcm2835_mailbox_buffer_flush_and_invalidate(, sizeof());
   

Re: Error while using Mailbox in RPI

[Pavel Pisa]

Hello Mudit Jain ,

On Sunday 19 of June 2016 10:51:37 Mudit Jain wrote:
> Hi all,
>
> I am getting an error in setting the power using the mailbox.
>
> This is how I am calling the function in the bcm_sdhci_attach as follows.
>
> ---
>-
> bcm2835_set_power_state_entries* power_state_sd;
> power_state_sd->dev_id=bcm2835_mailbox_power_udid_sd_card;
> power_state_sd->state=BCM2835_MAILBOX_SET_POWER_STATE_REQ_ON ;
> err = bcm2835_mailbox_set_power_state(power_state_sd);
> if (err != 0) {
> device_printf(dev, "Unable to enable the power\n");
> return (err);
> }
> ---
>---
>
> RTEMS on RPi gives a err = -2, indicating the
> *bcm2835_mailbox_buffer_suceeded *fails
>
> I have been stuck here from quite some time.Can someone help me with this ?

I see serious problem in your code.

You declare power_state_sd as pointer but do not fill it by location
(malloc or reference) so the following lines use random location in memory.

But it is possible that there could be some other problem so I analyzed
U-boot and Linux kernel how they communicate with VideoCore firmware
when they need to control power.

Linux kernel implements this part in.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/soc/bcm2835/raspberrypi-firmware.h

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/bcm/raspberrypi-power.c

Generally RTEMS code looks similar, the same channel
is used for property set. There is difference that
newer RPi firmware versions add support for domains functions.

#define BCM2835_MAILBOX_TAG_GET_DOMAIN_STATE0x00030030
#define BCM2835_MAILBOX_TAG_SET_DOMAIN_STATE0x00038030

But even in the case of newer firmware old

#define BCM2835_MAILBOX_TAG_SET_POWER_STATE  0x00028001

is used at least for USB, so I expect that old power
state control should work with new firmware.

On the other hand, Linux seems to not count SD card power
domain ID 0 into account. Linux IDs are defined as HW IDs - 1.
I would expect that it is already set by firware because
it uses SD card to boot the system.

But anyway, I have updated VideoCore access code to be sure that
data are correctly propagated to main memory after ARM caches are
enabled. Original Yang Qiao code does not care about that
(it is not required during startup before MMU is enabled)
and there could be difference that RPi2 Cortex-A7 data cache line
length is 64 bytes instead of 32 for RPi1 so without explicit
cache management there could be more problems on RPi2.

I am sending my patch as followup. If there is no objection,
I push it to RTEMS mainline. Patch is applied to my
personal RTEMS repo as well

https://github.com/ppisa/rtems/tree/rtems-rpi-devel

I have tested next code after VC cache flush update
with current RTEMS mainline and I get correct result

  int err;

  bcm2835_set_power_state_entries power_state_sd;
  power_state_sd.dev_id=bcm2835_mailbox_power_udid_sd_card;
  power_state_sd.state=BCM2835_MAILBOX_SET_POWER_STATE_REQ_ON ;
  err = bcm2835_mailbox_set_power_state(_state_sd);
  printk("Enable the power returns %d\n", err);

I have not tested before cache clarification because I have
noticed problem with pointer later.

All tested on RPi1 with U-boot based load.
I have tested with both serial and graphics console.
Testing on RPi2 would be appreciated.

Best wishes,

 Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel