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_STATE 0x00030030
#define BCM2835_MAILBOX_TAG_SET_DOMAIN_STATE 0x00038030
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(&power_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
