[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Tomasz Figa]

Commit

4178bac ARM: call of_clk_init from default time_init handler

added implicit call to of_clk_init() from default time_init callback,
but it did not change platforms calling it from other callbacks, despite
of not having custom time_init callbacks. This caused double clock
initialization on such platforms, leading to boot failures. An example
of such platform is mach-s3c64xx.

This patch fixes boot failure on s3c64xx by dropping custom init_irq
callback, which had a call to of_clk_init() and moving system reset
initialization to init_machine callback. This allows us to have
clocks initialized properly without a need to have custom init_time or
init_irq callbacks.

Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
---
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

NOTE: This is a critical boot regression fix for mach-s3c64xx that
should be merged for next 3.13-rc release.

diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
index 7eb9a10..2fddf38 100644
--- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -8,8 +8,6 @@
  * published by the Free Software Foundation.
 */
 
-#include <linux/clk-provider.h>
-#include <linux/irqchip.h>
 #include <linux/of_platform.h>
 
 #include <asm/mach/arch.h>
@@ -48,15 +46,9 @@ static void __init s3c64xx_dt_map_io(void)
 		panic("SoC is not S3C64xx!");
 }
 
-static void __init s3c64xx_dt_init_irq(void)
-{
-	of_clk_init(NULL);
-	samsung_wdt_reset_of_init();
-	irqchip_init();
-};
-
 static void __init s3c64xx_dt_init_machine(void)
 {
+	samsung_wdt_reset_of_init();
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
@@ -79,7 +71,6 @@ DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
 	/* Maintainer: Tomasz Figa <tomasz.figa@gmail.com> */
 	.dt_compat	= s3c64xx_dt_compat,
 	.map_io		= s3c64xx_dt_map_io,
-	.init_irq	= s3c64xx_dt_init_irq,
 	.init_machine	= s3c64xx_dt_init_machine,
 	.restart        = s3c64xx_dt_restart,
 MACHINE_END
-- 
1.8.5.1

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Arnd Bergmann]

On Friday 13 December 2013, Tomasz Figa wrote:
> Commit
> 
> 4178bac ARM: call of_clk_init from default time_init handler
> 
> added implicit call to of_clk_init() from default time_init callback,
> but it did not change platforms calling it from other callbacks, despite
> of not having custom time_init callbacks. This caused double clock
> initialization on such platforms, leading to boot failures. An example
> of such platform is mach-s3c64xx.
> 
> This patch fixes boot failure on s3c64xx by dropping custom init_irq
> callback, which had a call to of_clk_init() and moving system reset
> initialization to init_machine callback. This allows us to have
> clocks initialized properly without a need to have custom init_time or
> init_irq callbacks.
> 
> Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>

I see of_clk_init(NULL) getting called on two other ARM platforms:

$ git grep -w of_clk_init arch/arm
arch/arm/kernel/time.c:         of_clk_init(NULL);
arch/arm/mach-keystone/pm_domain.c:     of_clk_init(NULL);
arch/arm/mach-mvebu/armada-370-xp.c:    of_clk_init(NULL);
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:        of_clk_init(NULL);

Are the other two platforms ok here?

I assume that mvebu is fine since Sebastian would have noticed breaking
that one and it has a custom init_time function, but keystone seems
broken in the same way as s3c64xx. Santosh, can you have a look?

	Arnd

> diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> index 7eb9a10..2fddf38 100644
> --- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
> +++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c

> @@ -48,15 +46,9 @@ static void __init s3c64xx_dt_map_io(void)
>  		panic("SoC is not S3C64xx!");
>  }
>  
> -static void __init s3c64xx_dt_init_irq(void)
> -{
> -	of_clk_init(NULL);
> -	samsung_wdt_reset_of_init();
> -	irqchip_init();
> -};
> -
>  static void __init s3c64xx_dt_init_machine(void)
>  {
> +	samsung_wdt_reset_of_init();
>  	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>  }
>  
> @@ -79,7 +71,6 @@ DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
>  	/* Maintainer: Tomasz Figa <tomasz.figa@gmail.com> */
>  	.dt_compat	= s3c64xx_dt_compat,
>  	.map_io		= s3c64xx_dt_map_io,
> -	.init_irq	= s3c64xx_dt_init_irq,
>  	.init_machine	= s3c64xx_dt_init_machine,
>  	.restart        = s3c64xx_dt_restart,
>  MACHINE_END

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Olof Johansson]

On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 13 December 2013, Tomasz Figa wrote:
>> Commit
>>
>> 4178bac ARM: call of_clk_init from default time_init handler
>>
>> added implicit call to of_clk_init() from default time_init callback,
>> but it did not change platforms calling it from other callbacks, despite
>> of not having custom time_init callbacks. This caused double clock
>> initialization on such platforms, leading to boot failures. An example
>> of such platform is mach-s3c64xx.
>>
>> This patch fixes boot failure on s3c64xx by dropping custom init_irq
>> callback, which had a call to of_clk_init() and moving system reset
>> initialization to init_machine callback. This allows us to have
>> clocks initialized properly without a need to have custom init_time or
>> init_irq callbacks.
>>
>> Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
>
> I see of_clk_init(NULL) getting called on two other ARM platforms:
>
> $ git grep -w of_clk_init arch/arm
> arch/arm/kernel/time.c:         of_clk_init(NULL);
> arch/arm/mach-keystone/pm_domain.c:     of_clk_init(NULL);
> arch/arm/mach-mvebu/armada-370-xp.c:    of_clk_init(NULL);
> arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:        of_clk_init(NULL);
>
> Are the other two platforms ok here?
>
> I assume that mvebu is fine since Sebastian would have noticed breaking
> that one and it has a custom init_time function, but keystone seems
> broken in the same way as s3c64xx. Santosh, can you have a look?

Yeah, and Free Electrons also sent two systems to Kevin so he has them
in his boot test setup, and they're still happy there. Keystone lacks
such coverage though, so Santosh will need to check.


-Olof

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Santosh Shilimkar]

Arnd, Olof,

On Saturday 14 December 2013 12:50 AM, Olof Johansson wrote:
> On Fri, Dec 13, 2013 at 7:00 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Friday 13 December 2013, Tomasz Figa wrote:
>>> Commit
>>>
>>> 4178bac ARM: call of_clk_init from default time_init handler
>>>
>>> added implicit call to of_clk_init() from default time_init callback,
>>> but it did not change platforms calling it from other callbacks, despite
>>> of not having custom time_init callbacks. This caused double clock
>>> initialization on such platforms, leading to boot failures. An example
>>> of such platform is mach-s3c64xx.
>>>
>>> This patch fixes boot failure on s3c64xx by dropping custom init_irq
>>> callback, which had a call to of_clk_init() and moving system reset
>>> initialization to init_machine callback. This allows us to have
>>> clocks initialized properly without a need to have custom init_time or
>>> init_irq callbacks.
>>>
>>> Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
>>
>> I see of_clk_init(NULL) getting called on two other ARM platforms:
>>
>> $ git grep -w of_clk_init arch/arm
>> arch/arm/kernel/time.c:         of_clk_init(NULL);
>> arch/arm/mach-keystone/pm_domain.c:     of_clk_init(NULL);
>> arch/arm/mach-mvebu/armada-370-xp.c:    of_clk_init(NULL);
>> arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:        of_clk_init(NULL);
>>
>> Are the other two platforms ok here?
>>
>> I assume that mvebu is fine since Sebastian would have noticed breaking
>> that one and it has a custom init_time function, but keystone seems
>> broken in the same way as s3c64xx. Santosh, can you have a look?
> 
> Yeah, and Free Electrons also sent two systems to Kevin so he has them
> in his boot test setup, and they're still happy there. Keystone lacks
> such coverage though, so Santosh will need to check.
> 
Keystone isn't broken as such but some warnings are produced because of
the change. This was noticed on keystone quite a while back and a
patch[1] is already in my queue. It didn't click me that other
machines might have been also affected at that point of time. 

Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg288578.html

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Sebastian Hesselbarth]

