headers
P. Levine | 9 Feb 06:48
Picon

Re: emerge --root : users not created

2009/12/14  Sven Rebhan <odinshorse@...>

*



> The correct way to solve this would be to add an option to
> useradd, allowing to specify a passwd file other than /etc/passwd.
> Afterwards patch the corresponding eclass to use this option. Patches
> are welcome. ;-)
>
>> Quite annoying - workarounds would be highly appreciated!


I submitted a fix for this at http://bugs.gentoo.org/show_bug.cgi?id=302570

Shadow doesn't seem to allow a purely static build.
Busybox is purely self-contained, so I used that.
It works on my end but it could use some testing.

Any feedback is appreciated.
Permalink | Reply | 0 comments |
headers
David Relson | 9 Feb 01:26
Favicon

disk image question

Hello,

I'm working with PC/104 cards with vortex86 and vortex86sx SOCs.  So far
the project has been using large 1GB DOM (disk-on-modules), but it's
now time to prepare for installation to 32MB and 128MB DOMs.

I've not done this kind of thing before, so have invented a scheme.
Hopefully it makes sense, but I thought I'd ask those of you with more
experience...

My current plan is to create 32MB and 128MB images (using a USB
flash drive) and put them on a bootable USB drive which will
allow the installlation procedure to use dd to program the embedded
DOMs. I'm planning on partitioning the DOM as 1/8 DOS (formatted msdos)
and 7/8 linux (formatted ext2), populating the partitions from my
workstation, using dd to preserve the images, then putting the two
images on the install flash drive.

Does this make sense?  Is there a better way to create the 2
differently sized install images and package them for installation?

Thanks!

David
Permalink | Reply | 0 comments |
headers
Francisco Ares | 7 Feb 15:17
Picon

[OT] framebuffer hardware specs - where?

Hi

I'm planning on building a FPGA based gadget using it's Microblaze IP. And I
would like to have a video output.

There comes the question: how do I implement a video output module so that
it fits in the linux framebuffer specs, or how do I write a driver to be
compatible of the existing framework?

Thank for any tip
Francisco
Permalink | Reply | 1 comment |
headers
Angelo Arrifano | 9 Feb 01:03
Picon
Favicon

Re: [OT] framebuffer hardware specs - where?

On Dom, 2010-02-07 at 12:17 -0200, Francisco Ares wrote:
> Hi
> 
> I'm planning on building a FPGA based gadget using it's Microblaze IP.
> And I would like to have a video output.
> 
> There comes the question: how do I implement a video output module so
> that it fits in the linux framebuffer specs, or how do I write a
> driver to be compatible of the existing framework?

