<ysionneau>
oh, so no javascript interpretor but Lua
<ysionneau>
I would not have expected that :)
<ysionneau>
I should really give it a try one day (Lua)
<whitequark>
I'm not sure whether this is an interpreter either
<whitequark>
luajit is truly an amazing thing, and with 32MB of spare RAM it can fly
<whitequark>
i.e. be within 2x-5x of C for non-numeric workloads. this is just a ballpark figure, since I don't know how good is luajit's ARM port, how good is their translator, etc.
<ysionneau>
interesting
<whitequark>
main drawback for this, imo, is that it's fundamentally still a toy, it's very much bound to one particular set of hardware
<whitequark>
and it neither has the required knobs to port it, nor the set of people most likely to use this are competent enough to do the port.
<whitequark>
a really nice toy though
<ysionneau>
yes
<ysionneau>
usually you buy this because you are a web developer wanting to give a try to hardware toys
<whitequark>
exactly
<ysionneau>
you only know web languages and then you're happy with the JS api
<ysionneau>
but you cannot port it to another board
<ysionneau>
but maybe a company can make a product out of it
<ysionneau>
with a small team of low level guys
<ysionneau>
and a big team of high level js-style guys
<whitequark>
I really like how the problem is solved from a technical standpoint, but I don't like the problem itself at all
<whitequark>
all hardware it runs on is incredibly similar
<ysionneau>
well, phones before had a screen, a gsm radio, wifi could be optional, bluetooth also etc
<whitequark>
I mean, it differs mainly by {display,camera,sensor} resolution. they don't even have different sets of sensors anymore.
<ysionneau>
android api could "work" on old phones as well
<whitequark>
or sets of radios
<whitequark>
sure, but it's still very homogenous
<ysionneau>
well yes, I don't think you can hook up an Infra-red communication port for instance
<ysionneau>
or an ultrasonic detector
<ysionneau>
well, you can, but not within android own's api
<ysionneau>
you need to extend it (JNI, libhardware etc)
<ysionneau>
maybe the API is too "narrow" for now
<ysionneau>
maybe it will get more generic one day
<ysionneau>
but it's difficult when you want to have a big app store compatible with a lot of phones
<ysionneau>
you wanna have a very clear API, not some vague indication of an "I/O" device that one can inherit from and do it's ultrasonic interface etc
<ysionneau>
hum :(
<ysionneau>
I guess that's a tradeoff
<whitequark>
I'm not sure how app store model works for embedded device
<whitequark>
they'd need a complete opposite of that
<ysionneau>
works for phone for the reason you mentioned
<whitequark>
exactly
<wpwrak>
(before/after) before, phones were colorful and small. now they're big and try to be threatening.
<ysionneau>
maybe it could somehow work, less perfectly maybe than with today's phone, with a more semantic approach for the api
<whitequark>
ysionneau: I don't think so
<ysionneau>
instead of for instance drawing a TextEdit field in Java in the android app
<ysionneau>
you could say AskTheUserForAString()
<whitequark>
you can afford using your hw less efficiently for PC and phones because there's so much of them and because of that they're cheap
<ysionneau>
and it could be implemented several ways depending on the hardware
<ysionneau>
if there is voice recognition, keyboard/screen, bluetooth RFCOM
<ysionneau>
etc
<whitequark>
so you transfer some cost from developers to hardware
<whitequark>
and it works, because a lot of well-paid people develop for a very narrow range of cheap hardware
<whitequark>
but if you're doing something custom, there's pretty much the opposite
<ysionneau>
hum hum
<whitequark>
a single team develops a specialized application where every cent multiplicates in big production runs
<ysionneau>
yep , indeed
<whitequark>
so it makes sense to use your underlying platform for all it's worth (and maybe slightly more :)
<ysionneau>
funny to think about that
<ysionneau>
since I used to work on an embedded product (so I understand the using the hw at 120% and every cent is multiplicated for production) ... running android :)
<ysionneau>
we ended up creating our own little application store
<ysionneau>
not the google play store
<whitequark>
I'm not sure if most stuff running android can be considered embedded anymore
<whitequark>
according to dynamics I just described
<ysionneau>
héhé
<whitequark>
it's closer to PC
<ysionneau>
indeed
<ysionneau>
like all of today's phone
<whitequark>
yup
<ysionneau>
it was OMAP3 based product
<ysionneau>
512 MB ram ... 1 GB nand flash
<ysionneau>
"big stuf"
jekhor has quit [Ping timeout: 272 seconds]
<DocScrutinizer05>
ysionneau: don't get me started
<ysionneau>
with?
<DocScrutinizer05>
512MB-RAM/1GB-NAND
<ysionneau>
omap? :p
<whitequark>
DocScrutinizer05: do start :)
<ysionneau>
that's your hw for the neo900 right?
<DocScrutinizer05>
I'm about to go nuts with trying to source a 1GB RAM PoP
<ysionneau>
oh
<ysionneau>
pop
<ysionneau>
Can you do high bandwidth with pop? not too much interference?
<DocScrutinizer05>
hmm?
<ysionneau>
package on package?
<DocScrutinizer05>
yep
<ysionneau>
if you put a cpu, then flash on top, then DDR on top
<ysionneau>
you get hell lot of high frequency signals very next one to another
<DocScrutinizer05>
mt46h256m32l4jv-5
<ysionneau>
with length matching etc which are important, AND impedance
<DocScrutinizer05>
there's no 3-floors PoP sandwich
<ysionneau>
really?
<ysionneau>
I thoug
<ysionneau>
tought*
<ysionneau>
thought*
<DocScrutinizer05>
that would be so nice if we could stack NAND and RAM in separate PoP packages on top of OMAP3
<wpwrak>
DocScrutinizer05: given up on non-pop ?
<DocScrutinizer05>
wpwrak: last resort
<DocScrutinizer05>
CUS kills one UART and one McBSP and a few GPIO for us
<ysionneau>
one uart is not working on CUS package?
<wpwrak>
(last resort) ah, still stuck in idealism. that was Hegel, right ? :)
<DocScrutinizer05>
CPB with only RAM on PoP stoll kills a few bottom-balls for attaching NAND
* ysionneau
has been using 3630 CUS with 512 GB RAM (dual chips) and 1 GB NAND
<wpwrak>
it seems that you're in phase 3 now. two more and you'll be happy with a non-PoP solution :)
<ysionneau>
it seems very dangerous to start a new product using omap3
<ysionneau>
it's getting really old
<ysionneau>
and TI hotline sucks
<DocScrutinizer05>
this is no "new2 project
<ysionneau>
BUT at least loooooooots of silicon bugs have been discovered
<ysionneau>
you have them all nicely listed in the silicon errata
<ysionneau>
compared to brand new chips
<wpwrak>
i think all the legacy software they still have to substitute will leave them no other choice
<DocScrutinizer05>
yep
<wpwrak>
(errata) at least they'll always have a good excuse :)
<ysionneau>
I prefer a chip with lots of silicon errata but listed
<ysionneau>
than a chip with few and unlisted :p
<DocScrutinizer05>
like omap4
<DocScrutinizer05>
which has SiErr I know of that are *really* nasty
<wpwrak>
yeah. or one with many, you find and report them, others confirm them too, but the manufacturer denies their existence. (hi, samsung !)
<DocScrutinizer05>
and are not listed anywhere
<DocScrutinizer05>
wpwrak: Hi TI OMAP4
<ysionneau>
TI does not care about omap anymore
<ysionneau>
and omap3 is damn old
<wpwrak>
maybe they have a cross-border engineer exchange program :)
<ysionneau>
it's like EOL'd in their mind
<DocScrutinizer05>
when PVR busy and CPU suspended, a wake IRQ from e.g. HSI interface may go unnoticed by the IRQ-controller
<wpwrak>
EOL = you with the customers would die
<wpwrak>
s/with/wish/
<qi-bot>
wpwrak meant: "EOL = you wish the customers would die"
<wpwrak>
DocScrutinizer05: bah, suspending a CPU is always asking for trouble. have you learned nothing at OM ? (-:C
<DocScrutinizer05>
since HSI protocol is implemented on hw level and you hardly can change that, you're in a real pinch when suddenly your HSI locks up
<DocScrutinizer05>
wpwrak: on OMAP suspending one IP is not the same as suspending the system
<ysionneau>
DocScrutinizer05: ahah very nice bug :)
<DocScrutinizer05>
sth nobody in openmoko ever wrapped their head around
<ysionneau>
omap is a giant monster
<ysionneau>
I'm really amazed at how much logic we can put in modern chips
<ysionneau>
big caches... bit multi core cpus ... co-processors, tons of controllers
<ysionneau>
big*
<DocScrutinizer05>
even GTA04 SHR and other OS implemetations still use that insane suspend-to-ram approach
<ysionneau>
big GPUs
<DocScrutinizer05>
google SmartRefelx
<DocScrutinizer05>
SmartReflex even
<ysionneau>
and omap36xx is "only" 45 nm tech
<ysionneau>
crazy
<DocScrutinizer05>
yes
<DocScrutinizer05>
compared to 65nm in 3430
<ysionneau>
yep
<DocScrutinizer05>
thus it's faster and less energy hungry
<whitequark>
DocScrutinizer05: suspend-to-ram?
<whitequark>
do you mean it shuts down every single part of the kernel instead of just stopping cpu clock?
<larsc>
wpwrak: the don't exist for _you_
jekhor has joined #qi-hardware
<DocScrutinizer05>
whitequark: that's what I think it (SHR, even QtMoko?) does, yes
<DocScrutinizer05>
while maemo (kernel) is optimized for doing zero clock. And that's what makes the differnece
<DocScrutinizer05>
on S3C2442 we had no such thing like proper zero-clock AFAIK
<DocScrutinizer05>
and all "openmoko" distros thus are still using the insane suspend-to-ram approach
<DocScrutinizer05>
while on maemo it's not even 100% supported
<DocScrutinizer05>
of corse, since: what for would maemo need that?
<DocScrutinizer05>
course*
<larsc>
modern kernels use somethink called runtime PM, which is more or less a distributed suspend to ram. The components are shutdown whenever they are not needed and their state (if necessary) is saved to RAM
<larsc>
something
jekhor has quit [Quit: Leaving]
jekhor has joined #qi-hardware
jekhor has quit [Client Quit]
jekhor has joined #qi-hardware
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
PM kernel
<DocScrutinizer05>
omap PM extensions
<DocScrutinizer05>
everything done right, GTA04 shouldn't need any special care taken about power management, nor should it need any suspend-to-ram
<DocScrutinizer05>
on 3.12 PM kernel
<DocScrutinizer05>
AIUI
<DocScrutinizer05>
maemo Linux 2.6.28-omap1 #1 PREEMPT kernel already had all that, aiui
<larsc>
for certain definitions of "all" ;)
<DocScrutinizer05>
yeah, no friggin DT
<DocScrutinizer05>
which made things a LOT easier
<DocScrutinizer05>
but also disqualified the kernel to go upstream
<whitequark>
DT?
<DocScrutinizer05>
device tree
<larsc>
DT makes so many things so much easier (If done right)
<DocScrutinizer05>
the new acpi
<larsc>
the old acpi
<DocScrutinizer05>
the problem is: DT is not done right ;-)
<whitequark>
how would you do it right?
<larsc>
DocScrutinizer05: you have no idea what you are talking about ;)
<DocScrutinizer05>
probably in sourcecode in the end. there's no way to describe reality comprehensively in any simple grammar like used in DT
<DocScrutinizer05>
larsc: that's correct
<DocScrutinizer05>
how would you describe in DT that USB should wake up from USB-suspend-mode when GPIO_174 gets a signal?
<larsc>
wakup-gpio = <&gpio 174>;
<larsc>
;)
<DocScrutinizer05>
how would you describe the 2 seconds pull-to-low needed on GPIO_160 to make modem power up?
<larsc>
(Yes, I know what the problem with USB and devicetree is)
<larsc>
power-up-dealy = <2>;
<DocScrutinizer05>
uhuh, and now your modem driver for USB attached modem knows about pulling down GPIO_160 for two seconds to power up the modem?
<larsc>
sure, if you wrote your modem driver that way
<DocScrutinizer05>
dang, that must be a pretty universal driver
<larsc>
well it can be very specific to your device
<DocScrutinizer05>
or wait, why do I need DT then?
<larsc>
to describe the topology
<DocScrutinizer05>
LOL
<larsc>
the same modem might be used on a different board
<larsc>
or a similar modem
<DocScrutinizer05>
yeah, with completely different glue stuff#
<larsc>
if the glue is complex enough it will need its own driver
<DocScrutinizer05>
LOL
<larsc>
but that's nothing new
<DocScrutinizer05>
how about a structured netlist of the hardware ;-P
<DocScrutinizer05>
and a driver for every transistor
<DocScrutinizer05>
THAT would make a working comprehensive implementation of a DT
<DocScrutinizer05>
wait, isn't that pspice?
<DocScrutinizer05>
DT is fine for standard function blocks like e.g. I2C, it never will be comprehensive though, to handle all the special hacks of your particular hw platform
<larsc>
yea
<DocScrutinizer05>
IOW you'll always nee a driver like PHS8modem_in_Neo900.ko
<DocScrutinizer05>
need*
<DocScrutinizer05>
several of those, on any arbitrary platform
<roh>
DocScrutinizer05: well.. maybe that should make you think about how one abuses interfaces
<DocScrutinizer05>
prolly not
<larsc>
DocScrutinizer05: so?
<roh>
if its not abused (usb+gpio is NOT just usb anymore) dt is fine and enough.
<DocScrutinizer05>
I'm an EE and I won't adapt my circuits to a hyped coding style on any particular sw-engineering community
<roh>
often its simply used to distinguish dozends of very similar boards with simply different pcb routing and thus led, button and sometimes port ordering or used switch chips, phys, memory... (thus timing), flash etc
<roh>
DocScrutinizer05: do proper EE interfaces and youre in the clear. if you do hacks like usb+gpio you WILL need custom gluecode. which you can configure by dt again
<larsc>
DocScrutinizer05: I'm a SW and HDL guy and I write my HDL cores so they work fine with the existing software ecosystem
<DocScrutinizer05>
my hardware is designed to excel when driven by a tailored-to-fit software
<larsc>
you should also design your cicuits so they work fine with the existing software ecosystem
<roh>
and now we know why EE hw may be nice but you never get proper maintained sw for it ;)
<DocScrutinizer05>
larsc: please take that to MIPI
<DocScrutinizer05>
and to TI
<larsc>
my HDL cores?
<DocScrutinizer05>
and to USB-board
<larsc>
;)
<DocScrutinizer05>
your request
<larsc>
sooner or later even they will realize that this is a competitve advantage
<DocScrutinizer05>
sooner or later YOU will notice that reality isn't based on sourcecode
<larsc>
it's based on money
<DocScrutinizer05>
there's areality (aka hardware and physics) and you (sw-engineer) have to deal with it
<larsc>
building hardware that works is one way to generate money
<larsc>
I build 'hardware' and usually it works better at a fraction of the resource than other hardware with similar features
<DocScrutinizer05>
you kernel guys tried once (at least once) before to make reality adapt to your software defined ideal. It failed epically
<larsc>
and I'm able to do that because I know what the software needs and what not
<DocScrutinizer05>
ORLY
<DocScrutinizer05>
and I throw dice to develop my hardware?
<larsc>
I have no idea
<larsc>
maybe
<DocScrutinizer05>
yeah, evidently
<larsc>
if you don't know the requirements you can try as much as you want it will be more or less chance if your design meets the requirements or not
<DocScrutinizer05>
"maybe" is probably based on you throwing dice to determine the code you write? by deduction
<DocScrutinizer05>
and please stop teaching 101 here
<DocScrutinizer05>
your last post is outright silly
<larsc>
why?
<DocScrutinizer05>
why? maybe because nobody here needs to get educated about basic logics
<larsc>
good
<DocScrutinizer05>
when you don't know about X you can't act according to X
<DocScrutinizer05>
KTNX
<DocScrutinizer05>
ooh, you heard about it? 1+1=2 (usually)
<larsc>
sometimes
<DocScrutinizer05>
meh, I got better things to do that to feed the troll
<DocScrutinizer05>
cya
<whitequark>
huh
<larsc>
I'm just saying the days where you can first build hardware, then write the software for it are over
<larsc>
the integration process has to start much earlier
<whitequark>
was this ever true? I recall EWD describing how it gave his team a significant advantage
<whitequark>
in like 60s
<wpwrak>
first you do the recalls, then you sell, then you fix the bugs, then the hw bugs, the you write the sw, at the very end you make the hw :)
<wpwrak>
s/fix the bugs/fix the sw bugs/
<qi-bot>
wpwrak meant: "first you do the recalls, then you sell, then you fix the sw bugs, then the hw bugs, the you write the sw, at the very end you make the hw :)"
<wpwrak>
if you're really good, you never fix the bugs, you just add new ones fast enough that nobody notices :)
<larsc>
wpwrak: well it's truer than ever - or how does the saying go
<larsc>
wolfspraul:
<larsc>
argh
<larsc>
whitequark:
<larsc>
still too many w
<larsc>
whitequark: do you have a link
<larsc>
?
<larsc>
found this when google dijkstra and competitive advantage: "The alternative —also practised— is to consider competence an unfair advantage." :)
<whitequark>
I feel there's a better one but can't find it
dos1 has joined #qi-hardware
kyak has quit []
kyak has joined #qi-hardware
wolfspraul has quit [Ping timeout: 246 seconds]
wolfspraul has joined #qi-hardware
lekernel has quit [Ping timeout: 272 seconds]
wolfspraul has quit [Quit: leaving]
lekernel has joined #qi-hardware
jekhor has quit [Ping timeout: 246 seconds]
valhalla has quit [Ping timeout: 248 seconds]
<DocScrutinizer05>
[2013-11-22 22:28:07] * NishanthMenon thinks they made grass legal too soon.. DT became ABI as a result :P
<DocScrutinizer05>
[2013-11-22 20:43:26] <NishanthMenon> mag for dm3730 - the following are needed for 1GHz support in kernel: a) dt clock nodes, b) generic voltage layer for cpufreq, c) abb nodes, d) avs 1.5 support (which includes avs migration to dts), e) putting everything together ;)
<DocScrutinizer05>
[2013-11-22 20:43:45] <NishanthMenon> mag, pre-dt we just needed class1.5 ;) - with dt, we are 4 levels set back
valhalla has joined #qi-hardware
<DocScrutinizer05>
so I guess unlike me this guy(?) knows what he's talking about
rz2k has quit []
pcercuei has quit [Read error: Connection reset by peer]
<wpwrak>
at least he seems to know his acronyms ;-)
pcercuei has joined #qi-hardware
<wpwrak>
DocScrutinizer05: btw, what are you using for BT ?
<DocScrutinizer05>
still vapor
<DocScrutinizer05>
[2013-11-22 20:54:27] <NishanthMenon> DocScrutinizer05, i used to be part of N900 kernel team ;)
<DocScrutinizer05>
[2013-11-22 20:54:41] <NishanthMenon> you should see quiet a few patches from me already in the original kernel ;)
<wpwrak>
got any list of candidates ?
<DocScrutinizer05>
err, check feasibility study
<DocScrutinizer05>
I think it's coming with WLAN
<DocScrutinizer05>
we're not there yet
<DocScrutinizer05>
we're going to use a mudule for WLAN, and many of those come with BT naturally merged in
<DocScrutinizer05>
module*
<DocScrutinizer05>
they coexist nicely this way ;-)