<Turl>
wens: no idea, I'll check next time I boot my board :p
<wens>
looking at ux500 as a reference (since the docs use it as an example)
<wens>
machine should be sunxi, family probably should be sun[4-8]i
<wens>
Cubieboard is definitely wrong. you should be describing the SoC here, not the board
<shineworld>
I'm a little bit upsed. I'm looking at cubian script.bin (fix to stability issue) and matching with mine till now used there a lot of different settings in [clock] section but overall in [dram_para] where my settings are often a -1 value.
<Turl>
wens: it's the machine field though
<Turl>
wens: i.MX reads the model from DT, that's what I did there
<Turl>
what else would you put otherwise?
<shineworld>
At this point I don't know how my target works ... and if cubian script is right or bad
<Turl>
shineworld: why don't you grab the one on sunxi-boards? :)
<shineworld>
there is a place with a enough fine script.bin for CB2 ? I mean for main IP like dram, clock, etc ?
<Turl>
shineworld: the sunxi-boards one is ok
<shineworld>
I'm using android sources from 1.09 sdk
<shineworld>
I've extract script.bin from latest img
<shineworld>
and I've used this script.bin to my SD android
<shineworld>
but is very different in "sensible" chip fields
<mripard_>
what filesystem are you using in your mmc partition?
<mripard_>
and what happens if you set "rw" in the kernel command line?
rainbyte has quit [Read error: Connection reset by peer]
diego_r has quit [Ping timeout: 264 seconds]
ssvb has joined #linux-sunxi
<wens>
could it be your fstab is empty, so the init scripts don't remount your root?
<libv>
it is empty
<libv>
but it works with sunxi-3.4
apo_ has quit [Ping timeout: 256 seconds]
diego_r has joined #linux-sunxi
apo_ has joined #linux-sunxi
<mripard_>
libv: how the filesystem are mounted by default are left to the filesystems apparently
<mripard_>
so maybe 1) the default changed since then 2) allwinner changed the default 3) you're mounting it as ext4 while you were mounting it as ext2/ext3 previously?
diego_r has quit [Ping timeout: 255 seconds]
apo_ has quit [Ping timeout: 250 seconds]
apo_ has joined #linux-sunxi
diego_r has joined #linux-sunxi
<ssvb>
libv: since the a13 soc package does not even have the pb19/pb20 pins (which provide uart on a10s), using different uart is not a matter of somebody's random choice, but is a strict necessity
apo__ has joined #linux-sunxi
<ssvb>
libv: the runtime detection, based on the sun5i variant, seems to work fine for this case, and I have been experimenting with it since a few days ago
diego_r has quit [Ping timeout: 260 seconds]
apo_ has quit [Ping timeout: 240 seconds]
<ssvb>
<mripard_> it doesn't cover the case where the accessible UART is not UART0 but some other
<ssvb>
<mripard_> like wens have experienced
<ssvb>
^ wens, what kind of problems have you experienced?
<mripard_>
on his A23 tablet, the only accessible UART is not the UART0, but another one, R_UART
sehraf has joined #linux-sunxi
<ssvb>
mripard_: is it the same problem, related to the soc package just having much less pins than its bigger brothers?
<ssvb>
mripard_: is it possible to do A23 identification at runtime?
<mripard_>
no
<mripard_>
the UART0 is available on the SoC
<mripard_>
just not routed on his board
<wens>
uart0 is only muxed with mmc0
<wens>
it's available via the breakout board, just not very useful if you want mmc for root
<wens>
ssvb: what runtime identification are you referring to?
<wens>
btw, a23 does not have security id / efuse
<ssvb>
wens: no VER_REG on A23 anymore?
<wens>
ssvb: uh... where is that?
<ssvb>
wens: it is documented in the A20 user manual
<wens>
ah yes
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
<wens>
it works
<ssvb>
is a23 the only sun8i device? without something like a13 vs. a10s variants of sun5i
<wens>
depends on whether we do a33 i guess
<wens>
great, the a80 kernel source is gone :(
bgal has joined #linux-sunxi
TomiK has joined #linux-sunxi
TomiK has quit [Client Quit]
<ssvb>
wens: but a33 is supposed to be pin compatible with a23, so if we can distinguish between a23 and a33, then everything else outside the soc should be nearly identical
<wens>
there's still the possibility allwinner sneaked in some fixes/tweaks to various IP blocks
<wens>
i don't suppose anyone forked the cubie8 repo before it disappeared?
<ssvb>
mripard_: wens mentioned limited muxing capabilities, so it does not look like somebody is making random choices about the selection of debugging uart on a23
<ssvb>
mripard_: everything seems to follow a predictable pattern
<wens>
ssvb: the stock boot0/kernel use uart0 for debug/console, which makes it a pain to work with
<wens>
the extra uart is then used by the arisc core for debug output
<ssvb>
wens: hmm, ok, it does indeed look a bit messed up
<ssvb>
wens: still the extra R_UART is used as an uart? we would have a problem if the same pins were used for a different non-uart purpose on some real devices
issue_ has quit [Remote host closed the connection]
deasy has joined #linux-sunxi
<ssvb>
wens: it would have been a bit more logical if the stock boot0/kernel used the less useful uart0 for the arisc core
hramrach has quit [Remote host closed the connection]
tomboy64 has quit [Write error: Connection reset by peer]
tomboy64 has joined #linux-sunxi
hramrach has joined #linux-sunxi
leviathanch2 has quit [Ping timeout: 272 seconds]
leviathanch2 has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
bgal has joined #linux-sunxi
jemk has quit [Ping timeout: 255 seconds]
morfoh_ is now known as morfoh
npcomp has quit [Ping timeout: 255 seconds]
npcomp has joined #linux-sunxi
hansg has joined #linux-sunxi
Zboonet has quit [Quit: Leaving]
Zboonet has joined #linux-sunxi
Skaag has quit [Read error: Connection reset by peer]
<mripard_>
ssvb: like I was saying, it's pretty fragile. It relies on the fact that every board have the UART wired in the same way for a given SoC, which is a very poor assumption
<mripard_>
all that to take care of a debugging case
<mripard_>
that will probably go away in the near future
<mripard_>
I really don't see how it's worth the trouble.
<Flashtek>
Q: I have cubietruck - can the WiFi support monitor mode ?
<ssvb>
mripard_: but UART does happen to be wired in the same way in practice
<ssvb>
mripard_: and in the near future I would like to see the non-volatile memory (a part of NAND) taken into use to store the board-specific settings
<mripard_>
can you prove that?
<mripard_>
and again
<mripard_>
there's *no* use-case
<ssvb>
mripard_: "prove" is a rather strong word, but have a look into boards.cfg in u-boot
<ssvb>
mripard_: *you* simply don't see the use-case yet, but I guess this is fixable
<mripard_>
then show me one
<mripard_>
just prove me I'm wrong :)
<ssvb>
mripard_: a single SD card image for all sunxi boards
<mripard_>
we're already there
<ssvb>
mripard_: how so?
<mripard_>
at least as far as mainline is concerned
<ssvb>
mripard_: please give me a download link to this image, I will write it to an SD card and try to boot on all my sunxi devices
<ssvb>
mripard_: do you mean mainline u-boot or what?
<mripard_>
kernel
<mripard_>
we were talking about the kernel all along
<ssvb>
kernel is a part of the whole system
<mripard_>
or at least, libv, wens and I were
<ssvb>
mripard_: well, the context of this discussion is a bit bigger than just the kernel
<mripard_>
and more specifically, we were talking about earlyprintk in the kernel
<ssvb>
mripard_: the kernel has it easy, because the DT data is provided from the outside
<mripard_>
not in the earlyprintk case :)
<ssvb>
ok :)
<mripard_>
you still have to provide what physical address (ie which UART) you're using
<mripard_>
and what triggered this discussion is that libv was willing to autodetect which UART you wanted
netlynx has quit [Quit: Leaving]
<ssvb>
mripard_: autodetect is potentially useful (if can be done in a reliable way) for both u-boot and kernel
<mripard_>
now, in the u-boot case, yep, it's something we should tend to, but I don't really see how we can achieve this
<mripard_>
mostly because there will always be some hardcoded infos
<mripard_>
such as what devices are enabled, and the muxing, mostly
<mripard_>
using the NAND might work, but then, you have to be sure that you have a NAND, and the timings/muxing of the NAND, so you're stuck with a chicken/egg issue
<mripard_>
but it's definitely something we should aim for
<Flashtek>
Like providing CDROM drivers on CD...
<ssvb>
mripard_: the BROM is somehow able to read from NAND? or I get it wrong?
<mripard_>
ah, true
<mripard_>
so the muxing and timing should be ok
<mripard_>
at least safe for the timings
<mripard_>
but still, it doesn't make a NAND chip magically appear if you don't have one :)
<ssvb>
yes, a bunch of olimex boards have 2K eeprom and no nand, some of them even have neither :)
<mripard_>
and do we have enough space in SRAM to be that clever?
<mripard_>
iirc, it was pretty tight already
xavia has quit [Ping timeout: 255 seconds]
hansg has quit [Quit: Leaving]
kuldeepdhaka has quit [Ping timeout: 272 seconds]
FreezingCold has quit [Ping timeout: 245 seconds]
<libv>
what i wanted was: sunxi auto, sunxi uart0, sunxi uart1 : give people the ability to not care, but give them the ability to care as well
<libv>
as this sounded like something cheap and easy
hramrach has quit [Remote host closed the connection]
<libv>
anyway, despite my mmc ro issue, where i currently do not know where to begin looking
<libv>
i am first going to add simplefb dt stuff to u-boot and see whether that works in all permutations
<mripard_>
you didn't replied to our question either :)
<mripard_>
what's the filesystem, did you try with rw in the command line
<libv>
mripard_: which, where?
<libv>
oh, ext4
<libv>
and no, i didn't do that, as i was cooking at the time
<libv>
and only sporadically came in, no chance to tet
hramrach has joined #linux-sunxi
<libv>
let me test that now though
<mripard_>
ok :)
<mripard_>
like I was saying, the default behaviour is apparently left to the filesystem, maybe it changed since 3.4
<mripard_>
or maybe you were mounting it as ext2/3, and now as ext4
<libv>
but something tells me that it will just work
<libv>
hrm, the fstab is just as empty
<libv>
but perhaps the fs is different
<libv>
although i tend to walk through the manual build howto quite concisely every time
<libv>
ah, no
<libv>
doesn't matter
xavia has joined #linux-sunxi
<libv>
it works on the same install just with a different boot.scr and uImage
<libv>
(and script.bin instead of dtb)
<mripard_>
yeah, but maybe the 3.4 has fs options that we don't have enabled
<libv>
that's true, but perhaps now is not the time to go dig that out
<libv>
first simplefb
<libv>
anyway, rw
kuldeepdhaka has joined #linux-sunxi
xenoxaos has quit [Ping timeout: 240 seconds]
<libv>
yup, happy with rw, as expectex
<libv>
expected even
<libv>
i will test this further when i try simplefb enabled uboot against sunxi-3.4
ygeorge has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
<ygeorge>
Hello guys. I need a fast tutor on LiveSuit image creation. Our company changed their SoC to Allwinner A20 in the last moment, and I'm responsible for getting the images done.
<ygeorge>
If somebody willing to spend a couple of hours with me on Skype explaining that: $150 over Paypal.
<Turl>
ygeorge: unfortunately not many here know how to do that
<Turl>
ygeorge: the BSP has support for making livesuit images though
<ygeorge>
yes, I know. I could perhaps figure out things myself, or even reverse an image and put my files instead. but the time is really pressing.
<Turl>
and if you're using an allwinner android sdk they have it on the instructions too
<ygeorge>
I need bare Linux + wifi/nand/ethernet
<ygeorge>
I'm technically skilled to create images, compile kernel, etc. We used Rockchip, but now it's necessary to learn all over again with Allwinner. so if somebody could explain these things step by step - I'd be willing to pay a regular consulting fee for that.
<ygeorge>
basically the idea is to create something that would be suitable for a production device, skipping all redundant partitions - just having something like one root Linux partition and misc partitions with the bootloader etc - and importantly, pack it into an image, which a factory guy could use to flash the final device.
<libv>
ygeorge: manual build howto on our wiki
<libv>
then next stage is to try our bsp
<libv>
oh, you want it on nand
<ygeorge>
yes, and in LiveSuit format. that's the problem
<ygeorge>
I succeeded in everything else.
<ygeorge>
well, PhoenixSuit
<ygeorge>
and your latest uboot with automatic uEnv/uImage picking from the first partition would be great to use, but it doesn't have NAND support in it.
<ygeorge>
so basically it's not impossible, I just have very little time, and well - zero motivation, being rather irritated by the fact that we had to change the platform in the last moment.
<ygeorge>
If there's somebody who could help - what's the hourly charge, I'd be willing to pay.
<libv>
i am not sure i know anyone who is geared up for that atm
<ygeorge>
current SDK that I have is all in Chinese, and the default packing stuff contains lots of redundant fex files. I'll probably need to read an online counterpart of a thick book to really get through it.
<ygeorge>
ok - never mind. another question then - your latest 3.4 kernel seems to have problems with I2S I/O. With a patch from some (Russian?) guy on the forum I was able to get the output working, but the input seems to be unsupported?
<Turl>
libv: the bsp doesn't support packing a20 images now that I look at it :/
<Turl>
ygeorge: what kind of problems?
ninolein has quit [Ping timeout: 272 seconds]
ninolein has joined #linux-sunxi
<ygeorge>
Turl: no I2S input at all?
<ygeorge>
Turl: and I2S output without additional patching seems to be broken on the linux-sunxi default git branch?
<Turl>
maybe the driver was never updated for A20
<Turl>
there's not many people using that
<ygeorge>
I see. any estimate on NAND support in the latest Uboot ?
Skaag has joined #linux-sunxi
<ygeorge>
(the one that replaces boot0, boot1 and doesn't need a separate partition)
<ygeorge>
apologies for being inquisitive, I know this is a community project, but I've been hard pressed to deliver something working, so the state of mind shows up.
Nazcafan has joined #linux-sunxi
<Turl>
ygeorge: heh :)
<Turl>
ygeorge: some chinese people worked on mtd for uboot and shipped it on their product
<Turl>
but it had a couple of bugs and it didn't advance much if at all after that
<ygeorge>
since it's GPL, one could take it back?
<ygeorge>
oh, I see
<mripard_>
Turl: I guess someone with a bit of motivation could use bbrezillon work to bring it to u-boot
<Turl>
ygeorge: sure, you can work on that if you want