On 12/14/2013 04:00 AM, Arnd Bergmann wrote:
> On Friday 13 December 2013, Tomasz Figa wrote:
>> Commit
>>
>> 4178bac ARM: call of_clk_init from default time_init handler
>>
>> added implicit call to of_clk_init() from default time_init callback,
>> but it did not change platforms calling it from other callbacks, despite
>> of not having custom time_init callbacks. This caused double clock
>> initialization on such platforms, leading to boot failures. An example
>> of such platform is mach-s3c64xx.
>>
>> This patch fixes boot failure on s3c64xx by dropping custom init_irq
>> callback, which had a call to of_clk_init() and moving system reset
>> initialization to init_machine callback. This allows us to have
>> clocks initialized properly without a need to have custom init_time or
>> init_irq callbacks.
>>
>> Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>

Thomas,

thanks for catching this and sorry for the inconvenience. Either I
simply missed s3c64xx or it went in with that global of_clk_init
patch.

> I see of_clk_init(NULL) getting called on two other ARM platforms:
>
> $ git grep -w of_clk_init arch/arm
> arch/arm/kernel/time.c:         of_clk_init(NULL);
> arch/arm/mach-keystone/pm_domain.c:     of_clk_init(NULL);
> arch/arm/mach-mvebu/armada-370-xp.c:    of_clk_init(NULL);
> arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:        of_clk_init(NULL);
>
> Are the other two platforms ok here?

mvebu is fine as long as it has its own .init_time callback (which it
has).

> I assume that mvebu is fine since Sebastian would have noticed breaking
> that one and it has a custom init_time function, but keystone seems
> broken in the same way as s3c64xx. Santosh, can you have a look?

I also had a look at keystone and guess it is broken, too.
of_clk_init(NULL) is called in keystone_pm_runtime_init() which is
set as subsys_initcall. Simply removing the extra of_clk_init call
in keystone_pm_runtime_init should be enough here:

 From 4ef4720c0d7ca9be57b06dc7ab1483c77a5ada1d Mon Sep 17 00:00:00 2001
From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Date: Sat, 14 Dec 2013 12:21:01 +0100
Subject: [PATCH] ARM: keystone: remove call to of_clk_init

Commit

4178bac ARM: call of_clk_init from default time_init handler

added implicit call to of_clk_init(NULL) from default time_init callback.
This causes double clock initialization on keystone, leading to boot
failures.

This patch fixes boot failure on keystone by dropping the call to
of_clk_init(NULL) in keystone_pm_runtime_init(), which is set as
subsys_initcall and therefore called after arch-wide .init_time callback.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
  arch/arm/mach-keystone/pm_domain.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-keystone/pm_domain.c 
b/arch/arm/mach-keystone/pm_domain.c
index 2962523..3f17e16 100644
--- a/arch/arm/mach-keystone/pm_domain.c
+++ b/arch/arm/mach-keystone/pm_domain.c
@@ -16,7 +16,6 @@
  #include <linux/pm_runtime.h>
  #include <linux/pm_clock.h>
  #include <linux/platform_device.h>
-#include <linux/clk-provider.h>
  #include <linux/of.h>

  #ifdef CONFIG_PM_RUNTIME
@@ -74,7 +73,6 @@ int __init keystone_pm_runtime_init(void)
  	if (!np)
  		return 0;

-	of_clk_init(NULL);
  	pm_clk_add_notifier(&platform_bus_type, &platform_domain_notifier);

  	return 0;
-- 
1.8.4.rc3

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Santosh Shilimkar]

On Saturday 14 December 2013 06:47 AM, Sebastian Hesselbarth wrote:

[..]

> From 4ef4720c0d7ca9be57b06dc7ab1483c77a5ada1d Mon Sep 17 00:00:00 2001
> From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Date: Sat, 14 Dec 2013 12:21:01 +0100
> Subject: [PATCH] ARM: keystone: remove call to of_clk_init
> 
> Commit
> 
> 4178bac ARM: call of_clk_init from default time_init handler
> 
> added implicit call to of_clk_init(NULL) from default time_init callback.
> This causes double clock initialization on keystone, leading to boot
> failures.
> 
> This patch fixes boot failure on keystone by dropping the call to
> of_clk_init(NULL) in keystone_pm_runtime_init(), which is set as
> subsys_initcall and therefore called after arch-wide .init_time callback.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
I already have a patch [1] for this in my queue. Thanks

Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg288578.html

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Olof Johansson]

On Fri, Dec 13, 2013 at 11:59 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Commit
>
> 4178bac ARM: call of_clk_init from default time_init handler
>
> added implicit call to of_clk_init() from default time_init callback,
> but it did not change platforms calling it from other callbacks, despite
> of not having custom time_init callbacks. This caused double clock
> initialization on such platforms, leading to boot failures. An example
> of such platform is mach-s3c64xx.
>
> This patch fixes boot failure on s3c64xx by dropping custom init_irq
> callback, which had a call to of_clk_init() and moving system reset
> initialization to init_machine callback. This allows us to have
> clocks initialized properly without a need to have custom init_time or
> init_irq callbacks.
>
> Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
> ---
>  arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 11 +----------
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> NOTE: This is a critical boot regression fix for mach-s3c64xx that
> should be merged for next 3.13-rc release.

Applied to fixes. We sent a batch of fixes just the other day so this
will likely go in sometime next week, but it'll be in linux-next as of
the next release.

Hm, it'd be nice to get better coverage of 64xx as well as exynos 4.
Are there any cheap 64xx development boards out there?


-Olof

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Tomasz Figa]

On Saturday 14 of December 2013 16:19:05 hua dillon wrote:
> hi olof:
> 
>   i think mini6410 from china is the board you want .

There were several cheap boards with S3C6410 available, but I'm not sure
how many of them are still on the market.

I guess Mini6410/Tiny6410 are, as I can at least see their prices there:
http://www.andahammer.com/mini6410-sdk/
http://www.andahammer.com/t6410sdk/

They are almost fully compatible, so they should be thought as just
a single Mini6410 board, but in different form factors. I do most of
my testing on the latter.

>From other boards supported in mainline, there are:

 - A&W6410 (mach-anw6410) - I couldn't find any information on it
   anywhere,

 - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
   testing of audio codec AFAIK, but I'm not sure if you can get that
   anywhere.

 - HMT (mach-hmt), SmartQ 5/7 (mach-smartq*) - they are supposed to be
   some tablet-like products, but again I'm not sure if you can still
   get them,

 - SMDK6400/SMDK6410 are Samsung's official development boards for
   S3C6400/S3C6410 - I have access to one at the office; no idea if
   you can get one anywhere,

 - NCP - an abandoned Samsung's development board - you definitely
   can't get that anywhere; in fact I'd say that there is no more such
   board alive over the world and it just should be dropped from mainline.

That's all I can find at the moment. Anyway, I have copied Ben, maybe he
knows more than that.

Best regards,
Tomasz

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Dillon]

Hi all

  Let's me give some information about s3c6410 dev board in china,all of them are very cheap.

Ok6410
http://www.witech.com.cn/product/FL6410.html

Ut6410
http://go.ppwan.com/?pp_mid=10&sid=33242

Real6410
Http://www.realarm.cn/pic/?76_451.html

Arm sys 6410
http://www.hzlitai.com.cn/product/ARM/ARM6410/ARMSYS6410-L43T42.html


???? iPad

> ? 2013?12?14????8:41?Tomasz Figa <tomasz.figa@gmail.com> ???
> 
>> On Saturday 14 of December 2013 16:19:05 hua dillon wrote:
>> hi olof:
>> 
>>  i think mini6410 from china is the board you want .
> 
> There were several cheap boards with S3C6410 available, but I'm not sure
> how many of them are still on the market.
> 
> I guess Mini6410/Tiny6410 are, as I can at least see their prices there:
> http://www.andahammer.com/mini6410-sdk/
> http://www.andahammer.com/t6410sdk/
> 
> They are almost fully compatible, so they should be thought as just
> a single Mini6410 board, but in different form factors. I do most of
> my testing on the latter.
> 
> From other boards supported in mainline, there are:
> 
> - A&W6410 (mach-anw6410) - I couldn't find any information on it
>   anywhere,
> 
> - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>   testing of audio codec AFAIK, but I'm not sure if you can get that
>   anywhere.
> 
> - HMT (mach-hmt), SmartQ 5/7 (mach-smartq*) - they are supposed to be
>   some tablet-like products, but again I'm not sure if you can still
>   get them,
> 
> - SMDK6400/SMDK6410 are Samsung's official development boards for
>   S3C6400/S3C6410 - I have access to one at the office; no idea if
>   you can get one anywhere,
> 
> - NCP - an abandoned Samsung's development board - you definitely
>   can't get that anywhere; in fact I'd say that there is no more such
>   board alive over the world and it just should be dropped from mainline.
> 
> That's all I can find at the moment. Anyway, I have copied Ben, maybe he
> knows more than that.
> 
> Best regards,
> Tomasz
> 

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Mark Brown]