See /usr/src/linux/drivers/video/* you have plenty of examples there.
Also look at /usr/src/linux/Documentation/fb/*

TLDP might also have useful documentation.

Regards,
> 
> Thank for any tip
> Francisco
> 
> -- 
> "If you have an apple and I have an apple and we exchange apples then
> you and I will still each have one apple. But if you have an idea and
> I have one idea and we exchange these ideas, then each of us will have
> two ideas." - George Bernard Shaw
Permalink | Reply | 0 comments |
headers
wireless | 4 Feb 14:56
Picon

OT: ? Embedded Patent Fraud

Hello,

It's not often that I would interject a subject like this
into a Gentoo discuss. However, from my reading of this
patent, the awardee may be able to cause significant grief
to anyone that use a uP, FPGA, or such with at CPU/GPU.

http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F7607005

Hopefully, some of you will read about this patent and
conclude that this no way affects any embedded linux system
or any form of programmable embedded linux device,
particularly any where reconfigurable or programmable
hardware is contained therein....

This patent looks like the poster child for embedded system,
that should not have been issued. Hopefully Europeans are
not this stupid to allow this sort of patent-garbage to even
be filled, let alone enforced.

I see little in the way of original thought or work as every
claim made by the filers has existed before, from my
experiences. The "moron" that reviewed this:
"Primary Examiner: Connolly; Mark "
must be clueless about embedded systems, imho.

your thoughts?

James
Permalink | Reply | 3 comments |
headers
Peter Stuge | 9 Feb 09:41
Picon

Re: OT: ? Embedded Patent Fraud

wireless wrote:
> This patent looks like the poster child for embedded system,
> that should not have been issued.

Pretty much, it looks like. It covers any CPU+FPGA system where the
FPGA is used for any of signal I/O, co-processing, HID, graphics,
signal processing, communications and battery charging. :)

I'm sorry, but I find it too hilarious that "a system with an FPGA"
can be patented. It's a little bit like patenting the patent system..
;)

> Hopefully Europeans are not this stupid to allow this sort of
> patent-garbage to even be filled, let alone enforced.

I wouldn't bet on it..

//Peter
Permalink | Reply | 2 comments |
headers
wireless | 9 Feb 12:21
Picon

Re: OT: ? Embedded Patent Fraud

Peter Stuge wrote:
> wireless wrote:
>> This patent looks like the poster child for embedded system,
>> that should not have been issued.
> 
> Pretty much, it looks like. It covers any CPU+FPGA system where the
> FPGA is used for any of signal I/O, co-processing, HID, graphics,
> signal processing, communications and battery charging. :)
> 
> I'm sorry, but I find it too hilarious that "a system with an FPGA"
> can be patented. It's a little bit like patenting the patent system..
> ;)

Wide open was my take too. Way to broad, so I sure it will
get challenged as soon as somebody tries to enforce it. The
real danger is if somebody like Microsoft buys the patent,
then there is trouble against small companies who innovate.

>> Hopefully Europeans are not this stupid to allow this sort of
>> patent-garbage to even be filled, let alone enforced.
> 
> I wouldn't bet on it..
> 
> 
> //Peter

I find this most disturbing. America is owned by lawyers and
crooks, in the disguise of corporation. Europe was the last
bastion of anti-imperialism........?

No wonder most startups build their products in S. America
or Asia and just import them to the US....... and
politicians are looking for jobs?

Fix the stupid patent system....

/end/rant

James
Permalink | Reply | 0 comments |
headers
Martin Guy | 9 Feb 12:31
Picon
Gravatar

Re: OT: ? Embedded Patent Fraud

*



On 2/9/10, Peter Stuge <peter@...> wrote:
> wireless wrote:
>  > This patent looks like the poster child for embedded system,
>  > that should not have been issued.
> Pretty much, it looks like. It covers any CPU+FPGA system where the
>  FPGA is used for any of signal I/O, co-processing, HID, graphics,
>  signal processing, communications and battery charging. :)


It should be unenforceable due to prior art (and should not have been
granted for the same reason). Of course, the idiots in question might
still try to waste your time. Intellectual property? Intellectual
theft!

   M
Permalink | Reply | 0 comments |
headers
David Relson | 14 Jan 00:52
Favicon

serial port handling question

G'day,

I'm porting some old DOS code to Linux for a medical device that is
being upgraded.  Among other goodies, it has a sensor that sends data at
115KB to an onboard NS16550A (or equivalent).  

The sensor is controlled (in part) by setting RTS on and off. I looked
high and low (pun intended) for an ioctl or similar call that would
allow this level of control and couldn't find anything. I finally ended
up using the ollowing lines of code: 

 outb(inportb(MCR) |  0x02, MCR);  //DTR,RTS=ON
 outb(inportb(MCR) & ~0x02, MCR);  //DTR=ON,RTS=OFF

Directly tweaking the I/O port runs against the grain, but it's the
only thing I've found that works.

Is there a better way to control the chip?

Regards,

David
Permalink | Reply | 12 comments |
headers
Peter Stuge | 14 Jan 03:55
Picon

Re: serial port handling question

David Relson wrote:
> I'm porting some old DOS code to Linux for a medical device that is
> being upgraded.

Interesting, this business.

> The sensor is controlled (in part) by setting RTS on and off.

What is controlled, exactly? What is RTS being used for? If it is
indeed flow control then you are lucky and can simply enable hardware
flow control for the serial port, and Linux will then take care of
everything for you.

If not flow control and some other signalling, you have to write a
line discipline driver. I have done both this and serial drivers
(also related to DOS era equipment) and documentation is not the
greatest. Let me know if you would like some help.

> I looked high and low (pun intended) for an ioctl or similar call
> that would allow this level of control and couldn't find anything.

The best thing out there is tcsetattr() and friends.

By switching between baud rate 0 and something else you can reliably
and easily control both RTS and DTR, and nothing but RTS and DTR, but
always both at the same time.

Line disciplines can call the tty_throttle() and tty_unthrottle()
functions in the serial driver, which will then control RTS
accordingly, but the default TTY line discipline does not expose any
API that will result in throttle function calls.

>  outb(inportb(MCR) |  0x02, MCR);  //DTR,RTS=ON
>  outb(inportb(MCR) & ~0x02, MCR);  //DTR=ON,RTS=OFF
> 
> Directly tweaking the I/O port runs against the grain, but it's the
> only thing I've found that works.

Not only against the grain, it can mess up internal state in the
kernel serial layer and worst case lead to a kernel BUG_ON (kernel
hangs) or best case serial port hang (unhang e.g. by closing all file
handles for the port and opening again). It is not at all nice to
change these signals behind Linux' back.

//Peter
Permalink | Reply | 3 comments |
headers
David Relson | 14 Jan 05:30
Favicon

Re: serial port handling question

On Thu, 14 Jan 2010 03:55:07 +0100
Peter Stuge wrote:

> David Relson wrote:
> > I'm porting some old DOS code to Linux for a medical device that is
> > being upgraded.
> 
> Interesting, this business.

And it feels so good when one stops banging one's head against the wall.

> > The sensor is controlled (in part) by setting RTS on and off.
> 
> What is controlled, exactly? What is RTS being used for? If it is
> indeed flow control then you are lucky and can simply enable hardware
> flow control for the serial port, and Linux will then take care of
> everything for you.

Not sure (insufficient documentation).  The functions setting and
clearing RTS have names like RS485_RTS_Receiver_Enable and
RS485_RTS_Transmitter_Enable.  My query as to the meaning/purpose of
the routines is awaiting an answer..

> If not flow control and some other signalling, you have to write a
> line discipline driver. I have done both this and serial drivers
> (also related to DOS era equipment) and documentation is not the
> greatest. Let me know if you would like some help.
> 
> 
> > I looked high and low (pun intended) for an ioctl or similar call
> > that would allow this level of control and couldn't find anything.
> 
> The best thing out there is tcsetattr() and friends.
> 
> By switching between baud rate 0 and something else you can reliably
> and easily control both RTS and DTR, and nothing but RTS and DTR, but
> always both at the same time.

The RS485 routines mentionned above only change RTS.  DTR remains on.
Attempts to change both (using CRTSCTS and tcsetattr()) didn't work.

> Line disciplines can call the tty_throttle() and tty_unthrottle()
> functions in the serial driver, which will then control RTS
> accordingly, but the default TTY line discipline does not expose any
> API that will result in throttle function calls.
>  
> >  outb(inportb(MCR) |  0x02, MCR);  //DTR,RTS=ON
> >  outb(inportb(MCR) & ~0x02, MCR);  //DTR=ON,RTS=OFF
> > 
> > Directly tweaking the I/O port runs against the grain, but it's the
> > only thing I've found that works.
> 
> Not only against the grain, it can mess up internal state in the
> kernel serial layer and worst case lead to a kernel BUG_ON (kernel
> hangs) or best case serial port hang (unhang e.g. by closing all file
> handles for the port and opening again). It is not at all nice to
> change these signals behind Linux' back.

I'm well aware of the hackish nature of my "solution".  It'll be
interesting to see what unwanted side effects show up to bite me.

David
Permalink | Reply | 2 comments |

Gmane