Jump to content

TonyMac32

Moderators
  • Posts

    2399
  • Joined

  • Last visited

Everything posted by TonyMac32

  1. So RK805 PMIC like Rock64 and IIRC Renegade Looks like a SPI flash (25lq128), U-boot SPL might actually live there. Asmedia ASM1351 sata bridge Room for more RAMS
  2. Cost and complexity, they probably didn't want to bother with it and they don't want to bury it I would guess (the I/O side of the board looks full)
  3. For installation. purposes, although an 8 GB eMMC will often be a slow one. in BOOTROM mode that "A" is actually a slave, so it's alright. I wouldn't use that cable for anything else though...
  4. I would take a look at the dmesg if possible, I don't think this would be logged anywhere else. I have wireshark staring at mine while I try to get it to freeze to see if anything strange happens on the network itself, so stay posted
  5. Well then the USB loader is the only option. If they put a good U-boot that allows USB booting then it can be done that way, otherwise it's the crazy cable bootrom device mode.
  6. Well, some would agree with that assessment, as far as I'm concerned it is disappointing, but not useless. Were it a completely useless board I would not have put the time into supporting it. The danger here is that people use Armbian for servers and data-integrity-sensitive applications, and the Tinker simply can't fill that role without a lot of care. As far as my background, I have a degree in electrical engineering and design automotive electronics (safety related devices). When a board has 4 USB 2 ports on it, I expect them to meet the specification. If it chooses a power plug, it must be one capable of supplying the board at full load (so in this case board + 2 Amps of USB load). No board that I know of meets that requirement, so the Tinker is not alone. So expectations were extremely high, and the board didn't quite deliver. Well, at 5.0 Volts my stability testing repeatedly failed. That's common for RPi, 'x'Pi, etc etc etc. The voltage drop due to the micro-USB assures that. So I use 5.25 volts and sit *just* above the minimum allowed supply voltage for the USB peripherals. I would assume not, given the issue is a specification problem, not just a component source issue. I believe the parts are of sufficient quality, this is an ASUS product after all, it's just that the RPi foundation set a rather unfortunate standard, and their boards have a lot of workarounds because of it, which is replicated in the newer ASUS board. As you see in December I updated with more recent info, using the device for 2-3 weeks as my desktop, noting that system stability was not an issue, as long as the filesystem stayed on SD.
  7. Did you get any error messages/logs indicating what was happening? I am currently streaming data into and out of the device, but can't seem to get it to freeze, indeed this seems a rare issue so any info you have would be helpful.
  8. Congratulations! That said, the laws of physics still hold, and you missed providing the relevant information concerning your supply of choice: The voltage of the supply. Also, see: That post contains empirical data and observations while running the Tinker Board. If you wish to continue this discussion, we can do it in the review thread as it is off-topic for this thread. I would actually recommend that @chwe or another moderator make that move of these last two (or more as deemed prudent) posts to that thread if possible, since we're far off topic of RK3328 vs RK3288 and the power discussion may be enlightening to others. From that post: Remember that Armbian gives users the flexibility to run off of USB (after booting SD of course), and that use case would be a complete failure without spending some time seeing warnings like those above. I also am referencing "as packaged" when I discuss the "factory" heat sink, since obviously with fans/etc it will perform better. I can operate at a continuous 1.5 GHz with 30 second or so "sprints" at 1.6 when it cools slightly at full load, simply by attaching a superior low-cost heat sink, something I would highly recommend to anyone who did not want to suffer immediate and severe throttling (45 to 55% throttling is severe). Add a fan and it may never throttle under normal use.
  9. Thanks for that, @Myy. I'll take a look. [update] @Sire Gawain if you build a "Next" kernel now you will have support. https://github.com/armbian/build/commit/ac76d47785c130a20f8f2c6447bbae7f2c40bc14
  10. From what I've seen, no. They are doing an RPi-style workaround so voltage drop off will result in throttling rather than crashing. I was considering grabbing a Chromebook with the RK3288, since I spent so much time with the Tinker making it behave on Armbian. The processor is fine, the board is the issue, primarily the heat and power input. I power mine via GPIO and put a much larger heat sink on it Sent from my Pixel using Tapatalk
  11. Just to caution: This is conditionally true, assuming you can: Provide enough power for the device Can keep the device cool Are running general-purpose apps In stock form, none of these things are possible with the Tinker Board due to it's tiny heat sink and micro USB power. The RK3328 is not incredibly well supported in mainline just yet, certain important things are missing, like the entire video output system.
  12. ...I've run into this as well, I'm guessing there is a per-user global data size cap? Mine is at 0.01 MB If that's what it is, I can go through and revise my posts with images to use smaller ones, I would have expected the forum software to do some automagic shrinking to them.
  13. Missed that. Tinker OS has (most of) the most recent Rockchip customizations baked in, so I'm guessing this is still some sort of power issue. Without being able to reproduce it myself I'm afraid I can't be much help.
  14. Not that I am aware of, however I will check up on activity, the 4.4 is a fork of a Rockchip-specific kernel, so something may have come up in the meantime. What is your use case? I have only 1 Tinker, and I run Mainline 99% of the time. If you don't need the touchscreen and VPU, (and at the moment Bluetooth, although that is being addressed) mainline is often a better choice.
  15. I did assembly coding on hardware with tens of bytes of RAM, and I agree. As for the sources, in your clone of the repo: ./build/config/sources/<name_of_board>
  16. If you don't have peripherals attached to USB and only the ethernet attached, there should not be an issue. What did you use to go from the barrel jack to the GPIO pins? did you attach to 2 +5 and 2 Gnd pins?
  17. apt update apt upgrade Use a wireless dongle if available to make it easier.
  18. https://github.com/hardkernel/u-boot/commit/460fc4d3f4e97e8044cfba68ee8536d1b461d72c That should have made the MAC address correct/consistent on boot, assuming Hardkernel is setting it from factory. The only reason I'm not having any luck with this method on Le Potato and the K2 is that those devices are blank from factory.
  19. Mainline does not support that touchscreen yet, the changes to the drm system from 4.4 to 4.14, and the "special code" used in the 4.4 made me pause before patching any changes in. There are tons of mipi/DSI patches in the pipework, so I'll have to revisit it. For now pulling that node is perfectly acceptable.
  20. GitHub.com/armbian/build will let you build kernel images that work with the Armbian distro (outputs Deb packages), and that way you can also generate patches. Look at docs.armbian.com for details on the options of the build system. For friendlyArm, they have their own GitHub I don't have the link to off the top of my head.
  21. Well, not knowing the exact pedigree of the board I have (donated) I haven't completely trusted all the things it does, so please report any and all "strange things", that will verify anything I may have seen, and I can make a list to work on in the spare time. The memory issue would obviously be of primary interest.
  22. These are WIP images, I haven't spent a lot of time debugging. I can take a closer look next year, as long as other issues don't take precedent.
  23. To be honest WiFi working was "magic", I didn't do anything to accomplish that, I'm assuming the Bluetooth is either DT entry missing/incorrect or firmware. For language settings I'm afraid I'm useless. I'm "out of office" until sometime during the first week of January, so I'm afraid I'll not be able to look into anything in the meantime.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines