hexdump

  • Posts

    398
  • Joined

  • Last visited

4 Followers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hexdump's Achievements

  1. @jock - thanks for the info and the links ... yes it is possible to get it working (got it working too - here are my notes: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxb plus some more readme.g* around for the other amlogic socs), but its more complicated than the other socs in my opinion ... yes odroid c2 has boot blobs which are locked to odroid hw, but there are other blobs available which work ... booting from emmc is even more complicated as the boot block starts from sector 0 and covers the partition table area (as it seems the first sector is even checksummed in the bl2, so no way to even put a partition table in there by hand as @pista has found out) - at least @pista found a clever way to make it work somehow still in this thread ... some amlogic boxes (mi box II and a95x f2 or f3 i think) even have an encrypted boot block, so there is no chance at all to get anything working except using legacy u-boot and maybe chainloading mainline u-boot from it ... afaik amlogic cannot boot from usb storage but you can supply it a boot block, kernel etc. via usb - see: https://github.com/superna9999/pyamlboot
  2. @jock - there is no really useable mainline u-boot for the amlogic boxes (actually one can build one for one of the amlogic dev boards in u-boot - p201 or similar and they kind of work, but sometimes the dtb's do not match the hardware well enough) and those boxes are very easy to brick, plus default boot is from emmc. on top of that a few boxes even have nand instead of emmc. oh - and the memory timinig is done by blobs which seem to not be that interchangeable between different boxes plus it is a very complex procedure (in no way comparable to the easiness of rockchip - its more onion style with checksums on each layer - https://github.com/repk/gxlimg helps a lot for the s905x here) of many steps to build the final u-boot from the blobs and the compiled u-boot. due to this i think balbes150 (or maybe it was initially someone else) had the idea to just supply the legacy u-boot with a proper boot.scr style script to boot mainline linux kernels in a somewhat flexible way from sd card or usb. based on that i moved on one step by chainloading mainline u-boot from legacy u-boot, so that you get the features and flexibility of mainline u-boot (like extlinux.conf etc.) without the risk to brick the box. but even this is quite complicated as you better do not touch the first 700mb (older) to 1.5gb (newer) of the emmc as legacy u-boot reads a dtb from somewhere inbetween there and is very unhappy if it does not find it. rockchip and allwinner are really a dream compared to this mess best wishes - hexdump ps: another thing is that there is no usb tool comparable in power to what is there for rockchip for instance pps: i have some s905x, s905x2, s905x3 and s912 boxes running with native mainline u-boot but gave up on trying to generalize this setup as there is so much which can go wrong - s905 is even worse as there is no such tool as gxlimg to disassemble (to get the memory training info) and reassemble the blobs
  3. @pista - i enjoyed this conversation a lot too and i agree with you that we have reached a point now at which your solution simply seems to be the best of the available ones - trying to hack the gpt option to make it work will in the end not end up in a solution which is really more simple thanks a lot for sharing your solution, which is at least a possible solution and for doing all those experiments best wishes - hexdump
  4. @pista - there seems to be some backup gpt code in there - https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch#L44 ... did you get any gpt errors from u-boot? - the above patch is removing all the errors from u-boot which were spamming my console on this chromebook, so you should see them as well in theory i guess. looking roughly at the u-boot efi code at https://source.denx.de/u-boot/u-boot/-/blob/master/disk/part_efi.c#L676-711 i'm not sure if it really works with the backup gpt only - maybe on the chromebook part of the primary gpt sturcture is still there and only parts are broken, so that the backup gpt is then used ... will have to look closer at the u-boot source for this.
  5. @pista - it looks like this should have some good information in it: https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.gpt it looks like the gpt stuff is not defined in my s905 u-boot build - the chromebook config ( https://source.denx.de/u-boot/u-boot/-/blob/master/configs/chromebook_speedy_defconfig ) has CONFIG_CMD_GPT=y set (and i guess this one then pulls in CONFIG_EFI_PARTITION) and the s905 config i used ( https://source.denx.de/u-boot/u-boot/-/blob/master/configs/p201_defconfig ) not looks like a new u-boot is required for this to be able to work: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxb best wishes - hexdump
  6. @pista - i guess your theory about the checksum is correct then ... which linux version of the usb burning tool for amlogic did you use btw.? do you have to ground the emmc clock pin to get it recognized there or is it recognized if bricked even without that?
  7. @pista - just to mention it here: i'm aware of one other type of system with a strange boot setup: the rk3288 based chromebooks (veyron) are using gpt partitoning, which consists of the primary gpt partition table at the beginning of the disk (and spanning even more space then the traditional mbr partition table) and a backup gpt partition table at the end of the disk (a normal redunadancy measure of gpt partioning) ... the strange thing on those chromebooks is that you can create a gpt partition table successflly, but if you try to read it back it tells you that the primary gpt table is corrupted (not sure where this gets lost, but its consistent) ... the way i got it working was to write the gpt table and then boot the kernel with the "gpt" option, which tells it to use the backup gpt table if the primary one is corrupted - u-boot is complaining a lot about the broken primary gpt, but works in this case (i just commented out those warning from u.boot for it) ... i think there are patches for those chromebooks, which put the primare gpt table to another place, but my approach works without those patches maybe an approach like this might work for the s905 too - not sure, but your approach is fine too i guess (maybe the gpt one would be a bit more standard - if it works at all in this case ) https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_veyron/extra-files/boot/extlinux/extlinux.conf#L13
  8. @pista- this is interesting - to me it looks like this in theory should really work the way you did it ... so in result it did not even start to boot then in this case? which boot blocks are you using - the ones i built or built them yourself?
  9. @jock - i can confirm that those old mx10 boxes were rk3328 and they were the only ones i saw, which had a proper cpu voltage control ... i once had one of those some time ago @Matteo Venturi - i think there are at least two versions of this box: an older rk3328 one which should work very nice out of the box (i have one of those) and a newer rk3318 one which might have a few surprises in it resulting in it no longer working that easily best wishes and good luck - hexdump
  10. @pista - congratulations - this is a very clever approach ... i had "blkdevparts" still on my list of things to check out one day, but i think i would have never gotten to the idea of the mmc read to read all the stuff in one row into memory - really really clever one other thing i once noticed (not 100% sure anymore, so it might also be just wrong memory) was, that it looked like the boot block for the first sector for the s905 seemed to have an empty area where the actual fat partition table lives in the first sector (i think i saw it when doing a hexdump -C of a self built s905 boot block) ... in case my memory is right and there is no checksumming involved it would even be possible to get a boot block together which has a proper fat partition table in it and still works ... but maybe i just dreamed it once and its not really true best wishes - hexdump ps: i just did some recheck of my theory - if you hexdump -C this one: https://github.com/hexdump0815/u-boot-misc/releases/download/200718-01/boot-amlogic_gxb_atf-aarch64-serial.dd.gz which is a boot block for sd card, i.e. starting at block 1 then it looks like only the area from 0x0 to 0x70 (after dropping the first 512 bytes) is really used and the partition entries are usually living between 0x1be and 0x1fe (see https://www.easeus.com/resource/fat32-disk-structure.htm) - so maybe there is a chance to get it working? but so far i never tried it
  11. @pista - i must admit that i have lost the overview a bit about what your current setup and your goal is ... what did you manage to install to emmc and why do you use "mmc read" instead of "load/fatlload"? yes, the initial env is hardcoded into u-boot.
  12. @Dan MacDonald - iirc the open source driver has to exist so that the kernel driver they use for their own blob driver has any open source consumer and i guess this is why it is slowed down so much: its there as it has to exist for the kernel driver not to be thrown out of the kernel and otherwise nobody really cares about it ...
  13. @Sameer9793 - amlogic socs by default always boot from emmc if emmc is there (which is always the case for tv boxes) - best for you is to look at the multiboot script from the old images of balbes150 - this one uses the legacy u-boot of the box to boot an own kernel or to chainload a mainline u-boot to boot it - those options should be quite safe as everything else which does not write anything to emmc
  14. @Sameer9793- i collected some notes around mainline u-boot for amlogic in the readme.gxb (gxbb), readme.gxl (gxl) and readme.gxy (g12a, g12b, sm-1) in this repo: https://github.com/hexdump0815/u-boot-misc - but i would recommend you to play around with that stuff only if you really know what you are doing as you can very easily brick your box this way and then nobody can help you ... good luck and best wishes - hexdump
  15. @vilodeid - in case you really want to play around with panfrost on h616, then maybe have a look at this https://oftc.irclog.whitequark.org/linux-sunxi/2021-05-27#29961750 and the irc logs from the following days ... a lot to read and not really easy stuff, but i think this the most detailed information which is there so far regarding this topic happy reading and best wishes - hexdump