<hno>
libv, it may be possible to prove different configurations of the blank parts. It's basically really # of chips & size. The DRAM controller do not magically know.
<libv>
hno: some C code could be written that can be natively built for several androids, which can extract the necessary information from allwinner register space
<libv>
hrm, just statically linked code should work already, if we can access /dev/mem
t0dbld1 has quit [Ping timeout: 276 seconds]
<slapin>
hno, I see funny output from my code for executiig NAND commands - it runs OK READ0 (0x00), latches address w/o problems, then it outputs RNDOUT command (0x05) and immediately deselects NAND w/o transferring any parameters. Any ideas?
<slapin>
hno: I see it on LA crystal-clear, will upload it into the same place as it saves to its disk.
<hno>
libv, /dev/mem do not seem to work for some reason.
<hno>
slapin, sorry, quite at loss there. But will wire up my logic analyser and play around a little. But probably not tonight, head still very muddy.
stefanro1 has joined #arm-netbook
<libv>
set up of dram is done by the common allwinner code of uboot, right?
<hno>
dram setup is done by boot0 or u-boot SPL.
<hno>
probing of the missing parameters is done by livesuit when flashing the board.
stefanro has quit [Ping timeout: 244 seconds]
<hno>
interestingly it misdetects 8-bit chips as 16-bit.
<hno>
and still works fine.
Regressor has joined #arm-netbook
Regressor has quit [Client Quit]
hg_5 has quit [Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204]]
<libv>
hno: i am wondering, why do the script.bins not come with those bits of info?
RITRedbeard has joined #arm-netbook
<libv>
hno: i saw some ram sizing code in uboot
<libv>
is that code unreliable?
<libv>
does each device come with an especially hacked uboot?
<slapin>
hno: can you look at files at http://ossfans.org/nand/ ? there is dumps from original NAND u-boot
<slapin>
hno: I processed LA output (excluding repetitive data) and got this for our code: http://ossfans.org/nand/sunxi-u-boot-nand-dump.txt (please ignore crap at the end, I get this file from working LA, which is slow in storing info)
<slapin>
hno: original files are not processed, since I was still learning to use LA.
<hno>
slapin, which command are you trying to execute?
<slapin>
nand dump 0
<slapin>
original u-boot doesn't allow to execute command and just boots
<hno>
you can replace original u-boot.
<hno>
or boot lichhe-dev from SD.
<hno>
or JTAG, or loady.
<slapin>
hno: I still can't run graphical interface here
<hno>
?
<slapin>
hno: to replace u-boot
<slapin>
hno: I mean I don't have anything but serial port to device
<hno>
that's fine. loady works fine for loading a new version of u-boot to ram and execute.
<hno>
loady 0x4a000000
<hno>
[upload using y-modem]
<hno>
go 0x4a000000
<slapin>
hno: will it work from u-boot-sunxi? any wgettable url?
<hno>
loady is enabled in sunxi-current. Even sunxi I think.
<hno>
lichee-dev is in linux-sunxi u-boot repository.
<slapin>
hno: any pre-built u-boot binary somewhere?
<hno>
not of lichee-dev I think. And you probably want to change it to not read env from nand.
<hno>
One moment and I'll prepare a suitable nandtrace binary for you.
<slapin>
hno: should it immediately start reading NAND?
<hno>
Yes, more or less.
L84Supper has quit [Ping timeout: 245 seconds]
drachensun has joined #arm-netbook
<slapin>
so I jut setup my LA before running go 0x4a000000
<slapin>
hno: ?
<hno>
yes
IIV has joined #arm-netbook
<slapin>
hno: it is a problem to synchronize LA :( trigger runs too early because pins jump :(
merbzt has quit [Ping timeout: 246 seconds]
<hno>
you can wait until everything settled and issue comands to read.
<hno>
it will chat for a while due to the tracing, but will get to the bootwait prompt in a little while
<slapin>
hno: yeah, this way I was able to catch only reset command :( is it possible to make it just get into the prompt on boot, so I could use some nand command? (After prompt all pins will be in proper state and I can trigger on CE -> 0
<hno>
slapin, sure, just press enter.
<slapin>
hno: I won't it boots immediately like original u-boot, without delay
<hno>
no
<slapin>
hno: this is what I see on screen
L84Supper has joined #arm-netbook
<slapin>
hno: as I see again, only resets recoreded :(
<hno>
maybe the trace chatter delays too much? Stop at the prompt and use nand read
<hno>
reads up to 0x2000 in size is a single NAND operation on my device.
<slapin>
hno: it ignores keypresses, just outputs lots of NFC access
<hno>
Works for me.
<hno>
NFC READ NFC_REG_CTL=4301
<hno>
NFC WRITE NFC_REG_CTL=301
<hno>
sun4i#
<hno>
Hit any key to stop autoboot: 0
<slapin>
hno: probably your environment contains no bootdelay 0
<hno>
I just press enter while the initial spew.
<hno>
There is no environment in this u-boot build.
<slapin>
hno: hmmmmm
<hno>
should probably take out boot command as well..
<slapin>
hno: I think so, or just set bootdelay to something like -1 or so, so it won't boot
<slapin>
I don't remember which one, though...
<hno>
gah, this is a seriously fucked up u-boot config.
<hno>
slapin, I don't see a partition table in your dum. Seem to have some serious ECC errors. PHY_PageReadSpare : too much ecc err,bank 0 block 0,page 7f for example.
* hno
also crawls to bed. Good night.
<slapin>
hno: there is partition table, I just missed it in log.
<slapin>
hno: it just reads something infinitely. original u-boot boots without problems.
<rz2k>
you can easily have cheaper stuff and edited script.bin
<rz2k>
check if you have same ones and you can try to up the freq.
<rz2k>
my a13-tab has ddr3s from manufacturer that I didnt even know existed, it has lower clocks than usual too.
ibrah has joined #arm-netbook
<ssvb>
rz2k: yep, already did that, I was just curious about what is considered to be within allowed specs
<ssvb>
btw, script.bin appears to have no effect on dram clock frequency, it was still 360MHz according to the value in DRAM_CCM_SDRAM_PLL_REG (obtained on the running system via "devmem2 0x1c20020") and benchmarks showed poor results
<hno>
slapin, the trace seems to be missing the beginning (command & address). Starts with a long data read.
<hno>
raw trace seems corrupted @sample 9581->
grimes99 has joined #arm-netbook
cheng has joined #arm-netbook
tuliom has joined #arm-netbook
rz2k has quit []
grimes99 has quit []
merbzt has joined #arm-netbook
<hno>
slapin, there seems to be some noise in the traces. For example samle 1511, 2594, 6019, and some others. Do you have some flourecant lights or other noticeable radio emission nearby?
<libv>
gimli: are you sure that you are not building uboot here?
<gimli>
i'm sure.
<libv>
since you are using the defconfig, you can do a make mrproper on the kernel tree
<gimli>
even on a clean git clone ?
<libv>
hrm, ok
<libv>
and you have built uboot succesfully with this toolchain?
Curtman has joined #arm-netbook
<gimli>
didn't build u-boot jet. but another kernel for another arm platform
<libv>
and do not have any CFLAGS set?
<gimli>
so i asume the toolchain is fine
<libv>
hno: if you are around and have some time, can you help Curtman fill in the blanks in the dram.c for his uboot?
<libv>
try uboot, and see whether the problem is with the code, or with your setup or toolchain
<Curtman>
libv, I don't think its necessary. I notice on the stock u-boot it only shows 512MB, not 1GB. It seems to load the kernel just fine too, and the kernel inits 1GB.
<gimli>
so you tell me even if i compiled another kernel sucessfull my toolchain is not working ?
<libv>
Curtman: nice!
<libv>
gimli: am i telling you what is wrong, or am i suggesting possible routes for eliminating possible problems?
<hno>
Curtman, are you booting from NAND?
<Curtman>
libv, Right now it's just hanging after the serial port initializes for some reason. I was trying to get an ubuntu root image to try but http://rhombus-tech.net is still down. Any mirrors that you know of?
<libv>
gimli: first would require clearvoyancy
<Curtman>
hno, Nope, just from SD so far.
<libv>
gimli: so try it.
<hno>
Curtman, what device do you have?
<Curtman>
hno, Mele A3700
<libv>
gimli: i would find it very strange if there would suddenly be an issue with the kernel build system on even our hairy kernel
<libv>
Curtman: ah, serial init... try a full reset
<libv>
Curtman: reboots hang there for me on both my devices
<libv>
Curtman: needs a cold start
<libv>
very painful issue, but noone has taken the time to debug it
<Curtman>
I'm doing a cold boot though. Once its hung like that, I can't reset without yanking the power cord.
itamarjp has joined #arm-netbook
itamarjp has quit [Client Quit]
<libv>
:(
itamarjp has joined #arm-netbook
<hno>
Curtman, not even holding power button for ~10 sec?
<gimli>
libv: sorry to blabe the kernel sources, how could i
<Curtman>
libv, I'm blaming this Gentoo root for now. I'd like to get a rootfs that works on the A1000/2000 to try. but http://rhombus-tech.net is still down.
<libv>
Curtman: initializing the serial port and hanging is a kernel issue afaik
<Curtman>
Which branch of the linux git sources should I be working on do you think? I'm on the 3.0 branch as described in the docs.
<Curtman>
I don't see anything in the output about even mounting the rootfs either. It's possible it's just not getting that far, and borks during kernel init.
<libv>
gimli: there are many issues with our kernel, build time el/hf confusion has not occured so far
<hno>
Curtman, sounds as if something is very messed up.
<hno>
you said you boot from SD. Which board did you build u-boot for?
<Curtman>
hno, Yeah. It's to be expected. It'll take time to sort, but I've got most of today to play with it.
<hno>
Quite likely it's very similar to Cubieboard.
<Curtman>
All I should need it to do is load the kernel from SD, and let linux init the hardware though. At least that's how things have been on other ARM platforms I've tinkered with.
<hno>
u-boot configures the DRAM and a bunch of clocks the kernel expects.
<Curtman>
All that seems to happen in boot1 based on my script.bin though, no?
<hno>
Not i you are booting from SD with u-boot SPL.
<hno>
and no, it's not based on script.bin. It's based on what is in the header of boot0 primarily, and some parts initialized from boot1 file header.
<hno>
if usign allwinner bootloader.
<hno>
how did you make your bootable SD card?
<Curtman>
I followed the instructions. To get script.bin I used 'adb connect 192.168.1.224' then 'adb shell'. Then I did 'dd if=/dev/block/nanda of=/mnt/tmp/nanda.img', and I loop-mounted that on my desktop.
<hno>
clearly wrong, but thats how allwinner detects that dram config. Should be io_width: 8, density: 2048
tinti has joined #arm-netbook
tinti has quit [Read error: Connection reset by peer]
<libv>
hno: so we can get the actual dram parameters from somewhere else than the .fex?
<libv>
if so, tool and please document :)
<rz2k>
I believe you can grab dram data from boot1 header, but that will need NAND support from our spl
<ssvb>
libv: maybe directly read from the HW regs? At least getting the memory clock frequency is easy: "devmem2 0x1c20020", extract bits 8-13 from the returned value and multiply by 24
<rz2k>
ssvb: g2d is in kernel and should work, there is directfb for it, but not sure if it works, nobody had time yet to investigate there.
<ssvb>
rz2k: I figured this much :) just none of my google search requests for "premultiplied allwinner a10 g2d" returned anything
<ssvb>
I guess I just need to try to test it myself
<ssvb>
but if pixel alpha is not premultiplied, then it would make g2d a lot less useful for implementing xrender extension
<ssvb>
Turl: actually the g2d code on the kernel side looks more interesting
<ssvb>
and the block diagram from the datasheet seems to provide a rather good overview
<Turl>
kernel code implements about the same, blit, stretch blit, fill rectangle and a mem allocator
<ssvb>
well, the directfb code looks like a userland wrapper for the real implementation which does actual work on the kernel side
<ssvb>
IMHO the right thing to do is to try using g2d for some basic operations with the memory chunks inside framebuffer and check the results
<ssvb>
first testing whether the per pixel alpha is treated as premultiplied or not
jquip has joined #arm-netbook
<ssvb>
and next get some estimate for the expected performance
<ssvb>
as for the real DDX driver for x11, everyone and their dog implements them :)
MindBeat has quit [Ping timeout: 244 seconds]
focus_it has joined #arm-netbook
MindBeat has joined #arm-netbook
<focus_it>
Suggest some improvement for A10 sunxi linux
<focus_it>
1. if .fex text file is found and no .bin file, then activate fex2bin and create the .bin file
<Turl>
ssvb: well it was quite a welcomed improvement on my directfb testing ("hardware" vs "no-hardware" config)
<focus_it>
2. if meet several evb.bin files, put option on screen to reboot with a different evb.bin file or continue, and then reboot if new evb.bin selected
<Turl>
focus_it: .bin is loaded by uboot to memory and parsed by the kernel on early boot, you cannot expect a userspace tool to be run then
<Turl>
ssvb: do you have a cubieboard by any chance?
<ssvb>
I mean "your directfb testing"
<ssvb>
Mele A2000 here
<Turl>
ssvb: that means I downloaded directfb 1.4, patched with that, and ran with and without hw support, and it was considerably faster where hardware could do its thing :)
<Turl>
(drawing rectangles for example)
<focus_it>
Turl: then suggest uboot is adjusted to write a default .bin that can be picked up and modified by the user. When they 'ring' for support, somewhere in there will be a note to say the .bin was a default generated file.
<focus_it>
so all the work goes into uboot to extend it to make it more friendly
<ssvb>
Turl: ok, I just had a hope that there might be an archived message in the mailing list or a blog with a bit more details
<Turl>
ssvb: if you want to test it, building directfb is not hard
<Turl>
ssvb: and if you then build the examples, there's one named "df_dok" iirc which is a benchmark of all these operations
<ssvb>
Turl: thanks, good to know
<Turl>
ssvb: then on /etc/directfbrc you can write (no-)hardware to control the accel
<Turl>
focus_it: why do you think there will be no .bin btw?
<Turl>
focus_it: I mean, people have to flash uboot and make the partitions already
<focus_it>
As a newbie, I found a lot of hassle in trying to explain to myself how and why the .fex has to be changed to accommodate when going from MK802 to a tablet
<j1nx>
evening guys
<j1nx>
anybody cared to read my mail on the ML this afternoon?
<j1nx>
Just can't get the kernel to boot anymore.
<focus_it>
In the end I find I only need to change .fex two lines to make MK802 Lubuntu distro work on A10 tablet with LCD
<j1nx>
But I do left for a good couple of weeks so might missed some development
<focus_it>
So then it got me thinking, if I remove the .bin file and left it the fex file, then the system should be able to parse it and boot.
<focus_it>
if it can't boot, it could write a note somewhere why it can't boot.
<focus_it>
alternatively it can generate its own .bin file that it knows it can boot with and at least boot
<focus_it>
That is normal way in Linux to recover from damage
<Turl>
focus_it: script.bin is going to day on the future
<Turl>
and as I said, if you only have a fex, you'd have to parse it on uboot, but doesn't seem worth the hassle imo
<Turl>
j1nx: yeah I saw it, weird :| are you building the tip of sunxi-3.0?
<focus_it>
That be fine. Just the new system can be thought out to cope with distros that hop from one ARM system to another
<j1nx>
Turl: Yes. Nightlu does not boot as well
<Turl>
j1nx: can you bisect?
<j1nx>
Disabled "PM idle support", same crap
<j1nx>
bisect?
<Turl>
git bisect
<focus_it>
Think of what might happen when a distro made for an MK802 with HDMI is transferred to A10 tablet. The display has to change to LCD, the input method has to change to accommodate resistive/capacitive sensors, the wifi module may have to be detected as that would change and so on
<Turl>
yeah, that's going to happen with device trees
<j1nx>
Turl: how does it work
<Turl>
nowadays you need to replace script.bin and flash your device's uboot
<focus_it>
Users can only edit text files, so its best if the fex to bin functionality is built into uboot or somewhere else so that users don't have to fret over it.
<focus_it>
So the way the fex to bin issue would get resolved is that uboot will look for .bin and if not found it will activate fex2bin and take the info from fex and reboot with new .bin; if no .fex then put in default .bin specific for that embedded device - at least it can then boot in a known way, even if it is wrong. Looking at copy of .bin will let support know what might have happened.
<Turl>
j1nx: it doesn't sound like a kernel failure though, maybe your PSU went bad
<Turl>
j1nx: can you try a known working build and see if it works?
<j1nx>
hmm ok, started the bisect, told the one I am on is bad, but how do I know which was still good?
Mehhh has quit [Ping timeout: 245 seconds]
<Turl>
j1nx: well you need to figure that out first :)
<j1nx>
oh crap ;)
<Turl>
what were you running on your device earlier that worked?
<j1nx>
nothing
<j1nx>
been out of the loop for the last 3 months
<j1nx>
had some stuff to do in Africa
<Turl>
j1nx: just so we don't do unnecesary stuff
<Turl>
j1nx: do you have another PSU to try with?
<j1nx>
hmm, need to check
<focus_it>
I'm doing all the testing on uSD card - which means I don't need to flash devices, and still experiment.
<hno>
slapin, got my logic analyser connected, and the NAND controller is a bit automagic.
<hno>
but need to slow down the nand clock a bit or it's unstable with all the wires connected.
MindBeat has quit [Ping timeout: 255 seconds]
<hno>
mw.l 1c20080 8204000f
<hno>
works fine.
MindBeat has joined #arm-netbook
<hno>
you may want to slow it down much further to minimize the buzy gaps in the trace.
<hno>
err, that clock is not valid. mw.l 1c20080 8203000f
jquip has quit [Quit: jquip]
<j1nx>
Turl: Just downloaded one of the many images for mele, justed booted fine ?
<j1nx>
Don't think it is the PSU
<techn>
j1nx: Your sd card is broken?
<Turl>
ok then, get bisecting :P
<techn>
** Bad ext2 partition or disk - mmc 0:1 **
<hg_5>
does anyone have nexus 7?
pwhalen has quit [Quit: Leaving]
<j1nx>
techn: same card ;)
<j1nx>
Turl: Went back a couple of days, ad4e3898e1ada55defc153c7e4e95973c1973413
<j1nx>
see if that one boots
ibrah has joined #arm-netbook
jquip has joined #arm-netbook
<jquip>
erm.. hey guys... so I did something stupid... I have an arm netbook, the 'H6' as said by cnxsoft... so .. I tried Guillaume's method of partitioning the nand memory.. it looks all nice.. he's got it working on 32 mele nodes ya know.. (http://guillaumeplayground.net/pimp-my-mele/)... So before you go there reading ... basically I have removed all the nand partitions... and am getting the kernel on nanda() and rootfs on nandb... and am now struggling
<jquip>
in the dark because no usb to ttl.. Machine simply flickers with screen on start, and then nothin... it's a uboot thing
rellla has joined #arm-netbook
<jquip>
have tried amery's default lichee uboot.bin, among others..
Quarx has quit []
rellla has quit [Client Quit]
<bsdfox>
get usb to ttl
pwhalen has joined #arm-netbook
MindBeat has quit [Ping timeout: 252 seconds]
rellla has joined #arm-netbook
MindBeat has joined #arm-netbook
<jquip>
bsdfox: isn't there any other way? one can pipe that log to a file and then read it off after the boot process
<jquip>
I mean can't redirect log output from serial into a file ??
<jquip>
s/can't/can't we/
<ibot>
jquip meant: I mean can't we redirect log output from serial into a file ??
<jquip>
hno: your kind attention please?
<rz2k>
jquip: you are working with hardware, you need debug connectivity like UART or JTAG.
<rz2k>
UART is basic one, working after basic initializations. JTAG works all the time, but you dont need it if you dont know how to use it.
<jquip>
rz2k: well the board is fine... linux on SD boots well..
<jquip>
so i wasn't expecting any bugs from hw..
<hg_5>
hi which one will be better nexus 10 or samsung galaxy note 10.1 ?
<rz2k>
you still need to get the logs about whats happening when you boot from NAND. without them you will be blind in solving your problem.
<jquip>
yeahhh... getting that usb to ttl will take some time... I didn't want to wait till then..
ibrah has quit [Ping timeout: 248 seconds]
<jquip>
hg_5 : this channel is for linux development on arm...
<jquip>
and EOMA :)
<RaYmAn>
hg_5: n10 is better spec'ed, note has pen input. but yeah, not exactly a netbook ;)
ibrah has joined #arm-netbook
ibrah has quit [Read error: Connection reset by peer]
<hno>
jquip, what?
<jquip>
hno: Can we redirect uboot log output into a file instead of serial?? no usb-to-ttl on me... and I wanted to get those logs
<hno>
jquip, no
<hno>
there is no file.
<slapin>
hno: hi
<slapin>
hno: have you managed to get dumps?
<hno>
jquip, you can use netconsole if you have an ethernet interface.
<hno>
slapin, yes.
<hno>
slapin, have not got around to decode them yet. But looks nice in SUMP, but all up/down diagrams..
<jquip>
hno: Doh! yes I do have an ethernet interface...
<hno>
jquip, but you pretty much need u-boot console to configure it in the first place.
<jquip>
haha stalemate!
<slapin>
hno: of both our code and allwinner's?
<slapin>
hno: any ascii dumps to look at? haw did you set up triggers?
<hno>
slapin, only tried allwinners yet.
<jquip>
hno: I guess I will have to wait for it to arrive then.. Much Thanks..
<hno>
slapin, I trigger on WE=0 to start the capture, sufficient. It's compressed so fits reasonably well in the trace buffer. Obviously not the whole page read, but command, read prepare delay, and first two "sectors" I think.
<hno>
The controller is odd.
<hno>
But I absolutely need to slow down the NAND bus considerably or there is errors with all the cables wired.
<hno>
easibly visible in the ECC counters.
<slapin>
hno: set dividers to maximum?
<hno>
Yes.
<slapin>
hno: set AHB speed to minimum?
<hno>
Probably could go much lower by also switching to 24M clock.
<hno>
AHB should not be changed. It's an internal logic bus between processor and NAND controller.
<slapin>
hno: dunno if controller will like so slow speeds...
<hno>
and many other
<hno>
slapin, why?
<hno>
it's the nand controller clock, and the nand controller clocks the nand bus.
ibrah has joined #arm-netbook
<hno>
slapin, works fine at 24M / 8 / 16
grimes99 has joined #arm-netbook
<slapin>
hno: have you some mw.l instructions to set this up? It seems I was able to capture data in 96 ns sample rate, will upload now...
<slapin>
as soon as it manages to write 5MB file
<slapin>
everything in this LA is cool and fast, except file operations.
ibrah has quit [Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032]]
<focus_it>
Another idea to improve the Linux experience
<focus_it>
1. When booting Linux, make it high priority to throw up a splash screen first before much else for HDMI and LCD based systems
<focus_it>
2. If previously successfully booted on HDMI or LCD, then somehow save the configuration so that it on next boot it uses that same code to more rapidly get the consumer display working before anything else
<focus_it>
Just ideas - I'm taking an MK802 image and transferred it to tablet - and I notice a big lag before screen does something
<slapin>
focus_it: this all is possible, just be there, when they design new device...
<focus_it>
In today's consumer world where displays are top priority, its worth having a fast splash before anything else
<slapin>
focus_it: u-boot supports it, just add AW's HDMI/LCD support there.
gzamboni has joined #arm-netbook
<focus_it>
slapin: I be designing new device - I intend to be fully there even if right now my Linux on ebdedded is weak
<focus_it>
slapin: thank you, I note it down for future reference! :-)
<slapin>
as for later - it is better for device to sleep rather than reboot.
<hno>
slapin, mw.l 1c20080 8003000f
<focus_it>
Yes I fully agree, ultra low power sleep is a lot better than reboot
<slapin>
hno: will it set appropriate clock source?
<rz2k>
I believe it had some issues with LCD with our kernel, but not sure.
<rm>
skip the whole "Item specifics" section on Aliexpress, always
<rm>
it's filled with nonsense almost all the time
<rm>
see the table in the description down below instead
<focus_it>
On another tablet I see Operating System: Win CE, OS: Android :-)
lerc has quit [Read error: Connection reset by peer]
lerc has joined #arm-netbook
lerc has quit [Client Quit]
lerc has joined #arm-netbook
arnd_ has quit [Ping timeout: 244 seconds]
sv has quit [Quit: Sv]
<rm>
it will also sometimes tell you that the A10 has an AMD GPU inside
gimli has quit [Quit: Verlassend]
sv has joined #arm-netbook
madmalkav has quit [Quit: Leaving]
<focus_it>
is there a Linux alternative to livesuit to flash firmware to NAND?
j1nx has quit [Quit: He who laughs last, thinks slowest]
<rz2k>
focus_it: no, write one.
<rz2k>
rm: stop confusing noobs with your debian manual :p
<focus_it>
rz2k: I am capable, does it need cooperation of uboot?
<rz2k>
we already have FEL mode bootloader, talk with RaYmAn, he did something around that
tzafrir has quit [Ping timeout: 260 seconds]
<focus_it>
rz2k: any links? I know linux and embedded well, but not linux on embedded well enough, though I learn every day to solve that problem :-)
<rz2k>
basically livesuit loads up eFex flasher into the memory using FEL and executes it. eFex initializes RAM, USB and NAND, then just waits for connection and data. eFex uses 1:1 usb stack/gadgets as our kernel, debug messages are same.
<rz2k>
you can even load kernel using FEL, but I believe that will need some DDR initialization.
<L84Supper>
the new Nintendo Wii U has PPC + AMD Radeon, will we ever see ARM + Radeon?
<L84Supper>
magic 8-ball says "highly unlikely"
<xenoxaos>
depends....if some high $ company is working on an arm chip....needs to add in some video thing....and they have a deal with amd already...then they might
<Turl>
L84Supper: well, AMD is making ARM64 Opterons.. :)
<rm>
all it would take is some ARM board having a PCI-E (even x1) slot
<L84Supper>
it would be nice, I hope AMD can turn themselves around
<L84Supper>
libv mentioned some comment from AMD a while back about Radeon not getting ARM support
<L84Supper>
was a matter of principal or similar
<Curtman>
hno, Here's what my boot looks like with u-boot updated.. It still seems to hang at serial port init. http://pastebin.com/aMcRhXUs
<libv>
atombios is heavily tied to the fglrx and windows drivers which are now the same codebase
<L84Supper>
I talked to the radeon devs about this a few years ago, a port of Atom BIOS and dealing with unified memory were the two hurdles
<libv>
they are made bug compatible
<libv>
in any case, we have mali t604
<libv>
which is much more suited for this space, and which will scale up a bit
<L84Supper>
2W are soc with 100W GPU? :)
<L84Supper>
are/arm
<libv>
will never happen, cpu could never shift data fast enough for the gpu to use
<L84Supper>
ARM as coprocessor
<libv>
another reason why ati hw on arm is not likely: what deal with amd and qualcomm make a 4 years ago?
<specing>
ATI on ARM is a reality: Adreno
<L84Supper>
at the time it was pretty easy to saturate the PCIe on the Marvell soc's
<libv>
specing: which is owned to some large extent by qualcomm
<specing>
yes
<L84Supper>
the Imageon
<libv>
i am sure that they worked out some deal where amd will not be competing in markets that are valid for qualcomm
<libv>
and of course, qualcomm will be scaling up too
<specing>
One day AMD will buy qualcomm
<specing>
one day...
<libv>
the reverse is more realistic
<L84Supper>
the only way AMD could have made worse decisions in the past 5 years would have been if they ...... oh i give up
<libv>
L84Supper: it started with killing the geode
<libv>
one year before intel made the market with atom
<specing>
geode ;) have one
<L84Supper>
such a bad string of bad deals, it's almost like Intel made a deal with the board
<libv>
then they bought a crappy almost bankrupt canadian company
<libv>
for far far far too much cash
<L84Supper>
AMD made an offer to buy nvidia back then
<libv>
and they still haven't integrated ati properly
<libv>
the inverse is more likely true
<L84Supper>
the nvidia CEO wanted to run the new co
<libv>
which is why we at radeonhd bit the dust as we did
<L84Supper>
now nvidia could buy AMD
<L84Supper>
is Bridgman still at AMD (ATI) ?
<libv>
afaik, yes
<libv>
but he's been moved away
<L84Supper>
oh well
<libv>
only about 5y too late
ibrah has quit [Ping timeout: 246 seconds]
<libv>
anyway, the big question is, what is behind the deal with qualcomm, exactly what was sold and under what terms
<L84Supper>
I wonder if Intel ever felt like kicking themselves for selling off their ARM group years ago to marvell
<libv>
as the x86 market dominator, not too much
<L84Supper>
money is money
<libv>
intel can afford to spend a lot of engineering time on creating x86 "SoCs" which can compete with arm based designs