On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:

>  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>    testing of audio codec AFAIK, but I'm not sure if you can get that
>    anywhere.

Essentially no, though you could try asking nicely.  It's not suitable
for a test farm anyway without a SD mux as the only bootloader supported
is Qi which only boots from flash.

>  - SMDK6400/SMDK6410 are Samsung's official development boards for
>    S3C6400/S3C6410 - I have access to one at the office; no idea if
>    you can get one anywhere,

I believe they're no longer available though ICBW.  The cost for low
volume orders is likely to be a bit high too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131216/fdf10a37/attachment.sig>

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Charles Keepax]

On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
> 
> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
> >    testing of audio codec AFAIK, but I'm not sure if you can get that
> >    anywhere.
> 
> Essentially no, though you could try asking nicely.  It's not suitable
> for a test farm anyway without a SD mux as the only bootloader supported
> is Qi which only boots from flash.

Yeah, we don't have that many spare at the moment and whilst we
do use them fairly regularly we are not produce new boards
anymore.

Thanks,
Charles

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Olof Johansson]

On Tue, Dec 17, 2013 at 7:14 AM, Charles Keepax
<ckeepax@opensource.wolfsonmicro.com> wrote:
> On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
>> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
>>
>> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>> >    testing of audio codec AFAIK, but I'm not sure if you can get that
>> >    anywhere.
>>
>> Essentially no, though you could try asking nicely.  It's not suitable
>> for a test farm anyway without a SD mux as the only bootloader supported
>> is Qi which only boots from flash.
>
> Yeah, we don't have that many spare at the moment and whilst we
> do use them fairly regularly we are not produce new boards
> anymore.

Yeah, sounds unlikely to be a good fit.

Something like the tiny6410's would be useful. They seem to mostly be
available with LCD panels though, which ups the price a bit. I'll keep
an eye out for one.


-Olof

[PATCH CRITICAL] ARM: s3c64xx: dt: Fix boot failure due to double clock initialization

[Olof Johansson]

On Tue, Dec 17, 2013 at 11:12 AM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Dec 17, 2013 at 7:14 AM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
>> On Mon, Dec 16, 2013 at 09:09:15PM +0000, Mark Brown wrote:
>>> On Sat, Dec 14, 2013 at 04:41:06AM -0800, Tomasz Figa wrote:
>>>
>>> >  - Wolfson Cragganmore 6410 - Mark Brown (copied) is using it for some
>>> >    testing of audio codec AFAIK, but I'm not sure if you can get that
>>> >    anywhere.
>>>
>>> Essentially no, though you could try asking nicely.  It's not suitable
>>> for a test farm anyway without a SD mux as the only bootloader supported
>>> is Qi which only boots from flash.
>>
>> Yeah, we don't have that many spare at the moment and whilst we
>> do use them fairly regularly we are not produce new boards
>> anymore.
>
> Yeah, sounds unlikely to be a good fit.
>
> Something like the tiny6410's would be useful. They seem to mostly be
> available with LCD panels though, which ups the price a bit. I'll keep
> an eye out for one.

FWIW, I came across a store at Guang Hua Digital Plaza today that had
the tiny6410+SDK board on display, and ended up buying one. It'll take
me a little while to wire it up for testing.

Seems like there's no upstream u-boot support for the board, so
getting something onto it that can network boot seems to be a long
shot. We'll see what I can cobble together.


-Olof