alcides has quit [Quit: /(bb|[^b]{2})/ regular expression junkie + lover of literature...]
Hexxeh has quit [Remote host closed the connection]
steev has quit [Remote host closed the connection]
Hexxeh has joined #arm-netbook
steev has joined #arm-netbook
jlj has quit [Ping timeout: 260 seconds]
drachensun has quit [Read error: No route to host]
tekzilla has quit [Ping timeout: 252 seconds]
tekzilla has joined #arm-netbook
calris has quit [Ping timeout: 260 seconds]
calris has joined #arm-netbook
newbie has joined #arm-netbook
newbie is now known as hp__
Quarx has joined #arm-netbook
ZaEarl has quit [Quit: Ex-Chat]
steev has quit [Excess Flood]
steev has joined #arm-netbook
jlj has joined #arm-netbook
robws has quit [Ping timeout: 260 seconds]
robws has joined #arm-netbook
Quarx has quit [Read error: Connection reset by peer]
gimli has joined #arm-netbook
mSquare has joined #arm-netbook
rvalles has quit [Ping timeout: 252 seconds]
rvalles has joined #arm-netbook
jlj has quit [Ping timeout: 260 seconds]
rellla has joined #arm-netbook
rellla has quit [Quit: rellla]
<techn_>
WarheadsSE: chmod your /dev/ump
<techn_>
or if you have done so.. try with that buf2 patch
orly_owl has quit [Quit: leaving]
jlj has joined #arm-netbook
MMlosh has quit [Quit: Bye...]
popolon has joined #arm-netbook
MMlosh has joined #arm-netbook
rellla has joined #arm-netbook
jlj has quit [Ping timeout: 240 seconds]
rellla has quit [Quit: rellla]
rvalles has quit [Ping timeout: 252 seconds]
lkcl has joined #arm-netbook
rvalles has joined #arm-netbook
cheng has joined #arm-netbook
plan_b has joined #arm-netbook
<techn_>
mnemoc: this can be removed? wip/allwinner-v2.6.36-android/disp :)
<mnemoc>
techn_: ok
<techn_>
what I noticed that there is only one hack to supress crash
<mnemoc>
yes
<mnemoc>
done
<techn_>
how about these? /allwinner/amery/lichee-v2.6.36-dev, /amery/linux-2.6.36-sun4i ?
<mnemoc>
techn_: we still need the 2.6.36 ref for sun3i
<techn_>
ok
<RaYmAn>
it also really doesn't matter much whether you delete the branch or not (Except for the github ui)
<mnemoc>
but I can rename them if the "amery" prefix bothers you
<mnemoc>
RaYmAn: eventually orphan heads get removed
<mnemoc>
and that implies losing data
<techn_>
mnemoc: no.. I'm just cleaning my own repo.. and trying to find out valid branches
<techn_>
RaYmAn: you can force compress which removes dead head's
<RaYmAn>
sure
<techn_>
mnemoc: how about 3.3 branches? :)
<mnemoc>
techn_: there is work from steev there
<mnemoc>
techn_: which i don't want to trash until it's ported to 3.4
<mnemoc>
but they are also part of our "attic"
<RaYmAn>
perhaps it's time to consider making a github "organisation" to put the "official repos" on, e.g. u-boot and kernel? then the more experimental can stay at amery and hno repos?
<mnemoc>
i would love too... but I fear about broken links
<mnemoc>
I still get people forking my uboot repo regarless the big warnings asking them to use hno's
<RaYmAn>
so clean it out? :P
<mnemoc>
hno's is a fork of mine
<mnemoc>
no clue how will github react
<RaYmAn>
it won't affect anything
<RaYmAn>
you can delete your repo and hno's will be unaffected.
<mnemoc>
i thought they were linked
<RaYmAn>
mm ,probably behind the scenes - but I'm 100% that github does the right thing
<RaYmAn>
it would be chaos if all forks went haywire if original repo was broken
<mnemoc>
fair point
<RaYmAn>
but rather than deleting, it would probably be better to remove all content and and make sure to link on to the proper repo
<RaYmAn>
so you don't break http links to it :)
<mnemoc>
that sounds like a good idea
<cat1>
is it only me who gets this error http://sprunge.us/IXPP while compiling recent linux-sunxi-3.4? note that CONFIG_RTL8192CU_SW=m is used instead of mainstream driver.
<mnemoc>
cat1: yes, the driver is bound to android stuff deprecated in their 3.4 branch
<mnemoc>
we can either fix the driver, or trash it
<cat1>
mnemoc: yeah, once we get rtlwifi working with fw :)
<cat1>
actually i do not really remember, maybe that was working with 3.4..
<cat1>
but i doubt..
<mnemoc>
we should move the usb_wifi_para handling into proper power management
<mnemoc>
cat1: try it ;-)
<cat1>
mnemoc: but the problem i have seems not to be realted to pm
<techn_>
mnemoc: could there be used kernel's own usb suspend logic?
<mnemoc>
cat1: it's not
<mnemoc>
cat1: but the reason for that driver to exist and be used instead of mainline is [usb_wifi_para] support
<mnemoc>
which enable/disable the usbc if the wifi module is loaded/unloaded
<mnemoc>
to save power
<cat1>
mnemoc: ok, marked for the future :) anyway, the thing is that i am really annoyed by the fact that network connectivity is missing to the target..
<mnemoc>
disable CONFIG_RTL8192CU_SW
<cat1>
mnemoc: it is not fun :)
<mnemoc>
:)
<cat1>
the real fun is to get mainline stuff working.
<mnemoc>
but fixing the fw problem on the mainline driver in 3.6 doesn't add value to sunxi =)
<cat1>
mnemoc: actually it does as i suspect it does not work in 3.4 too!
<cat1>
will figure it out soon as i am preparing 3.4 for testing
<cat1>
techn_: aha, the only problem is that my house is located on the coverage boundary, so only 2bars on strength indicator :) dunno if it will cause any connection stability issues.
<cat1>
techn_: yeah, i still have nokia paid adsl line -- restults are proximately in the same range as yours.
<cat1>
techn_: but soon it will be terminated so i am looking for alternatives.
<techn_>
cat1: external antenna would help?
<cat1>
techn_: maybe, but i wont bother unless i experience real problems.
<techn_>
repo size went from 800MB to 600MB with aggressive gc :)
<rz2k>
techn_: could you please write step-by-step manual about how you got es2gears working, I've tested clean install on r2p4 with latest buf2 patch, I have same errors and black screens. tested both in-kernel and modules for hdmi/lcd/disp stuff.
<rz2k>
we have same config.h
silentaa has joined #arm-netbook
<techn_>
rz2k: I compiled everythink like in the wiki.. except I didn't run autoreconf -vi command.. if I remember correctly
<rz2k>
yes, autoreconf fails r2p4 setup because ARM guys was too lazy to write working configuration, so they've supplied output from autoconf in package.
<mnemoc>
instead of "instructions" we should provide patch
<techn_>
I have to leave.. back in 2 hours :(
<rz2k>
techn_: could you try clean install of r2p4 with kernel from -v2 + your buf2 patch and everything like in wiki? I believe you've did something that I miss.
<rz2k>
+ using your default script.bin, for instance, script.bin from mele-vga package from dl.linux-sunxi.org has different clock_div than my default one.
RITRedbeard has joined #arm-netbook
orly_owl has joined #arm-netbook
strong has joined #arm-netbook
strong has left #arm-netbook [#arm-netbook]
jlj has joined #arm-netbook
penguin42 has joined #arm-netbook
orly_owl has quit [Remote host closed the connection]
orly_owl has joined #arm-netbook
orly_owl has quit [Remote host closed the connection]
RITRedbeard has quit [Ping timeout: 245 seconds]
orly_owl has joined #arm-netbook
orly_owl has quit [Quit: leaving]
orly_owl has joined #arm-netbook
orly_owl has quit [Client Quit]
chz_ has joined #arm-netbook
chz_ has quit [Client Quit]
orly_owl has joined #arm-netbook
popolon has quit [Quit: Quitte]
Quarx has joined #arm-netbook
<techn_>
back
<captainigloo>
i'm trying to use nand-part of sunxi-tools
<captainigloo>
but i'm not able to get my nand back :(
<captainigloo>
somebody already uses it ?
<mnemoc>
after repartitioning you might need to reboot
<mnemoc>
i doubt the changes are taken immediately
<captainigloo>
yeah but they seems not to be taken at all
<penguin42>
more expensive (note the $199 from November) but nice stuff; 1GB, PCIe, SATA, GBe
<rz2k>
I was thinking about making imx6q board for self education or university paper, but didnt find any data about when imx6q will go out for minor customers and when documents like reference designs will be available.
<rz2k>
"q4 2012" doesnt say anything because it is already q4 2012.
<penguin42>
not until Monday it isn't!
<penguin42>
Turl: What's interesting about the wandboard is it's modular with the CPU/RAM etc on a separate board; with a creative commons defined interface (EDM)
ssvb has quit [Quit: Leaving]
mikey_w has quit [Remote host closed the connection]
popolon has quit [Ping timeout: 245 seconds]
RITRedbeard has joined #arm-netbook
gimli_ has joined #arm-netbook
plan_b has quit [Quit: Verlassend]
RITRedbeard has quit [Ping timeout: 245 seconds]
gimli has quit [Ping timeout: 245 seconds]
orly_owl has quit [Quit: leaving]
popolon has joined #arm-netbook
mikey_w has joined #arm-netbook
n6pfk has joined #arm-netbook
ssvb has joined #arm-netbook
ssvb has quit [Client Quit]
ceo16 has quit [Ping timeout: 248 seconds]
ceo16 has joined #arm-netbook
jlj has quit [Ping timeout: 260 seconds]
<drachensun>
has anyone tried to get a tablet camera working?
<drachensun>
I can load the camera driver but I'm not sure whats needed after that
<lkcl>
penguin42: yeah... it looks great, until you realise that it's designed for purely factory-install purposes *only*. just like the qseven-standard. you can't do anything with an EDM module, without a matching breakout PCB.
<Turl>
lkcl: same with EOMA-68 too?
<Turl>
drachensun: it uses video4linux from what I recall
RITRedbeard has joined #arm-netbook
<lkcl>
Turl: no. EOMA-68 re-purposes PCMCIA. you can stick an EOMA-68 CPU Card in your top pocket without damage.
<lkcl>
ok, that's assuming it's inside a PCMCIA metal shield of course, rather than being straight off an engineer's R&D lab desk
<lkcl>
EOMA-68 is designed for mass-volume end-user purposes [with a case on] as well as for factory-install purposes [with the case off]
<Turl>
ah, I see what you mean now
<lkcl>
yeah.
<Turl>
you could stick some shielding on top of EDM too I guess
<Turl>
or make a carrying case
<lkcl>
plus, unfortunately, just like in the q-seven standard, many of the interfaces are "optional".
<lkcl>
did i ever tell you the story about the development of the X-25 standard?
<lkcl>
it's quite a simple one.
<Turl>
I don't think you did :)
<lkcl>
:)
<lkcl>
ahh, allow me :)
<Turl>
X-25 reminds me of X-28, any relation?
<Turl>
(alarm system)
<lkcl>
the X-25 standard is similar to RS-232 - it was what the JANET network ran on.
<lkcl>
it's 9 pins, and it has (had) a hardware line dedicated to "interrupt", and it had a "Tx" clock line.
RITRedbeard has quit [Ping timeout: 246 seconds]
revident has joined #arm-netbook
<lkcl>
but, *just in case* someone forgot to honour the hardware "interrupt" line, they put "software interrupt" into the serial data stream
<lkcl>
no, sorry - it only had a "Rx" clock line.
<lkcl>
anyway - because it had both hardware and software interrupt, *everyone* had to support software interrupt
<lkcl>
thus, the hardware interrupt line was *utterly* useless.
jlj has joined #arm-netbook
<Turl>
heh
<lkcl>
which is a total waste of a pin, esp. when it could have been used as a "Tx" clock line
<drachensun>
Turl: yeah I figured out the drivers needed from looking at the android but I'm getting crashes in videobuf_core now
<lkcl>
so instead of a $2 cable like in RS232, you had to have a $7 box generating a Tx clock to *both* parties, with a $3 power supply!
<drachensun>
I'm looking for 'low hanging fruit' features to fix up right now
<lkcl>
you see the point i'm making - which is that you must NOT have "optional features" in a hardware standard?
<lkcl>
if you do have options, they must be negotiable over the bus lines.
<lkcl>
e.g. USB2 has speed-negotiation... but done in hardware.
<lkcl>
SATA has speed-negotiation... all the way from 150mbits/sec up to 3gbits/sec... but that's done over the *same* 4 wires
<lkcl>
ethernet as well.
<lkcl>
EDM, unfortunately, makes many of its interfaces optional
<Turl>
drachensun: on kernel?
<lkcl>
that immediately to me is a red flag
<Turl>
lkcl: any optional features on EOMA-68? :)
<drachensun>
Turl: when I used fswebcam to try to read from the camera the kernel driver videobuf_core is crashing
<drachensun>
I'm installing another v4l program now to see if maybe thats all it is
<Turl>
it shouldn't crash even if it's a bad v4l program :)
<lkcl>
Turl: nnnope :)
<lkcl>
i learned the lesson of X-25 :)
<drachensun>
heh yeah I guess not
<drachensun>
it was checking for working resolutions
<drachensun>
and I'm thinking maybe the first resolutions just aren't supported
RITRedbeard has joined #arm-netbook
<penguin42>
lkcl: How 'factory only' is EDM? What makes it any worse than a so-dimm?
RITRedbeard has quit [Ping timeout: 245 seconds]
<lkcl>
penguin42: it's exactly the same factory-only usefulness for all those form-factors. MXM, SO-DIMM, EDM, Q-Seven.
<penguin42>
lkcl: In that case, I don't see the problem
<penguin42>
lkcl: Plenty of people carry SO-DIMMs around, fit them in their own laptops etc
<lkcl>
you only have to think, "would a module of standard X survive my grandma putting it in the top pocket of her best nylon-polyester dress?"
<penguin42>
lkcl: But why is that important for EOMA?
<lkcl>
penguin42: think "grandma". does grandma carry around SO-DIMMs and fit them into her laptop?
<penguin42>
lkcl: No, grandma carries around a system with an HDMI port on
<lkcl>
penguin42: because we're expecting the volumes to be somewhere around a million a month or greater
<penguin42>
lkcl: That's way less than SO-DIMM
<lkcl>
penguin42: exactly. an EOMA-68 CPU Card has an HDMI port.
<penguin42>
lkcl: No, my point is what is granny going to do with her EOMA?
<penguin42>
lkcl: Why wouldn't she just carry her tablet around?
<lkcl>
penguin42: i was underestimating. GW's capacity is... even into numbers bigger than i can appreciate
<penguin42>
lkcl: Seriously, that EDM stuff looks like exactly what is needed
<lkcl>
penguin42: yes. good question. granny's tablet breaks. little johnny (her 8-year-old tech support) tells her to take the EOMA-68 CPU Card out and bring it over to his mum's house.
<penguin42>
lkcl: No he doesn't, little jonny tells her to bring her tablet over
<rm>
rz2k, what am I missing? mali_exa.h:27:21: fatal error: ump/ump.h: No such file or directory
<lkcl>
or, granny takes it back to the store when it's broken, takes the EOMA-68 CPU Card out and she puts it in her handbag.
<penguin42>
lkcl: No, Granny takes the tablet back
<penguin42>
lkcl: The differential between the card and the object it's part enough has to be large enough to justify the difference
<lkcl>
penguin42: sorry, you don't get it. if you don't get it, i'm not going to spend a lot of time explaining.
<penguin42>
lkcl: Sorry, I don't; I see the point in making stuff modular, I don't get the reason to make it more robust for that type of app
RITRedbeard has joined #arm-netbook
<lkcl>
penguin42: if you're going to argue with the envisaged scenarios without listening, there's no point in me trying to explain, is there.
<penguin42>
lkcl: Apologies, I seriously don't mean to be like that; I don't see what I haven't listened to
<lkcl>
penguin42: the point is that anything that's removable *will* be hit or damaged by the average person.
<lkcl>
penguin42: if there's even a 1% returns rate on items that are sold in quantities of 100 million, that's still a loss of a million units.
<lkcl>
in the mass-volume retail sector, typically the profits are below 1%.
<penguin42>
lkcl: OK, so I'm trying to understand why the SO-DIMM doesn't hit that problem?
<lkcl>
it does hit that problem. it's not protected from damage through static, is it?
<lkcl>
or from being dropped
<lkcl>
or poked at with a sharp implement
<lkcl>
or peoples' fingers pressing against the connector and getting oil on it
<penguin42>
lkcl: Yep, so laptops are still mostly sold with SO-DIMMs in - so why do they survive?
<lkcl>
because the average person DOES NOT DO THE INSTALL, do they?
<lkcl>
what's the average lifecycle on removal and insertion of an SO-DIMM memory module?
<penguin42>
lkcl: I'd guess 10
<lkcl>
it'll be about once every.... 5 years.
<lkcl>
whereas we're anticipating EOMA-68 modules to be inserted/removed on a similar order as USB
<penguin42>
lkcl: OK, but why do you want EOMA to be installed/removed more often - I want to understand why granny would want to do this
<lkcl>
SO-DIMM sockets have a lifecycle of about .... something like 25 cycles *total*.
<lkcl>
because they can.
<lkcl>
granny might not
<lkcl>
but a professional who has an EOMA-68-compliant Digital SLR Camera, as well as an EOMA-68-compliant smartphone
<lkcl>
and tablet
<lkcl>
and laptop
<lkcl>
and 30in LCD monitor at work
<lkcl>
and a games console at home
<lkcl>
they might end up inserting/removing their EOMA-68 CPU Cards up to 10 times a *day*
<penguin42>
lkcl: OK, I hadn't seen that use of it
<lkcl>
yeah - it's like... the potential here is *huge*. it covers virtually every mass-volume electronics system you can think of, in the world.
<lkcl>
with the exception of the hard-core gaming industry, the high-end server market, high-end / real-time video editing industry
<lkcl>
and ... err... i run out of examples where EOMA-68 could not be used. oh yeah: portable watches :)
<penguin42>
and music players
<lkcl>
i'm not going to wear a device of 86x54 mm on my wrist :)
<lkcl>
true. yes. music players... well..... you think, we used to have walkmans and so on.... 86x54 is credit-card-sized... but... yeah
<lkcl>
people now expect them to be usb-stick-sized
<penguin42>
lkcl: and I think mobiles are now probably below it
<lkcl>
just about, yes. although some smartphones have to have larger screens.
<drachensun>
people still buy ipods, how big are those now?
<lkcl>
and esp. the smartphones with keyboards
<drachensun>
still phone sized I think
<lkcl>
ipods? ooo, they're about the size of Compact Flash.
<lkcl>
which is why i drew up EOMA-CF as well
<lkcl>
but, we'll get to that later
<penguin42>
lkcl: Right, so I hadn't seen your vision of that before which is why I couldn't see that before - the challenge then which I'm not too sure of is whether the market is really there; people carry the SD card between there tablet/tv/camera/laptop, or use their mobile as the module
<lkcl>
penguin42: sorry!
<drachensun>
cost cost cost, I think consumers would see the benefit of "I want the latest camera with 2123123 MP but this one is less because it uses my old cameras processor board"
<lkcl>
penguin42: yeah, some people aren't going to "grok" the various combinations
<penguin42>
lkcl: That argument is much better than 'servicing' argument; because 8 year old jonny probably can change an SO-DIMM
<Turl>
drachensun: you're likely to need a new processor to process the extra MPs anyway
<lkcl>
but that's ok - there are benefits for the factories, SoC vendors etc. etc. as well which gives them some incentive to make them
<lkcl>
penguin42: there's an article coming out in a couple of weeks
RITRedbeard has quit [Ping timeout: 260 seconds]
<drachensun>
Turl: maybe not a perfect example, but in a lot of consumer electronics pieces don't change generation to generation, except the processing
<penguin42>
lkcl: It's interesting though how uses change; the SD card and the mobile are now to some extent getting used as the module; people can carry their data around between all their devices; and I think on iphone 5 Apple have put a high bandwidth interface which I expect them to push that idea further (wtf they didn't use the thunderbolt or USB-3 I don't get, or is it actually a thunderbolt derivative)
<Turl>
drachensun: I really can't think of a single example :|
techn has joined #arm-netbook
<drachensun>
well I just noticed there is a videobuf2-core driver
<drachensun>
maybe that is what I need
techn_ has quit [Ping timeout: 255 seconds]
<lkcl>
penguin42: apple have a different kind of agenda. compliance with e.g. EU regulations on industry standards such as the USB charger/audio connector standard ain't high on their list....
<penguin42>
lkcl: Right, but their move to higher bandwidth interfaces I suspect is the interesting one to watch
<captainigloo>
I build my own kernel, git://github.com/amery/linux-allwinner.git branch allwinner-v3.0-android-v2 with arch/arm/config/sun4i_defconfig
<hno>
captainigloo, good.
<captainigloo>
but it freezez just after loading kernel in uboot
<hno>
that's not good.
<captainigloo>
:)
<lkcl>
penguin42: yeahhh, they have the funds to create entire eco-systems, amortising the R&D and tooling across the cost of the devices, but still pushing up the overall unit price
<hno>
captainigloo, what device do you have?
<captainigloo>
i compare mine with the one in nightly build hw pack
<captainigloo>
mele a2000
<lkcl>
whereas we're re-using stuff that's just borderline obselete, using decade-old lowest common denominator interfaces. radically different approach!
<hno>
the nightly build should be a sun4i_defconfig build as well.
<captainigloo>
it seems there is a diff in load adress and entry point of the uboot format
<mnemoc>
and was going to add an equivalent call to init the PMU when called
<mnemoc>
with [target] values
<hno>
Ok.
<hno>
The SUN5I values are for Olinuxino A13.
<hno>
And the original SUN4I ones are Mele.
<mnemoc>
ok
<hno>
Ah, density on the 1GB cubieboard should be 4096, not 2048.
<hno>
and size 1024.
<mnemoc>
but might that cause it to not greet at all?
<hno>
unlikely.
<hno>
should run fine with too small density & size.
<mnemoc>
hno: it seems to be PMU related, in both (a13 olinuxino and cubieboard) with plugging the board with a card made of unified-aw there is no reaction in uart AND the power button does nothing at all
<mnemoc>
after pressing reset, boots fine from NAND
<mnemoc>
with the uSD still connected
<captainigloo>
did you already get this kind of error with nand driver :
<rm>
what's with that problem where U-boot SPL refuses to see MMC on one MK802
<mnemoc>
techn: there is a thread about edid in the cubieboard list which desperately needs you :)
<rm>
any hope it's been fixed by something recently? should I retry?
<mnemoc>
isn't that fixed with a clock factor change?
<rm>
I thought clock factor was fixing something else, i.e. that instability and kernel crashes
<mnemoc>
ah, ok. never mind
<hno>
mnemoc, pushed.
ssvb has joined #arm-netbook
<hno>
rm, there is reports about u-boot-mmc not liking some SD cards, probably a timeout issue where it doesn't wait long enought for the card to come online.
<mnemoc>
rootwait ?
<mnemoc>
meh. need to sleep
<hno>
no, earlier when u-boot tries to access the mmc.
<hno>
not planning to look into MMC issues until PMU support is implemented.
calris has joined #arm-netbook
<hno>
rm, yes that.
<rm>
also this is with 3 or 4 different cards, but consistently on one MK802 out of three
<mnemoc>
hno: `fexc -O uboot` now makes an struct pmu_para made out of [target]
<hno>
rm, could also be the PMU issue, if it's a newer MK802 with PMU. Running the CPU under voltage gives all kinds of wierd errors.
<mnemoc>
still only a proof of concept obviusly, output needs to match uboot needs
<hno>
mnemoc, plus that more and more boards will come with empty parameters.
<hno>
luckily rand, bus, io, density and size can all be determined by visually inspecting the board.
<mnemoc>
livesuit uses sys_config, so there must be "good defaults" we can adopt
<hno>
s/rand/rank/
<ibot>
hno meant: luckily rank, bus, io, density and size can all be determined by visually inspecting the board.
<hno>
mnemoc, livesuit is said to autodetect memory layout these days.
* mnemoc
doesn't believe in magic
<mnemoc>
it could trial and error
<hno>
It's supposedly one of the big things with the A13 push as it makes the same image run on many different boards.
<hno>
ofcourse it's trial and error.
<mnemoc>
so NULL fields would mean "detect"?
<hno>
but some educated trial & error.
<hno>
yes.
<mnemoc>
do I turn those into... 0xffffffff ?
<hno>
no idea what phoenixcard does.
<hno>
the code I have do not do any autodetection.
<mnemoc>
yet :)
<hno>
have not planned to implement any autodetection.
<mnemoc>
:)
<hno>
but guess we will need to deal with this one way or another as information is unavailable.
<hno>
to users-
<mnemoc>
thinking in "the users" if we can't trust script.bin, and "good defaults" are not possible... a fel tool to dump the boot1 header?
<mnemoc>
kind of sucks :|
<mnemoc>
another way is to keep an archive of trustworthy $board.fex files
<mnemoc>
like the chips thing in the SDK, but corrected to not assume livesuit will do it's thing
<hno>
Well. there isn't really that many different DRAM configurations. So a little guide based on number of chips, type of chips and cpu model helps filling in the gaps.
<hno>
but having corrected fex files helps a lot.
<mnemoc>
hno: cubieboard + unified-aw (with board_cubieboard.c) worked :)
<hno>
livesuit misdetects the A13 Olinuxino configuration btw.
<hno>
but don't try that meminfo with MALI enabled.
<hno>
mnemoc, better.
<hno>
I also have another dram.c based on toms code, but much more work to merge that and rewrite to seinsible parameterized code than to switch to the allwinner code.
<mnemoc>
btw, that board_mele.c is made from the stock script.bin, not from the code I deleted
<hno>
should not differ. Does it?
<mnemoc>
didn't check :p
<mnemoc>
DRAM: 1 GiB
<mnemoc>
\o/
jlj has quit [Ping timeout: 245 seconds]
<hno>
Yes, but clock speed probably isn't very good.
<mnemoc>
i'll start playing with the kernel here tomorrow... with mali disabled
<hno>
maybe possible to use cpufreq to switch to better speeds, that do reprogram the PMU. But don't know. There is more voltage settings than just the core.
<mnemoc>
:(
<mnemoc>
maybe setting the default governor to performance can make an early reclocking?
<hno>
you can try. But I would prefer to get the PMU under control before trying higher clocks.
<mnemoc>
fair enough
<hno>
but on the other hand most A10 devices seem fine with default voltages for some strange reason.
<hno>
I do have PMU TWI traces, but then realized the trace is a warm trace with the PMU already configured. Need to redo the trace at cold boot.
<hno>
The third access is reading a non-default value of a user defined register (4 bytes of user defined usage, preserved by PMU as long as there is at least backup power)
revident has quit [Ping timeout: 246 seconds]
popolon has quit [Quit: Quitte]
<captainigloo>
mnemoc: nand-part works again
<mnemoc>
\o/
<captainigloo>
:)
<captainigloo>
but i don't understand what it says