<oliv3r>
mnemoc: i tried to apply hansg's patches to stage-3.4 but i stopped after the 3rd as it failed to apply
<oliv3r>
i can try to fix those patches up, but how would you want it? Hansg did a nice patch set with lots of comments, is there any easy way to keep his commit message but apply my patch instead? :)
ibrah has quit [Ping timeout: 264 seconds]
ibrah has joined #linux-sunxi
<oliv3r>
mnemoc: and those that have been applied allready; shall I reply to those mails so you know what is done allready? :P
hipboi has joined #linux-sunxi
ibrah has quit [Ping timeout: 245 seconds]
<oliv3r>
hipboi: quick question; SRAM B (secure) isn't really documented, i think it may be used for ARM Trustzone? By when or what is it used? Do you think it is possible to access it from SPL (and only from SPL)?
<oliv3r>
wingrime: awflash? what did you do and what do you need to do?
<wingrime>
flashimages to nand without livesuit
<hipboi>
oliv3r, searched the manual, not documents
<oliv3r>
wingrime: that works just fine usually :) unless you flash the wrong partition, but even that is fixable
<wingrime>
i want 1) full usb boot 2) full usb nand flash
<wingrime>
3) dumping
<wingrime>
dumping it first step
<oliv3r>
hipboi: the user-manual (leaked ones) don't mention secure sram anywhere in detail, just that its 'off limits'. Our theory is, that it is used by ARM securezone and shouldn't eveer be used by the soc. but in SPL, who cares if we 'abuse' sram B for other purposes ;)
<hipboi>
yes
<oliv3r>
wingrime: first, you need a 'livesuit image' from your device. My tablet has those as 'firmware'
<hipboi>
oliv3r, in spl you can try to access it
<wingrime>
oliv3r: are you saw a13 manual ?
<oliv3r>
wingrime: yeah nothing about sram B there
<oliv3r>
hipboi: interesting, we will try (we are working on it)
<wingrime>
I think Aw moved "big" things to separated docs
<wingrime>
we need them
<wingrime>
I can try rewrite usb
<oliv3r>
wingrime: which partition did you break?
<wingrime>
but only "host"
<oliv3r>
wingrime: make sure to talk to Felipe Balbi, he's WiP on the USB driver
<wingrime>
oliv3r: I want try nand boot on a13 but i need save current stock image
<oliv3r>
hipboi: i'll try to work up a test if we can read/write to sram B
<hipboi>
oliv3r, ok
<oliv3r>
hipboi: if that is possible (only during SPL, trustzone can have sram B back for regular u-boot) it would mean 64k more memory!
<hipboi>
oliv3r, yeah
<oliv3r>
hipboi: 64 + 20 k is a lot more interesting than 20k :)
<oliv3r>
but i only have an A10 tablet, no uart :( so can't test it :S
<oliv3r>
hipboi: went over the brom dissasembly and that didn't touch sram B really
<hipboi>
oliv3r, but the address is different, i mean secure ram
<hipboi>
oliv3r, i can send you a cubieboard and a uSD breakout board
<oliv3r>
hipboi: it's not 0x00020000 - 0x0002ffff for A10?
<hipboi>
i mean not continuous
<oliv3r>
hipboi: the datasheet doesn't say anything other then that :(
<hipboi>
i mean from 0x0 to 0xbfff we have continuous sram
<hipboi>
but the secure ram is from 0x20000 to 0x2ffff
<oliv3r>
Sram A port A1, A2, A3 and A4; right?
<oliv3r>
ah well that can be worked around I guess?
<oliv3r>
first see if it goes; then see what we can do :D
ibrah has quit [Ping timeout: 248 seconds]
Zenton`` has joined #linux-sunxi
e-ndy_ has joined #linux-sunxi
Skaag` has joined #linux-sunxi
zub_ has joined #linux-sunxi
ibrah has joined #linux-sunxi
Zenton` has quit [*.net *.split]
Skaag has quit [*.net *.split]
e-ndy has quit [*.net *.split]
zub has quit [*.net *.split]
ibrah has quit [Read error: No route to host]
ibrah has joined #linux-sunxi
<mnemoc>
hipboi: I love your mascot!
<mnemoc>
oliv3r: yes, reply freely. and please resubmit his once you get them applied :p
<mnemoc>
oliv3r: git am -3 --whitespace=ignore *.eml helps a lot
<mnemoc>
oliv3r: another way is to get another tree moved back in time, apply there and then rebase OR copy over the file to the original tree when you are in the git am conflict break
<oliv3r>
mnemoc: i think the 'to be deleted' files don't match anymore
<mnemoc>
oliv3r: be careful to check those files weren't moved instead of deleted
<oliv3r>
nah
<oliv3r>
it's a 'merge'
<mnemoc>
if they where deleted, just redelete them
<mnemoc>
were*
<oliv3r>
sun5i-audio -> sun4i-audio
<oliv3r>
yeah
<mnemoc>
BUT
<mnemoc>
when you move something you can also change it
<mnemoc>
so you need to diff the original and then new of a git mv change
<mnemoc>
some bits of the sun5i file might have been added
<mnemoc>
i think that's what broken reboot on A13
<mnemoc>
3.0 has an exception for sun5i in the reboot code, i think 3.4's doesn't
<oliv3r>
this is pure sound/soc/sun*i changes
<oliv3r>
so doubt that it does much
<oliv3r>
BUT, the -3 --whitespace=ignore probably makes a world of difference
<oliv3r>
not sure what the -3 does :p
<mnemoc>
3-way
<mnemoc>
also, you'll get the >>>>> ==== <<<<< thing in the files
<oliv3r>
ah, so you can manually fix
<oliv3r>
well
<mnemoc>
yes
<oliv3r>
wel 03/12 applies cleanly, if you don't delete any of the files from the patch
<mnemoc>
but do it looking at the original diff
<mnemoc>
i want to preserve the original intention of the patch :p
<mnemoc>
if that was deleting, so deleteting
<mnemoc>
but you need to be careful nothing of the delete files was merged with the other
<oliv3r>
you make things so difficult :p
<mnemoc>
:(
<mnemoc>
if you got a move in the original (conflicting) commit. undelete the file that was moved, and diff it with the resutling
<mnemoc>
if it's identical, then re-delete
<oliv3r>
i'll see what's going on
<oliv3r>
and why it won't delete
<oliv3r>
and ... figure something out :p
<oliv3r>
and i'll let you worry about getting the commit messages etc right :p
<mnemoc>
:D
<mnemoc>
git am will do the commit message job for you
<oliv3r>
the last change to sun5i was by tom last year
vicenteH has joined #linux-sunxi
<oliv3r>
so this patch can not possibly mess it up
<mnemoc>
once you `git am ---resolved` the thing will get commited with the right message and date
<oliv3r>
it's probably a whitespace issue
<mnemoc>
also, it might be a good idea to review the corresponding -dev branches after the unification
<mnemoc>
and bring in the relevant changes
<oliv3r>
what do you mean? i branched the stage/3.4 and am applying the changes there
<mnemoc>
yes
<mnemoc>
but then, once the unification is done, review the lichee/*-dev branches for sound fixes
<mnemoc>
our starting point for sun5i is even older than teh A13 itself
<mnemoc>
oct 2011 or something like that
<mnemoc>
so a lot of things might have changed
<mnemoc>
brb
<oliv3r>
mnemoc: ohh, you mean compare it to see what AW has improved
<rm>
my favourite is "hal-disable-polling --enable-polling"
<rm>
"Enable polling instead of disabling it."
<oliv3r>
mnemoc: what do you think I did!
<rm>
good thing HAL died
<oliv3r>
lol yes
<oliv3r>
mnemoc: sorry for the ml noise if that's what it is; i'll use those mails as reminders what i have to do/test :)
<mnemoc>
rm: not sure if ending up with systemd is better
<oliv3r>
mnemoc: I have fixed the patches so they all apply now. After doing some tests, shall I git mail all patches from that patch?
<oliv3r>
eudev!
<rm>
mnemoc, udev replaced hal
<rm>
not systemd
<mnemoc>
and systemd ate udev
<oliv3r>
eudev!!
<mnemoc>
oliv3r: resubmiting hansg's patchset would be welcomed, yes. there is no need to repeat the work you just did to make them apply
<mnemoc>
oliv3r: unfortunatelly eudev isn't a serious alternative
<oliv3r>
mnemoc: not YET; it's a fork; so why not
<oliv3r>
mnemoc: give it time :)
<mnemoc>
oliv3r: because it was made for the wrong reasons and without any key dev
<mnemoc>
it's not like egcc or eglibc
<oliv3r>
mnemoc: if I send-email it; will it preserve hansg's comments etc? or do you prefer pull-request via github?
<mnemoc>
oliv3r: git-format-patch will preserve the commit message
<oliv3r>
mnemoc: it's made because of a) udev's dependance of systemd; b) iditiot things like 'oh lets merge /bin and /usr/bin and break everything'
<oliv3r>
mnemoc: ok i'll send them after testing (unless you want them now ;)
<mnemoc>
redhat's evil wish to take over the freesoftware
<oliv3r>
mnemoc: and the key-devs want systemd to replace udev anyway :)
<mnemoc>
oliv3r: no rush, I won't be applying anything today :<
<oliv3r>
mnemoc: for review :p
<oliv3r>
brb lunch time
eebrah has joined #linux-sunxi
calris has joined #linux-sunxi
<oliv3r>
calris: how are you
<calris>
oliv3r: good thanks
<oliv3r>
calris: got a poc yet? was talking to hipboi this morning and he said it may be possible; only issue of course is that sram a and sram b aren't continues
<calris>
oliv3r: just read whitequark logs... SRAMB looks promising
<oliv3r>
i agree
<calris>
I have not had a chance to test
<oliv3r>
i was about to write some demo myself ;)
<oliv3r>
i guess we are hard-limited to the SRAM to load the actual binary in though
<calris>
But you know you can just rb.b and wb.b in u-boot
<oliv3r>
no i don't, i'm not that advanced :p
<calris>
No need for special code :-)
<oliv3r>
but you mean you can tell to compiler where binary is stored and where ram is stored?
<calris>
Yes
<calris>
We can use sramb as heap for malloc
<oliv3r>
but binnary data is limitted to sram A though; rihgt?
<calris>
Does not need to be contiguous with other sram
<calris>
BROM will load code into drama
<calris>
srama I mean
<oliv3r>
but only maximally using the size of sram a
<calris>
When the code (spl) executes, it will poke sramb
<oliv3r>
so the binary may never be larger then 64k
<calris>
No
<calris>
Only 20k for code
<oliv3r>
howcome?
<calris>
(Including read-only data like strings)
<calris>
Limitation of BROM
<calris>
It will only load 20k from mmc
<oliv3r>
and nand?
<calris>
I suppose so
<calris>
Ask hipboi
<calris>
:-)
<oliv3r>
:p
<oliv3r>
how about loading the ext4 or fat driver as 'plugin'?
<oliv3r>
so 20k is mmc init
<calris>
64k of malloc heap should be heaps (pardon the pun) for a file system driver like ext4
<calris>
I think the core code of ext4 is very small (particularly the read-only part)
<calris>
Its the malloc'd buffers that case
<calris>
Cause issues
<calris>
Hmmm....
<calris>
Your idea gives me an idea...
<calris>
Use a tiny SPL to load more than 20k
<calris>
But I think we can squeeze all we need into 20k anyway
<calris>
But first, fire up a U-Boot command line and try to touch SRAMB
* calris
does not have access to his board
* calris
is in bed
hansg has quit [Quit: Leaving]
<oliv3r>
calris: hmm
<oliv3r>
-rwxr-xr-x 1 oliver 1000 24576 Mar 24 16:39 boot0_sdcard.bin*
<oliv3r>
-rw-r--r-- 1 oliver 1000 376832 Mar 24 16:39 boot1_nand.bin
<oliv3r>
-rw-r--r-- 1 oliver 1000 376832 Mar 24 16:39 boot1_nand.bin
<oliv3r>
boot1_sdcard is a bit smaller
<calris>
Try mtesr
<oliv3r>
but in binary form it's allready 24k i have no clue how this will work :p But i don't know anything
<oliv3r>
mtesr? what's that
<oliv3r>
and what makes yo u think i have that :)
<calris>
mtest 0x20000 0x2fff
<oliv3r>
calris: i don't have a uart so can't do anything to u-boot :)
<calris>
From the u-boot command line
<calris>
Ah
<calris>
I do
<calris>
But o access to my board
<oliv3r>
ah, but that would be u-boot and not even spl :p but i can't yet :(
<oliv3r>
12:13 -!- calris [~AndChat21@d110-32-165-185.sbr801.nsw.optusnet.com.au] has joined #linux-sunxi
<oliv3r>
i guess :p
<oliv3r>
What I wonder, if we can also hijack SRAM C
<oliv3r>
it's mapped to Video Encoder by default, but SPL doesn't care about hte video encoder
<oliv3r>
so that's a nother ... i dunno, from my initial findings it could be 800 kiB but i highly doubt that :D
<oliv3r>
sram D is 1M (for use with USB, which i doubt now even more)
<oliv3r>
(USB-OTG)
<mnemoc>
your plan sounds pretty evil :p
<oliv3r>
lol
<oliv3r>
well, SRAM is used for various bits, but only when you have a full OS running
<oliv3r>
in SPL mode, it's all just sitting there unused
<oliv3r>
but lets see how far we get with SDRAM A and C
<mnemoc>
except with the USB chunk, you can experiment very easily using fel
ibrah has joined #linux-sunxi
<oliv3r>
i'll read into the fel tools
<mnemoc>
you basically inject a baremetal function and call it
<mnemoc>
then inject another and read the result from another address
<oliv3r>
function? or actual binary code?
<oliv3r>
and then execute it?
<mnemoc>
a C function
<oliv3r>
so you compile a C function, upload that to the core, it executes it and stores the result in some meory location
<mnemoc>
you get stack and all the wrapping
<mnemoc>
yes
<oliv3r>
I guess that's what SRAM D is used for 'usb'
<oliv3r>
oh that should make things inteserting to test things
<oliv3r>
that I could do with my tablet even!
<mnemoc>
you can see fel-pio.c as an example
<oliv3r>
SRAM A3 and A4 are using emac!
<oliv3r>
being used by *
<oliv3r>
i think there's a lot of sram available, if configured properly
<oliv3r>
what would BIST stand for?
<oliv3r>
Built in self test?
<mnemoc>
maybe
<oliv3r>
you map sram eithe rto a functionality, or to 'CPU/DMA' and 'CPU/BIST'
calris_ has quit [Ping timeout: 240 seconds]
<RaYmAn>
you can actually even boot a linux kernel through fel - though, apparently I'm the only one who has been successfully at getting that working, lol
<oliv3r>
:p
calris has joined #linux-sunxi
<oliv3r>
calris: i thoguht you where sleepin ;)
rz2k has joined #linux-sunxi
ibrah has quit [Ping timeout: 256 seconds]
<oliv3r>
oh i like adb-devprobe.sh is it still functional? though I doubt i have the module :(
arete74_ has quit [Ping timeout: 245 seconds]
arete74 has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
<oliv3r>
has anyhting done with the 'IMage Enhancement Processor'
<oliv3r>
or 'Security ID'? A 'one on chip 128-bit EFUS for secrity application'
<oliv3r>
it can be also be used as a root key or for other purpposes'
hipboi has joined #linux-sunxi
<oliv3r>
wb :)
<oliv3r>
I guess the CSI driver or the like could use the 'image enhancement processor'
<oliv3r>
and the 'Security ID' could be a device unique key
<oliv3r>
i guess we could use that to store some root encryption key; It basically sounds like 128bytes of eeprom, but using fuses instead of flash
shineworld has joined #linux-sunxi
vicenteH has quit [Ping timeout: 272 seconds]
<bsdfox_>
oliv3r, thanks, I asked him about it but he hasn't made much progress yet. I don't think he'd experienced my issues with i2c either
hipboi has quit [Ping timeout: 245 seconds]
<oliv3r>
bsdfox_: well mripard_ is the one that has the i2c mainlining thing on his name
<mripard_>
oliv3r: yes, as a work in progress
<oliv3r>
bsdfox_: have you tried a stock android kernel or something the like?
<oliv3r>
hi mripard_!
<mripard_>
hi :)
<oliv3r>
mripard_: is there anything super trivial you suggest I can invest some time in :)
<mripard_>
oliv3r: I know Turl has been working a bit on hno's watchdog driver, but didn't here from him on that driver for quite some time
<mripard_>
it's not very complicated, so I guess, if Turl's ok with this, to continue his effort
<oliv3r>
Turl moved on to the Security system :)
<mripard_>
hmmm, some words are missing
<mripard_>
yes, and the clocks :)
<oliv3r>
and .. and .. :p
<mripard_>
that's probably why I didn't much from him on that part :)
<oliv3r>
mripard_: do we have a use for the Security ID?
<mripard_>
I don't know, it's true that it's really simple
<oliv3r>
it look sextremly simple
<oliv3r>
and i can possibly see how it could used somehow
<oliv3r>
does the kernel have a framework for it?
<mripard_>
yes, it's just reading/writing to a register to get a value, and that's it
<mripard_>
I don't know if there's a framework
<mripard_>
it would probably be well fitted under the eprom one
<oliv3r>
i guess to the kernel it's nothing more then that, a dword eeprom
<mripard_>
but on another hand, do we really want the users to mess with the fuses?
<oliv3r>
i think it's flash memory implemented as fuses
<oliv3r>
I guess you could either store a serial code or encryption key there
<oliv3r>
which could be interesting from a users point of view
<mripard_>
I mean, fuses is most of the time used to store really important values, like crypto key, mac address, that shouldn't change
<oliv3r>
mac address!
<oliv3r>
A10 doesnt' store mac address
<oliv3r>
you either have to get external eeprom, or use script.bin
<mripard_>
or device tree ;)
<mripard_>
so, yes, my point is that you shouldn't really give access to the fuses to the users
<mripard_>
write access at least
<mripard_>
but yes, you can probably do that
<mripard_>
what hardware do you have access to ?
<oliv3r>
just a tablet, without emac :)
<mripard_>
A13 then?
<oliv3r>
but i think hipboi is sending me a cubieboard with adapter :)
<oliv3r>
A10!
<mripard_>
ok
<oliv3r>
i've uploaded a bunch of internal pics of http://linux-sunxi.org/BORA (it's not hte bora but the easiest to type link :)
<oliv3r>
mripard_: how about a read-only driver? maybe a kernel flag to enable write access? or a 3rd party 'run as root only' tool?
<mripard_>
hmmm, then, yes, you can either do something with the security id stuff, or like I was saying, the watchdog
<mripard_>
yes, a read-only driver would be fine
<oliv3r>
readonly-eeprom :p
<mripard_>
and the 3rd party root tool you're talking about is devmem :)
eebrah has quit [Ping timeout: 245 seconds]
<oliv3r>
mripard_: yep :p
<bsdfox_>
oliv3r, no I haven't tried android. Do you know of any tools I can use to play with i2c in android?
<oliv3r>
bsdfox_: root? :D
<oliv3r>
bsdfox_: in theory, you should be able to compile your binaries and try those on android just as well
<bsdfox_>
oliv3r, I've been using eeprog and python/smbus in linux
<oliv3r>
python, ouch
<bsdfox_>
I don't have an android dev environment setup but I might try it if I get desperate :)
<oliv3r>
bsdfox_: well our kernel should, in theory, be more feature rich :)
hipboi has joined #linux-sunxi
shineworld has quit [Quit: Leaving]
<oliv3r>
mripard_ what's the 'clean' way to obtain the memory address, hardcode it via a define in the driver/header, or use arch/arm/mach-sunxi/*
<mripard_>
neither
<mripard_>
get it from device tree
<mripard_>
at least for mainline
<wingrime>
mnemoc: what about commits, I wait you aprove to contine work after unify sun[45]
<mripard_>
if it's not for mainline, define a resource for it
<mripard_>
and you don't hardcode it anywhere in the driver
<mripard_>
use only relative addresses in your driver
<oliv3r>
mripard_: all memory base address are stored in devicetre?
<oliv3r>
i'll look at your tree to see
<oliv3r>
wingrime: mnemoc is very busy movin atm :(
<mripard_>
oliv3r: yes, and it used to be stored in the board files before that
<mripard_>
never in the kernel
<Turl>
mripard_: I've been procrastinating on the watchdog driver :) I just added basic dt glue
<mripard_>
s/kernel/driver/
<Turl>
but it needs to be moved to the new wdt framework before it can be mainlined
<Turl>
it shouldn't be hard at all, it just needs boilerplate trimming
<Turl>
oliv3r: if you want to do it, feel free, otherwise I'll do it when I get a chance
<oliv3r>
Turl: i'll keep my first one a small one :p i'll do the Security ID first :)
<mripard_>
oliv3r: it's only used for early init stuff, when the kernel doesn't have access to the DT yet
<oliv3r>
ah, ok
<mnemoc>
oliv3r: it's not really that I'm busy moving... I'm awfully busy with work, but otoh I need to move out of this apartment tomorrow and (as children don't help for these tasks) then packaging and preparing the other apartment takes all my not-$work$ time :<
<oliv3r>
mnemoc: so busy moving :p
<mnemoc>
:)
<Turl>
mnemoc: kids love unboxing stuff and finding old toys and things
<oliv3r>
do i break things horribly if i add mripard's gree as remote?
<mnemoc>
Turl: and not such a great thing to do *before* moving :|
<mnemoc>
but I did find my cubies :)
<Turl>
yeah, but they can help after
<Turl>
:)
<hipboi>
mnemoc, you find a better apartment?
<mripard_>
oliv3r: no, that will work fine
<mnemoc>
hipboi: i was kicked out of this one :| owner wants it for her daughter. but the other is new and cheaper, so it's a good deal
<oliv3r>
mripard_: good, cause i allready started adding and fetching :D
<oliv3r>
mnemoc: is it bigger and more energy efficient too? :)
<mnemoc>
smaller, but more energy efficient
<oliv3r>
You where frmo spain right?
<mnemoc>
i'm from chile, but I live in the north-west corner of spain (rainy part)
<oliv3r>
ah, that's why it's .cl :)
<mnemoc>
:)
<oliv3r>
barcelona!
<mnemoc>
oposite
<mnemoc>
coruña
<oliv3r>
oh duh
<oliv3r>
how's economy now? we no longer hear from spain anymore up here, it's not all 'cyprus'
<mripard_>
mnemoc: oh, so we're not that far away
<oliv3r>
mripard_: dts doesn't like spaces after comma's does it
<mnemoc>
mripard_: where are you? toulouse?
<mripard_>
mnemoc: indeed
<mripard_>
oliv3r: what are you refering to?
<mripard_>
it doesn't care
<mripard_>
except maybe for the compatible
<oliv3r>
mripard_: i see a lot of compatible = "cubietech,a10-cubieboard", "allwinner,sun4i-a10";
<oliv3r>
so it mst not like it :)
<oliv3r>
hometime :(
<wingrime>
unlike me I am in asia))
hipboi has quit [Quit: Leaving]
<mripard_>
oliv3r: this format is imposed by the spec iirc
<wingrime>
mripard: we have to make dts for every board ?
<mripard_>
yes
<mnemoc>
eventually we can convert all myboard.fex into myboard.dts
<wingrime>
dts support includes etc ?
<mnemoc>
once the format has settled
<mnemoc>
modeling*
<wingrime>
mnemoc: unfortunly same models can have differ hw
<mripard_>
wingrime: yes
<mripard_>
depending on what's under your "etc"
<mripard_>
but yes, dts supports include
<wingrime>
I mean make single dts for a10
<mripard_>
it would make no sense
<mripard_>
the device tree is about describing the hardware
<mripard_>
you'll never have the same hardware on every A10 devices
<wingrime>
I think it possible to make HW detection
<mnemoc>
my soc-detect branch is still a total failure :<
<mripard_>
wingrime: or you can just trust the device tree and get rid of all these weird logic of hardware detection
<wingrime>
mnemoc: mripatd witch information can't be autodetected
<wingrime>
?
<wingrime>
and more one, can't be forwarded using comandline
<mripard_>
the point is not wether it can be dectected or not
<mripard_>
it probably can
<mnemoc>
wingrime: mainline trusts 100% in the dts
<mripard_>
the point is that they don't want hardware detection
<wingrime>
mripard: we not need autodetection soc inner stuff
<wingrime>
I mean screen , ts , dram
<wingrime>
mripard: a agree with mainline that soc stuff didn't need autodetection
<wingrime>
mripard: I talking about soc inner sfuff
<mripard_>
the answer still applies
<mnemoc>
the dts tells exactly what soc runs on it. but you might still need to detect the revision of the soc for the workaround
<wingrime>
mnemoc: you know some HW errors in some revisons ?
<mripard_>
how can you detect the base address of your I2C controller, what controller it actually is, and what revision of that controller?
<mripard_>
detecting it is not realistic
<mnemoc>
wingrime: code shows several rev. based workarounds. on the clocks, on disp
<mnemoc>
btw, I'm only talking about soc/rev detection, not periferals or dram
<wingrime>
mripard: i talk about, that dts ONLY for inner SoC stuff not for ts, video, and I disagree that we need dts for every board at least in kernel tree
<mripard_>
well, disagree as much as you like, it's how it's done in mainline kernel
<mnemoc>
wingrime: due to pinmux boards can be very different
<mnemoc>
and that description goes in the .fex file in the legacy kernel and in the .dts in mainline
<mnemoc>
and the myboard.dts including the generic per-soc .... .dti?
<wingrime>
mnemoc: Thats becose that i talking about includes in dts
<mnemoc>
that only describes the SoC. you still need a dts to describe how that is wired
<mnemoc>
even if they are all very similar, they are different
<wingrime>
I just can't imagine how much board dts we have to support
<mnemoc>
wingrime: that's why we have the sunxi-boards repo
<mnemoc>
once the dts structure for mach-sunxi settles, it will be pretty simple to "compile" from .fex to .dts for all known boards
<mnemoc>
or directly from script.bin
<Turl>
wingrime: all the common soc stuff is on a common sunxi dts, device specific stuff goes in device dts; like for example lcd timing, refresh rate etc
<wingrime>
Turl: good
ganbold_ has quit [Remote host closed the connection]
<mnemoc>
techn_: hey! that says 11:35, not 15m ago :p
<techn_>
googlegroups shows it wrong time :p
<mnemoc>
techn_: so it's tested and really fixes the root=/dev/nandd issue?
<techn_>
I gave <tested> 30min ago
<techn_>
so yes.. it fixes nand{letter} rootfs issue
<techn_>
there is only bad choises to fix that properly :(
<mnemoc>
no 1/2 ?
<techn_>
hramrach: ?
<techn_>
hramrach: ^
paulk-desktop has quit [Quit: Ex-Chat]
<oliv3r>
techn_: what tree? can i cherry pick it to 3.0?
<techn_>
oliv3r: I think mnemoc already applied it
<techn_>
to every branch
<oliv3r>
mnemoc: how will toybox be better? It will only make GPL violation harder; and worse, they can close stuff without violating. its bad news imo
<mnemoc>
oliv3r: it's not a license thing. rob is far more commited with simplicity than the current maintainers of busybox
<mnemoc>
the last years busybox has been bloated a lot
<oliv3r>
maybe, but GPL >> BSD
<oliv3r>
busybox has been very proactivly defending GPL
* mnemoc
doesn't believe in the GPL
<mnemoc>
companies who want to violate it, will violate it and NOTHING will happen unless they actually WANT to honor it
<mnemoc>
and otoh is gives troubles to companies that care about honoring licenses
<mnemoc>
linksys dropped a huge linux-based project after they were attacked by GPL enforcers
<oliv3r>
if it weren't for the gpl; we'd be in a far worse situation
<mnemoc>
no one wins
<oliv3r>
if linux, the kernel, wasnt gpled;we'd have only closed kernels from many manufactures
<techn_>
things could change now that microsoft knows how to make money with linux :p
<oliv3r>
it would be worse
<oliv3r>
techn_: that won't last for long
<oliv3r>
you can use fear only for so long to make money
<mnemoc>
oliv3r: manufacturers releases GPL codes because they want. not because of the license
<oliv3r>
they got caught with their pants down a few times
<oliv3r>
mnemoc: because they want to honor the license
<oliv3r>
or have to
<mnemoc>
but that only affects the manufacturers that care
<oliv3r>
in china ;p
<oliv3r>
in the western world; they can be sued for ignoring it
<mnemoc>
everywhere
<oliv3r>
what did linksys drop?
<oliv3r>
causecisco is about to drop linksys, after the screwed it up
<mnemoc>
who won?
<oliv3r>
if you are thinking wrt54, they still sell the linux version; and a cheaper (less ram/flash) vxwork version
<mnemoc>
there is no win in using the legal way to get GPL honored
<mnemoc>
the best you can get is the product removed from the shelves
<mnemoc>
and maybe an small business bankroupted. but no sources will be released unless the company already wants to do it
<mnemoc>
a company that has them obviusly
<oliv3r>
if they violate it from the get go
<mnemoc>
because most of the business in the chain don't have such access or they are limited by an NDA
<techn_>
I dont understand what they lose if they release their hacks :/
<oliv3r>
but if said company starts with a product, and 'needs' the linux kernel (which isn't that odd) they know before hand they have to honor it
<techn_>
no one else customer will benefit of that
<techn_>
else *than
<mnemoc>
techn_: that's another story. i'm only saying that no one wins from GPL enforcement
<mnemoc>
techn_: it's most likely they fear to be sued by a patents lawyer AFTER releasing the sources
<oliv3r>
but GPL enforcement happens AFTER the fact of violation
<techn_>
mnemoc: same thing came in my mind.. almost everything has been software patented
<oliv3r>
if it where BSD, you could only cry and pray and hope
<oliv3r>
with gpl, you have a minor minor chance
<oliv3r>
that's the only difference
<oliv3r>
gpl gives hope
<mnemoc>
oliv3r: and troubles
<oliv3r>
the linux kernel and the GPL gave us leverage of having mor eopen source
<mnemoc>
oliv3r: license responsible companies can't use that software
<oliv3r>
without it, nobody would have cared
<oliv3r>
companies don't care
<oliv3r>
i see it at work daily
<mnemoc>
for them the GPL is irrelevant
<oliv3r>
100% closed microsoft shop
<oliv3r>
linux, free and libre is 'evil'
<oliv3r>
it must cost tons or it's not good
<mnemoc>
if the GPL is irrelevant for the violators, and annoying to those who care... the GPL is not a good thing
<mnemoc>
BSD/MIT ends up been the same for GPL violators, and useful to those who care
<oliv3r>
lets agree to dissagree then :p
<mnemoc>
openness can't be enforced. it only works from those who believe in it
<oliv3r>
that I agree with
<oliv3r>
but managers don't care nor agree iwth
<Turl>
many big names release gpl code because they have to
<oliv3r>
even if engineers do
<Turl>
otherwise they'd just sell you a blob
<oliv3r>
now they can wave the GPL card :p
<oliv3r>
Turl: exactly
<oliv3r>
maybe it makes only 1% differencein the final decision; that 1% helps
<oliv3r>
if android required apps in the app store to be open sourced (yes, it wouldn't have been so popular) people would have done so to 'join the android' train,now the yodn't have to so they don't care
<oliv3r>
obviously its a paradox, since if android was small, nobody would have cared
<mnemoc>
and not having GPL on userspace helped android to grow
<mnemoc>
because manufacturers wouldn't have adopted it if not
<oliv3r>
doesn't android have BB :p
<oliv3r>
absolutly true
<oliv3r>
proving your point
<mnemoc>
not by default
<oliv3r>
manufacutres don't care about being open
<mnemoc>
bb is added by manufacturers because google's bb replacement is a pile of crap
<Turl>
android ships toolbox, pretty unusable at times
<Dreadlish>
often not linked or without essential options
torindel has quit [Ping timeout: 255 seconds]
<oliv3r>
anyway oss is like being green :p
<oliv3r>
we all know its better, but nobody cares
torindel has joined #linux-sunxi
<mnemoc>
toybox (the thing that triggered this discussion) is the result of rob been heavily pissed off with the current BB maintainer bloating everything attitude, and rob getting losing a contract with cisco after GPL enforcers sued cisco for bb code mostly written by rob
<mnemoc>
but in my case I just like the cleanness and simplicity of toybox
<oliv3r>
they should have used their resources to clean up bb
<oliv3r>
but now it just feels like an anti-gpl move
<mnemoc>
more a anti-sfc move
<mnemoc>
sflc*
<oliv3r>
to me, RMS is my hero; while a little wacky at times, he's right :p
<oliv3r>
not sure if i agree with the SFC ways
shineworld has quit [Remote host closed the connection]
<Dave77>
100% closed microsoft shop is great.. I have drivers for all my hardware.. no driver for my USB TV in linux+many other hardware.. think i'll be waiting a long time for one to appear
<oliv3r>
Dave77: there's plenty going wrong there :)
<oliv3r>
Dave77: butthey buy there hardware matching their software
<oliv3r>
there'splenty of supported USB TV cards
<oliv3r>
but the situation is bad and hopefully at some point will improve
<mnemoc>
immediatelly after installing MS's OS from the retail DVDs you hardly have hardware support for anything
<mnemoc>
while the same with linux gives mostly functional everything, out of the box
rellla has quit [Remote host closed the connection]
<mnemoc>
but MS users seem to love all those driver hunting quests, and reboot at least once after installing each just to realize they installed the wrong one
<mnemoc>
sure the drivers exist, somewhere... but I personally wouldn't enjoy needing several hours just to install a functional OS
<libv>
where we suck is modularity
<libv>
either suspend works, or wifi works, or graphics works (good enough)
<libv>
never all together
<mnemoc>
:)
<libv>
kernel update, mesa update, x update? start quivering
<libv>
yet everyone sticks to this system, where the best part of a dozen of parts of a graphics driver stack are spread out, and usually embedded in their "infrastructure"
<libv>
need to update one part, too bad, you'll end up updating most of your system, and will take out suspend or wifi or both with it
<mnemoc>
sudo apt-get dist-upgrade
<libv>
mnemoc: for fixing a display that will not come up, or a bug that only happens in a specific game?
<libv>
what else will break in return?
<libv>
usually more than what gets fixed
<mnemoc>
:)
<mnemoc>
let's make another distro!
<mnemoc>
j/k
<libv>
like everyone who ever got frustrated with a particular issue
<libv>
people seem to like spending their time making new distributions, new build systems, or a new window manager or desktop environment
<libv>
heck, i even know someone who has been claiming that he is developing a proper version of openoffice for years
<mnemoc>
libv: sure the state of the linux desktop isn't perfect, and graphic, suspend and wifi drivers are a big pain. but the starting point of a freshing installed linux on a 1yo machine is much better than the starting point of the same hardware with retail windows
<libv>
nobody ever gets to the core issues and tackles them directly
<Turl>
Processor: Marvell New Armada Dual Core 1.2GHz SoC / Memory: 1GB RAM
<oliv3r>
hramrach's patch doesn't work
<oliv3r>
it won't omcpile
<oliv3r>
see ML
<libv>
mnemoc: ah, there you have it
torindel has quit [Ping timeout: 252 seconds]
<libv>
mnemoc: "retail windows"
<libv>
mnemoc: you get your hardware with all the necessary drivers preinstalled
<libv>
and those drivers remain useful for the life of the device
torindel has joined #linux-sunxi
<mnemoc>
libv: and if you don't make a DVD out of it immediatelly you'll lose those drivers for ever
<oliv3r>
libv: hah, my laptop works pretty good! suspend, wifi, graphics! but it's an aging T42
<libv>
mnemoc: i bought my gf a hp 63x with SLED 11 pre-installed
<libv>
and am one of the few people who kept sled installed on it
<oliv3r>
thogh I have been dissapointed with ubuntu; its becoming slower and slower :S
<libv>
why, because i know that 1km away, a lot of people are working hard on bringing up all bits and bobs on these machines
<libv>
and make damn sure that suspend, wifi and graphics works
<libv>
install an opensuse, and it will all go to shit
<Turl>
my laptop worked out of the box since day 0, suspend, wifi, all the things :P
<Turl>
acer ftw
<libv>
my intel graphics driver locks up from time to time
<libv>
hibernate only works half the time
<libv>
update, and things will be worse
<Turl>
the stable version of the intel stack never failed me
<libv>
Turl: oh, they have a stable version now?
<Turl>
and my suspend and hibernate have never been broken
<libv>
Turl: what did you have to do to install it?
<Turl>
libv: stable == what debian ships
<libv>
Turl: then your hw was old enough, but also not too old
<libv>
there is a very very small window there
<Turl>
libv: GM45
<oliv3r>
i'd install gentoo, but since I installed one of the early ssd's on it years ago (32gb only) and i wanted my laptop to 'always work' and have 'fluff' i choose mainstream distro; i'll see how gnome remix of ubuntu goes, and if its as bad as 12.04, i'll try something else :) one of the reason i've stuck with ubuntu for so long though, stupidly is I like the default colorscheme :p i hate feodra's
<libv>
and you have to have very popular hw too
<Turl>
HD4500MHD or sth like that
<Turl>
s/^HD//
<oliv3r>
i have radeon 9600; pentium-m
<oliv3r>
atheros wifi
<libv>
oliv3r: heh, how often has that broken in the meantime
<oliv3r>
hey, it's a thinkpad :p
<Turl>
intel wifi over here
<oliv3r>
libv: when i just got it, the early days of madwifi; wifi was horrible :p but that was 2004 mind you
<Turl>
as long as wifi isn't marvell you're pretty much covered :P
<libv>
our plan to let everything before r500 be the standard radeon driver, so that it could stabilize, was sacrificed for political forking games
<oliv3r>
yeah i know :(
<oliv3r>
sad sad
<oliv3r>
libv: gpl or bsd
<libv>
?
<libv>
in what context?
<oliv3r>
libv: do you prefer the GPL or the BSD license
<libv>
depends on the situation
<oliv3r>
getting hardware supported
<libv>
MIT or lgpl
<mnemoc>
:)
<libv>
libpci being gpl is plain stupid
<libv>
same thing for graphics drivers, but there the standard is mit
<oliv3r>
libv: and the kernel?
<oliv3r>
would it have been better if it where bsd or the like licensed?
<mnemoc>
oliv3r: don't cheat, the discussion was about userspace
<libv>
oliv3r: it's fine with the gpl
<Turl>
oliv3r: there's no need to ask that, go and look at your favorite BSD :P
<oliv3r>
mnemoc: was it? :p it was general; but went to busybox :)
<libv>
especially now with all the crap chinese breaching it all the time
<oliv3r>
Turl: osx? jk jk
<libv>
gpl gives us at least something
<libv>
even though most do not care
<oliv3r>
i think mnemoc said 'they don't careabout th elicense anyway'
<oliv3r>
mnemoc: to be fair; i was thinking kernel mostly
<libv>
but see how google is treating the gpl... they rather go and replace everything than touch that stuff
<mnemoc>
i said that no lawyer will get you the sources if the company doesn't want to provide them
<libv>
the whole chain is usually the problem
<oliv3r>
well to us,driver support should be most important; get specs/source for drivers so it can be supported
<libv>
you might be able to sue the guy selling you hw with gpled software on it...
<oliv3r>
userland-wise; we're good mostly
<libv>
and ARM might be able to push the SoC vendor to produce GPLed code
<libv>
but there are sometimes multiple steps between the SoC vendor and the guy selling the device
<libv>
good luck with that
<mnemoc>
imo it's ARM's *moral* obligation to be sured their licensees honour the GPL
<oliv3r>
mnemoc: building stage/sunxi-3.0 to see if that builds; will try stage/3.4 after
<oliv3r>
yes, true, but i think the hard cold turth is, they don't care
<mnemoc>
and they (indirectly) profit from the violation
<libv>
mnemoc: i think ARM, as a whole, only cares just enough not to be liable
<libv>
otherwise i wouldn't have so much spare time to talk about this sort of thing here :p
<oliv3r>
i agree, and if weren't for the GPL; they wouldn't have cared period ;0
<oliv3r>
but it's ranting to the choir :)
<libv>
oliv3r: good point
<mnemoc>
oliv3r: when we get leaks, we don't only get the GPL codes, but the whole android tree
<oliv3r>
but are those leaks because they care and want to be open
<oliv3r>
or because they try to be non-violating
<libv>
too bad they are leaks, but on the other hand, sunxi is in much much better shape than others
<oliv3r>
and leak too much
<mnemoc>
been GPL has zero relevance on what gets leaked and what's not
<mnemoc>
they just release those whole thing they got
<oliv3r>
but why dotheydothat
<mnemoc>
blobs, BSD/MIT sources, GPL sources, and GPL violating sources
<hramrach>
plat/mbr.h should exist after previous nand patches
<hramrach>
git status?
<oliv3r>
hramrach: on sunxi-3.0; it's all up to date
<oliv3r>
i'll cherrypick those 2 commits; cbf2b6041fe6498d81706b2e33c64f34af4de211 and 2a353cf8a5766a0b73c7796fa8602cccdcc9cf37 and see if that fixes it
* mnemoc
just realized he has CONFIG_SUNXI_NAND_COMPAT_DEV disabled in his test .config-s
<oliv3r>
git: 'format-commit' is not a git command. See 'git --help'.
<mnemoc>
format-patch
<mnemoc>
oliv3r: but that's after you fix it and commit it :)
<hramrach>
oliv3r: yes, you will need those
<hramrach>
but if you don't have it should not be broken ??
<oliv3r>
i dont' have plat/mbr, only sunxi/mbr
<oliv3r>
mnemoc: i'm in bed :p
<oliv3r>
to late and tired to learn all that :p i'll try to cherry-pick; but either those hashes fail to apply, so probablyneed more
<hramrach>
without cbf2b6041fe6498d81706b2e33c64f34af4de211 you should have working nand*
<oliv3r>
hramrach: but that's without then nandd fix?
<hramrach>
cbf2b604 or equivalent breaks the nand booting because it makes nanda-nando parition and the init code fails to find it
<mnemoc>
well... I suppose I now have to merge all nand patches on stage to non-stage
<hramrach>
but it's not on stage so it should work
torindel has quit [Ping timeout: 245 seconds]
<hramrach>
plus adding just the fix without the commits it fies up on non-stage breaks build, yes
<oliv3r>
i'll use the stage build :p
torindel has joined #linux-sunxi
calris_ has joined #linux-sunxi
<mnemoc>
so, anything against merging all nand code on stage to non-stage? :)
<hramrach>
I mean it's only in stage so the non-stage branches should work
<mnemoc>
hramrach: I merged your fix to non-stage
<hramrach>
yes, I see that
<mnemoc>
revert?
<oliv3r>
calris_: good morning
<hramrach>
yes, revert I geuss
<calris_>
'morning :)
<oliv3r>
well android won't run without those :p
<calris_>
oliv3r: I was asleep - just my tablet dropping in and out
<hramrach>
it's fix for something that's not supposed to be broken there
<calris_>
oliv3r: My bedroom is only just in WiFi range :)
<oliv3r>
calris_: just a quick note before i fall a sleep; check out sunxi-tools/fel we have some fel tools that lets us read/write sram via USB
<hramrach>
or if you can back out the commit - it's on top still
<calris_>
oliv3r: OK - but we can also use U-Boot (if you have a UART on board)