On Wed, Jun 17, 2020 at 09:58:03AM +0200, Tomek The Messenger wrote:
> Hi
> Thanks for reply.
> We make some proxy layer in linux /sys. So for example we have directories:
> /sys/resets
> /sys/routers
Really? That's a total abuse of sysfs, don't do that.
Seriously, that's not ok at all.
> etc.
Hi
Thanks for reply.
We make some proxy layer in linux /sys. So for example we have directories:
/sys/resets
/sys/routers
etc.
So if user wants to get to know what is the reset reason he doesn't use
devmem 0xfff, he just read the file in /sys/resets/..
If user wants to know some routing path
On Wed, 17 Jun 2020 12:39:08 +0200, Tomek The Messenger said:
> OK, I will ask if it is possible to share the code.
Well... if you planned to ship that code and that hardware outside
your organization, it's going to have to be GPLv2-compatible.
pgpYuxiJgxB3c.pgp
Description: PGP signature
Hello Greg and all,
Thus wrote Greg KH (g...@kroah.com):
> Please do not do that. There are valid kernel apis to grant access to
> registers easily,
the most simple case would be a "reset reason" register within the
chip's address space. A hand-crafted driver would ioremap the region and
Hello List,
I have asked this before on several mailing lists, but still no solution,
so I am trying again here.
I'm having trouble with using FIQ interrupts with the ARM timer on raspberypi
zero, (BCM2835 chip).
I created a kernel module, and the test version of this driver can be found in
On Wed, Jun 17, 2020 at 11:17:28AM +0200, Tomek The Messenger wrote:
> OK, so I had to wrongly described something because in my company this is
> popular approach to use /sys as some abstract layer to get access to
> registers.
Please do not do that. There are valid kernel apis to grant access
On Wed, 17 Jun 2020 14:48:36 +0200, Tomek The Messenger said:
> This is the case about which Martin write shortly. Then let's assume on
> another soc reset reason is not stored in chip's address space memory
> mapped to address 0xfff but it is accessed via some spi operation. On
> another soc
OK, so I had to wrongly described something because in my company this is
popular approach to use /sys as some abstract layer to get access to
registers.
So maybe in other words.
Let's say You have many socs. In one soc reset_reason can be gotten from
devmem 0xfff In other soc reset_reason can
Maybe some pseudo-code:
So in other to implement file /sys/resetreg/reason You have to write:
static ssize_t reason_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf)
{
u32 val;
val = some_readAPI_to_get_reboot_reason();
return scnprintf(buf, PAGE_SIZE, "%d\n", (u32)(val));
}
OK, I will ask if it is possible to share the code.
Thanks
BR
Tomek
On Wed, Jun 17, 2020 at 11:41 AM Greg KH wrote:
> On Wed, Jun 17, 2020 at 11:17:28AM +0200, Tomek The Messenger wrote:
> > OK, so I had to wrongly described something because in my company this is
> > popular approach to use
This is the case about which Martin write shortly. Then let's assume on
another soc reset reason is not stored in chip's address space memory
mapped to address 0xfff but it is accessed via some spi operation. On
another soc reset reason is still memory mapped but to different address
0xfff...
On Wed, Jun 17, 2020 at 08:24:14AM -0400, Valdis Klētnieks wrote:
> On Wed, 17 Jun 2020 12:39:08 +0200, Tomek The Messenger said:
>
> > OK, I will ask if it is possible to share the code.
>
> Well... if you planned to ship that code and that hardware outside
> your organization, it's going to
On Wed, 17 Jun 2020 16:26:49 +0200, Tomek The Messenger said:
> Yes separate drivers but the actions do by them is to create the same files
> in sysfs. So if somebody use intel, texas instrument or xilinx soc then in
> order to read reset reason or other stuff he will use sysfs. So this will
>
Hello,
On 6/17/20 2:48 PM, Tomek The Messenger wrote:
> This is the case about which Martin write shortly. Then let's assume on
> another soc reset reason is not stored in chip's address space memory
> mapped to address 0xfff but it is accessed via some spi operation. On
> another soc reset
On Wed, Jun 17, 2020 at 04:26:49PM +0200, Tomek The Messenger wrote:
> > If we have one unique sysfs interface then it is easier for
> > everyone: tester, developer to proceed with such device, testing or
> > debugging.
>
> >>No - not really. Because if you're mapping 3 or 4 SOC resets reasons
> If we have one unique sysfs interface then it is easier for
> everyone: tester, developer to proceed with such device, testing or
> debugging.
>>No - not really. Because if you're mapping 3 or 4 SOC resets reasons to
>>one thing, you then have to write code that says "If it's SoC 1, then
>>a
On Wed, Jun 17, 2020 at 02:35:28PM +0200, Martin Kaiser wrote:
> Hello Greg and all,
>
> Thus wrote Greg KH (g...@kroah.com):
>
> > Please do not do that. There are valid kernel apis to grant access to
> > registers easily,
>
> the most simple case would be a "reset reason" register within the
Hi Everyone,
I recently upgraded Ubuntu 18.04 x86_64 to the 5.4.0-37 kernel.
VirtualBox died, and I am trying to reinstall virtualbox-dkms. The
reinstall fails because the build fails. The log is below.
Is there anything I can do to solve the problem?
==
$ cat
18 matches
Mail list logo
