rellla has quit [Remote host closed the connection]
penguin42 has joined #arm-netbook
<penguin42>
anyone know what to expect from a debian chroot running on an older kernel - wheezy armel works but not armhf (which segs)
MaDMaLKaV has quit [Read error: No route to host]
MaDMaLKaV has joined #arm-netbook
luka_ has quit [Quit: leaving]
luka has joined #arm-netbook
luka has quit [Changing host]
luka has joined #arm-netbook
<hno>
penguin42, how old kernel?
<penguin42>
hno: 26.29
<penguin42>
.
<penguin42>
hno: The Ubuntu Quantal/Raring binaries are marked to say they won't run on that kernel, the Debian ones aren't
<penguin42>
lkcl: Linus had fuck all to do with the device tree stuff as I understand it
ibrah has joined #arm-netbook
Yaku321 has joined #arm-netbook
<lkcl>
penguin42: but his words in 2007 would have inspired people to consider it.
<lkcl>
it was at the conference in cambridge (the one that coincided with UKUUG).
<penguin42>
lkcl: I think it was designed by a lot of the ARM guys though, not people who just knew x86
<lkcl>
he called together the architecture teams. over half of the people present were ARM SoC chip people
<lkcl>
penguin42: it still does not help - it really doesn't.
<penguin42>
lkcl: Well, I agree it might not help, but I think it's wrong to blame him in your mail
<lkcl>
the only way it helps is to illustrate that it's another solution that doesn't work
<penguin42>
lkcl: I also thing you underestimate just how much the modern PC is broken with the ACPI/EFI/executable bytestreams
<lkcl>
well, if he understood the scope of the problem, he would not have told those people to "go away, come back when you have only one representative"
<lkcl>
penguin42: yeah that's a whole different can of worms... a solution that isn't properly implemented, but at least they're trying.
<penguin42>
lkcl: No, I sympathise with the view that the ACPI/EFI way will never work properly
<lkcl>
in the ARM world, due to the sheer diversity they can't even try. there's just not enough communication.
<lkcl>
regarding the instigation of device-tree, i believe you'll find that linaro are key players here.
<penguin42>
lkcl: Yeh I agree it was Linaro, and those guys do know ARM
<lkcl>
so device-tree may help the linaro subscribers...
<lkcl>
but... yeah
<penguin42>
many of the Linaro devs know their ARM a lot more than the subscribers
<lkcl>
ok, i have to get back to a critical web site i'm doing - got to get it done by tuesday
<lkcl>
that was a major distraction :)
<penguin42>
lkcl: My view is that it's the hardware designers who have to understand their work has to fit in a device tree; the problem is that there is hardware design and that's thrown over the wall and then the softees go 'htf do we work with that crap'
rz2k has quit []
Yaku-noob has joined #arm-netbook
Yaku321 has quit [Disconnected by services]
datagutt_ has quit [Remote host closed the connection]
specing has joined #arm-netbook
ibrah has quit [Quit: Leaving]
<lkcl>
penguin42: precisely. and there's no incentive for the hardware designers to pay one scrap of attention to device tree. what's the incentive, when an outrageously-GPL-violating company like MStar Semi can do the entire hardware-software design *in secret*? that's an extreme case btw
<penguin42>
lkcl: I don't think that's actually the case - it's just there's traditionally a big gap between hardware software teams - they never talk to the software guys until too late
* penguin42
notes vi on e-ink isn't pretty
<penguin42>
lkcl: Even the closed houses have it in their interest to minimise the work by their software teams - their just too dumb to realise how to do it
datagutt_ has joined #arm-netbook
Yaku321 has joined #arm-netbook
Yaku-noob has quit [Ping timeout: 255 seconds]
<hno>
lkcl, the world is not that black/white.
<hno>
some even do generate the device-tree from the hardware rtl when designing the silicon. That's admittedly the other extreme.
ZaEarl has joined #arm-netbook
ZaEarl has quit [Read error: Operation timed out]
datagutt_ has quit [Remote host closed the connection]
MindBeat has joined #arm-netbook
datagutt_ has joined #arm-netbook
ZaEarl has joined #arm-netbook
rymnio_ has quit [Ping timeout: 251 seconds]
ganbold___ has joined #arm-netbook
ganbold__ has quit [Ping timeout: 276 seconds]
<penguin42>
hno: That's nice
<lkcl>
hno: neat. ... but what does it gain from the perspective of simplifying linux kernel development (and the review of commits) across multiple SoCs and multiple hardware devices?
<lkcl>
sure it would help simplify the use of those specific SoCs
<lkcl>
to some extent
<lkcl>
but will it help the addition of hard-wired peripherals to those specific SoCs?
<penguin42>
lkcl: It means the hardware designers are encouraged to do stuff in a way that fits into a device tree
<penguin42>
lkcl: Rather than using random gpio's tacked onto random places
<lkcl>
... which even if successful merely moves the complexity from the linux kernel.... into device tree *plus* the linux kernel
<penguin42>
lkcl: No
<penguin42>
lkcl: The easiest thing they can do is to build something that fits nicely into the same way another device is done rather than reinventing the wheel again
<lkcl>
yes... but did you read what i wrote?
<penguin42>
yes
<lkcl>
did you see the example about the UDA1381?
<penguin42>
I did but forgot it - remind me
<lkcl>
it has 2 interfaces. one's SPI, the other's I2S.
<penguin42>
do you have to use both at once or is it a choice?
<lkcl>
one team wrote code that worked with one of the hardware interfaces. let's say..
<lkcl>
it's a choice
<penguin42>
ok, so what's the problem?
<lkcl>
ok wrong example.
<lkcl>
... *think*....
<lkcl>
ok
<lkcl>
sorry
<lkcl>
think.
<lkcl>
let's take 50 device designers across the world.
<lkcl>
and 5 ARM SoCs.
<penguin42>
ok, these are handset (say) designers not SoC designers?
<lkcl>
let's say they use 10 each.
<lkcl>
handsets, tablets, laptops etc.
<lkcl>
they're geographically far apart. they're potentially even in the same company, different teams. they have access to different people with different purchasing teams
<lkcl>
buying, sampling etc.
<lkcl>
8 of them are in korea, spread out across that country, and they have local resources (local peripherals).
<lkcl>
they make phone calls and do different searches
<penguin42>
ok
<lkcl>
what do you think the chances are of those 50 devices sharing any of the low-level hardware ICs?
<lkcl>
apart from the SoCs themselves.
<penguin42>
depends :-)
<lkcl>
yeah
<lkcl>
it does.
<lkcl>
they don't communicate *even in the same company*.
<penguin42>
lkcl: My point is that if they're tied into the softies and the softies can go 'hey these devices already have drivers and example dt stanzas - so please use one of these'
<penguin42>
lkcl: Trust me, I work for a vast multinational - I understand the lack of comms
<lkcl>
if they're lucky, they'll find the best prices.
<lkcl>
best priced products
<lkcl>
but even then, it'll most likely be the best priced *local* ICs.
<penguin42>
lkcl: I'm not saying it stops variety, I'm just saying it rewards reuse
<lkcl>
you remember the problem with the raspberry pi? they designed the PCB, completed it, tested it, and shipped off the gerber files to china.... and they said, "sorry, we can't get that 32khz XTAL it's only available in Europe"
<penguin42>
right, but that's because they didn't do their homework
<lkcl>
penguin42: the variety is so disproportionately large compared to the reward that the sheer number of people needing to be educated about the fact that there is even a reward leaves virtually no room for actual success
<lkcl>
true - the point is that parts are local.
<lkcl>
and even if they're local, it's about who you know, and about your reputation, as to whether you can get access to the parts.
<lkcl>
samsung *hates* working with chinese factories, and won't even talk to them unless they'll do a MOQ 50k cash order
<penguin42>
lkcl: It's the same mess on PC audio systems - have you seen how many different CODECs they use and different ways they wire them?
<lkcl>
yeahhhh.... i'm not really looking forward to that on EOMA-200 :)
<lkcl>
now there *is* a good use of device tree.
<lkcl>
mandate that the standard must have I2S, then put the device tree data into the I/O board EEPROM, and bam. done. he said. hopefully :)
<penguin42>
lkcl: Device tree isn't supposed to be a magic solution for everything - but even if it can make life simpler it's a good thing
<lkcl>
sadly i just don't see it happening except in some unusual outlier cases.
<penguin42>
lkcl: Your example of the PXA stuff doesn't help though - it's ancient; modern Cortex stuff in principal should be better since AMBA - not sure if it is, but in principal....
<lkcl>
EOMA standards, 64-bit ARM SoCs in standard ITX motherboard format for example
<lkcl>
penguin42: not really. AMBA isn't the point. PXA is the marvell processors. i also mentioned ARM11 (S3C6410 and Cortex A8 (S5PC100 and 110).
* penguin42
points out to 7dayshop what my browser pointed out to me - their registration page asking for a password is done using http
<lkcl>
awesome!
<penguin42>
even though the page is fetched in https the form submit is http
datagutt_ has quit [Remote host closed the connection]
<penguin42>
still, the pages with my cc data seem to be https... and hopefulyl I'll get the 16GB sammy uSDHC
valhalla_ is now known as valhalla
rellla has joined #arm-netbook
ganbold___ has quit [Remote host closed the connection]
rymnio has joined #arm-netbook
rellla has quit [Remote host closed the connection]
<aholler>
lkcl: sorry, but just saying that the device tree is burden is a bit closed-minded
<aholler>
even if it wouldn't help, at least it forces hw-devs to describe their hw at least in part publicity
<penguin42>
aholler: Well it encourages them - it doesn't force them; there's nothing stopping them doing a gross hack
<aholler>
penguin42: sure, but that was always the case.
<penguin42>
nod
<aholler>
it also helps sw-guys to understand the drivers better. I remember how often I wondered what this and that pin in the driver does if I wanted to adopt a driver to some sligthly different hw
Gujs has quit [Ping timeout: 264 seconds]
eebrah is now known as eebrah|away
valhalla has quit [Ping timeout: 268 seconds]
valhalla has joined #arm-netbook
datagutt_ has joined #arm-netbook
rsalveti has quit [Ping timeout: 245 seconds]
rsalveti has joined #arm-netbook
Gujs has joined #arm-netbook
pwhalen has quit [Read error: Connection reset by peer]
rymnio has quit [Read error: Connection reset by peer]
rymnio has joined #arm-netbook
pwhalen has joined #arm-netbook
herdingcat has quit [Remote host closed the connection]
abesis has joined #arm-netbook
datagutt has quit [Quit: kthxbai]
Yaku321 has quit []
roric has joined #arm-netbook
tzafrir has quit [Read error: Operation timed out]
inkwizytor is now known as qermit
focus_it has joined #arm-netbook
<focus_it>
anyone know if DDR RAM modules used for PCs can be used for A10 chip. If problematic, what is the problem?
MMlosh has quit [Quit: Bye...]
gimli has quit [Ping timeout: 245 seconds]
christopher has joined #arm-netbook
<hno>
focus_it, the A10 memory interface is 32-bit. Normal DIMM modules are 64-bit. (72 for ECC modules)
popolon has joined #arm-netbook
<lkcl>
aholler: i didn't have a problem with adopting/adapting a driver to some slightly different hardware when it was all based around struct platform_driver. admittedly it was a little awkward as i needed to have 4 or 5 files open and track things down but i'm used to that and had adjusted to it.
<lkcl>
aholler: i'm sure it helps in that regard, but does it help reduce the burden of development across multiple SoCs, multiple hardware devices which have nothing in common except the base instruction set? of course it doesn't.
<lkcl>
focus_it: also you'll need to know the DDR RAM timings before you can boot up. i presume, normally, that kind of information is stored in a BIOS. on the A10 at initial boot you've only got... what... 32k of memory to play with, and you need to identify the memory type and its settings from... what/where?
<lkcl>
bit tricky... :)
<specing>
32k memory is an abundance!
<lkcl>
:)
rymnio has quit [Ping timeout: 252 seconds]
tzafrir has joined #arm-netbook
<specing>
Wish I had that much RAM on AVRs
<specing>
Instead I have to cramp it all into 128 bytes
<penguin42>
lkcl: The sdram-samsung-k4x4g303pb-or-hynix-h8mbx00u0mer-0em.h file in the source for this Nook is a good example of why a device tree would be useful - just a set of values
<focus_it>
slapin_n1:I think we all must make a standardized memory module so that we can slap together from off the shelf modules when prototyping - PC ddr memory modules are 64 bit, and for arm we want 32 bit
<focus_it>
may be a way is to use 32 bit only of PC ddr and waste the remaining bits (for prototying work)
<slapin_n1>
focus_it: I will buby just any 128M x 8 DDR3 chips I find, now I got the same ones as Olimex
<focus_it>
good plan - but board layout will have to change each time?
<slapin_n1>
focus_it: no, I use BGA78 packae
<slapin_n1>
*package
<focus_it>
hmm so they standardize the pinout for BGA78? I'm out of touch on these big memory chips.
<slapin_n1>
focus_it: I am going to do another variant with BGA96 package to have all 512MB mem in one chip to save space and tracing work
<slapin_n1>
focus_it: it is standard
<slapin_n1>
focus_it: JEDEC one
<focus_it>
that be good! :)
<focus_it>
how do you manage line lengths in KiCAD? manual calculation?
<slapin_n1>
focus_it: no other options yet
<focus_it>
is the board finished - or does it a thorough check before it can be said to be ready?
<focus_it>
no lcd connector?
<focus_it>
p2 is got the uboot pin and p4 has usb - so that should make it easy to check if CPU is alive through doing FEL mode
<focus_it>
slapin_n1: I think a 40 pin FPC for LCD would be missed
popolon has quit [Quit: Quitte]
<focus_it>
slapin: I'm so glad you managed to make these KiCAD files. I'm tempted to put it on to a 200 pin SO-DIMM, add 2 more layers to get all the wires out to the SO-DIMM edge connector, and then tell my CN partner company to go make it!! :)
<focus_it>
I'll put the FPC on it - my boss would be pleased!
<focus_it>
all the files will be GPL'd of course for anyone to re-use :)
<focus_it>
I get rid of any tantalums. Now 1uF 0603 ceramic caps available and 4.7uF and and 10uF ceramic caps in 0805 package available for very low price
<focus_it>
I also put uSD card to allow it to boot from that
<focus_it>
Worry about 4GB storage as limiting - may be put 2chips - get 8GB.
<focus_it>
Add CPU reset switch + flashing LED for chip to indicate manually by the CPU that it is still alive
rymnio has quit [Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204]]
<focus_it>
Also dedicate a couple of pins for 1620 type of displays (4 pin data)
<focus_it>
also dedicate a couple of lines for servo signals :)
_whitelogger has joined #arm-netbook
rm has quit [Ping timeout: 246 seconds]
rm has joined #arm-netbook
rm has quit [Changing host]
rm has joined #arm-netbook
focus_it has quit [Quit: Leaving]
hramrach_ has quit [Remote host closed the connection]