hexdump
-
Posts
457 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by hexdump
-
-
@s-petersen - what kind of u-boot are you using on this device? i guess you use the u-boot on the device to load and boot the kernel from usb? - this might actually work as you seem to have proven
-
@chewitt - not really automated, but at least a way to get the acs info from a box boot block: look at an existing acs file for that type of soc - usually it is possible to find the signature of its beginning in the boot area of a box dump and iirc the end is clear from size and some free space afterwards as well - this worked well for me for g12a and sm1 where acs can be assembed in properly when building new boot blocks - see: https://github.com/hexdump0815/u-boot-misc/blob/d75cf6cbb8f95d7b32ab7f66111c79196d7f7c07/readme.gxy#L153-L158
for gxl i extracted the bl* parts (one of which also contains the ram timing) from the box boot blocks via glximg and reassembled new bootblocks based on them - see: https://github.com/hexdump0815/u-boot-misc/blob/b10b9a5aca46438233fde86f96b452d76d7158f8/readme.gxl#L115-L160
but i guess you know most of that already
best wishes - hexdump
-
-
i think amlogic socs do not support booting from usb ... there is some usb boot mode which is something quite different: sending over a kernel or u-boot via usb from another system using some very special protocol and i guess this is not what you are looking for
- no idea if its even supported on the s805 - see https://github.com/superna9999/pyamlboot
best wishes - hexdump
-
@jock and JMCC: i think this is what you ment: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328#L43-L53 - right?
i think you had it initially in your rk322x instructions, but dropped it at some point.
best wishes - hexdump
-
@pennm - not directly armbian, but maybe it is the same problem there too: https://github.com/hexdump0815/linux-mainline-and-mali-rockchip-rk33xx-kernel/commit/ece606e53780dec397cca7c1f10d70d57f1d0511
good luck and best wishes - hexdump
-
@jock - little update: v12 of the patches is out - it is essentially v11 pus the above mentioned fixes and rebased for v5.19:
-
https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao@google.com/
-
https://patchwork.kernel.org/project/linux-mm/list/?series=650073
-
https://www.phoronix.com/scan.php?page=news_item&px=MGLRU-v12-For-Linux-5.19-rc
-
https://github.com/hexdump0815/kernel-extra-patches/tree/main/multi-gen-lru/v12
best wishes - hexdump
-
-
-
@maziizam - you might try to dd this u-boot: boot-amlogic_sm1-aarch64-x96-air.dd.gz or boot-amlogic_sm1-aarch64-x96-air-serial.dd.gz from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 (after unzip) to the beginning of the disk via: dd if=boot-xyz.dd of=/dev/your-sd-card bs=512 seek=1 skip=1 (the seek/skip tries to preserve the partitiona table)
good luck and best wishes - hexdump
-
@jock- just fyi: there is now an updated version of the extra patch from the patch series author against mglru v11: https://github.com/hexdump0815/kernel-extra-patches/commit/87ba91b3503f95d625ab5eed403e47e65986fd89 still got some warnings with the old version
-
@jock - i already sent you a pm about this, but meanwhile i tested it to be working for me, so maybe its better to post it here as well in case others are interested too: i got a response from the mglru patch series author and a patch which seems to fix the problem on 32bit arm for me (tested on rk3288 with 2gb ram so far) - the patch can be found here: https://github.com/hexdump0815/kernel-extra-patches/blob/main/multi-gen-lru/v11/v11-15-extra-patch-from-author-with-armv7l-fix.diff
good luck and best wishes - hexdump
-
-
@TRS-80 - i would recommend a kukui = mt8183 chromebook - you can get them used for really cheap (around 100 $ or euro) and it looks like with v5.18 and a few patches on top nearly everything is working (except external display via usb-c and the webcams on some models - on most models the webcam is usb video class and thus even working) and you do not have to struggle with all the pain points of the pinebook pro like strange noises and a really lowest quality touchpad ...
-
just some random information from the side: it never worked for me with mainline on my self built (non armbian) kernels - so i guess its simply broken for tegra 210 ...
-
@jock - does it even have 32bit arm support? i thought it was only for x86_64 and arm64 and there are also some extra code parts which are only in there for those two arches.
best wishes - hexdump
-
@gounthar - if you are looking for arm laptops for use with linux, then you should also consider arm chromebooks. best supported are the mediatek mt8183 based kukui and the snapdragon 7c based trogdor devices - nearly everything is working for them with mainline with only very few to no patches required and they are available used or new really cheap (by a factor lower than any other arm laptop option). both have 8 cores, 4gb (some 8gb) ram and 64+/-gb fast emmc. performance wise they are above odroid n2 level. if you can get (not easy due to supply issues) or build (there are a few docs with instructions online) a suzyqable you even get features like a serial console on a laptop which you usually never get. the build quality and reliability of such chromebooks is usually way higher as for average sbc's and with mainline on the above mentioned series you get: panfrost gpu support, working suspend/resume and power saving modes, working wifi, bt, sound and for most of them even camera(s). maybe have a look at cadmium: https://github.com/Maccraft123/Cadmium or my linux on arm chromebooks page: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks to get started.
the best supported other arm laptop is the a few years old lenovo c630 (not the chromebook version) and it is still missing some basic functionality here and there (sleep/suspend etc.). another option - the pinebook pro - is in a different performance and quality league (sadly downwards).
best wishes - hexdump
-
the u-boot setup on amlogic tv boxes is very special - a legacy u-boot is chainloading a mainline u-boot and it is very likely that saveenv in this setup simply does not work ... the readme linked by me above at least gives a rough idea about the steps to build it, but maybe its not really easy for someone not used to build u-boot all the time ... i'm not having the time right now to take care of it myself
best wishes - hexdump
-
@Jeebus - it comes from CONFIG_BOOTDELAY=5 in the config used when building u-boot - in case your u-boot is saying something about hexdump in its output then here are some notes on how it was built: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxl - in the end you'll have to build your own u-boot in case you want to get rid of it ... the idea behind it is to have a chance to press a key at this point to enter raw u-boot cmdline to fix things by hand in case your setup got broken ...
good luck and best wishes - hexdump
-
i have this on my radar and my todo list for a while, but did not yet get to testing it - it looks very primising for lower end systems as the ones we are often dealing with here, especially i assume it will give a big push in useability for 4gb systems (i.e. enough ram to really make something out of it)
-
@Pic55 - the possible cpu clocks are usually specified in the opp tables in the dtb, so either they only contain entries up to 1.7ghz in your dtb or the higher entries are disabled (status="disabled") or the supply voltage regulator (defined in the cpu node i think) does not go high enough for the highest opp entries in your case
-
@Pic55 - i even have h6 boxes running at ~2 ghz (with a fan) successfully and stable - in the end it really depends on the actual box ... i think the cpu voltage on most h6 tv boxes is fixed and depends maybe a bit on the box (i think the cpu voltage is not regulated as for most other boxes and sbc's) and i think that this maybe is also the cause of the temperature differences: the higher the fixed voltage, the higher the soc can be clocked in a somewhat stable way and the hotter it runs (... and the earlier it will break most probably too)
best wishes - hexdump
-
with those newer amlogic socs you never know what you get - they seem to randomly remove or exchange components and give it a new name - i once got an s905l2 working by changing the mali config (https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/misc.av8/patches/mali-with-only-2-pp-cores.patch), but your problem looks different ... so in the end its better to avoid any newer amlogic boxes ...
best wishes - hexdump
-
@jock - that linked u-boot was for a rk3328 box, which has the sd card connected in a way, so that it cannot boot from it - with that special u-boot written to emmc i was able to boot that u-boot and that then was able to read a boot.scr or extlinux.conf from sd card or usb and so it allowed to indirectly boot from sd card
on boxes with locked bootloader i have two amlogic ones (one s905x2 and one s905x) and a rk3288 one (https://github.com/hexdump0815/imagebuilder/tree/main/systems/orbsmart_s92_beelink_r89) which most probably all do not match here ...
best wishes - hexdump
-
@phelum - you might give this a try to make shutdown at least somehow working (i did not find the time yet to test it myself): https://libera.irclog.whitequark.org/tegra/2022-01-30#31661546 and https://libera.irclog.whitequark.org/tegra/2022-01-31#31668641
"<digetx> hexdump0815: likely that max77620 just needs to be marked as system-power-controller in nano's dtsi to enable powering off using PMIC"
"<tagr> hexdump0815: Jetson Nano will by default try to power off using PSCI, but the PSCI implementation is incomplete, so it won't actually cause the system to power down - so for now the best thing you can do is to try something like digetx suggested"
and while we are at the not so good sides of running mainline on the jetson nano, there is also this one to keep in mind which for me results in the performance being way lower than with the legacy kernel right now: https://libera.irclog.whitequark.org/tegra/2022-01-31#31668655
"<tagr> regarding the performance, Tegra210 doesn't support EMC frequency scaling yet because the firmware doesn't pass the EMC tables in the right format on Jetson Nano I think the boot EMC frequency is fairly low, so that might explain some of the performance issues that you're seeing"
besides that the gpu currently cannot be clocked very high, otherwise the system will hang ...
best wishes and good luck - hexdump
samsung go book
in Beginners
Posted · Edited by hexdump
@noom - this is what is possible with it so far, i.e. it boots, kdb and usb works (with some restrictions) - https://github.com/aarch64-laptops/debian-cdimage/issues/21# ... so its something in case you would like to help moving it forward, but its far from generally useable ...
best wishes - hexdump