Archana has quit [Remote host closed the connection]
Archana has joined #beagle
set_ has quit [Ping timeout: 248 seconds]
indigaz has quit [Quit: Good bye!]
indigaz has joined #beagle
Archana has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
vagrantc has quit [*.net *.split]
renrelkha has quit [*.net *.split]
starblue has quit [*.net *.split]
zjason` has quit [*.net *.split]
mag has quit [*.net *.split]
noahm has quit [*.net *.split]
Epakai has quit [*.net *.split]
noahm_ has joined #beagle
set_ has joined #beagle
vagrantc has joined #beagle
Epakai_ has joined #beagle
zjason` has joined #beagle
starblue has joined #beagle
Epakai_ is now known as Epakai
mag has joined #beagle
renrelkha has joined #beagle
GenTooMan has joined #beagle
<set_>
Hey!
<set_>
I am back.
<set_>
Phew, the system kept kicking me for whatever reason. Over and over.
<set_>
Are the servers going through updates?
<set_>
was I being abusive or something?
<set_>
Wait. I did not even say anything!
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 264 seconds]
SJFriedl has joined #beagle
brook has joined #beagle
brook has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
brook has joined #beagle
n0stalgia has joined #beagle
balrog has quit [Ping timeout: 252 seconds]
ikarso has joined #beagle
shoragan has quit [Ping timeout: 246 seconds]
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
renrelkha has quit [Ping timeout: 252 seconds]
renrelkha has joined #beagle
shoragan has joined #beagle
Shadyman has joined #beagle
balrog has joined #beagle
starblue has quit [*.net *.split]
zjason` has quit [*.net *.split]
vvn has quit [*.net *.split]
jfsimon1981 has quit [*.net *.split]
ds2 has quit [*.net *.split]
insurgent has quit [*.net *.split]
jfsimon1981 has joined #beagle
starblue has joined #beagle
insurgent has joined #beagle
vvn has joined #beagle
Shadyman has quit [Ping timeout: 264 seconds]
Shadyman has joined #beagle
Shadyman has quit [Ping timeout: 268 seconds]
Shadyman has joined #beagle
Shadyman has quit [Remote host closed the connection]
xet7 has joined #beagle
ft has quit [Quit: leaving]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
swen has joined #beagle
demirok has joined #beagle
kongn has joined #beagle
<kongn>
whelp, I think the am3358 doesn't actually mean that it doesn't care what's in your MBR as long as your partitons are listed. Resorted to dd'ing from a know good mbr to get my MLO and u-boot working off FAT
<zmatt>
kongn: it definitely doesn't care what's in your mbr, unless your mbr somehow looks like a valid configuration header for direct (non-FAT) mmc boot
<kongn>
I have tried every which way all the while purging my post-512 bytes data so no TOC or raw MLO could be detected.
<zmatt>
example of a known-good way to make a bootable sd card for the am335x (this is just using a tiny demo program as MLO but it obviously works the same when the MLO is u-boot SPL): https://github.com/mvduin/bbb-asm-demo#example-fat-partitioned
<zmatt>
the only thing that matters is that the partition is marked as bootable
<kongn>
I don't think that would work when your bytes 0-460 are 0
<zmatt>
it does
<zmatt>
bootrom does not care about those bytes except to see if it's a configuration header for raw mmc boot
<kongn>
then maybe it's an interaction with the sd card being MLC.. lemme test right now.
<zmatt>
the type of NAND cell an sd card uses is irrelevant and invisible
<kongn>
would the following commands be suitable? echo 248,131072,0x0C,* \n 133120,+,0x83,- to sfdisk?
<kongn>
*2048
<zmatt>
I'm not particularly familiar with the syntax of sfdisk, but if that means a bootable fat partition followed by a non-bootable linux partition then sure
brook has quit [Ping timeout: 268 seconds]
<kongn>
Yup, no luck, hexdump shows all 0's before 0x1b0 and after 0x200 till 0x100000.
<kongn>
lemme compare the good one vs this one.
<kongn>
Yup, when I write in the first 80 bytes of the good mbr sector to the bad one, the bad one loads from FAT.
<zmatt>
what's in those bytes?
<kongn>
no clue, but probably headers on how to read the raw sectors as that good card has a RAW MLO at 0x20000
<zmatt>
this looks like garbage bytes to me, or maybe a bootloader for x86 systems
<zmatt>
raw mmc boot does not require anything in any sectors other than the configuration header that immediately precedes the MLO, and is located at sector 0, 256, 512, or 768
<kongn>
I was trying to avoind raw mmc as this is for simplicity/ will be moving u-boot to spi flash for production. Maybe the empty spi flash was interfering with mmc boot from fat
<zmatt>
raw mmc boot is simpler and more reliable than using a fat partition, and it will also more closely resemble your final configuration where you won't have any reason to have a fat partition at all
n0stalgia has quit [Quit: Client closed]
<kongn>
Well, this is why I should have been on here earlier instead of banging my head against a wall after making packaging scripts and running into this mbr issue.
<kongn>
Thank you for the pointer.
<zmatt>
kongn: hmm, I just tested it and I can't get the FAT partitioned example to work anymore, while the raw mmc boot one works fine
<kongn>
Yea, I do see how the raw would be easier, but I do think with the u-boot modifications still needing to be done, I'll use the "magicalMBR.img"
<zmatt>
that part still makes absolutely zero sense to me whatsoever, I really have no idea what could be going on there
<zmatt>
I'm also quite sure the procedure I documented was tested to work when I wrote it... so I don't know why it no longer does
<kongn>
I did see there was a change in sfdisk functionality across some version
<kongn>
the yocto scripts change flags across version 2.26.2
<zmatt>
I just also tried using plain fdisk
<zmatt>
maybe there's something particular about the partition table itself? I really don't think the early bytes are relevant
<kongn>
yea, just tested again, and my magical mbr is not working again...
<zmatt>
lol
<zmatt>
ok now I have it booting from FAT, so wtf is different
<zmatt>
this time I had a colleague FAT-format the card instead of doing it myself
<zmatt>
kongn: interestingly after they formatted it the mbr also had those bytes, but wiping those bytes has no effect, it still boots just fine
<zmatt>
I'm 99% sure that's an x86 bootloader
<kongn>
That makes sense, I'll look into mkfs.vfat flags.
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt>
yeah it's somehow the formatting.. if I partition the card but let my colleague FAT-format using the GUI disks utility (instead of me doing it with mkfs.fat) then it works
<zmatt>
so it's not the partitioning
demirok has quit [Quit: Leaving.]
<kongn>
Yup, windows format of the disk also allows it to work
<zmatt>
kongn: lol wtf, I compared the fat metadata between the two and the working one has "sectors/track 16, heads 4" while mkfs.fat produces "sectors/track 16, heads 4"
<zmatt>
mkfs.fat -g 4/16 fixed the issue for me
<zmatt>
sorry, mkfs.fat produced "sectors/track 61, heads 4"
<kongn>
Great find! thank you! will test.
<kongn>
Yup, bash script working. Thank you
<zmatt>
you're welcome! and see, obscure nonsense like this is exactly why it's a good idea to avoid using a FAT boot partition ;)
<kongn>
I wonder if the 61/16 is just a mistype in mkfs source. 61 doesn't sound like a valid size
<kongn>
haha
<zmatt>
I don't think so, based on the manpage it uses quite a magic algorithm to determine those parameters
<zmatt>
heh, I've been doing this testing with my old tiny demo program written in assembly and y'know... it's kinda nice to see a program get loaded and running so fast that I can't visually see any delay between releasing the reset button and the program running ;)
<zmatt>
I mean sure, it does basically nothing, but still
<kongn>
Yea, Uboot does boot quick, it's really nice compared to the bootup time we still need to trim from the linux system
<zmatt>
my tests didn't involve u-boot, u-boot is pretty slow
<zmatt>
like, it's not slow in absolute terms, but it is slow for what it does
<kongn>
what were you testing? assembly code for the arm?
<kongn>
ahh, I see now, what sort of demo test was it?
<zmatt>
a trivial one, it just toggles the leds when you press the S2 button
<zmatt>
there's absolutely no reason to do this in asm but someone was looking for an example of doing that
<zmatt>
it does demonstrate irq handling (since it uses an irq for the button-press)
vagrantc has joined #beagle
<kongn>
that sounds like a great demo. I can see how the setup time is minimal.
<zmatt>
yeah the initialization of that program is completely dwarfed by the (itself imperceptible) time it takes bootrom to load the program
n0stalgia has joined #beagle
n0stalgia has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
buzzmarshall has joined #beagle
demirok has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981_b has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
ft has joined #beagle
brook has joined #beagle
Shadyman has joined #beagle
Guest92 has joined #beagle
<Guest92>
Set up beaglebone with jtag using ccs
<Guest92>
Is anybodya can help
Guest92 has quit [Client Quit]
Guest92 has joined #beagle
Guest92 has quit [Client Quit]
Guest92 has joined #beagle
Guest92 is now known as Neel
<Neel>
Hello
Neel has quit [Client Quit]
demirok has quit [Quit: Leaving.]
Shadyman has quit [Remote host closed the connection]
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
xet7 has quit [Ping timeout: 264 seconds]
xet7 has joined #beagle
brook has quit [Remote host closed the connection]
buckket has quit [Quit: buckket]
buckket has joined #beagle
jfsimon1981_b has quit [Remote host closed the connection]