iamfrankenstein has quit [Ping timeout: 240 seconds]
techn_ has joined #linux-sunxi
techn has quit [Ping timeout: 256 seconds]
JohnDoe_71Rus has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
sehraf has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 252 seconds]
hansg has joined #linux-sunxi
hansg has quit [Remote host closed the connection]
lemonzest has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
philectro has joined #linux-sunxi
clonak has joined #linux-sunxi
clonak has quit [Remote host closed the connection]
philectro has quit [Quit: Konversation terminated!]
premoboss has joined #linux-sunxi
orly_owl has quit [Read error: Connection reset by peer]
orly_owl has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
domidumont has quit [Quit: Leaving.]
clonak has joined #linux-sunxi
clonak has quit [Remote host closed the connection]
clonak has joined #linux-sunxi
domidumont has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 264 seconds]
paulk-collins has joined #linux-sunxi
clonak has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
philectro has joined #linux-sunxi
awe00 has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 256 seconds]
paulk-collins has joined #linux-sunxi
RdlP has joined #linux-sunxi
paulk-collins has quit [Ping timeout: 244 seconds]
<RdlP>
Hello, I have a problem with hummingbird A20 Kit. I follow the steps in the wiki: http://linux-sunxi.org/Manual_build_howto . This is I built u-boot I built script.bin with the hummingbird fex file, I built the kernel, I installed the kernel and script.bin. I created boot.cmd and then boot.scr and I set the rootfs (of course I record the data in microSD as said in the guide). The problem
<RdlP>
is that when I connect the board with the micro-sd inside, the board doesn't boot.
<RdlP>
Any advice?
hipboi has quit [Read error: Connection reset by peer]
enrico_ has joined #linux-sunxi
hipboi_ has joined #linux-sunxi
<libv>
RdlP: what does serial/uart say?
<RdlP>
The serial nothing say
<RdlP>
When I start directly nothing appear
<RdlP>
If I start without micro-sd I can see startup of android
<RdlP>
and I can type commands like ls or pwd
<premoboss>
RdlP, if no output on serial, ere are 2 option: A. serial doen not work (or hardware problem or not configured by software). B. the system doen not bot (problem came fro mOS that does not bot or from hardware dead)
<RdlP>
but when I insert the micro-sd it doesn0t work
<premoboss>
if android on board works, it means probmea came from usd
<premoboss>
the OS on uSD fails.
hipboi_ has quit [Ping timeout: 256 seconds]
<libv>
RdlP: u-boot should pretty quickly show itself on the serial console
hipboi_ has joined #linux-sunxi
<libv>
RdlP: dd the first megabyte, and look at it with hexdump and verify that uboot is actually installed on the sd card
<RdlP>
how can I verify that u-boot is installed? dd the first MB and compare with the u-boot binary?
<libv>
RdlP: you just need to compare some bits
<libv>
not the whole of the dd
philectro has quit [Quit: Konversation terminated!]
<RdlP>
Ok, I restart my system and test it and comment it to you
RdlP has quit []
naobsd has quit [Quit: naobsd]
popolon has joined #linux-sunxi
viccuad has joined #linux-sunxi
RdlP_ has joined #linux-sunxi
<RdlP_>
hello
<RdlP_>
I made dd
<RdlP_>
Which bytes have to compare?
<RdlP_>
Which bytes I have to compare?*
<libv>
RdlP_: read the dd commands that you used when you created the sd card
<libv>
RdlP_: we are not here to handhold you, you have to do some thinking by yourself.
kaspter has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
<RdlP_>
start from 0x0002000 adress of my sd is the same that my u-boot-sunxi-with-spl.bin
p1u3sch1 has joined #linux-sunxi
<RdlP_>
As said in the wiki the first 8KB is unused
<RdlP_>
for that my data in SD start from 0x0002000 (8192 = 8K)
<RdlP_>
so I think it is correct
<libv>
there should be a dos partition table in the first 8kb
<libv>
the first sector that is
<libv>
but this will not stop your card from booting
<RdlP_>
I partitioned my sd with fdisk so in the first 8KB there should be a partition table
<libv>
if you dd-ed the first megabyte, then that should be there
Net147 has quit [Quit: Quit]
<libv>
if not, verify that your sd device in /dev/ is correct, and that you did not create a file there with dd and then later filled it up
Net147 has joined #linux-sunxi
premoboss has quit [Ping timeout: 250 seconds]
<RdlP_>
when I insert the sd in my system the system detect it and mount 2 partitions
<libv>
RdlP_: so why is there no partition table in your hexdumped dd ?
<RdlP_>
one of them is a 17MB partition (with boot.cmd boot.scr, LOST.DIR uImage and script.bin)
<RdlP_>
and in the other partition is the rootfs
<libv>
RdlP_: that does not mean that you dded uboot to the right place
<RdlP_>
I dd-ed it with the following command: dd if=u-boot-sunxi-with-spl.bin of=${card} bs=1024 seek=8
<RdlP_>
where ${card} is /dev/sdb
pekka30 has quit [Quit: Leaving.]
<libv>
RdlP_: do you also create the hexdump from there?
<RdlP_>
just now, I created hexdump from the first MegaByte of /dev/sdb
<RdlP_>
when you said me to do that
<libv>
do you see the partition table in the first 512 bytes?
<libv>
hrm, empty with me as well, this goes in against my knowledge of sdcard mbrs
<libv>
ah, could it be that it lives at the bottom end of 0x200?
<RdlP_>
From bytes 0x0000000 to 0x00001bd is fill with zeros
<libv>
RdlP_: ok, so there is a partition table there
<libv>
RdlP_: what uboot did you build, and how?
<RdlP_>
then, from 0x00001bE to 0x00001fd it contains data (but in that range also there are zeros, many zeros) and from 0x0000200 to 0x0002000 it is fill with zeros
<libv>
sounds good
<RdlP_>
to compile I execute the following commands
<RdlP_>
git clone git://git.denx.de/u-boot.git
<RdlP_>
make CROSS_COMPILE=arm-linux-gnueabihf- <board_name>_defconfig
<RdlP_>
and
<RdlP_>
make CROSS_COMPILE=arm-linux-gnueabihf-
<libv>
with <board_name> being?
<libv>
hah
<libv>
so noone bothered to fix up the manual build howto?
<libv>
ah, no, the message on top is correct
<RdlP_>
I think that I used this exact command: make CROSS_COMPILE=arm-linux-gnueabihf- Hummingbird_A20_defconfig
<RdlP_>
But I doesn't remember I that defconfig exist in the directory or I clone from other
<libv>
hah
<RdlP_>
But I doesn't remember If that defconfig exist in the directory or I clone from other*
<libv>
RdlP_: so you thought it was ok just to copy a config file from another board and to not change anything
<libv>
and then to come in here and wonder "why doesn't it boot"
<RdlP_>
definitly I thint that my Hummingbird_A20_defconfig file is a clone of Hummingbird_A30_defconfig
<libv>
and then waste our time?
<libv>
there is no mainline uboot support for the hummingbird_a20
<libv>
it is also not mentioned on the device page
<libv>
copying a board config is very very very stupid
<libv>
and then being unable to match that poor decision with the sd card not working later on is even more stupid.
<RdlP_>
Here it is say that the board is supported
<libv>
RdlP_: do you see a mainline uboot section on that page?
<RdlP_>
No
<libv>
RdlP_: wasn't the fact that no config existed another pretty monumental hint that your device isn't supported by mainline uboot?
<RdlP_>
It is probably but why say the wiki that it is supported?
<libv>
given, our manual build howto has been maimed in that it does not distinguish between sunxi-uboot and mainline uboot properly
<libv>
RdlP_: did your sdcard boot?
<libv>
RdlP_: so is your board supported by the uboot you installed on it?
<libv>
if the answer to both of those is not "no" i will bill you handsomely for 2h of my time.
<RdlP_>
My sdcard now doesn't boot and I don't know if the board is supported, as say in the wiki it is supported but you say that it isn't supported
<libv>
RdlP_: it is supported in our sunxi-uboot but not supported in mainline uboot.
<libv>
RdlP_: are you really unable to comprehend that?
<RdlP_>
I understand it
<RdlP_>
There is a wiki page that explain how to compile your uboot?
pmattern has joined #linux-sunxi
<RdlP_>
I found it
<libv>
NiteHawk: fix the shit you did to the manual build howto.
<libv>
NiteHawk: explain when one can pick mainline, and when one should pick sunxi
<libv>
this is part of the confusion here
kaspter has quit [Remote host closed the connection]
<RdlP_>
How can I add support for a specific board to a uboot (for both, mainline and sunxi)?
<libv>
the other part is assuming that the lack of a config file is no issue, and that one can just copy another (even for another SoC altogether) and then wondering why it doesn't boot.
<libv>
RdlP_: there is support in our sunxi-uboot for your device
<libv>
adding support to sunxi-uboot is part of our new device howto
<libv>
i somehow doubt that a similar howto is available for mainline uboot, but i would be happy to learn otherwise.
<RdlP_>
yes, but I have more board that isn't support, I used hummingbird_a20 to learn the proccess of compile and so on, but I want to setup uboot and linux on other boards that are not supported
<atsampson>
there wasn't one the last time I looked, but the best way to see how is probably to look at recent commits from other people doing the same thing...
<libv>
RdlP_: i just mentioned the new device howto
<libv>
atsampson: the best way to see for you and me, but not for average joe user like RdlP_ here
<libv>
RdlP_: it should be pretty complete, but if you have any questions or worries, ask here
<libv>
ask before you run into an issue like before and before you end up wasting a lot of time on all ends
dizzuhen has joined #linux-sunxi
<NiteHawk>
libv: ? basically i just pointed to mainline u-boot as the new 'default', where you'd probably end up after reading the "deprecated" warning on http://linux-sunxi.org/U-Boot anyway
<libv>
NiteHawk: read the backlog.
<libv>
and revise your logic.
<libv>
make it clear which needs to be used when.
<libv>
not plainly point people to mainline and wait for shit like the above to happen
domidumont has joined #linux-sunxi
kaspter has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
<RdlP_>
thanks you very much libv
<libv>
RdlP_: did it work with the sunxi-uboot?
<RdlP_>
I doesn't try it. I am reading the wiki to adding new devices, I'll try it this afternoon or tomorrow
<RdlP_>
I have some question about wiki page to adding new devices. This page is for mainline uboot or for your uboot?
<libv>
sunxi-uboot
<libv>
given the poor state of the mainline uboot page, i doubt that anyone has bothered so far
<RdlP_>
Warning! Information below is a somewhat outdated as u-boot-sunxi is not used anymore
<libv>
yes
<libv>
another pretty poor addition.
<libv>
one which only confuses people.
<libv>
and it then references to the same email!
<libv>
on a fucking wiki.
<libv>
lazy wankers/
<RdlP_>
so... sunxi-uboot is deprecated
<RdlP_>
or not?
<libv>
RdlP_: at least it is documented
<libv>
RdlP_: why would you use something obscure and undocumented, when it is clear that the developers do not want other people to use or add to their code?
<NiteHawk>
sunxi-uboot is largely obsolete for those devices that are supported in upstream ("mainline") u-boot
<RdlP_>
Ok. Always it is possible I should use sunxi-uboot
<RdlP_>
despite it is outdated
<RdlP_>
ok. I understand
<libv>
NiteHawk: that's a more nuanced statement than some of the things recently thrown (from very far) into the wiki
<libv>
NiteHawk: and even your statement doesn't help people to decide what to do
<libv>
the mainline uboot wiki page should have a mostly complete howto for adding new devices
<libv>
and then tell people that it makes more sense to add to mainline uboot as sunxi-uboot sees little development is only kept for those devices that have not been ported yet
<NiteHawk>
with mainline being a fast moving target (e.g. the current migration to device model), that's quite a task :/
<libv>
NiteHawk: not really.
<libv>
and not everyone can do the math
<libv>
very few people can to be fair
<NiteHawk>
yup, i'm always learning that the hard way all over again
<libv>
those that can, don't need a wiki to see if their device is supported.
<libv>
NiteHawk: our wiki is device page first.
<libv>
everything comes from that.
<libv>
if the device page has a mainline uboot section, people can choose the mainline uboot build howto from there
<libv>
first listing a sunxi-uboot build target, then pointing to the manual build howto which points to the mainline uboot page, thats just asking for issues like the above.
<NiteHawk>
interesting point by the way. from your point of view, would it be more feasible / desirable to get unsupported devices into mainline u-boot first - or might it be easier to get them going on legacy uboot-sunxi? i'd expect "it depends" in many cases
<libv>
NiteHawk: i stated what i think above.
<libv>
NiteHawk: as long as the documentation for adding devices to mainline uboot is _that_ useless, people should add to sunxi-uboot.
<libv>
if people can finally get off their lame asses and fix the mainline uboot addition howto properly, then people should be told to add to mainline first.
<libv>
but only then.
<libv>
not before.
<libv>
NiteHawk: now add a sentence that states that, if your device supports mainline uboot (and has that section in its sunxi support section), the mainline build howto can also be chosen
<libv>
you can add a link to the category of mainline uboot supported devices from that sentence
<libv>
as for adding new devices on mainline: it really is not that much work now that the kconfig stuff has gone through
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
hipboi_ has quit [Ping timeout: 256 seconds]
hipboi_ has joined #linux-sunxi
<RdlP_>
Ok, I am going to compile sunxi-uboot and try it on my hummingbird_a20 board
Black_Horseman has quit [Remote host closed the connection]
kaspter has quit [Remote host closed the connection]
<RdlP_>
libv, there are also linux kernel mainline and linux kernel sunxi?
<libv>
RdlP_: the sunxi version is what you want first
<libv>
you can try mainline later, if it suits your needs
philippe_fouquet has quit [Remote host closed the connection]
<RdlP_>
yes, because I can read that sunxi kernel is the only that support accelerated 3D graphics
domidumont has quit [Read error: Connection reset by peer]
domidumont has joined #linux-sunxi
<libv>
NiteHawk: mainline u-boot _should_ be preferred
<libv>
ah, scrolled up, and not down due to 3g lag
<libv>
to finish that statement: but mainline u-boot cannot be preferred until the wiki for adding devices is useful
kaspter has joined #linux-sunxi
<RdlP_>
in uboot mainline the sd's paritition could be fat (fatload) but in sunxi uboot only mentioned ext2load it couldn't be fat?
philippe_fouquet has joined #linux-sunxi
mrnuke has quit [Remote host closed the connection]
mrnuke has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]