On Mon, Apr 1, 2013 at 9:01 PM, Lennart Sorensen
wrote:
> On Mon, Apr 01, 2013 at 07:20:44PM +0100, luke.leighton wrote:
>> already on the CPU Card.
>
> Oh yeah. :)
>
>> ... unless converted. i'm dithering as to whether to add a TFP410
>> [1] onto the mini-engineering board, to convert RGB/TTL
On Mon, Apr 01, 2013 at 10:14:52PM +0100, Tim Small wrote:
> When necessary (e.g. long cable runs, or dot-clock limited DVI outputs),
> I've always been able to get the dotclock down far enough by reducing
> the refresh rate and/or using reduced blanking. All my 1920x1200
> monitors have been happ
On 01/04/13 21:01, Lennart Sorensen wrote:
> Many HDMI outputs are limited to 1920x1080 after all (with a few capable of
> 1920x1200)
When necessary (e.g. long cable runs, or dot-clock limited DVI outputs),
I've always been able to get the dotclock down far enough by reducing
the refresh rate and
On Mon, Apr 01, 2013 at 07:20:44PM +0100, luke.leighton wrote:
> already on the CPU Card.
Oh yeah. :)
> ... unless converted. i'm dithering as to whether to add a TFP410
> [1] onto the mini-engineering board, to convert RGB/TTL into DVI (aka
> HDMI without the encryption and audio). that woul
On Mon, Apr 1, 2013 at 7:05 PM, Lennart Sorensen
wrote:
> I would just want something with an HDMI port.
already on the CPU Card.
> LCD has no interest at all.
... unless converted. i'm dithering as to whether to add a TFP410
[1] onto the mini-engineering board, to convert RGB/TTL into DVI
On Mon, Apr 01, 2013 at 05:35:22PM +0100, luke.leighton wrote:
> yes lennart - specially for you. just don't ask for RTS/CTS ok? :)
If it is a console port, then I won't. :)
> the "flying squirrel" should, all going well, be done first boards in
> about 2-3 weeks. a few parts to chase down fr
On Mon, Apr 1, 2013 at 5:15 PM, Lennart Sorensen
wrote:
> On Sun, Mar 31, 2013 at 12:07:34AM +, luke.leighton wrote:
>> ok lennart, RS232 added. even with some level-shifters to put it up
>> to proper voltages and protect the CPU at the same time, how's that
>> for service? :)
>
> A real 232
On Sun, Mar 31, 2013 at 12:07:34AM +, luke.leighton wrote:
> ok lennart, RS232 added. even with some level-shifters to put it up
> to proper voltages and protect the CPU at the same time, how's that
> for service? :)
A real 232 port? Yay!
> btw the reason for the sudden focus is because i
On Wed, Feb 27, 2013 at 3:50 PM, Lennart Sorensen
wrote:
> On Wed, Feb 27, 2013 at 12:51:13AM +, luke.leighton wrote:
>> http://rhombus-tech.net/freescale/iMX6/news/
> Well for a board to be interesting to me it has to have:
>
> SATA (which you have)
>
> Ethernet (which you have)
>
> serial
On Mon, Mar 4, 2013 at 4:36 PM, Thibaut Girka wrote:
> Last time I've checked, glamo's specs weren't public. Have I missed something?
> Any link?
There are two sets of public glamo specs:
The leaked ones, which came out while I was trying to get the official ones out:
ftp://ifctfvax.harhan.org/
Thibaut Girka writes:
Hi,
> On Sat, Mar 02, 2013 at 12:39:44PM +0800, Paul Wise wrote:
>> On Sat, Mar 2, 2013 at 5:57 AM, Lennart Sorensen wrote:
>>
>> > Hmm I thought it had died out. I remember in the past they had issues
>> > with some component not being open after all and causing problems
On Sat, Mar 02, 2013 at 12:39:44PM +0800, Paul Wise wrote:
> On Sat, Mar 2, 2013 at 5:57 AM, Lennart Sorensen wrote:
>
> > Hmm I thought it had died out. I remember in the past they had issues
> > with some component not being open after all and causing problems.
> > Maybe the new generation boar
On Sat, Mar 2, 2013 at 5:57 AM, Lennart Sorensen wrote:
> Hmm I thought it had died out. I remember in the past they had issues
> with some component not being open after all and causing problems.
> Maybe the new generation boards finally solved that.
gta04 is a completely new design done from s
On Fri, Mar 01, 2013 at 11:02:12AM +0100, Sander wrote:
> Not even an OpenMoko? http://wiki.openmoko.org/wiki/Main_Page
Hmm I thought it had died out. I remember in the past they had issues
with some component not being open after all and causing problems.
Maybe the new generation boards finally
On Fri, Mar 1, 2013 at 10:02 AM, Sander wrote:
> Lennart Sorensen wrote (ao):
>> I still just a plain old cell phone because there isn't a single smart
>> phone out there I am willing to own.
>
> Not even an OpenMoko? http://wiki.openmoko.org/wiki/Main_Page
maybe with a GTA04 board http://www.gt
Lennart Sorensen wrote (ao):
> I still just a plain old cell phone because there isn't a single smart
> phone out there I am willing to own.
Not even an OpenMoko? http://wiki.openmoko.org/wiki/Main_Page
Sander
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subje
On Thu, Feb 28, 2013 at 10:32 PM, Lennart Sorensen
wrote:
> On Thu, Feb 28, 2013 at 09:54:59PM +, Luke Kenneth Casson Leighton wrote:
>> they do have to be that different. just changing from a phillips
>> audio chip to an Akai 4641, it's like... utterly, utterly, 100%
>> different. there *a
On Thu, Feb 28, 2013 at 04:39:17PM -0600, Bill Gatliff wrote:
> I wouldn't say that they don't care.
>
> Rather, (a) Google and Android gave them some spectacularly bad models
> to follow, which they are because it's both the path of
> least-resistance and there aren't any ready-made better altern
On Thu, Feb 28, 2013 at 10:18:09PM +, Luke Kenneth Casson Leighton wrote:
> ... and how many powerpc fabless semiconductor companies are there?
> one? no, i can think of two: there's... ahh... freescale and there's
> IBM.
Sure, each of thich makes lots of chips, used on many boards with
diff
On Thu, Feb 28, 2013 at 4:32 PM, Lennart Sorensen
wrote:
>
> So I can see why makers of cell phones and tablets just don't care.
I wouldn't say that they don't care.
Rather, (a) Google and Android gave them some spectacularly bad models
to follow, which they are because it's both the path of
lea
On Thu, Feb 28, 2013 at 09:54:59PM +, Luke Kenneth Casson Leighton wrote:
> they do have to be that different. just changing from a phillips
> audio chip to an Akai 4641, it's like... utterly, utterly, 100%
> different. there *are* no standards. *everything* is different.
> even the philips
On Thu, Feb 28, 2013 at 8:01 PM, Lennart Sorensen
wrote:
> On Thu, Feb 28, 2013 at 01:48:42PM -0600, Bill Gatliff wrote:
>> There you go, trying to simplify the universe again. :-)
>
> I have to. :)
>
>> The phones in question are already designed. The unicorn has already
>> left the castle.
>
>
On Thu, Feb 28, 2013 at 7:41 PM, Lennart Sorensen
wrote:
> On Thu, Feb 28, 2013 at 01:33:14PM -0600, Bill Gatliff wrote:
>> Part of me regrets being as positive about DT as I was on LAK back
>> when the decision was made. But I had just come off of a PowerPC
>> project, and it worked pretty well
On Thu, Feb 28, 2013 at 7:38 PM, Lennart Sorensen
wrote:
> Of course it would seem that if the HTC phones are that different from
> each other while doing essentially the same things, then the hardware
> designers are designing them wrong. If they don't have to be different,
they do have to be
On Thu, Feb 28, 2013 at 01:55:48PM -0600, Bill Gatliff wrote:
> With all due respect, I'll just say this: it WILL go wrong. There is
> no point designing for a universe where things will not go wrong,
> because that universe simply does not exist.
>
> So if your plan does not include an accommoda
On Thu, Feb 28, 2013 at 01:48:42PM -0600, Bill Gatliff wrote:
> There you go, trying to simplify the universe again. :-)
I have to. :)
> The phones in question are already designed. The unicorn has already
> left the castle.
That doesn't mean we can't make sure future designs are done right.
On Thu, Feb 28, 2013 at 1:47 PM, Lennart Sorensen
wrote:
>
> I think the big difference is: Some of us design it to not go wrong.
> Some of us design it to make it easy to fix when something goes wrong.
> Different philosophy.
With all due respect, I'll just say this: it WILL go wrong. There is
On Thu, Feb 28, 2013 at 1:38 PM, Lennart Sorensen
wrote:
>
> Of course it would seem that if the HTC phones are that different from
> each other while doing essentially the same things, then the hardware
> designers are designing them wrong. If they don't have to be different,
> then they shouldn
On Thu, Feb 28, 2013 at 01:44:04PM -0600, Bill Gatliff wrote:
> This. As in, "what he said".
>
> And if the kernel+initramfs that it loads ends with an optional kexec
> and/or pivot_root, then the end user sees the overall experience as
> the platform "booting" their kernel from /boot in their fi
On Thu, Feb 28, 2013 at 1:32 PM, Luke Kenneth Casson Leighton
wrote:
>
> there is absolutely no reason why this application should not read a
> linux kernel + initrd and execute that instead of u-boot.
>
> the point i'm making is: the exact same technique could be deployed
> on any other hardwar
On Thu, Feb 28, 2013 at 01:33:14PM -0600, Bill Gatliff wrote:
> Part of me regrets being as positive about DT as I was on LAK back
> when the decision was made. But I had just come off of a PowerPC
> project, and it worked pretty well there and so I figured, "why not?".
Yes on powerpc devicetree
On Thu, Feb 28, 2013 at 07:24:28PM +, Luke Kenneth Casson Leighton wrote:
> On Thu, Feb 28, 2013 at 3:14 PM, Lennart Sorensen
> wrote:
>
> > There is no need to do things 500 different ways.
>
> lennart: you've fundamentally misinformed of the reality of the ARM
> hardware development world
On Thu, Feb 28, 2013 at 1:24 PM, Luke Kenneth Casson Leighton
wrote:
> On Thu, Feb 28, 2013 at 3:14 PM, Lennart Sorensen
> wrote:
>
> all that devicetree has done is move the problem, as well as add a
> runtime overhead to the execution of resource-critical devices.
>
> not very clever, that.
On Thu, Feb 28, 2013 at 7:19 PM, Bill Gatliff wrote:
> I'm not insisting that we have to bring all this stuff into Linux too.
> In fact, keeping some of these details hidden away inside a true
> bootloader is often a good idea because some low-level hardware
> details Linux just doesn't care abo
On Thu, Feb 28, 2013 at 3:14 PM, Lennart Sorensen
wrote:
> There is no need to do things 500 different ways.
lennart: you've fundamentally misinformed of the reality of the ARM
hardware development world. there are over 600 ARM licensees,
world-wide. automatically therefore you're above the
On Thu, Feb 28, 2013 at 1:03 PM, Luke Kenneth Casson Leighton
wrote:
>
> u-boot began as a mind-f**k merge of parts of uclibc (or equivalent),
> some userspace code and the linux kernel.
Awww. That's about the nicest thing I've heard anyone say about
u-boot in a long time. :-)
(I don't hate u
On Wed, Feb 27, 2013 at 11:25 PM, Bill Gatliff wrote:
> I think the origins of Linus' tantrum lie in a misunderstanding of the
> problems that ARM machines face
absolutely. and device tree merely moves the problem from the linux
kernel into... device tree. development of ARM products, due to
On Wed, Feb 27, 2013 at 11:05 PM, Sven Luther wrote:
>> so yes, it *can* be done... but not by numptys like me :)
>
> Alternatively, you can use a cpu module of some kind, and just do the
> easy things :)
... what.. like... like an EOMA-68 CPU module, like wot exaccerly i'm
designnin? :)
/pe
On Thu, Feb 28, 2013 at 6:51 PM, Lennart Sorensen
wrote:
> Using a kernel as essentially a bootloader to me is the opposite of
> your goal of making the lines of code less for your startup process.
> You have made it huge by using a linux kernel for what should be a simple
> boot loader problem.
On Thu, Feb 28, 2013 at 09:58:19AM -0600, Bill Gatliff wrote:
> At some point, that's essential. And since you can't change it, you
> want the LOC for that part to be as small as possible so that you
> reduce your exposure to defects. That means stripping out everything
> you can live without.
>
Lennart:
On Thu, Feb 28, 2013 at 9:14 AM, Lennart Sorensen
wrote:
>
> That bit would be tricky unless you had a part of your storage that was
> never written to that contained the code to boot when nothing else worked.
At some point, that's essential. And since you can't change it, you
want the
On Wed, Feb 27, 2013 at 05:25:16PM -0600, Bill Gatliff wrote:
> Yes. For example, the approach I described. :-)
>
> It isn't always about speed per se, but it is always about flexibility
> without fundamentally destabilizing the fundamentals of the system.
> Consider what it would take to modify
Lennart:
On Wed, Feb 27, 2013 at 2:00 PM, Lennart Sorensen
wrote:
> I really think that one way could work for all, including what you are
> doing.
Yes. For example, the approach I described. :-)
> No one says that firmware has to be as slow as many PCs seem to
> be able to make it. I rememb
On Wed, Feb 27, 2013 at 09:28:57PM +, Luke Kenneth Casson Leighton wrote:
> > I am no electric engineer, but i had a collegue who designed three arm
> > based boards with gEDA,
> > it is feasible.
>
> ... if you know what you are doing. i don't :) if you know exactly
> how to lay out diffe
n
>> > wrote:
>> >> http://rhombus-tech.net/freescale/iMX6/news/
>> >>
>> >> just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5
>> >> weeks away from a first prototype, so i wanted to ask people if there
>> >> is any
On Wed, Feb 27, 2013 at 01:32:18PM -0600, Bill Gatliff wrote:
> Lennart:
>
> On Wed, Feb 27, 2013 at 12:54 PM, Lennart Sorensen
> wrote:
> >
> > What you are doing is to me a terrible idea that I hate and have always
> > hated. I hated it on the netwinder in the late 90s, I hated it on the
> > a
/
> >>
> >> just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5
> >> weeks away from a first prototype, so i wanted to ask people if there
> >> is any feedback on RAM, NAND flash sizes or any other features that
> >> would make it useful
On Wed, Feb 27, 2013 at 5:10 PM, Bill Gatliff wrote:
> Luke:
>
> On Tue, Feb 26, 2013 at 6:51 PM, luke.leighton
> wrote:
>> http://rhombus-tech.net/freescale/iMX6/news/
>>
>> just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5
>> weeks away
Lennart:
On Wed, Feb 27, 2013 at 12:54 PM, Lennart Sorensen
wrote:
>
> What you are doing is to me a terrible idea that I hate and have always
> hated. I hated it on the netwinder in the late 90s, I hated it on the
> alpha in the form of MILO. They were always getting out of date and
> would be
On Wed, Feb 27, 2013 at 12:33:45PM -0600, Bill Gatliff wrote:
> Thing is, by the time you make a bootloader that intelligent, you are
> well on your way to reinventing the things Linux+initramfs can already
> do better---and that's even before you consider the device driver
> implications. That's
Lennart:
On Wed, Feb 27, 2013 at 12:29 PM, Lennart Sorensen
wrote:
>
> Well a standard firmware that initialized hardware and then calls a
> dedicated bootloader like grub that resides on sata is certainly very
> convinient and I wish arm boards would start doing something like that.
> I am not s
On Wed, Feb 27, 2013 at 11:24:06AM -0600, Bill Gatliff wrote:
> My vote would go in the exact opposite direction: the board has to
> boot from NAND (or eMMC), and then step over to SATA if present.
> Among other things, that makes it realistic that a new developer boots
> it by merely plugging in t
Guys:
On Wed, Feb 27, 2013 at 9:50 AM, Lennart Sorensen
wrote:
> On Wed, Feb 27, 2013 at 12:51:13AM +, luke.leighton wrote:
>> http://rhombus-tech.net/freescale/iMX6/news/
>
> I know the iMX53 boots from SD. Not sure what the iMX6 boots from.
> As long as I can use SATA for my filesystem and
Luke:
On Tue, Feb 26, 2013 at 6:51 PM, luke.leighton wrote:
> http://rhombus-tech.net/freescale/iMX6/news/
>
> just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5
> weeks away from a first prototype, so i wanted to ask people if there
> is any feedback on RAM, N
On Wed, Feb 27, 2013 at 12:51:13AM +, luke.leighton wrote:
> http://rhombus-tech.net/freescale/iMX6/news/
>
> just a heads-up that the iMX6 EOMA-68 CPU card is probably about 3-5
> weeks away from a first prototype, so i wanted to ask people if there
> is any feedback on RAM, N
55 matches
Mail list logo
