<marex>
jason1234: arch/arm/boot/dts/omap3-pandora-1ghz.dts would indicate that the device is in mainline Linux since 2015 at least
<vagrantc>
it's only partially supported in mainline
<marex>
vagrantc: ok good, please take over
<marex>
vagrantc: btw why ? GPU I can imagine is a problem, anything else ?
<marex>
vagrantc: although, there was some work to update the powervr sdk somehow for maemo leste
<vagrantc>
marex: the keyboard was implemented in a way that will never be properly supported
<vagrantc>
i haven't had much luck booting mainline linux on it ever ... mainline u-boot worked ok-ish, but it's been ages since i've tried it
<vagrantc>
it was a really nice keyboard and mouse-nub interface ...
<marex>
vagrantc: matrix keyboard ?
<marex>
vagrantc: i.e. one oversampled by GPIOs or something ?
<marex>
vagrantc: you might be able to implement some handling in the PRU , assuming it had PRUs
<vagrantc>
it's been so long since i looked, but matrix sounds familiar
<vagrantc>
wild guess that urjaman would remember more...
samueldr has quit [Ping timeout: 264 seconds]
mvaittin has quit [Ping timeout: 264 seconds]
cpackham[m] has quit [Ping timeout: 264 seconds]
<vagrantc>
wow, the documentation for the sifive_unmatched board goes through all the trouble to document how to set up partitions for the u-boot-spl.bin and u-boot.itb ... and then installs with a raw device offset :)
<jason1234>
do you maybe know how to access the u-boot on nand of pandora, and enable 5 to 10 sec to press key, to allow input command line directly at boot into u-boot?
<Forty-Bot>
vagrantc: well, they use raw device offsets when setting up the partitions anyway
<Forty-Bot>
a better way might be to do "A_START=0; A_SIZE=1337; B_START=A_START+A_SIZE; ..." but that can get a bit tedious
<Forty-Bot>
unfortunately, I'm not aware of any tools off the top of my head which will extract partition offsets
<Forty-Bot>
and of course, if you're clever you can create the entire disk image as a normal user and only sudo at the very end
stefanro has quit [Remote host closed the connection]
stefanro has joined #u-boot
agust has joined #u-boot
<vagrantc>
Forty-Bot: if the partitions are at the right offsets, you can just write to the partition by partition labels rather than the offsets
<vagrantc>
it's the same either way, but it's a little harder to do the wrong thing with partitions ... and, you can easily leave significant room to grow with the partition method
<vagrantc>
jason1234: you can flash a new u-boot, but if it goes horribly wrong, you have a pandora brick
<vagrantc>
jason1234: i think mainline u-boot just uses distro_bootcmd ... which should be a 2 second delay
<vagrantc>
jason1234: but you need to use serial console; mainline doesn't support video output last i looked on pandora
<urjaman>
but if you're using the pandora specific u-boot, you can just hold one of the shoulder buttons and pick the lcd console from the menu
matthias_bgg has quit [Ping timeout: 244 seconds]
<urjaman>
(DO NOT saveenv from there tho, you'll break stuff... but you can enter arbitrary boot menu entries into a file on the NAND UBI boot/kernel partition to be ran from that menu...)
<urjaman>
and the same is with the SD boot, the boot.txt (or autoboot.txt) can contain any u-boot commands...
alpernebbi has joined #u-boot
<urjaman>
(also AFAIK mainline u-boot no longer even has the pandora ... unless someone neglected to remove it, but atleast I heard that was the plan)
matthias_bgg has joined #u-boot
tnovotny has joined #u-boot
<milkylainen>
Still can't get zboot to start a kernel from a u-boot x86 UEFI-payload.
torez has quit [Remote host closed the connection]
torez has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
FO3 has joined #u-boot
rfs613_ has joined #u-boot
mvaittin has quit [*.net *.split]
cpackham[m] has quit [*.net *.split]
samueldr has quit [*.net *.split]
FO2 has quit [*.net *.split]
rfs613 has quit [*.net *.split]
Tartarus has quit [*.net *.split]
mckoan is now known as mckoan|away
Tartarus has joined #u-boot
smartin has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
<jason1234>
hi guys
<jason1234>
vagrantc: no pandora brick, no openpandora brick at all
<jason1234>
vagrantc: how to get into the 2 sec to boot, space key?
<jason1234>
I need acess to toocommand line of u-boot
<jason1234>
The openpandora has on nand, the u-boot, this u-boot is configured to wait for RIGHT Pad button, hold, and to start a menu
<jason1234>
this menu will prompt select sd1 or 0 to get the system to boot. it has a 50MB fat32 on sd0, partition1, and this autoboot.txt will be read. it does a fatload mmc and put a adress (slot left or slot right) on mmy.
<jason1234>
mmc.
<jason1234>
the ideal, would be to hack it that uboot can uboot on the kernel7.img of netbsd of beagleboard stored on fat32 50mb part1, /kernel7.img
<jason1234>
once netbsd kernel7.img (netbsd) kernel is started, we are safe, it has an integrated command line (alt + ctrl + Esc) that does like under linux initramfs.. mount /dev/sd0a / ; exit
<vagrantc>
jason1234: it's been a long time
<vagrantc>
jason1234: can't remember
<jason1234>
you did manage on openpandora? really? a lot of people dream to run openbsd or netbsd on openpandora, really...
<vagrantc>
i only ever ran linux
<vagrantc>
if i could get anything usable on 512MB of ram, i'd love to try it :)
<jason1234>
netbsd and openbsd run on 3-4 MB only. nothing can beat BSD. BSD is magically power
<vagrantc>
magic, wow.
<jason1234>
a typical openbsd.rd installer is about 10-15mb for instance or less.
<jason1234>
since it is very well designed, BSD can or could run well on an openpandora. Once booted, it is quite easy to port drivers on it.
macromorgan has joined #u-boot
cpackham[m] has joined #u-boot
mvaittin has joined #u-boot
lokeshvutla has quit [Remote host closed the connection]
samueldr has joined #u-boot
tperrot_ has quit [Ping timeout: 265 seconds]
tperrot has joined #u-boot
FO3 has quit [Read error: Connection reset by peer]
djStolen has joined #u-boot
<djStolen>
hi guys. where can i find which cpus are supported by u-boot. i am specifically interested in mediatek mt7628nn
<cambrian_invader>
jason1234: you can use any key to break into the boot timeout
<cambrian_invader>
if your uart has a fifo (which it almost certainly does) you can press that key as soon as the soc exits reset
<cambrian_invader>
djStolen: I don't know if there is a list; fwiw there seems to be mention of the mt7628a in the source code
redbrain has joined #u-boot
redbrain has quit [Ping timeout: 252 seconds]
<jason1234>
cambrian_invader: well openpandora does not allow any break of keys... seems like.
<cambrian_invader>
if there is a delay, you should be able to break in
<cambrian_invader>
if you want to mess with this, look at CONFIG_BOOTDELAY:
<vagrantc>
jason1234: ah, i used a serial console to access mainline u-boot
<jason1234>
maybe you can give my a little u-boot that would run from /media/mmcblk0p1 out of the fat32 ???
<jason1234>
this way, maybe from mmcblk0p1 we could start your u-boot, and we could launch BSD from the other mmcpblk0p2, bit like a tweak
<jason1234>
*mmcblk1pX.
jwdonal has joined #u-boot
<jwdonal>
is this an appropriate place to ask for help with a u-boot issue i'm having? or is it better to just use the mailing list?
<jwdonal>
i am specifically having an issue with 'unzip' command on ARM64 arch on Altera SoC FPGA
<vagrantc>
ask away, wait patiently :)
<jwdonal>
was also thinking about sending email directly to Marek Vasut (according to this site https://www.denx.de/wiki/U-Boot/Custodians) but not sure if that's frowned upon
<jwdonal>
ok
<vagrantc>
and if you don't get a response, follow-up on the list
<vagrantc>
CCing maintainer is usually ok
<jwdonal>
i wanted to include my .config file for reference. what would be the best way to do that in IRC land? pastebin link?
<vagrantc>
yeah, pastebin
<jwdonal>
ok. let me get some pastes setup. thanks
yates has joined #u-boot
<yates>
does (or can) u-boot make use of the linux kernel drivers? e.g., if the boot device is a nand flash with ubi, can it utilize the kernel's nand driver and ubi driver before booting linux?
<yates>
at build time, that is.
<marex>
jwdonal: I never really worked with the arm64 altera socs (stratix/agilex), but ... what is the question ?
<jwdonal>
was just about to post my pastebin links :)
<marex>
jason1234: I _think_ you might be missing how that whole embedded bootloader/kernel stuff really works, it isn't like on x86
smartin has quit [Quit: smartin]
<jwdonal>
i actually don't ...think... this is specific to arm64. i think it's just some issue with unzip command. and most likely something totally stupid that i'm doing wrong
<marex>
jason1234: to provide some parallel, u-boot is kinda on the level of your x86 bios, so the "can you provide me u-boot which starts from fat32" is like saying "can you provide me bios which starts from fat32"
<marex>
jwdonal: so, describe the problem ?
<marex>
jwdonal: and then the kernel7.img sounds like something Raspi specific , no ? The bsd kernel images were I think plain elf files, there was some loader needed to relocate them in DRAM and jump to entry point
<marex>
err ... jason1234 ^
<marex>
u-boot has this elf loader , but you would need a matching kernel port for that to work
<marex>
jwdonal: btw which socfpga is that , stratix or agilex ?
<jwdonal>
ok. so here is problem description. i am transferring (via TFTP) a binary image file that I want to flash onto my SD card. in the first test I transfer a NON-gzip image to DDR (via TFTP), program the image that is stored in DDR to the flash, read data back from the flash into different DDR location, then memdump the readback data to check it, and upon inspection the read back data is *good*,
<jwdonal>
no issues. In the second test (and this is my desired approach), I transfer a GZIP'd version of the same image to DDR (again via TFTP), unzip the image data to a different DDR location using 'unzip' command, then memdump the unzipped data to check it, upon inspection the unzipped data is *corrupted*
<marex>
jwdonal: could it be the unzip command overwrites part of your data during the decompression ?
<jwdonal>
yes, i was originally using gzwrite. I love gzwrite!! But I was getting corruption issues with it as well. So in my attempt to debug what was causing the corruption I was trying to strip out steps and just see if basic 'unzip' command would even work. and i discovered that just plain 'unzip' doesn't work
<djStolen>
Guys, short question. What is the meaning of rfb in mt7628_rfb_defconfig?
<marex>
ReFerence Board maybe ?
<marex>
djStolen: ask stefanro when available
<jwdonal>
i am guessing that gzwrite makes use of the 'unzip' function code. so i've narrowed down the cause of the corruption down to just unzip itself instead of the whole gzwrite method
<djStolen>
marex: ok, cool. thanks
<marex>
jwdonal: yes
<marex>
jwdonal: which U-Boot version is that ?
<jwdonal>
"could it be the unzip command overwrites part of your data during the decompression ?" if you look at the command logs you can see that I am unzipping to a much higher region of memory so there shouldn't be any way that unzip command could be overwriting the original gzip data i don't think
<marex>
(just so we're not looking for a fix for something which was already fixed)
<jwdonal>
it's in my pastebin (2020.10)
<marex>
doesnt the gunzip function need some temporary buffer ?
<marex>
jwdonal: can you try 2021.07-rc4 or HEAD ?
<marex>
jwdonal: also, how big is the file you're decompressing ?
<jwdonal>
also, it might be useful to note that I was successfully using this same approach (with gzwrite) in 2020.01. i had no issues there. *however*, i want to be clear that that was on a different arm (non-64) development board.
<jwdonal>
the gzipped file size is 54375273 bytes
<marex>
I've used gzwrite on multiple aarch64 boards just fine
<jwdonal>
ok that's good to know
<marex>
jwdonal: well, try a smaller file, just gzip a 1 MiB block of data and see if that decompresses fine
<marex>
it looks like in your case, the unzip corrupts a byte of each word or so
<jwdonal>
ok i will try a smaller block
<marex>
jwdonal: yes, try that, if that works that might indicate overflow of sorts
<jwdonal>
also, i put my .config on pastebin too but it says it's pending moderation for some reason. blah. so i can't send you working link for that
<marex>
jwdonal: btw you're sure the data got correctly tftp'd over, running sha1sum on those data indicates everything fine ?
<marex>
(and matches the checksum of the same file on your tftp server?)
<jwdonal>
i actually used md5sum and md5sum -v and they checked out valid
<marex>
good enough
<marex>
all right
<jwdonal>
i computed md5 on machine that gzipped the image and then transferred that md5 value to u-boot and used md5sum -v to validate
<marex>
OK, so input is correct
<jwdonal>
i also considered maybe an issue with DDR (calibration or something) but that's clearly not the case since I can transfer the entire (huge) NON-gzip file to DDR (via TFTP), write to flash, readback data, and it's correct, and i can boot into linux successfully and linux works well. so DDR seems A-ok. (p.s. i am working on smaller gzip block transfer right now)
<marex>
because that one has this non-upstream patch in zlib code
<marex>
1db62581ad ("Use post-increment only in inffast.c.")
<marex>
well, if you want support for vendor u-boot fork with various custom patches in random locations, you should ask vendor
<jwdonal>
well that's certainly interesting...that could be related to my problem?
<jwdonal>
ok
<marex>
I don't know , maybe ?
<marex>
but that would explain why I never ran into this problem
<marex>
revert the patch and see if that helps ?
<jwdonal>
ok let me just try this smaller 1 MiB block since i'm already in the middle of it
<jwdonal>
yes, i will try that as well
<jwdonal>
ok, so i tried 1MiB block and it resulted in identical corruption
<marex>
jwdonal: git revert --no-edit 1db62581ad1e29de37d6be0398ae2270dcca7ada ; <compile as usual>
<jwdonal>
ok thanks. i have a quick question on this: "if you want support for vendor u-boot fork with various custom patches in random locations, you should ask vendor". So you are listed as custodian for Altera SoCFPGA ARM architecture (u-boot-socfpga) on https://www.denx.de/wiki/U-Boot/Custodians. But you are not the correct person to ask about this? I guess I'm not clear on what "custodian" means?
<jwdonal>
So regardless of you being 'custodian' I should still go to vendor directly for support? Really sorry if I posted this question to wrong place. :/ So you don't do any development for u-boot-socfpga for altera? I guess that's what I'm confused about.
<marex>
jwdonal: I only handle the upstream stuff , well , in fact Ley does these days , since its mostly the arm64 socfpga
<marex>
but Ley left intel recently, which is sad, because Ley did fantastic job
<jwdonal>
ah i see now what custodian means. thanks
<marex>
jwdonal: intel has some downstream fork on github which is lagging behind upstream and has additional patches (of whatever quality, who knows)
<marex>
jwdonal: so if you pull u-boot from source.denx.de (ie. upstream), I can help you with that
<jwdonal>
haha. ok
<marex>
jwdonal: if you pull intel fork from github, go to intel for support
<marex>
jwdonal: intel is pushing stuff upstream though, so it is very likely that if you use upstream, it will just work (and better)
<marex>
jwdonal: and no, I am not on intel payroll
<marex>
jwdonal: I did work on the 32bit socfpga and upstreamed it , and then the 64bit socfpga was taken over by intel themselves
<jwdonal>
yes i see. the problem i've found with trying to use straight vanilla u-boot source on these FPGA dev boards is that virtually nothing works. specifically, for these absurdly complex FPGA boards the vendor adds TONS of source code additions/modifications, linker scripts, etc to make u-boot work with that specific board architecture layout. so it's been incredibly difficult (read: I have never
<jwdonal>
been successful) to take vanilla u-boot source and massage it to work on these FPGA dev boards (xilinx/altera). i've always had to use the vendor source repos (at least for xilinx and altera boards)
<jwdonal>
in the past when I try using vanilla non-vendor u-boot repo it's a miracle if I can even get u-boot to boot at all. i think i was only able to do that once, but didn't get further than a few lines of debug output and gave up
<marex>
jwdonal: it could be the 32bit socfpga is rather simple(r), there you start SPL from ocram (fixed location), that brings up DRAM (hard component, not going through fabric), and then that loads U-Boot into DRAM and starts it
<marex>
I recall arria10 was starting to be a bit more complicated due to the DRAM being routed via fabric, but then they added more OCRAM too
<marex>
I dont recall what stratix does
<marex>
jwdonal: are you more on the software side or fpga design side ?
<jwdonal>
i do both. but just using startix 10 for the first time on this dev kit
<marex>
jwdonal: is that the big one with the watercooler ?
<jwdonal>
haha, YES
<marex>
heh
<jwdonal>
annoying having to sit next to this stupid thing. so loud
<marex>
jwdonal: so did the revert help ?
<jwdonal>
have not done yet. i left to get a drink of water and someone stopped me in the hall for a minute to talk. i am back on it now though
djStolen has quit [Quit: Client closed]
<jwdonal>
while i'm waiting for this to compile i've always wanted to ask someone this. why does u-boot not have a seperate ARCH=arm64 like linux kernel source tree does?
<marex>
jwdonal: I don't know, different decision than linux was taken ...
<marex>
Tartarus: ^ do you remember ?
<jwdonal>
i'm flashing reverted u-boot to board now...takes a little while
<marex>
iopaniuk: that redundant boot on imx8mn/mp is so unbelievably broken, why did nxp remove the perfectly working option that was present until 8mm, sigh
<jwdonal>
marex: hmm..well i ran the revert but after re-compiling and flashing to the board the SPL will no longer boot u-boot from SPI. just stuck on "Trying to boot from SPI", then times out and resets the board
<jwdonal>
so that was very revealing unfortunately
<marex>
jwdonal: is zlib even compiled into your SPL at all ?
<marex>
jwdonal: could it be what you wrote into the NOR isn't "correct" ?
<marex>
i.e. you need to patch in various headers generated by the bsp-editor or whatever it is called now, before compiling the u-boot binary
<marex>
did you get all that set up right ?
<jwdonal>
yes, all of that works since I can boot u-boot and linux just fine
<jwdonal>
it's just unzip corruption that i'm dealing with
<jwdonal>
if i don't use unzip i have 0 issues
<marex>
jwdonal: so, revert the revert, compile, write and see if that "fixes" the board